Converting newline

[sevedaja]

hello

I¡¦ve recently started learning Java ( and programming in general ),
but it's not that easy.

1) According to System.getProperty("line.separator"); on windows
systems newline is represented by CR+LF. Then why, when reading from
standard input ( keyboard ) and pressing enter, the only character
read is CR ( \n ), but not also LF (¡¥\r¡¦):

InputStreamReader is = new InputStreamReader ( System.in );
int i1 = fr.read(); // after pressing enter, i1 equals 10
int i2 = fr.read(); // after pressing enter, i2 equals 10


2) As I understand it, when java writes ¡¥\n¡¦ to the output stream, it
doesn¡¦t translate this character into platform dependent newline
sequence ( CR + LF „³ ¡¥\n¡¦ + ¡¥\r¡¦ )? Same when writting ¡¥\r¡¦ to the
output stream.
So if we want to write to a certain type of file, then we must know
beforehand which character ( or sequence of characters ) represent
newline in this file, else text editor or word processor, used to
display this file, won¡¦t be able to display it correctly ( if nothing
else, the whole text will be on only one line )?

3)I assume each of word processors or text editors running on same
platform ( like windows ) can use different character sequences for
newline (notepad for example doesn¡¦t use CR+LF for newline, but
instead uses LF+CR)?
So if each program running on top of windows can use different
characters to represent newline, then why would Java programmer need
to know platform¡¦s native newline representation?

4)Are there any Java write()methods, that do convert ¡¥\n¡¦ ( or ¡¥\r¡¦ )
into platform dependent newline?


I hope you can help

thank you

 

[Arne Vajhøj]

1) According to System.getProperty("line.separator"); on windows
systems newline is represented by CR+LF. Then why, when reading from
standard input ( keyboard ) and pressing enter, the only character
read is CR ( \n ), but not also LF (‘\r’):

line separator is really a file thing and not a console thing.

InputStreamReader is = new InputStreamReader ( System.in );
int i1 = fr.read(); // after pressing enter, i1 equals 10
int i2 = fr.read(); // after pressing enter, i2 equals 10

I will recommend BufferedReader or Scanner for console input.

2) As I understand it, when java writes ‘\n’ to the output stream, it
doesn’t translate this character into platform dependent newline
sequence ( CR + LF 迳 ‘\n’ + ‘\r’ )? Same when writting ‘\r’ to the
output stream.
Yes.

So if we want to write to a certain type of file, then we must know
beforehand which character ( or sequence of characters ) represent
newline in this file, else text editor or word processor, used to
display this file, won’t be able to display it correctly ( if nothing
else, the whole text will be on only one line )?

If the app is using platform convention then
System.getProperty("line.separator") will work fine.

3)I assume each of word processors or text editors running on same
platform ( like windows ) can use different character sequences for
newline (notepad for example doesn’t use CR+LF for newline, but
instead uses LF+CR)?

Not correct. Notepad uses CR+LF.

So if each program running on top of windows can use different
characters to represent newline,

They should not.

then why would Java programmer need
to know platform’s native newline representation?

Java writes files for well behaved apps.

4)Are there any Java write()methods, that do convert ‘\n’ ( or ‘\r’ )
into platform dependent newline?

If you wrap the OutputStream in a PrintStream then you can use
println method and not worry about it.

Arne

 

[Roedy Green]

So if each program running on top of windows can use different
characters to represent newline, then why would Java programmer need
to know platform??s native newline representation?

You could do an experiment to see what happens when you read a file
with different nl conventions,
\r \n \r\n

With different system properties for the newline.

I suspect you may find everything works.

See http://mindprod.com/applet/fileio.html

to generate the code.

Please report back with your findings.

However when you create a NEW file, you have to choose the line ending
convention, either by accepting the default or by setting the system
property.

See http://mindprod.com/jgloss/properties.html

 

[Roland de Ruiter]

hello

I’ve recently started learning Java ( and programming in general ),
but it's not that easy.

1) According to System.getProperty("line.separator"); on windows
systems newline is represented by CR+LF. Then why, when reading from
standard input ( keyboard ) and pressing enter, the only character
read is CR ( \n ), but not also LF (‘\r’):

InputStreamReader is = new InputStreamReader ( System.in );
int i1 = fr.read(); // after pressing enter, i1 equals 10
int i2 = fr.read(); // after pressing enter, i2 equals 10
[Snip]

Contrary to your findings, on my Windows XP SP3 both CR an LF characters
do get read.

Using the following program

package test;
import java.io.InputStreamReader;
public class ReadingFromConsole {
public static void main(String[] args) throws Exception {
System.out.print("Type stuff (press Ctrl+C to quit): ");
InputStreamReader reader = new InputStreamReader(System.in);
int ch;
while ((ch = reader.read()) != -1) {
System.out.print(ch);
if (ch >= 32) {
System.out.print('\t');
System.out.print((char) ch);
}
System.out.println();
}
}
}

the output on the console (cmd.exe) is as follows:

C:\Documents and Settings\RuiterR\My Documents\Projects\Trials>java
-showversion -classpath bin test.ReadingFromConsole
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

Type stuff (press Ctrl+C to quit): foo bar baz
102 f
111 o
111 o
32
98 b
97 a
114 r
32
98 b
97 a
122 z
13
10

13
10

 

[sevedaja]

hello

You could do an experiment to see what happens when you read a
file with different nl conventions, \r \n \r\n

I suspect you may find everything works.

It doesn’t, if by works you mean that Java would be converting ‘\n’ or
‘\r’ to native newline:

a) The following writes to the file:

static void nlw() throws IOException{
FileOutputStream fs=new FileOutputStream( "D:/example");
OutputStreamWriter ow=new OutputStreamWriter(fs);
char c='\n';
char c1='\r';
String s ="A\r\nB\nC\rD";
ow.write(s, 0, s.length());
ow.flush();
ow.close();


Hex editor shows:
41 0D 0A 42 0A 43 0D 44

Thus, Java didn’t replace ‘\n’ with native newline sequence ( \r\n )

b) Next code reads back from the file:

static void nlr() throws IOException{

FileInputStream fi=new FileInputStream("D:/example");
InputStreamReader in=new InputStreamReader(fi);
int i=0;

while(i !=-1){
i=in.read();
if( i!=-1) System.out.println(i);
}

in.close();
}

And here is the output:

65 13 10 66 10 67 13 68


2)

However when you create a NEW file, you have to choose the line
ending convention, either by accepting the default or by setting
the system property.

I’m not sure what you are trying to say here. The following code
snippet creates a new file:

FileOutputStream fs=new FileOutputStream( "G:/example");
OutputStreamWriter ow=new OutputStreamWriter(fs);

but none of the constructors has any parameters for setting line
ending sequence. Besides, it is obvious from the code above, that
whatever the platform’s default setting is, Java doesn’t convert
‘\n’ (or ‘\r’) to it!


3)

the output on the console (cmd.exe) is as follows:
Type stuff (press Ctrl+C to quit): foo bar baz
102 f
111 o
111 o
32
98 b
97 a
114 r
32
98 b
97 a
122 z
13
10
13
10

I only got value 10 ( LF ), but not 13 ( CR ). I have Win2k, so maybe
that is the reason?!

4)

If the app is using platform convention then >System.getProperty("line.separator") will work fine.

Not if Java doesn’t automatically convert to native newline when
writing to a file residing on that platform.


with regards

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arne Vajhøj schreef:
| (e-mail address removed) wrote:
|> 1) According to System.getProperty("line.separator"); on windows
|> systems newline is represented by CR+LF. Then why, when
reading from
|> standard input ( keyboard ) and pressing enter, the only
character
|> read is CR ( \n ), but not also LF (‘\r’):
|
| line separator is really a file thing and not a console thing.

Hm, this gets me thinking: I use
System.getProperty("line.separator") in messages I show my users
with Swing’s JOptionDialog. Now that is a bit clumsy, and
since it isn’t read to a file, would simply using \n still
guarantee that it works as wanted on all platforms?

Example:

~ if (!welcome) {
~ JOptionPane
~ .showMessageDialog(
~ null,
~ "Welcome to MonaSearch."
~ + System.getProperty("line.separator") //$NON-NLS-1$
~ + "MonaSearch stores preprocessed treebanks and
information about your queries in a designated directory."
~ + System.getProperty("line.separator") //$NON-NLS-1$
~ + "Please choose a directory."
~ + System.getProperty("line.separator") //$NON-NLS-1$
~ + "Since you don’t have to care about it after
choosing it, it is suggested you make this directory hidden."
~ + System.getProperty("line.separator") //$NON-NLS-1$
~ + "If you decide not to use MonaSearch any
longer, you may remove this directory.",
~ "Welcome to MonaSearch!", JOptionPane.INFORMATION_MESSAGE);
~ this.getUserPrefs().putBoolean(this.getWelcomePrefKey(), true);
~ }

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFITQgie+7xMGD3itQRAqfDAJ4wouegRh0H0aGFTx3E2bb7lgUhywCfUHUt
54AtNt51aKMKzeTHuGgqtU8=
=s0Yx
-----END PGP SIGNATURE-----

 

[sevedaja]

Greetings

I apologize for not being able to reply sooner, but I wasn’t home for
the past few days. Anyways, I hope someone will still reply.

Nor should it, nor does it claim to. What is your point here?

The way to get platform independence is to use
System.getProperty( "line.separator" )

In what way do you use System.getProperty( "line.separator" ) to get
platform independence?
I suppose you can't somehow incorporate
System.getProperty( "line.separator" ) into existing write()methods
and thus change method's behaviour?

 

[sevedaja]

hello

Use it instead of hard-coding the end-of-line value to a particular character
sequence.


You build it in the simple way into the Strings that you write() or print().

final String sep = System.getProperty( "line.separator" );

String s = "A" + sep + "B" + sep + "C" + sep + "D";
ow.write(s, 0, s.length());

The whole point of methods is that you don't change their behavior, you change
their data. Methods encapsulate consistent behavior across disparate inputs.
The thought process should have worked like this:

"I am putting line-end character sequences into Strings. System.getProperty()
can yield the correct line-end character sequence in a cross-platform way. I
will retrieve that character sequence from that method, and use it wherever a
line-end character sequence is needed."

Not, "Geez, now I have to rewrite all my methods because they have different
Strings as arguments now."

So if my code first reads (via read() ) from a file and then writes
( via write() ) that to another file, then I should write some sort of
mechanism, which will, when a newline sequence is encountered ( '\n'
or '\r' or '\r\n' or ... ), replace it with
System.getProperty( "line.separator" )?

with regards

 

[Lew]

So if my code first reads (via read() ) from a file and then writes
( via write() ) that to another file, then I should write some sort of
mechanism, which will, when a newline sequence is encountered ( '\n'
or '\r' or '\r\n' or ... ), replace it  with
System.getProperty( "line.separator" )?

That depends.

Doesn't the input file follow the same convention as the platform?

 

[sevedaja]

That depends.

Doesn't the input file follow the same convention as the platform?

I'd imagine you can never be sure if that is always case, so just to
be on the safe side, I'd put such mechanism into my code.

Anyhow, thank you all for your kind help