Sorry, my bad, I mixed up \r and \n. Let me rephrase: 1. If we get sent a \n only, should we print EOL or \n? Since \n is not the canonical line ending in the RFC, we might not want to treat this as a line ending that we should convert into the local line ending. 2. if we get sent a \r\n, we should clearly print EOL 3. If we get sent a \r only, we currently print EOL. Given the argument above, is this correct?
/niklas On Thu, May 28, 2009 at 12:13 AM, David Latorre <dvl...@gmail.com> wrote: > 2009/5/27 Niklas Gustavsson <nik...@protocol7.com>: >> On Wed, May 27, 2009 at 3:07 PM, David Latorre <dvl...@gmail.com> 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 >> >
