IniRead does not read variables from the first section of a multi section ini file OR if the ini file contains only one section

[exwhyz]

IniRead is unable to read variables if the ini file contains only one section. Additionally even if the ini file has more than one section it is unable to extract values from the first section. Sections past the first one work fine. Here is the ini file and the script to reproduce the issue. I am on AutoIT version 3.3.16.0 

Ini File:

[S1]
A=1
[S2]
B=2

Script:

#include <WinAPIFiles.au3>

Local $sMFA = IniRead("my.ini", "S1", "A", "XXX")
ConsoleWrite("Section 1 always fails: " & $sMFA)

Local $sMFA = IniRead("my.ini", "S2", "B", "XXX")
ConsoleWrite(@CRLF & "Section 2+ works fine: " & $sMFA & @CRLF)

 

 

[taurus905]

It works as expected for me:

Section 1 always fails: 1
Section 2+ works fine: 2

What output are you getting?

[Subz]

Check the section name doesn't have any hidden characters, or create a new ini file from notepad and re-test.

[Musashi]

2 hours ago, exwhyz said:

IniRead is unable to read variables if the ini file contains only one section. Additionally even if the ini file has more than one section it is unable to extract values from the first section.

This happens, for example, if the .ini file was saved in an UTF-x format (character encoding) with BOM (Byte Order Mark).

The Byte Order Mark is placed (not always visible in all Text editors, but in a Hex-Editor) at the beginning of the file. If the first line of the ini.file is a section, e.g. [Section1], then the BOM will be inserted before [Section1]. As a consequence, IniRead no longer recognizes this line as a valid section and associated key/values will be ignored.

Just for information : BOM headers 
Hex : EF BB BF (Decimal : 239 187 191) -> UTF-8
Hex : FF FE (Decimal : 255 254) -> UTF-16 Little Endian
Hex : FE FF (Decimal : 254 255) -> UTF-16 Big Endian

Solution (as already suggested by @Subz ) :

Open the .ini file in e.g. Notepad++ and change the encoding to ANSI -> save it.

[TheSaint]

I have had an issue with the first section of an INI file on a few occasions. It has proved to be how the text file was created in the first place or updated not using INI functions. Using _FileCreate or _FileWriteToLine for instance can cause this issue. From what I recall it is a UTF8 and BOM issue ... some ANSI thing.

EDIT - IT would appear Musashi has the right of it in better detail than my explanation.  

Edited September 23, 2022 by TheSaint

[TheDcoder]

I'm surprised that this somewhat common issue doesn't have a mitigation built-into AutoIt by now, the INI parser can simply ignore any leading BOM character in the file, it's supposed to be ignored anyway.

Pinging @jpm so that I can get their opinion on this since they are the most active core dev AFAIK

[exwhyz]

Yes indeed it was the BOM that was the issue, requires an explicit ANSI format for it to work.

[TheDcoder]

7 hours ago, exwhyz said:

requires an explicit ANSI format for it to work.

That's not true, AutoIt can handle Unicode.

The INI parser in AutoIt just has trouble if there's a BOM.

[Musashi]

1 hour ago, TheDcoder said:

The INI parser in AutoIt just has trouble if there's a BOM.

@TheDcoder is right (as almost always ).

AFAIK IniRead based on the Windows function GetPrivateProfileString (A/W ?) from the Kernel32.dll and is capable of processing both ANSI and UNICODE. The problem with parsing an .ini file is just the Byte Order Mark at the beginning.

For example, if the first line is a comment, such as

; My ini file V 2.1.5
[Section1]
Key=value
...

then the [Section1] will be read without any problems, because the comment line starts with the BOM and will be ignored anyway.

In general, however, a Byte Order Marking is not a negative feature, as it allows the character encoding to be determined unambiguously. With ANSI and UTF-8, for example, this is not so easy.

 

Edited September 23, 2022 by Musashi
typo

[exwhyz]

I stand corrected, UTF-8 does works fine, it is the UTF-8 with BOM that pukes. Adding a comment as the first line for UTF-8 BOM bypasses the issue.

[TheDcoder]

Thanks @Musashi, but I'd like to mention one thing:

6 hours ago, Musashi said:

In general, however, a Byte Order Marking is not a negative feature, as it allows the character encoding to be determined unambiguously. With ANSI and UTF-8, for example, this is not so easy.

It can be a negative feature in some contexts, especially for UTF-8 is supposed to be backward compatible with ASCII but adding a BOM breaks that compatibility, and for this reason the Unicode standard neither recommends nor prohibits addition of the BOM. This section from the Wikipedia article for UTF-8 explains it very well:

Quote

The Unicode Standard neither requires nor recommends the use of the BOM for UTF-8, but warns that it may be encountered at the start of a file trans-coded from another encoding.^[30] While ASCII text encoded using UTF-8 is backward compatible with ASCII, this is not true when Unicode Standard recommendations are ignored and a BOM is added. A BOM can confuse software that isn't prepared for it but can otherwise accept UTF-8, e.g. programming languages that permit non-ASCII bytes in string literals but not at the start of the file.

 

[Musashi]

3 hours ago, TheDcoder said:

It can be a negative feature in some contexts, especially for UTF-8 is supposed to be backward compatible with ASCII but adding a BOM breaks that compatibility, and for this reason the Unicode standard neither recommends nor prohibits addition of the BOM. This section from the Wikipedia article for UTF-8 explains it very well:

I fully agree with you, that the Byte Order Mark can become a pitfall.

With my comment "In general, however, a Byte Order Marking is not a negative feature... " I only intended to avoid the impression, that BOM's are something "bad" at all. As we know from many posts, the whole topic is confusing enough already, especially for newcomers .