freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
- Subject: Re: Ode to UTF-8 (fwd)
- Date: Tue, 3 Sep 2002 12:27:05 -0400
> From: Steve Langasek [mailto:vorlon AT netexpress.net]
> Sent: September 3, 2002 10:59 AM
>
> Further assertion: all national language character sets in current use
> on either Unix or Windows platforms are codepoint compatible
> with ASCII.
> With the exception of widechar encodings (UCS-2 and UCS-4),
> they are also byte-compatible with ASCII.
Support for your assertion.
http://turnbull.sk.tsukuba.ac.jp/Tools/I18N/LJ-I18N.html:
...the major standards for programming languages (e.g., ISO C), operating
systems (POSIX), user interfaces (the X Window system), and inter-system
communication (RFC 1123, MIME, and ISO 2022) all specify portable character
sets which are subsets of ASCII. Protocol keywords are defined to be strings
from the portable character set, and where an default initial encoding is
specified, it is US ASCII (or its superset, ISO-8859-1). (Note that in most
cases it is a character set that is specified; for example, in C and X
Windows, IBM mainframes must support a portable character set which is a
subset of ASCII, but those characters will be encoded in EBCDIC.)
The only exception is ISO 2022 which specifies neither a portable character
set nor ASCII as default, and even there the influence of ASCII is extremely
strong: the 256 possible bytes are divided into "left" (eighth bit zero) and
"right" (eighth bit one) halves of 128 code points each, and within each
half the first 32 code points (0x00--0x1F) are reserved for control
characters, while the remaining 96 may be printable characters. Further,
positions 0x20 and 0x7F have reserved interpretations as the SPC and DEL
characters respectively and may not be used for graphic characters, while
0xA0 and 0xFF are often left unused.
--jkl
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.
-
Re: Ode to UTF-8 (fwd),
James K. Lowden, 09/03/2002
- <Possible follow-up(s)>
- Re: Ode to UTF-8 (fwd), Steve Langasek, 09/03/2002
- Re: Ode to UTF-8 (fwd), Lowden, James K, 09/03/2002
Archive powered by MHonArc 2.6.24.