Hidden errors in .txt text files
Solved
lativ
-
lativ -
lativ -
Hello,
Configuration: Windows 7 / Chrome 51.0.2704.84
I am encountering a curious problem: I wrote a program myself (in Delphi) that processes text files to extract various information. Everything was working fine for several years, and suddenly it crashes. I examined my text file and managed to identify the line that caused the crash; by deleting it, the software worked again. Then I manually retyped the line that was causing the crash (carefully checking character by character), and now it doesn't crash anymore!
Any explanation for the mystery?
Configuration: Windows 7 / Chrome 51.0.2704.84
I am encountering a curious problem: I wrote a program myself (in Delphi) that processes text files to extract various information. Everything was working fine for several years, and suddenly it crashes. I examined my text file and managed to identify the line that caused the crash; by deleting it, the software worked again. Then I manually retyped the line that was causing the crash (carefully checking character by character), and now it doesn't crash anymore!
Any explanation for the mystery?
3 réponses
Without the erroneous file in question, it will be difficult to respond.
Perhaps a non-printable character, an encoding issue, a copy/paste error (faulty hard drive), it can come from many places.
If you encounter this error again, copy the defective file BEFORE correcting the error so that you can make a byte-by-byte comparison later.
Perhaps a non-printable character, an encoding issue, a copy/paste error (faulty hard drive), it can come from many places.
If you encounter this error again, copy the defective file BEFORE correcting the error so that you can make a byte-by-byte comparison later.
There is indeed a difference in encoding between the files:
(below, "error" is the file triggering the error and "clean" is the file without error):
When performing a binary diff:
We can see that the "clean" version uses "0D 0A" for a newline -> windows
While the "error" version uses only "0A", which resembles Unix format.
Were the files created on different machines? Or different text editors that each have their own method?
(below, "error" is the file triggering the error and "clean" is the file without error):
$file error
error: ISO-8859 text
$file clean
clean: Non-ISO extended-ASCII text, with CRLF line terminators
When performing a binary diff:
We can see that the "clean" version uses "0D 0A" for a newline -> windows
While the "error" version uses only "0A", which resembles Unix format.
Were the files created on different machines? Or different text editors that each have their own method?
Thank you for everything.
There are indeed a few differences at the beginning of the file, but they weren't what caused the error. At offset 1158h, there is a space before tab characters, so the line starts with a space, which my program doesn't like, as it is not robust enough. I have, of course, just corrected it.
But what is tricky is that if you put a space before a tab, Notepad shows no difference!
There are indeed a few differences at the beginning of the file, but they weren't what caused the error. At offset 1158h, there is a space before tab characters, so the line starts with a space, which my program doesn't like, as it is not robust enough. I have, of course, just corrected it.
But what is tricky is that if you put a space before a tab, Notepad shows no difference!
The corrected file is: http://vital.chauve.free.fr/calend.txt
The files differ starting from line 107, but it is not lines 107 and onwards that caused the error; it is lines 102 to 104.
The text file contains deadlines to be met (time in hh:mm format) or already met (time in hhhmm format), and the software's function is to send a warning if there are unmet deadlines within eight days. After the warning (if applicable), the software offers to open the text file in Notepad for updating.
Thank you for looking into my problem.
http://vital.chauve.free.fr/tmp/calendtmp.txt
and
http://vital.chauve.free.fr/tmp/calend.txt