This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/12814] New: ISO-2022-JP-2 conversion of U+20AC givesstrange result
- From: "glibcbugz at ghalkes dot nl" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sources dot redhat dot com
- Date: Fri, 27 May 2011 08:28:30 +0000
- Subject: [Bug localedata/12814] New: ISO-2022-JP-2 conversion of U+20AC givesstrange result
- Auto-submitted: auto-generated
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.