home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1120 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  2.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!usc!sdd.hp.com!think.com!enterpoop.mit.edu!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: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Date: 9 Jan 1993 17:35:04 GMT
  6. Organization: MIT Artificial Intelligence Laboratory
  7. Lines: 42
  8. Message-ID: <1in2c8INNmbj@life.ai.mit.edu>
  9. References: <1993Jan7.033153.12133@fcom.cc.utah.edu> <1993Jan8.092754.6344@prl.dec.com> <1993Jan9.024546.26934@fcom.cc.utah.edu>
  10. NNTP-Posting-Host: wheat-chex.ai.mit.edu
  11. Keywords: Unicode ISO10646 CharacterEncoding
  12.  
  13. In article <1993Jan9.024546.26934@fcom.cc.utah.edu> you write:
  14. >[ First a clarification of something which is my fault because of my
  15. >  background in comm software:  I have been informed that the currently
  16. >  "blessed" correct terminlogy for what I have been calling "Runic
  17. >  encoding" is "Process code", "File code", or "Interchange code".  I'll
  18. >  try to call it "Interchange code" from now on (I feel the other terms
  19. >  imply applications, some of which I disagree with). ]
  20.  
  21. I should have been more clear.  A "process code" is a fixed-width encoding
  22. suitable for internal processing, e.g., ASCII, Unicode, 10646 UCS2, and
  23. 10646 UCS4, EUC wide char; a "file code" or "interchange code" is a
  24. potentially variable length encoding suitable for file storage (non memory
  25. mapped environments) or interchange, e.g., UTF1 and UTF2 (FSS-UTF),
  26. Shift JIS, EUC Multibyte.
  27.  
  28. [My objection to your use of the word "rune" was (1) you weren't clear
  29. about which of these encodings you were referring to, and (2) I hate
  30. cute terminology which is opaque when perfectly transparent terminology
  31. already exists.]
  32.  
  33. One should not in general use an interchange code (UTF1 or UTF2) for
  34. processing.  While one may use a process code for interchange, some
  35. communication channels may have difficulties with data transparency
  36. (e.g., Unicode and 10646 UCS[24] allow NULL bytes and ISO2022 C0/C1 control
  37. code bytes in any byte position of their "process codes").
  38.  
  39. I can't imagine why anyone in their right mind would want to use UTF[12]
  40. or any other ostensibe interchange code for processing, given the problems
  41. of variable length encodings.  However, that doesn't mean that unaware
  42. applications can't effectively use an interchange code internally, e.g.,
  43. 8-bit clean applications which interpret only the ASCII (ISO646) characters
  44. could use UTF2 (FSS-UTF) without difficulty.  But if one is to create
  45. an aware application which uses more than the ASCII subset, or if it is
  46. to memory map files, then use of a fixed-with process code (even for backing
  47. store) becomes much more sensible.
  48.  
  49. Glenn Adams
  50.  
  51.  
  52.  
  53.  
  54.  
  55.