home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / internat / 621 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  5.1 KB
  1. Path: sparky!uunet!ogicse!mintaka.lcs.mit.edu!ai-lab!wheat-chex!glenn
  2. From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: ISO 10646 the final character set?
  5. Message-ID: <26625@life.ai.mit.edu>
  6. Date: 15 Aug 92 03:50:22 GMT
  7. Article-I.D.: life.26625
  8. References: <BstGEq.7E7@immd4.informatik.uni-erlangen.de> <q++ygqb@rpi.edu>
  9. Sender: news@ai.mit.edu
  10. Organization: MIT Artificial Intelligence Laboratory
  11. Lines: 82
  12.  
  13. Even though John Jenkins and Erik Naggum have already responded to some
  14. recent second-hand statements about 10646, I think it is worth emphasizing a
  15. couple of points.
  16.  
  17. 1. 10646 is now an official ISO standard which defines a character
  18.    repertoire *aimed* at covering the written form of all languages.
  19.    [Some languages cannot be represented yet since the scripts used
  20.    to write them have yet to be incorporated into 10646; namely, the
  21.    writing systems based on the Burmese, Ethiopic, Khmer, Mongolian,
  22.    Sinhalese, and Tibetan scripts.  These are planned for a future
  23.    version along with other archaic and less-used scripts. ]
  24.  
  25. 2. 10646 defines two encodings for these characters:  a 32-bit canonical
  26.    form and a 16-bit Base Multilingual Plane (BMP).  The 16-bit form, also
  27.    called UCS2 (universal character set - 2 byte form), can be transformed
  28.    into the 32-bit form (UCS4) by zero extending the 16-bit value to 32 bits.
  29.  
  30. 3. No characters are currently defined outside of the BMP.  The BMP is
  31.    derived from Unicode 1.0 with some changes; Unicode 1.1 will be identical
  32.    to the BMP.  [In fact, Unicode 1.0, volume 2, which publishes the Han
  33.    character encodings, is already identical to the Han encodings in the BMP;
  34.    other changes required of Unicode 1.0, volume 1, in order to accomodate
  35.    the new 10646 are also documented in volume 2.]
  36.  
  37.    The first 256 encodings of both the USC2 and UCS4 forms are identical to
  38.    ISO8859-1 (of which ASCII constitutes the first 128 elements).
  39.  
  40. 4. Software should not interpret 10646 encoded data as a sequence of bytes
  41.    for the purpose of determining character values; only 16-bit and 32-bit
  42.    unsigned integral units should be used.  [Byte swapping may be necessary
  43.    to deal with mixed endian envrionments; 10646 does define a mechanism to
  44.    ensure that the correct endian order can be determined].
  45.  
  46. 5.  There are *no* holes in the encoding space of either UCS4 or UCS2 (BMP).
  47.     There *are* unassigned code points (bit values); but these may be assigned
  48.     in future versions of the standard.  [This differs from EUC, Shift Jis,
  49.     and other similar encoding techniques that *do* have holes in their
  50.     encoding spaces.]
  51.  
  52. 6.  The language of the text encoded with 10646 is not determined by 10646;
  53.     a higher level protocol such as an environment variable, an escape
  54.     sequence, or other out-of-band data must supply the language which is
  55.     being represented.
  56.  
  57. 7.  10646 does not allow creating new *characters* by using "combining
  58.     characters."  The semantics of combining characters is that their
  59.     visual form is intended to "combine" with the visual form of a base
  60.     character.  The combination so produced is not a "character" in the
  61.     sense of "a member of a character set."  However, an application or
  62.     user may choose to interpret the combination as a "letter" (i.e., a
  63.     unit of writing) in the context of their written language.
  64.  
  65. 8.  The issue of combining characters in 10646 is *very* different from
  66.     the issue of variable length encodings in ShiftJis, EUC Multibyte,
  67.     and other similar variable length encoding techniques.  In these cases,
  68.     one *cannot* interpret a sequence of bytes *as a character in a
  69.     character set* without scanning from the beginning of the string (or
  70.     by synchronizing to a character encoding boundary).  In contrast, with
  71.     10646, a program can randomly index (by 16-bit unit) any character
  72.     encoding (code element) in a string and be assured of finding a proper
  73.     character encoding; with Shift Jis, a random index (by byte), may land
  74.     one right in the middle of a character encoding and thus yield garbage.
  75.  
  76. 9.  Contrary to claims otherwise, 16-bits is adequate for representing all
  77.     of the world's languages if two principles are followed:  (1) unify
  78.     different uses of the same script and encode only once instance of
  79.     a given script; and (2) allow characters to combine in a visual sense
  80.     in order to produce more complex shapes or forms from simpler shapes or
  81.     forms.  Both of these principles are followed by Unicode (and 10646 BMP).
  82.     It is unlikely that the full 32-bit canonical forms will ever be needed
  83.     except for perhaps compatibility or efficiency reasons.  However, in
  84.     terms of actually representing all languages, 16-bits is quite adequate.
  85.  
  86.     [Personally, I will bet my Sparcstation that a number of major vendors,
  87.     including Apple and Microsoft, will never support the 32-bit form for
  88.     internal processing.  It simply isn't needed.]
  89.  
  90. Finally, I'd like to note that  an Implementers Workshop for Unicode &
  91. 10646 is being planned for early December in Frankfurt, Germany.  A formal
  92. announcement will be forthcoming.
  93.  
  94. Glenn Adams
  95.