home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1119 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  6.8 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!allegra!alice!andrew
  2. From: andrew@alice.att.com (Andrew Hume)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
  6. Message-ID: <24579@alice.att.com>
  7. Date: 9 Jan 93 07:51:57 GMT
  8. Article-I.D.: alice.24579
  9. References: <id.EAHW.92A@ferranti.com> <1993Jan7.033153.12133@fcom.cc.utah.edu> <1993Jan9.024546.26934@fcom.cc.utah.edu>
  10. Organization: AT&T Bell Laboratories, Murray Hill NJ
  11. Lines: 119
  12.  
  13. In article <1993Jan9.024546.26934@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes:
  14. ~ In article <1993Jan8.092754.6344@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
  15. ~ >Using Plan 9 utf you know the maximum size in bytes that a Rune can
  16. ~ >be encoded into.  Fixed fields only have to be a multiple of this value,
  17. ~ >defined to be to be UTFmax.  So where's the problem?
  18. ~ 
  19. ~ [ First a clarification of something which is my fault because of my
  20. ~   background in comm software:  I have been informed that the currently
  21. ~   "blessed" correct terminlogy for what I have been calling "Runic
  22. ~   encoding" is "Process code", "File code", or "Interchange code".  I'll
  23. ~   try to call it "Interchange code" from now on (I feel the other terms
  24. ~   imply applications, some of which I disagree with). ]
  25. ~ 
  26. ~ A good question.  The answer is fourfold:
  27. ~ 
  28. ~ 1)    The field length is still not descriptive of the number of
  29. ~     characters a field may contain; you have only set a minimum
  30. ~     "maximum character count".  It is still possible to enter
  31. ~     in more characters in a non-maximally encoded character set
  32. ~     than this value, unless you adopt the abstraction of a
  33. ~     maximum character count seperate from the maximum necessary
  34. ~     storage length.  The maximum character count is what we
  35. ~     would normally think of as the displayed field length (ie:
  36. ~     what you see as the size of an input box).  If my field
  37. ~     length is 6 bytes times the maximum record length for 31
  38. ~     bits (as with UTF encoding), would I not be better off using
  39. ~     raw 32 bit encoding, yielding only 4 times the maximum
  40. ~     record length for the same data (or only 2 times for 16 bit
  41. ~     data)?
  42.  
  43.         what objective function are you maximising? frankly,
  44.     if i were doing fixed records, i would keep char/byte counts.
  45.     the reason to use UTF is precisely system-independence (see below).
  46.     if density is an issue (it rarely is for us), then i agree --
  47.     16bit encodings save you space for kanji.
  48.  
  49. ~ 2)    A database application with memory mapped I/O for both the
  50. ~     front and back ends can not keep a consistant coding for
  51. ~     data throughout the application.  If I memory map a UTF
  52. ~     file, conversion is required before searches.  This will
  53. ~     either have to be done at search time, or will have to be
  54. ~     done via non-UTF encoded cache buffers within each database
  55. ~     engine (there may be several for a single database).  This
  56. ~     is wasteful of user-space memory and requires additional
  57. ~     swapping of pages for the user-space cache implementation.
  58. ~     Further, UTF encoded data must be converted into some
  59. ~     native representation before it can be written to display
  60. ~     memory if memory mapped output is used.
  61.  
  62.         as it turns out, MANY (but not all) applications can
  63.     work quite well on the UTF-encoded text. mostly, apps search
  64.     for literal strings, and all that happens is that their length
  65.     increases a little. our experience in plan 9 is that relatively
  66.     few applications do enough that it is more efficient to convert
  67.     to Runes before processing.
  68.  
  69. ~ 3)    If UTF is used for internal encoding in the application,
  70. ~     (such as would be necessary for direct use of memory mapped
  71. ~     files), then you have a dilemma: the natural input mechanism
  72. ~     into such a system is also UTF encoded data.  This means that
  73. ~     either the device must directly supply UTF encoded data (a
  74. ~     problem, in that the reson the memory-mapped files are UTF in
  75. ~     user space is our reluctance to do translation to and from
  76. ~     UTF within the kernel), or each application must carry around
  77. ~     it's own raw-input-to-UTF-conversion code.  This enlareges the
  78. ~     size of the application.  Note that this conversion code is
  79. ~     not "already there" if the native processing mode for an
  80. ~     application is UTF, since other conversions would not take
  81. ~     place.
  82.  
  83.         ahhh, therein lies the nub! Plan 9 is UTF all the way
  84.     through. by and large, the problem with this approach for
  85.     unix systems should only be in the moral equivalent of teh tty driver.
  86.     once characters are entered, everything is just UTF. the OS
  87.     and libraries and compilers and ... all need to be recompiled
  88.     with care. this is not as bad as it seems but is a lot of fussing.
  89.     on the other hand, ascii systems are there already!
  90.  
  91. ~ 4)    Backward comatability with existing systems requires the ability
  92. ~     to crossmount using existing mechanisms (NFS, RFS, etc.).  How
  93. ~     can this be supported without kernel code, when the remote
  94. ~     system is ignorant of UTF deencoding?  With kernel code, what
  95. ~     is the purpose in using the UTF encoding as the native processing
  96. ~     mode in the application?
  97.  
  98.         well, if the existing remote systems are just ascii,
  99.     then you have no problem. by and large, everything just works
  100.     (if your system is 8-bit clean). if the remote systems are
  101.     (and remain) non-ascii, then you have problems. the purpose
  102.     (at least in plan 9) of teh kernel using UTF is that the entire
  103.     system uses UTF -- all text strings are 10646 chars UTf encoded into
  104.     a byte stream.
  105.  
  106. ~ There are workarounds to these, but they are much uglier than compact
  107. ~ storage processing, where storage is done in a locale-specific set if
  108. ~ possible.  This would also allow a business to convert relatively
  109. ~ painlessly by leveraging current investments in prior localization
  110. ~ technology.
  111.  
  112.     i'd be the first to admit the plan 9 approach has its
  113. difficulties. however, there is a nice coherence to the system
  114. that applies to everything it connects to. i am unimpressed with
  115. the alternative you suggest (although i admire the length and thoroughness
  116. you have shown in discussing it) because it seems to me like
  117. ``here is an island, there is an island, interchange is a bitch''.
  118. all interchange must be explicitly typed and converted on system
  119. boundaries. and i have no idea how you do that. you can't convert
  120. binaries, just text; but how do you tell the difference? and how
  121. do you recognise system boundaries? (for example, when i mount
  122. a remote system's files, i may be getting several systems' files;
  123. how doe sthe file server know which ones to convert and how?
  124. plan 9 is inherently very distributed and so we see
  125. the difficulties of teh island approach earlier or more clearly.
  126. on the other hand, i'd be the last person to advocate massive system
  127. upheavals just for the sake of using 10646. if you are willing to be
  128. an island, and for many systems it may be the practical choice, then
  129. all power to you.
  130.  
  131.         andrew
  132.