We Keep Coding

Java: PrintWriter and newlines in a string

My question is pretty straight forward, if I have a single long string with alot of "\n" newlines within it, i.e:
strings = "Hey\nThere\nFriend\n"
And use a PrintWriter in Java to do the following:
PrintWriter save = new PrintWriter("test.txt");
save.println(strings);
save.close();
Will the file I end up with be formatted with the \n? i.e the file will have:
Hey
There
Friend
Or will it have:
Hey\nThere\nFriend
If it's the latter, can someone guide me on how I might change my code (and understanding of how PrintWriter works) to create the former output?

In fact, \n will work but only for Unix based OS. Windows based OS use \r\n as separator.
You should avoid using specific OS line separator if you want to write a portable code.
Favor System.lineSeparator() to not be OS dependent.
Note also that PrintWriter provides println() to achieve a break line that is not OS dependent (even if it is not necessary useful for you use case)

You will get a text file containing a single text line Hey\nThere\nFriend\n followed by your operating system new-line sequence (inserted by println()).
The meaning of \n depends on the operating system and possibly the text editor. On Linux \n usually will be interpreted as new-line sequence but on Windows the new-line sequence is \r\n so most text editors (e.g. native Notepad) will display a single HeyThereFriend line.

On windows platform \n means char(13) +Char(10) you can use
String nl = Character.toString ((char) 13)+Character.toString ((char) 10);
String strings = "Hey"+nl+"There"+nl+"Friend"+nl;
System.out.print(strings);

Java code unexpectedly appending "&#13" to line endings

Our code is unexpectedly appending &#13 to the end of the lines created by the following routine:
public String getNotation(ClientMessage TransactionMessage) {
StringBuffer sb = new StringBuffer();
String lineSeparator = System.getProperty("line.separator");
String osName = System.getProperty("os.name").toLowerCase();
sb.append(getNotationTitle(TransactionMessage));
sb.append(lineSeparator);
sb.append(lineSeparator);
The "line.separator" seems to be getting translated to the string &#13 only when the code is run on a Windows Server 2008 box. It runs fine when we run the same on Windows 7 or UNIX.
Has any one encountered this issue, and if so is there any logical explanation and a solution to correct this?

HTTP (and other textual internet protocols) mandate the use of ASCII CR+LF for line break sequences - CR being the "carriage return" character (\r) and LF being the "line feed" character (\n).
This escape sequence - \r\n - is also the file separator used on Windows systems, and thus is what gets returned by your call to System.getProperty("line.separator") and then gets appended by your call to sb.append(lineSeparator) to the output string. This is happening both in your tests and when "the code is executed on the actual server" - in both instances (I presume), the code is being executed on your windows server, and thus the same string generated.
This sequence is not being translated to &#13, as you suggest. If it was, then your entire output would appear on a single line, with &#13 inserted where newlines are expected. However, it doesn't sound like that's the case - it sounds like you're getting the line breaks where you expect them but with an unexpected &#13 at the end of each line.
This makes sense when we recognize that a lone \n is sufficient to represent a line break in most programming languages and environments, and that 13 is the decimal representation of the carriage return character
I presume that your tests are displaying the strings generated in raw string form (perhaps simply by a call to println(sb.toString()), in which case the \r\n is being interpreted and displayed as you expect it to be.
I also presume that your TransactionMessage class is transmitting messages not as raw strings but rather as HTML, because &#13 would be the HTML entity code for the decimal representation of the carriage return character.
I can't tell you exactly why (at least without knowing more about your particular situation), but for some reason the LR character is being converted to its decimal representation, and your chosen method for displaying the resultant string on the client doesn't recognize that representation as a control character and therefore is displaying it as the literal &#13 immediately preceding the \n, which is being interpreted as an escape.
(unrelated side note: Since Java 7, you can use System.lineSeparator() in place of System.getProperty("line.separator"))

printf: Difference between \n and %n [duplicate]

I'm reading Effective Java and it uses %n for the newline character everywhere. I have used \n rather successfully for newline in Java programs.
Which is the 'correct' one? What's wrong with \n ? Why did Java change this C convention?

From a quick google:
There is also one specifier that doesn't correspond to an argument. It is "%n" which outputs a line break. A "\n" can also be used in some cases, but since "%n" always outputs the correct platform-specific line separator, it is portable across platforms whereas"\n" is not.
Please refer
https://docs.oracle.com/javase/tutorial/java/data/numberformat.html
Original source

%n is portable across platforms
\n is not.
See the formatting string syntax in the reference documentation:
'n' line separator The result is the
platform-specific line separator

While \n is the correct newline character for Unix-based systems, other systems may use different characters to represent the end of a line. In particular, Windows system use \r\n, and early MacOS systems used \r.
By using %n in your format string, you tell Java to use the value returned by System.getProperty("line.separator"), which is the line separator for the current system.

Warning:
If you're doing NETWORKING code, you might prefer the certainty of \n, as opposed to %n which may send different characters across the network, depending upon what platform it's running on.

"correct" depends on what exactly it is you are trying to do.
\n will always give you a "unix style" line ending.
\r\n will always give you a "dos style" line ending.
%n will give you the line ending for the platform you are running on
C handles this differently. You can choose to open a file in either "text" or "binary" mode. If you open the file in binary mode \n will give you a "unix style" line ending and "\r\n" will give you a "dos style" line ending. If you open the file in "text" mode on a dos/windows system then when you write \n the file handling code converts it to \r\n. So by opening a file in text mode and using \n you get the platform specific line ending.
I can see why the designers of java didn't want to replicate C's hacky ideas regarding "text" and "binary" file modes.

Notice these answers are only true when using System.out.printf() or System.out.format() or the Formatter object. If you use %n in System.out.println(), it will simply produce a %n, not a newline.

In java, \n always generate \u000A linefeed character. To get correct line separator for particular platform use %n.
So use \n when you are sure that you need \u000A linefeed character, for example in networking.
In all other situations use %n

%n format specifier is a line separator that's portable across operating systems. However, it cannot be used as an argument to System.out.print or System.out.println functions.
It is always recommended to use this new version of line separator above \n.

How to create a String with carriage returns?

For a JUnit test I need a String which consists of multiple lines. But all I get is a single lined String. I tried the following:
String str = ";;;;;;\n" +
"Name, number, address;;;;;;\n" +
"01.01.12-16.02.12;;;;;;\n" +
";;;;;;\n" +
";;;;;;";
I also tried \n\r instead of \n. System.getProperty("line.separator") doesn't work too. it produces a \n in String and no carriage return. So how can I solve that?

It depends on what you mean by "multiple lines". Different operating systems use different line separators.
In Java, \r is always carriage return, and \n is line feed. On Unix, just \n is enough for a newline, whereas many programs on Windows require \r\n. You can get at the platform default newline use System.getProperty("line.separator") or use String.format("%n") as mentioned in other answers.
But really, you need to know whether you're trying to produce OS-specific newlines - for example, if this is text which is going to be transmitted as part of a specific protocol, then you should see what that protocol deems to be a newline. For example, RFC 2822 defines a line separator of \r\n and this should be used even if you're running on Unix. So it's all about context.

The fastest way I know to generate a new-line character in Java is: String.format("%n")
Of course you can put whatever you want around the %n like:
String.format("line1%nline2")
Or even if you have a lot of lines:
String.format("%s%n%s%n%s%n%s", "line1", "line2", "line3", "line4")

Try \r\n where \r is carriage return. Also ensure that your output do not have new line, because debugger can show you special characters in form of \n, \r, \t etc.

Do this:
Step 1: Your String
String str = ";;;;;;\n" +
"Name, number, address;;;;;;\n" +
"01.01.12-16.02.12;;;;;;\n" +
";;;;;;\n" +
";;;;;;";
Step 2: Just replace all "\n" with "%n" the result looks like this
String str = ";;;;;;%n" +
"Name, number, address;;;;;;%n" +
"01.01.12-16.02.12;;;;;;%n" +
";;;;;;%n" +
";;;;;;";
Notice I've just put "%n" in place of "\n"
Step 3: Now simply call format()
str=String.format(str);
That's all you have to do.

Try append characters .append('\r').append('\n'); instead of String .append("\\r\\n");

Thanks for your answers. I missed that my data is stored in a List<String> which is passed to the tested method. The mistake was that I put the string into the first element of the ArrayList. That's why I thought the String consists of just one single line, because the debugger showed me only one entry.

String.split to split data lines doesn't work correctly

I use VB.NET to create data for my game (for Android, Java code), this is how it look like:
5;0000000100011100010000000;2;2
5;1000001100010000000000000;0,1;0,1
where each line is a level. In VB.NET, I create new line by vbNewLine constant (I think its ASCII code is 13) then use IO.File.WriteAllText to write it to the file.
In my game in Java, I use \n to split the levels:
String[] levelData = rawData.split("\n");
However, when processing throught the data, the levelData always has a "new line" after the end. For example, the levelData[0] is 5;00...2;2<new line>, which cause Integer.parseInt exception. Then I debug, and found this:
rawData.charAt(31) //It's a \r, not \n
So, I change the split line:
String[] levelData = rawData.split("\r");
But now, the levelData[1] will be <newline>5....
What exactly do I have to do to solve this problem? And please explain how "new line" work in Java String.

I suppose that vbNewLine constant put both "\r\n" at the end and hence one character is left while splitting. Try to split it by using both.

Most probably it is from the code you show in VB that is the problem.
I create new line by vbNewLine constant (I think its ASCII code is 13)
First verify this for certain, then look up what code 13 is! Here is a general ascii table.
code 13 is a carrige return and is represented in Java as \r
code 10 is line feed and is represented in Java as \n
A good tip would be to read up a little about NewLines, It's completely fu**ed up, Windows and Linux uses different ways of representing a new line.
CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC-DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS
LF: Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others.
CR: Commodore 8-bit machines, Acorn BBC, TRS-80, Apple II family, Mac OS up to version 9 and OS-9

Why don't you use Scanner to read your file and split for lines instead?
Scanner sc = new Scanner(new File("levels.text"));
while (sc.hasNextLine()) {
String nextLine = sc.nextLine();
if(nextLine.lenght() > 0) { // you could even use Java regexes to validate the format of every line
String[] levelElements = nextLine.split(";");
// ...
}
}

vbNewLine is platform dependant. on windows newline is comprissed of two characters \n and \r and not just \n