In recent projects need to export files, in fact, export files is a very simple thing. But it was a strange question.
The first export to the file requires the use of bufferedwriter. The line break is through the Bw.newline () method, and the problem is above the newline () method.
Let's take a look at the newline () API:
newLine publicvoid newLine () throws IOException writes a line separator. The line separator string are defined by the system property Line.separator, and are not necessarily a single newline ( ' \ n ') character. Throws: -If an I/O error occurs
English itself should not be difficult, meaning: the NewLine method calls the system line break. And that is the root of the problem.
Line breaks for different systems:
Windows--\ r \ n
Linux--\ R
Mac--\ n
Our general development is developed under Windows, and the server is typically Linux.
If we use the newline function to wrap, in the native test, because it is the Windows environment, the line break is \ r \ n, open the file when the natural file is a newline, no problem.
When we deploy to the server, the server is the Linux environment, the newline read system line break is \ r, exported to a file, the file line break is \ r, when we download this file through the browser to Windows, then open the file will be there is no line-wrapping problem. Because the explanation for \ r under Windows is not a line break.
Therefore, when developing, we cannot use the newline method if we need to specify that the file should be wrapped in some places. You must specify a newline character manually: \ r \ n Because, according to the different system line-breaks listed above, if the end of the string is \ r \ n in three systems, viewing the file will be interpreted as a newline.
At this point, the problem analysis is complete.
Note: Reference link: http://blog.csdn.net/TroyLemon/article/details/47781817
The Java output file wraps through the Bufferedwriter.newline () method.