I have a String that contains lines of data. At the end of each line, there is a carriage return and line feed (0D and 0A), then and the End of the file, there is the same. I am trying to write that string out to a file, but when I write it to a file, the carriage return is removed from the file. How do I write out that string and keep the CR/LF formatting? Here is what I am doing now:
FileOutputStream out = new FileOutputStream(outputDirectory + File.separator + outputFileName); PrintWriter p = new PrintWriter(out); p.print(output); p.close();
Unfortunately Jan-Jeep's answer is not going to do it. Perhaps contrary to popular belief, PrintWriter does not change CRLFs into LFs or anything of the sort; it will add a platform-specific line terminator when you call println(), but it will never alter line endings within a String.
So the problem is likely with your preparation of the String "output". Can you show us where that comes from?
mmmh, my mistake. I read the post and guessed he was reading the lines (in a loop) and wanted to write each on a newline in a file.
but it will never alter line endings within a String.
<-- i knew that one. I assumed he ended up with a file that consisted of one line with all the output strung together, so that he was looking for a way to "add" a line seperator.
oops, too many assumptions i guess. [ October 27, 2006: Message edited by: Jan-Jaap van Nieuwkerk ]
posted 13 years ago
Thanks for the welcome. Unfortunately, I do not have any control over the "output" string. It is coming from another system with the CRLF�s embedded and I simply want to write that out into a text file.
I understand the sarcasm. I believe that the root of the problem is because the CRLF�s in the String object are not literal CR and LF�s. They are not escape characterslike this: \r or \n. I am running the IDE in debug and I can see the String Object before it is written out. Looking at the String it simply looks like they are spaces, but if I copy that String and place it in UltraEdit or TextPad, and look at it in Hex, those spaces are indeed 0D(HEX for carriage return) and 0A(HEX for line feed). Maybe I need to convert the String into something else so that when writing it out, Java sees those as literal \r and \n. I hope that clears it up a little.
The "\r" and "\n" sequences appear in source code only. In compiled code, they are just characters with values 10 and 13, as you know. There's only one way to represent them internally.
So anyway, what you're saying is that the String "output" does seem to contain CRLF sequences, and you've been trying to verify that with a debugger , which is great. The part about TextPad or UltraEdit is a little worrisome, though, as it's highly likely that on a Windows machine, these programs are going to insert the CRs if they're missing. But in the debugger, when you look at the Strings, do you see two spaces, or only one, at the end of each line? If you definitely see two, then good, they're there; but if you see only one, then they're not. A debugger is not going to lie and substitute those characters.
In any case: tell me what platform the program is running on, and how you examined the output file to determine that the CRs are missing?
You might try writing a very short test file, with content like "foo\r\nbar\r\n". (That's a Java string literal, of course, where the actual String will have real CR and LF characters.) Does the resulting file have size 10 bytes (as expected, for any common encoding), or something else? Looking at the file size gives you clues which are independent of the viewing program you use to look at the file. You may try other Strings as well, like "\r\n\r\n", "\r\r\r\r" or "\n\n\n\n". Each of those should be 4 bytes - are they?
"I'm not back." - Bill Harding, Twister
Roses are red, violets are blue. Some poems rhyme and some don't. And some poems are a tiny ad.
Devious Experiments for a Truly Passive Greenhouse!