This is the mail archive of the libc-locales@sourceware.org mailing list for the GNU libc locales project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug localedata/12814] New: ISO-2022-JP-2 conversion of U+20AC givesstrange result


http://sourceware.org/bugzilla/show_bug.cgi?id=12814

           Summary: ISO-2022-JP-2 conversion of U+20AC gives strange
                    result
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: localedata
        AssignedTo: libc-locales@sources.redhat.com
        ReportedBy: glibcbugz@ghalkes.nl


When trying to convert U+20AC (EURO SIGN) to ISO-2022-JP I get the following
sequence of bytes: 1B 2E 46 1B 4E A4 1B 24 28 43 22 66 1B 28 42. This is not
correct. The correct sequence is either 1B 2E 46 1B 4E 24 (which is equal to
the first part of the returned sequence with the caveat that the last byte has
its high bit reset), or 1B 24 28 43 22 66 1B 28 42 (the second part of the
returned sequence).

The first sequence uses the ISO-8859-7 set to encode the Euro sign, while the
second sequence uses the KSC 5601 set. Either would be correct (although
strictly speaking neither is, because the officially mandated sets are the
versions before the Euro update).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


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