home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0004.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.4 KB  |  45 lines
  1. Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  2.  
  3. In article <16p6bmINNs1l@ftp.UU.NET>
  4.     mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) writes:
  5.  
  6. >How UCS-2 files have to be handeled under future OS versions (e.g. UNIX)
  7. >seems to be quite obvious:
  8. >
  9. >  - Every UCS-2 file begins with feff. If it begins with fffe, than library
  10. >    routines will activate a 'byte order swap mode' that corrects the
  11. >    data from an otherendian machine.
  12.  
  13. What?
  14.  
  15. How can 'cat' know the file being read is a text file?
  16.  
  17. Do you want to introduce an infamous "FILE TYPE" to UNIX?
  18.  
  19. >  - In this way, every UNIX tool (cc, cat, ...) can easily determine,
  20. >    how the file has to be interpreted, because everything starting
  21. >    with something else is considered to be an 8-bit Latin 1 encoded
  22. >    file (if it is interpreted as a 'text file' at all).
  23.  
  24. What if a 8-bit Latin 1 file begins with 0xfffe?
  25.  
  26. Code points 0xfe and 0xff represent valid Latin 1 characters.
  27.  
  28.     0xfe: LATIN SMALL LETTER THORN
  29.     0xff: LATIN SMALL LETTER Y WITH DIAERESIS
  30.  
  31. Can you still say "quite obvious"?
  32.  
  33. >But how may UCS-4 files be identified? Do they always begin with 0000feff
  34. >and are converted if they begin with fffe0000 or other permutations?
  35. >Does ISO 10646 say anything about this or will any future POSIX extension do?
  36.  
  37. It is one of the well known defects of ISO 10646, which the standardizing
  38. committee simply neglected.
  39.  
  40.                             Masataka Ohta
  41.  
  42.  
  43. Volume-Number: Volume 29, Number 5
  44.  
  45.