How do I read in a text file line by line that uses Hex0D as a line terminator?
-
Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.
-
Franzk, with the solution suggested by Ivan it does no matter.
What you do is to read from the file one character at a time until you reach the end. For every character, you check if the value corresponds to what you consider the EOL, then the program close the text line and go ahead.
Indeed, using this method your EOL character can be everything you want: is the program that create lines based on the character that you decide. When the line is complete, I suppose that the source creating a line string set automatically the EOL with the right character. A similar approach is those used to manage linux-encoded text files with windows programs and vice-versa. -
[quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Why should it? No platform supported by Qt uses that control character. -
Why complicating a simple thing? There are tons of cases where a file is non standard. Reading character by character the problem does not exist.
Or not ?
-
It would be nice to be able to control it though. If you have to produce files that have to be processed by other tools, control is needed.
-
Andre, what does you means with "control"? To set a control like those explained above or what ?
-
[quote author="Alicemirror" date="1299694794"]Andre, what does you means with "control"? To set a control like those explained above or what ?[/quote]
I mean that I, as a programmer, can choose what QTextStream and QIODevice considder the line separator. Sure, you can output your data character by character, but I did not choose Qt to do everything by hand...
-
[quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Well, yeah.. That's the actual root of the problem :/
I've been reading too much Qt Labs Blog posts.. Sadly, it seems I'm becoming one of those qt-is-perfect-no-need-to-change-anything guys >.<
Jonathan, you should file a bug report http://bugreports.qt.nokia.com/
-
[quote author="Andre" date="1299694989"][quote author="Alicemirror" date="1299694794"]Andre, what does you means with "control"? To set a control like those explained above or what ?[/quote]
I mean that I, as a programmer, can choose what QTextStream and QIODevice considder the line separator. Sure, you can output your data character by character, but I did not choose Qt to do everything by hand...[/quote]
I agree with you. The best solution is indeed that.
QTextStream and QIODevice already have the subroutines to read a file up to some hardcoded characters. It would be wise to add some "control" on what these classes consider a EOL.Then, the same routine could be used to read any character-separated file.
-
[quote author="peppe" date="1299694316"][quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Why should it? No platform supported by Qt uses that control character. [/quote]Mac is no longer supported?
Even if it is true, \r is still a valid line ending and should therefore be supported, even if only by configuration.
-
[quote author="Franzk" date="1299695807"][quote author="peppe" date="1299694316"][quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Why should it? No platform supported by Qt uses that control character. [/quote]Mac is no longer supported?
Even if it is true, \r is still a valid line ending and should therefore be supported, even if only by configuration.[/quote]
Just to add to your arguement, a quote from wikipedia:
http://en.wikipedia.org/wiki/Newline :
"Systems based on ASCII or a compatible character set use either LF (Line feed, '\n', 0x0A, 10 in decimal) or CR (Carriage return, '\r', 0x0D, 13 in decimal) individually, or CR followed by LF (CR+LF, '\r\n', 0x0D 0x0A). " -
AH :)
Andre, you are right! As a matter of fact I focused the attention of all my answers thinking that there was a non standard line terminated file, while - silly, real! - \r is the old, famous carriage return...
-
As suggested, I've filed bug report QTBUG-18038.
-
[quote author="Franzk" date="1299695807"][quote author="peppe" date="1299694316"][quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Why should it? No platform supported by Qt uses that control character. [/quote]Mac is no longer supported?
Even if it is true, \r is still a valid line ending and should therefore be supported, even if only by configuration.[/quote]
Therefore I'm allowed to argue that ASCII 0x07 (BEL) is a valid line ending in my wonderful system, therefore QTextStream should support it? :)
Come on, stick to reality: if you need custom line endings handle the line splitting yourself. It's easy and always works.
(BTW: where do those files come from? Mac OS 9?)
Eventually, you can suggest an API extension to allow for custom line endings in QTextStream, and/or provide the implementation yourself (quite easy) and submit a merge request.
-
My code would have been much tidier if I could have specified the end of line character.
But to be general, it would have to be a string. Didn't some systems use "x0Ax0D"?
-
[quote author="Franzk" date="1299695807"][quote author="peppe" date="1299694316"][quote author="Franzk" date="1299693469"]Actually, the root of the problem is that Qt doesn't accept \r as a valid EOL.[/quote]
Why should it? No platform supported by Qt uses that control character. [/quote]Mac is no longer supported?
Even if it is true, \r is still a valid line ending and should therefore be supported, even if only by configuration.[/quote]
Mac OS 9 was never supported during Qt 3 nor Qt 4. Mac OS X uses Unix newlines ('\n').
-
[quote author="Jonathan" date="1299701652"]My code would have been much tidier if I could have specified the end of line character.
But to be general, it would have to be a string. Didn't some systems use "x0Ax0D"?
[/quote]Yes, f.i. Windows.
-
[quote author="peppe" date="1299701793"]
[quote author="Jonathan" date="1299701652"]My code would have been much tidier if I could have specified the end of line character.But to be general, it would have to be a string. Didn't some systems use "x0Ax0D"?
[/quote]Yes, f.i. Windows.[/quote]
That has always been \r\n, not \n\r as stated above.
-
[quote author="peppe" date="1299701466"]Therefore I'm allowed to argue that ASCII 0x07 (BEL) is a valid line ending in my wonderful system, therefore QTextStream should support it? :)[/quote]That might be taking it a bit far, but if you insist, I'm sure the implementer could take into account that you wish to view BEL as a EOL as well ;).
Edit: I just added a note to the issue referencing "the unicode standard on newlines":http://www.unicode.org/standard/reports/tr13/tr13-5.html.
-
Hi Franzk,
thank you for your note, but the Newline character I even known is NL, not NEL, or this is another definition that I don't know?
Qt full respect the Unicode specifications for this character? Because regardless from this specific case, the differences between the line termination in files became very important on Qt development environment that can work on different desktop platforms (Linux+Mac and Windows) where the sources the same are saved with different line-termination characters: if you try to open a source code created with QT-Linux under Windows (with notepad) it result unreadable, while Qt-Windows does the right interpretation.