What is the correct way to write CRLF in every enviroment?
I am implementing HTTP client so line terminator must be CRLF in every enviroment.
i can write CR with '\r', but how about this line feed?!??
I have readed JVM specs, and i found following texts:
Because Unicode escapes are processed very early, it is not correct to write '\u000a' for a character literal whose value is linefeed (LF); the Unicode escape \u000a is transformed into an actual linefeed in translation step 1 (�3.3) and the linefeed becomes a LineTerminator in step 2 (�3.4)
(3.4) LineTerminator: the ASCII LF character, also known as "newline" the ASCII CR character, also known as "return" the ASCII CR character followed by the ASCII LF character
InputCharacter: UnicodeInputCharacter but not CR or LF
Lines are terminated by the ASCII characters CR, or LF, or CR LF. The two characters CR immediately followed by LF are counted as one line terminator, not two.
Joined: Dec 13, 2002
ok.. more.. what i mean that is "\r\n" CRLF in linux and windows and mac.. =)
For maximum portability, use System.getProperty("line.separator") to obtain the line separator as a String or use one of the io classes that provide such a thing like BufferedWriter.newLine() or PrintWriter.println()
Until we know it, we feel bad.
As I had an issue with SFTP/SCP transferred file from UNIX to Windows and found the simple resolution, I would like to share I learn.
Whatever the platform you are using, handling the file which was transferred by SFTP or SCP does not seem to be easy and simple - especially when the next process on Windows PC expects a simple text (DOS in this situation) file format. I tried to see the raw bytes of the records and insert the CR in front of each LF, because UNIX transferred file has LFLF if transferred via SFTP/SCP from UNIX. It did not work, and analyzing how it should work would take your time a lot.
The mistake started with InputStream read!
We should use the simplest file read scheme, FileReader->BufferredReader. This method will read in only the text part of the file with no control characters like CR or LF.
Now, the simplest file write scheme, FileWriter->BufferedWriter, can write only the record's text part. So, paired/coupled/followed BufferredWriter.newLine() is a critical part.
I know ordinary programmer should know this already, but a 20 year IT field player did not know this fact. Anyway, it's fun to know how to handle this.