1st file has 0d 0a line ending
2nd file has 0d
2nd file is treated as one long line
Settings: Treat both files as text, Ignore line ending styles, use view filter
Both files attached below
End of line styles ignored in v8.0
-
- New Member
- Posts: 1
- Joined: Sun Oct 20, 2019 7:45 pm
End of line styles ignored in v8.0
- Attachments
-
- payload-huge.7z
- (463 Bytes) Downloaded 938 times
-
- payload-huge1.7z
- (462 Bytes) Downloaded 808 times
Re: End of line styles ignored in v8.0
Nope. It has 0a, unix style.2nd file has 0d
Worse than this. I see only a long line of the usual placeholder for "unprintable" characters.2nd file is treated as one long line
This looks a lot like a bug.

N.B. EDP 10.
-
- Expert Member
- Posts: 114
- Joined: Sun May 02, 2010 12:00 pm
- Location: Edinburgh
Re: End of line styles ignored in v8.0
I don't see what you describe. The first file hassystemsplanet wrote: Sun Oct 20, 2019 7:55 pm 1st file has 0d 0a line ending
2nd file has 0d
2nd file is treated as one long line
Settings: Treat both files as text, Ignore line ending styles, use view filter
Both files attached below
0A at offsets +5F and +17D and +1BA - no adjacent chars are 0D
and
0D at offsets +CE and +DB and +E5 - no adjacent chars are 0A
So there are NO instances of 0D0A.
The second file has
0A at offsets +55 and +17C and +1B9 - no adjacent chars are 0D
and contains no 0D bytes at all.
I viewed the files using: https://mh-nexus.de/en/hxd/ albeit not the most
recent version - v1.7.7.0 - because that's what I last installed.
Ah. AH. Right - now I see it. YOU FORGOT TO SAY THAT THE .7z files should
be unpacked. I (and I expect MSpagni) looked directly at the contents of the
7z files themselves.
Re: End of line styles ignored in v8.0
No, Jeremy, I unpacked the archives.
It makes no sense to speak of text when it's packed: in that case it's binary.
It makes no sense to speak of text when it's packed: in that case it's binary.
Re: End of line styles ignored in v8.0
The issue here is that EDP treats the second file as Unicode.
Why? With missing BOMs, EDP uses the Windows API IsTextUnicode(), and this function sometimes gets confused. It is also used by Notepad, so if you open your file in Notepad, you will see the same result. Why the API is confused is hard to tell, it uses a number of heuristics to determine encodings.
You can force ANSI encoding by opening the File Open dialog (click on the Browse button next to the file path drop-down) and selecting ANSI in the Encoding combo. Once you do this, the files will be indeed identical.
Why? With missing BOMs, EDP uses the Windows API IsTextUnicode(), and this function sometimes gets confused. It is also used by Notepad, so if you open your file in Notepad, you will see the same result. Why the API is confused is hard to tell, it uses a number of heuristics to determine encodings.
You can force ANSI encoding by opening the File Open dialog (click on the Browse button next to the file path drop-down) and selecting ANSI in the Encoding combo. Once you do this, the files will be indeed identical.
psguru
PrestoSoft
PrestoSoft
Re: End of line styles ignored in v8.0
Understood.
Thanks.
Thanks.