The Java output file uses the BufferedWriter. newline () method to wrap the line,

The Java output file uses the BufferedWriter. newline () method to wrap the line,

Exporting files in recent projects is actually quite simple. But it encountered a strange problem.

BufferedWriter is required to export data to a file. The newline method uses the bw. newline () method. The problem lies in the newline () method.

Let's take a look at newline () api:

    newLine            public void newLine()                   throws IOException            Writes a line separator. The line separator string is defined by the system property line.separator, and is not necessarily a single newline ('\n') character.            Throws:          IOException - If an I/O error occurs  

The newLine method calls the system line break. This is the root of the problem.

 

Line breaks for different systems:

Windows --> \ r \ n

Linux --> \ r

Mac --> \ n

We generally develop programs in windows, while the servers are generally linux.

If we use the newline function to wrap a line, during the local test, the line feed is \ r \ n because it is a windows environment. When opening a file, the natural file is a line feed, no problem.

When we deploy it to the server, the server is a linux environment, newline reads the system line break \ r, exports it to the file, and the file line break is \ r, when we download this file to windows through a browser, there will be no line break when opening the file again. In windows, \ r is not interpreted as a line break.

Therefore, the newline method cannot be used if we need to specify a line break for a file in some places during development. You must manually specify the line break: \ r \ n because the system line break listed above is used. If the end of the string is \ r \ n in three systems, view the file, will be interpreted as a line feed.

Now, the problem analysis is complete.

 

Note: Reference link: http://blog.csdn.net/TroyLemon/article/details/47781817