Jump to content

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


Go to solution Solved by Musashi,

Recommended Posts

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)

 

 

Link to post
Share on other sites

It works as expected for me:

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

What output are you getting?

"Never mistake kindness for weakness."-- Author Unknown --"The highest point to which a weak but experienced mind can rise is detecting the weakness of better men."-- Georg Lichtenberg --Simple Obfuscator (Beta not needed.), Random names for Vars and Funcs

Link to post
Share on other sites
  • Solution
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.

Musashi-C64.png

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

Link to post
Share on other sites

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 by TheSaint

Make sure brain is in gear before opening mouth!
Remember, what is not said, can be just as important as what is said.

Spoiler

What is the Secret Key? Life is like a Donut

If I put effort into communication, I expect you to read properly & fully, or just not comment.
Ignoring those who try to divert conversation with irrelevancies.
If I'm intent on insulting you or being rude, I will be obvious, not ambiguous about it.
I'm only big and bad, to those who have an over-active imagination.

I may have the Artistic Liesense ;) to disagree with you. TheSaint's Toolbox (be advised many downloads are not working due to ISP screwup with my storage)

userbar.png

Link to post
Share on other sites

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 :)

EasyCodeIt - A cross-platform AutoIt implementation - Fund the development! (GitHub will double your donations for a limited time)

DcodingTheWeb Forum - Follow for updates and Join for discussion

Link to post
Share on other sites
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.

EasyCodeIt - A cross-platform AutoIt implementation - Fund the development! (GitHub will double your donations for a limited time)

DcodingTheWeb Forum - Follow for updates and Join for discussion

Link to post
Share on other sites
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 by Musashi
typo

Musashi-C64.png

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

Link to post
Share on other sites

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.

 

EasyCodeIt - A cross-platform AutoIt implementation - Fund the development! (GitHub will double your donations for a limited time)

DcodingTheWeb Forum - Follow for updates and Join for discussion

Link to post
Share on other sites
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 ;).

Musashi-C64.png

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...