This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: EUC-JP and the Yen sign


"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> As you've indicated, it should use the conversion 3.1.2 (c) when
> converting EUC-JP to Unicode; I agree. That, in turn, means there is
> a bug in glibc, which currently implements the procedure of 3.1.2 (b).

Ulrich Drepper mentioned that he's more concerned about what people
actually do than about what the standards say.  So here are some data
points about what existing software actually does.

From these data points it appears that, while the issue is clearly
controversial, a majority prefers 0x5C == backslash.  I haven't
surveyed Korean software, but I wouldn't be surprised if there were
similar results there.


The following implementations treat EUC-JP 0x5C as backslash:

   GNU Emacs*
   XFree86
   IBM
   Oracle
   Novell
   Sony
   tcs (Plan 9)*
   Concurrent Japan RTU 6.x   
   Nihon Pyramid DC/OSx


The following implementations treat EUC-JP 0x5C as a Yen sign:

   Hitachi
   HP
   Mitsubishi Electric FONTRUNNER


The following implementations support both methods:

   DEC
   Fujitsu
   NEC
   nkf (Network Kanji Filter)*
   Jcode <http://openlab.ring.gr.jp/Jcode/>*


The following implementations are inconsistent: they display 0x5C as a
Yen sign, but they translate it to a backslash (e.g. when converting
to and from UTF-8).

   Microsoft (Windows 3.1 and later)
   Sun Solaris*


* The starred items above are ones that I checked myself.
  The nonstarred items are from the table in
  <http://www.opengroup.or.jp/jvc/cde/euc-e.html>,
  or from earlier messages in this thread.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]