\r vs \n\r and related issues

A

Aaron Fude

Hi,

I'm a little confused by the \r \n\r differences between operating systems.
For example, does the output of println() depend on the operating system?
Also, what is a reliable way to use a StringTokenizer to break up input into
lines - what do you use as a delimiter?

Thanks,

Aaron
 
S

Sudsy

Aaron said:
Hi,

I'm a little confused by the \r \n\r differences between operating systems.
For example, does the output of println() depend on the operating system?
Also, what is a reliable way to use a StringTokenizer to break up input into
lines - what do you use as a delimiter?

From the javadocs (always a good place to start) for PrintWriter:

"The println() methods use the platform's own notion of line separator
rather than the newline character."

As to parsing input, that's why we have BufferedReader. From the
javadocs (again) we find the following text in the readLine method
description:

"A line is considered to be terminated by any one of a line feed ('\n'),
a carriage return ('\r'), or a carriage return followed immediately by
a linefeed."

IOW, you don't have to worry about it! I can even FTP a file from M$
to a *NIX box and read it with no problems.
 
F

Frank

I'm a little confused by the \r \n\r differences between operating
systems.
For example, does the output of println() depend on the operating system?

The answer here is technically yes. println() calls will write the current
platform's default line seperator to the output. Conceptually, this should
be relatively transparant to you though, as, regardless of the platform,
it will generate a new line. This does get a bit problematic though, when
the output is not necessarily displayed on the same machine that is
generating it :/
Also, what is a reliable way to use a StringTokenizer to break up input
into
lines - what do you use as a delimiter?

"\r\n" should work just fine as a delim for StringTokenizer. That way,
either single char will mark an EOL, and a doubled instance should get
ignored.

Hope this helps!

Frank
 
T

Tony Morris

Aaron Fude said:
Hi,

I'm a little confused by the \r \n\r differences between operating systems.
For example, does the output of println() depend on the operating system?
Also, what is a reliable way to use a StringTokenizer to break up input into
lines - what do you use as a delimiter?

Thanks,

Aaron

http://www.xdweb.net/~dibblego/java/faq/answers.html#q44

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
 
T

Tony Morris

I was wonderring at the time why
you do not mention ..
System.getProperty("line.separator")
.. in that entry.

I'm not sure if either a) I do not understand your question or b) you
overlooked that I did in fact mention the "line.separator" system property:
<quote>
You can obtain the EOL terminator by accessing the System property called
"line.separator".
</quote>
Am I missing something in your question?

The sharp eye will have noticed that I quoted the hexadecimal values for \r
and \n incorrectly - this is pending on my "to do list" to fix.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
Home : +61 7 5502 7987
Work : +61 7 5552 4076
Mobile : 0408 711 099
(2003 VTR1000F)
 
A

Andrew Thompson

Am I missing something in your question?

No. I was missing something in your answer. ;-)
The sharp eye will have noticed that I quoted the hexadecimal values for \r
and \n incorrectly - this is pending on my "to do list" to fix.

This 'sharp eye' did not even
pick up the reference to
System.getProperty("line.separator")
...and your talkin' hex??
 
P

Peter Kirk

Roedy Green said:
no. A0 is often used an non-breaking space. that should read 0x0a.

Yes, I did not have sharp enough eyes to see that it was already identified
elsewhere under this thread as a mistake on the website.
 
M

Malcolm Dew-Jones

Sudsy ([email protected]) wrote:

: As to parsing input, that's why we have BufferedReader. From the
: javadocs (again) we find the following text in the readLine method
: description:

: "A line is considered to be terminated by any one of a line feed ('\n'),
: a carriage return ('\r'), or a carriage return followed immediately by
: a linefeed."

Wow, that sounds ugly. Typically a file uses one or the other or both
together, but not normally both individually. A file that uses \n as the
separator might have \r's and in that case they normally aren't
separators, and vice versa for files using \r's to end the lines, any \n's
are not normally line separators.

However, I suppose it is an easily consistent way to handle the situation.
 
T

Tony Morris

"\r\n" (0x00D0 0x00A0);
Yes, I did not have sharp enough eyes to see that it was already identified
elsewhere under this thread as a mistake on the website.

Apologies for the confusion.
I will fix it first thing when I get back to work next week.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top