View Single Post
  #11  
Old June 16th 18, 12:04 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Reading an .ini file with Notepad using Windows 10

malone wrote:
On 16-Jun-2018 5:00 pm, Nil wrote:
On 15 Jun 2018, Monty wrote in
alt.comp.os.windows-10:

In regard to your query, I have the same software on my PC and I
can open i_view.ini in Notepad without any problem.

I've opened that INI file on several different computers and with
several different text editors/viewers and nothing acts out of the
ordinary. Irfanview does caution you, via a comment in the file, that
the INI file is Unicode encoded, but otherwise it's straight text, no
binary information in there. I'd say there's something peculiar about
his system, that it's not a general Windows 10 issue.


Yes. I think you're right.

Since my original post I've found another Windows 10 computer with
Irfanview and the .ini file on that reads perfectly ok. I've also used
several other text readers with consistent results so it's nothing to do
with Notepad.

Thanks everyone for all the other helpful information. It's really
useful as I'll need to try to work out why this particular Windows 10
computer exhibits this strange behaviour.


I still think you should pick up a free hex editor.

https://mh-nexus.de/en/hxd/

It will give you a chance to see what is really inside
that file. And you won't even need to scroll the display,
as the "interesting bit" of that file is at the very
beginning.

What you want to observe, is whether the file has
a BOM at the beginning, and whether the BOM is
a well known one. This amounts to only a few bytes
of hex, which you can Google with the word "BOM".
You may be able to decode the "intentions" of what
was done that way.

The bytes that come after that, might be single
characters next to one another. If every second
byte is 0x00, then that suggests 16-bit character
representations (which Windows likes because it
supports foreign languages). Even the registry
contents, when you see what looks like a "binary"
string, in fact it's just 16-bit text in disguise.

Using the hex editor, you can learn more about
your prey.

The system locale or language choice, might make
a difference if the BOM was missing, and some
editor was trying to "guess" what to do, by
using the current locale declaration to try
to make the file viewable. That's about the
only other idea I can think of. I'm not
really good with this locale/internationalization
stuff.

Paul
Ads