WL#1820: Variant SJIS and UJIS Japanese Character Sets
Affects: Server-6.1
—
Status: Assigned
We want more Japanese character sets, to handle the variant encodings in different SJIS and UJIS versions. This affects yen sign, reverse solidus, overline, and tilde. Or, we're just trying to fix for 0x5c and 0x7e. There are several other cases where fullwidth makes a difference for mapping, so we'll try to handle them too.
The Yen+Tilde Character Sets
----------------------------
This requirement was originally added due to a
complaint from a customer whose name is visible
in the Progress notes for 2010-02-05.
We will not change the current behaviour of sjis.
Confirm and document that it is equal to:
x-sjis-jdk-1.1.7 our name = sjis
x-sjis-cp932 our name = cp932
Add these character sets
x-sjis-jisx0221-1995* our name = sjisjisx0221
x-sjis-unicode-0.9 our name = sjisunicode
We will not change the current behaviour of ujis.
Confirm and document that it is equal to:
x-eucjp-unicode-0.9 our name = ujis
x-eucjp-open-19970715-ms our name = eucjpms
Add these character sets
x-eucjp-open-19970715-0201 our name = eucjpopen0221
x-eucjp-open-19970715-ascii our name = eucjpopenascii
x-eucjp-jisx0221-1995 our name = eucjpjisx02211995
Where I have "our name =" I [Peter Gulutzan] am just guessing.
I originally suggested names like 'sjis_jisx0221' but Bar
[Alexander Barkov] would like us to avoid use of '_' in character
set names.
Oracle gets by with only a few extra "...YEN" and "...TILDE"
character sets:
(SJIS) JA16MACSJIS, JA16SJIS, JA16SJISTILDE, A16SJISYEN
(UJIS) JA16EUC, JA16EUCTILDE, JA16EUCYEN. Described in:
http://download-
west.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90236/appa.htm#956722
The Yen+Tilde character sets: Conversion Charts
-----------------------------------------------
The differences are apparently slight, according to some sources,
and these are the main variants. But the same sources don't appear
to mention all possible differences, for example cp932 and sjis
have a different kanji repertoire which isn't described here. So
some further complications might exist beyond what I describe here.
Here is an SJIS variation list from
http://www.y-adagio.com/public/standards/tr_xml_jpf/kaisetsu.htm
I added the IBM-943 column based on
http://www-950.ibm.com/software/globalization/icu/demo/converters?conv=ibm-943
but at this time am not proposing that we support IBM-943.
Code Point x-sjis-jdk1.1.7 x-sjis-unicode-0.9 x-sjis-jisx0221-1995
---------- --------------- ------------------ --------------------
0x5C U+005C(REVERSE SOLIDUS) U+00A5(YEN SIGN) U+00A5(YEN SIGN)
0x7E U+007E(TILDE) U+203E(OVERLINE) U+203E(OVERLINE)
0x815C U+2015(HORIZONTAL BAR) U+2015(HORIZONTAL BAR) U+2014(EM DASH)
0x815F U+005C(REVERSE SOLIDUS) U+005C(REVERSE SOLIDUS)U+005C(REVERSE SOLIDUS)
0x8160 U+301C(WAVE DASH) U+301C(WAVE DASH) U+301C(WAVE DASH)
0x8161 U+2016(DOUBLEVERTICAL) U+2016(DOUBLEVERTICAL) U+2016(DOUBLEVERTICAL)
0x817C U+2212(MINUS SIGN) U+2212(MINUS SIGN) U+2212(MINUS SIGN)
0x8191 U+00A2(CENT SIGN) U+00A2(CENT SIGN) U+00A2(CENT SIGN)
0x8192 U+00A3(POUND SIGN) U+00A3(POUND SIGN) U+00A3(POUND SIGN)
0x81CA U+00AC(NOT SIGN) U+00AC(NOT SIGN) U+00AC(NOT SIGN)
Code Point x-sjis-cp932 IBM 943
---------- ------------ -------
0x5c U+005C(REVERSE SOLIDUS) U+00A5(YEN SIGN)
0x7e U+007E(TILDE) U+203E(OVERLINE)
0x815C U+2015(HORIZONTAL BAR) U+2014(EM DASH)
0x815F U+FF3C(FULLWIDTH REVERSE SOLIDUS) U+FF3C(FULLWIDTH REVERSE SOLIDUS)
0x8160 U+FF5E(FULLWIDTH TILDE) U+301C(WAVE DASH)
0x8161 U+2225(PARALLEL TO) U+2016(DOUBLEVERTICAL)
0x817C U+FF0D(FULLWIDTH HYPHEN-MINUS) U+2212(MINUS SIGN)
0x8191 U+FFE0(FULLWIDTH CENT SIGN) U+FFE0(FULLWIDTH CENT SIGN)
0x8192 U+FFE1(FULLWIDTH POUND SIGN) U+FFE1(FULLWIDTH POUND SIGN)
0x81CA U+FFE2(FULLWIDTH NOT SIGN) U+FFE2(FULLWIDTH NOT SIGN)
And here supposedly is an Apple SJIS variant, unconfirmed, according to
http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
Code Point Mac OS
---------- ------
0x5c U+00A5(YEN SIGN)
0x7e U+007E(TILDE)
0x80 U+005C(REVERSE SOLIDUS) (!!)
0x815c U+2014(EM DASH)
0x815F U+FF3C(FULLWIDTH REVERSE SOLIDUS)
0x8160 U+301C(WAVE DASH)
0x8161 U+2016(DOUBLE VERTICAL)
0x817C U+2212(MINUS SIGN)
0x8191 U+00A2(CENT SIGN)
0x8192 U+00A3(POUND SIGN)
0x81CA U+00AC(NOT SIGN)
It shows what the value in the "Code Point" column converts to, in ucs2.
For example _sjis_jdk 0x81ca = _ucs2 0xac, _sjis_ibm943 = _ucs2 0xffe2.
MySQL's "sjis" fits x-sjis-jdk1.1.7.
A partial translation of the adagio table comments:
http://sources.redhat.com/ml/libc-alpha/2000-10/msg00190.html
Here is a UJIS variation list from
http://www.y-adagio.com/public/standards/tr_xml_jpf/kaisetsu.htm
Code Point x-eucjp-unicode-0.9 x-eucjp-jisx0221-1995
---------- -------------------
0x5C U+005C(REVERSE SOLIDUS) U+005C(REVERSE SOLIDUS)
0x7E U+007E(TILDE) U+007E(TILDE)
0xA1B1 U+FFE3(FULLWIDTH MACRON) U+FFE3(FULLWIDTH MACRON)
0xA1BD U+2015(HORIZONTAL BAR) U+2014(EM DASH)
0xA1C0 U+005C(REVERSE SOLIDUS) U+005C(REVERSE SOLIDUS)
0xA1C1 U+301C(WAVE DASH) U+301C(WAVE DASH)
0xA1C2 U+2016(DOUBLEVERTICAL) U+2016(DOUBLE)
0xA1DD U+2212(MINUS SIGN) U+2212(MINUS SIGN)
0xA1F1 U+00A2(CENT SIGN) U+00A2(CENT SIGN)
0xA1F2 U+00A3(POUND SIGN) U+00A3(POUND SIGN)
0xA1EF U+FFE5(FULLWIDTH YEN SIGN) U+FFE5(FULLWIDTH YEN SIGN)
0xA2CC U+00AC(NOT SIGN) U+00AC(NOT SIGN)
0x8FA2B7 U+007E(TILDE) U+007E(TILDE)
0x8FA2C3 U+00A6(BROKEN BAR) U+00A6(BROKEN BAR)
Code Point x-eucjp-open-19970715-ms x-eucjp- x-eucjp-
open- open-
19970715- 19970715-
ms ascii
---------- ------------------------ ---------- ---------
0x5C U+005C(REVERSE SOLIDUS) 00A5 5C
0x7E U+007E(TILDE) 203E 7E
0xA1B1 U+FFE3(FULLWIDTH MACRON) FFE3 203E
0xA1BD U+2015(HORIZONTAL BAR) 2014 2014
0xA1C0 U+FF3C(FULLWIDTH REVERSE SOLIDUS) 005C FF3C
0xA1C1 U+FF5E(FULLWIDTH TILDE) 301C 301C
0xA1C2 U+2225(PARALLEL TO) 2016 2016
0xA1DD U+FF0D(FULLWIDTH HYPHEN-MINUS) 2212 2212
0xA1F1 U+FFE0(FULLWIDTH CENT SIGN) 00A2 00A2
0xA1F2 U+FFE1(FULLWIDTH POUND SIGN) 00A3 00A3
0xA1EF U+FFE5(FULLWIDTH YEN SIGN) FFE5 00A5
0xA2CC U+FFE2(FULLWIDTH NOT SIGN) 00AC 00AC
0x8FA2B7 U+FF5E(FULLWIDTH TILDE) 007E FF5E
0x8FA2C3 U+FFE4(FULLWIDTH BROKEN BAR) 00A6 00A6
MySQL's "ujis" fits x-eucjp-unicode-0.9.
MySQL's "eucjpms" fits x-eucjp-open-19970715-ms.
The mm character sets
---------------------
This requirement was originally added due to a suggestion
from a Japanese user group represented by Shuichi Tamagawa.
Four more Japanese character sets:
sjismm same as sjis
eucjpmsmm same as eucjpms
ujismm same as ujis
cp932mm same as cp932
There will be no 'mm' equivalents for the new character sets
described in the previous section (sjisjisx0221 etc.). The
Japanese users' suggestion was only for current character sets.
The initials 'mm' stand for 'multiple mapping'.
Saying sjismm is "same as sjis" means the repertoire is
the same, the representation (code points) are the same,
the applicable ordering rules are the same. The only
difference is the way that conversions occur, that is,
when casting or converting to/from another character set such
as ucs2, the results may differ for 22 characters.
The mm character sets: Conversion Chart
---------------------------------------
In this conversion table, the ucs2 column is the
source, and the sjis/cp932/ujis/eucjpms/etc. columns
are the destination, that is, what the hexadecimal
result would be if we used convert(ucs2) or if we
assigned a ucs2 column containing the value to an
sjis/cp932/ujis/eucjpms column.
character name ucs2 sjis sjis cp93 cp93 ujis ujis eucj eucj
mm 2 mm mm pms pmsmm
---- ---- ---- ---- ---- ---- ---- ---- ---- ----
BROKEN BAR 00A6 3F 3F 3F FA55 8FA2C3 8FA2C3 3F 8FA2C3
FULLWIDTH BROKEN BAR FFE4 3F 3F FA55 FA55 3F 8FA2C3 8FA2C3 8FA2C3
YEN SIGN 00A5 3F 5C 3F 5C 20 5C 3F 5C
FULLWIDTH YEN SIGN FFE5 818F ? 818F ? A1EF A1EF 3F A1EF
TILDE 007E 7E 7E 7E 7E 7E 7E 7E 7E
OVERLINE 203E 3F 7E 3F 7E 20 7E 3F 7E
HORIZONTAL BAR 2015 815C 815C 815C 815C A1BD A1BD A1BD A1BD
EM DASH 2014 3F 815C 3F 815C 3F A1BD 3F A1BD
REVERSE SOLIDUS 005C 815F 5C 5C 5C 5C 5C 5C 5C
FULLWIDTH "" FF3C 3F 815F 815F 815F 3F A1C0 A1C0 A1C0
WAVE DASH 301C 8160 8160 3F 8160 A1C1 A1C1 3F A1C1
FULLWIDTH TILDE FF5E 3F 8160 8160 8160 3F A1C1 A1C1 A1C1
DOUBLE VERTICAL LINE 2016 8161 8161 3F 8161 A1C2 A1C2 3F A1C2
PARALLEL TO 2225 3F 8161 8161 8161 3F A1C2 A1C2 A1C2
MINUS SIGN 2212 817C 817C 3F 817E A1DD A1DD 3F A1DD
FULLWIDTH HYPHEN-MINUS FF0D 3F 817C 817C 817C 3F A1DD A1DD A1DD
CENT SIGN 00A2 8191 8191 3F 8191 A1F1 A1F1 3F A1F1
FULLWIDTH CENT SIGN FFE0 3F 8191 8191 8191 3F A1F1 A1F1 A1F1
POUND SIGN 00A3 8192 8192 3F 8192 A1F2 A1F2 3F A1F2
FULLWIDTH POUND SIGN FFE1 3F 8192 8192 8192 3F A1F2 A1F2 A1F2
NOT SIGN 00AC 81CA 81CA 3F 81CA A2CC A2CC 3F A2CC
FULLWIDTH NOT SIGN FFE2 3F 81CA 81CA 81CA 3F A2CC A2CC A2CC
(No special rules for U+FFE3 FULLWIDTH MACRON or U+2026 HORIZONTAL ELLIPSIS.)
For example, consider this extract from the above table:
ucs2 sjis sjis
curr mm
---- ---- ----
NOT SIGN 00AC 81CA 81CA
FULLWIDTH NOT SIGN FFE2 3F 81CA
It means "for NOT SIGN which is Unicode U+00AC,
MySQL converts to sjis code point 0x81CA and
that's the same thing that Shuichi Tamagawa wants
(no change), but for FULLWIDTH NOT SIGN which
is Unicode U+FFE2, MySQL converts to sjis code
point 0x3F which is question mark "?" and that
is different from Mr Tamagawa's patch, which would
convert to 0x81CA."
Looking for a pattern in the table, you'll see
that the frequent desire is to replace 0x3F
with the closest fullwidth coding (if
sjis/ujis), or the closest not-fullwidth coding
(if cp932/eucjpms). That's loose and that is
not the universal rule, therefore we keep the
old way (in sjis etc.) but allow a new way
(in sjismm etc.).
The Japanese group did not propose changes for
the reverse direction, i.e. with destination
= ucs2, except for "sjis" 0x815F and "ujis" 0xA1C0.
I [Peter Gulutzan] will propose here a rule which
is compatible with the "sjis 0x85F / ujis A1C0" request,
for all cases:
When two possibilities exist, take the bigger.
For example, using NOT SIGN again, we see that
_sjismm 0x81ca can be converted to either
_ucs2 0x00ac or _ucs2 0xffe2. Choose _ucs2 0xffe2
because it is bigger. And similarly, since
_sjismm 0x81ca can be converted to either
_ujis 0xa2cc or _ujis 0x3f, choose _ujis 0xa2cc
because it is bigger. (The exception, of course,
is that 0x3f always converts to 0x3f and 0x20
always converts to 0x20.)
This does not help round tripping. But
that's okay, round tripping won't work
anyway.
The chart also shows two slight errors in the
current character sets:
U+00A5 converts to _ujis 20 instead of 3F
U+203E converts to _ujis 20 instead of 3F
But we will not fix these errors.
Minor note: if MySQL had an mm for the eucjp-open "ascii"
variant, then it would convert U+203E to A1B1.
Collations
----------
Collations for the new character sets will
be the same as the current character sets.
It might prevent confusion if we had different
names, for example sjismm_japanese_ci not
sjis_japanese_ci. But in fact the differing
characters are in the same positions.
Does that mean that we can say
... WHERE _sjis 'a' = _sjismm 'a'?
Answer: NO. That's easy but special rules confuse.
Advice
------
The variant character sets will be little used, so
save space on table lookups, and say that converting
with these character sets will be a little slower.
JIS 2004
--------
Japanese Industrial Standard X 0213 came out in 2000 (JIS X 0213:2000)
and was revised in 2004 (JIS X 0213:2004). A Wikipedia introduction is:
http://en.wikipedia.org/wiki/JIS_X_0213
Both JIS X 0213:2000 and JIS X 0213:2004 added characters outside the
Unicode BMP, but MySQL added support for non-BMP characters due to WL#1213
"Implement 4-byte UTF8, UTF16 and UTF32". JIS X 0213:2004, often
called "JIS 2004" or "JIS2004", is important because Vista supports it.
"Mapping Tables between JIS X 0213 and Unicode" for SJIS + UJIS are here:
http://x0213.org/codetable/index.en.html
It includes:
* Mapping table between Shift_JIS-2004 and Unicode
* Mapping table between EUC-JIS-2004 and Unicode
* Mapping table between ISO-2022-JP-2004 and Unicode
* Mapping table between JIS X 0213:2004 7-bit code and Unicode
For each new character, these documents state which version of
JIS X 0213 and Unicode the character first appeared in.
So we have a clear specification.
The unsettled point is: should the new characters be added to the
existing SJIS and UJIS character sets, or should there be even
more character sets? Alexander Barkov and Peter Gulutzan discussed
this in May/June 2007
"Extending ujis wirth JIS X 0213 characters" (dev-public thread),
[ mysql intranet archive] /secure/mailarchive/mail.php?folder=5&mail=67744
References
----------
http://www.haible.de/bruno/charsets/conversion-tables/Japanese.html
http://www.opengroup.or.jp/jvc/cde/ucs-conv-e.html
http://www.opengroup.or.jp/jvc/cde/appendix-e.html
http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/
http://sources.redhat.com/ml/libc-alpha/2000-10/msg00190.html
http://x0213.org/codetable/index.en.html
http://www.debian.org/doc/manuals/intro-i18n/intro-i18n.txt
BUG#50934 hyphen is not mapped
A long series of emails about the mm suggestion is in thread
"RE: Feedback and Requests from Japanese users community"
(not in a public archive but available from Peter Gulutzan
or Alexander Barkov)
See also WL#2555 Standard Japanese collation support.
Copyright (c) 2000, 2025, Oracle Corporation and/or its affiliates. All rights reserved.