2009/5/27 Niklas Gustavsson <[email protected]>: > On Wed, May 27, 2009 at 3:07 PM, David Latorre <[email protected]> wrote: >> I added a fix and some tests but ToNetASCIIOutputStream in >> commons-util will always replace to \r\n so I'm uploading a modified >> version. With this fix ascii mode should not eat line separators >> anymore. > > Thanks! Looking into the fix I'm not sure we should print EOL on \r. > Since \r is not the canonical line ending in the RFC, I think we > should rather print \r as it is in the stream. What do you think?
I don't really know if \r has other users than being part of the New Line sequence. I guess \r could take us back to the beginning of the line ... but it doesn't make much sense in a file. My reasons to leave \r as the character substituted by EOL are 1) Because it was previously written in that way. 2) Mac OS 9 and before had \r as the new line separator, so if the line endings of a Mac OS 9 text file weren't transformed to \r\n and we were ignoring \r , we would swallow the new line again. On the other hand, if we write the \r character, we cannot transform to Unix line endings which have no \r... So, I'm sure there are other options and they might be more performant, but this solution seems to work in several situations which are usually not supported and the code is fairly easy to understand ... Of course, for me , the best solution is to entirely remove the ASCII mode from the RFC :-D > > /niklas >
