Code in ASCII UTF8??

[chunhui_true]

I know in ASCII '\r' is 0x0d,'\n' is 0x0a.
But some say ASCII characters in UTF8 is unchanged.
Now I want to know in UTF8 '\r' and '\n' are already 0x0d and 0x0a??
Could anybody can tell me? Very Thanks!!!!

[Peter Nilsson]

Clark S. Cox III wrote:

Lawrence Kirby <lk****@netacti ve.co.uk> said:

On Thu, 17 Feb 2005 00:38:52 -0800, chunhui_true wrote:

I know in ASCII '\r' is 0x0d,'\n' is 0x0a.

Wasn't that the other way around on Macs?

No, the actual values of '\r' and '\n' are unchanged on the Mac.

Depends on the development tool and compiler settings.

Generally, most old mac implementations used the normal form, but at
least two offer(ed) the option of setting \r to 10 and \n to 13.

--
Peter

[Lawrence Kirby]

On Thu, 17 Feb 2005 13:59:00 -0800, Peter Nilsson wrote:

....

Metrowerks 3.0, Mac IIvx, swap \n and \r enabled...

\r = 10
\n = 13

The compiler option allows mac implementations to avoid having
to perform runtime translations of text file end-of-lines.

So it is dangerous to assume that '\n' is 10 and '\r' is
13 even on an ASCII based system.

Lawrence

[SM Ryan]

"chunhui_tr ue" <ch*********@gm ail.com> wrote:
# Does ASCII characters remain unchanged under UTF8????Since it
# unchanged,Why I can't printf thme in screen?
# I use libcap get the FTP commands from Ethernet.I have one class to

You're going to have to deal with the sources or authours for your software.

When your printing characters, the software is interpretting a subsequence of
bits as an index to a raster pattern or font character, and then painting that
on the screen or printer. Everybody has to agree where character divisions are
in the bit stream and how character codes are encoded. Or chaos ensues.

If you've got non-ASCII unicode characters in your UTF-8 stream, they will
show up as one or more non-ASCII characters. How the software deals with non-ASCII
characters depends on the software. It might mask off the high bit; it might
discard them; it might treat them similar to letters and digits. The software
might assume some other encoding like macintosh or windows and interpret
the non-ASCII codes as different characters then you wanted it to.

The same sort of confusion happened when 8-bit characters ousted 6-bit, but
at least then it was in smaller community.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Mention something out of a Charleton Heston movie, and suddenly
everybody's a theology scholar.

[osmium]

"Lawrence Kirby" writes:

On Thu, 17 Feb 2005 13:59:00 -0800, Peter Nilsson wrote:

...

Metrowerks 3.0, Mac IIvx, swap \n and \r enabled...

\r = 10
\n = 13

The compiler option allows mac implementations to avoid having
to perform runtime translations of text file end-of-lines.

So it is dangerous to assume that '\n' is 10 and '\r' is
13 even on an ASCII based system.

I don't agree with that. K&R, p 193, says carriage return is \r. In ASCII,
carriage return is 13. So a platform that says \r = 10 is simply not ASCII.

I haven't been following this thread so it may be that what you *mean* is
true, but the literal meaning of the your post is simply wrong as I see it.
I think the thing actually being discussed has to do how various platforms
handle the \n problem in a non \n world, i.e., ASCII as originally
promulgated. And I agree that assumptions WRT \r and \n and what they
*do* are dangerous.

[Michael Mair]

osmium wrote:

"Lawrence Kirby" writes:

On Thu, 17 Feb 2005 13:59:00 -0800, Peter Nilsson wrote:

...

Metrowerks 3.0, Mac IIvx, swap \n and \r enabled...

\r = 10
\n = 13

The compiler option allows mac implementations to avoid having
to perform runtime translations of text file end-of-lines.
So it is dangerous to assume that '\n' is 10 and '\r' is
13 even on an ASCII based system.

I don't agree with that. K&R, p 193, says carriage return is \r. In ASCII,
carriage return is 13. So a platform that says \r = 10 is simply not ASCII.

Please, make that '\r' and '\n' vs <CR> and <LF>. C does not care about
the character encoding it works with. If there is a "non-ASCII" platform
which has a different binary representation (maybe including multiple
bytes) of such an escape sequence, '\r' and '\n' still are carriage
return and newline, respectively.
If I use your reasoning then only Unix text files are ASCII files
because only they use <LF> as newline encoding.

BTW: The only thing _I_ rely on if hearing ASCII is that
0x20 through 0x7F will represent the printable characters I am used to.
Cheers
Michael I haven't been following this thread so it may be that what you *mean* is
true, but the literal meaning of the your post is simply wrong as I see it.
I think the thing actually being discussed has to do how various platforms
handle the \n problem in a non \n world, i.e., ASCII as originally
promulgated. And I agree that assumptions WRT \r and \n and what they
*do* are dangerous.

--
E-Mail: Mine is a gmx dot de address.

[Lew Pitcher]

Michael Mair wrote:
[snip]

BTW: The only thing _I_ rely on if hearing ASCII is that
0x20 through 0x7F will represent the printable characters I am used to.

ITYM 0x20 through 0x7E will represent the printable characters you are
used to. ASCII 0x7F is a 'control character', the 'DEL' (delete) control
character to be precise.

But, IKWYM

--

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFCFgyfagV FX4UWr64RAoLIAJ 9guTivNQ+5Y6utz 8q0SdY9fKB06wCg kYId
4OtpbKa3WU/PnsqiXGvhwtU=
=5XQX
-----END PGP SIGNATURE-----

[Michael Mair]

Lew Pitcher wrote:

Michael Mair wrote:
[snip]

BTW: The only thing _I_ rely on if hearing ASCII is that
0x20 through 0x7F will represent the printable characters I am used to.

ITYM 0x20 through 0x7E will represent the printable characters you are
used to. ASCII 0x7F is a 'control character', the 'DEL' (delete) control
character to be precise.

Yes, that is what I meant... Thanks for the correction.

But, IKWYM

:-)
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.