A1C2
MINUS SIGN
2212
817C
3F
A1DD
3F
FULLWIDTH HYPHEN-MINUS
FF0D
3F
817C
3F
A1DD
CENT SIGN
00A2
8191
3F
A1F1
3F
FULLWIDTH CENT SIGN
FFE0
3F
8191
3F
A1F1
POUND SIGN
00A3
8192
3F
A1F2
3F
FULLWIDTH POUND SIGN
FFE1
3F
8192
3F
A1F2
NOT SIGN
00AC
81CA
3F
A2CC
3F
FULLWIDTH NOT SIGN
FFE2
3F
81CA
3F
A2CC
Теперь рассмотрите эту часть таблицы:
ucs2
sjis
cp932
NOT SIGN
00AC
81CA
3F
FULLWIDTH NOT SIGN
FFE2
3F
81CA
Это означает, что MySQL преобразовывает NOT SIGN (Unicode U+00AC) в sjis 0x81CA и в cp932 3F (3F как раз и есть знак вопроса (?), то есть то, что всегда используется, когда преобразование не может выполняться.
10.11.5: Что я должен делать, если я хочу преобразовывать SJIS 81CA в cp932?
Имеются серьезные жалобы относительно этого: много людей предпочли бы свободное преобразование так, чтобы 81CA (NOT SIGN) в sjis становился 81CA (FULLWIDTH NOT SIGN) в cp932. Изменение для этого поведения планируется.
10.11.6: Как MySQL представляют знак Yen (Tе)?
Проблема возникает потому, что некоторые версии японских наборов символов (sjis и euc) обрабатывают 5C как reverse solidus ( он же backslash), а другие обрабатывают это как знак йены (Tе).
MySQL следует только за одной версией JIS (Japanese Industrial Standards). В MySQL
10.11.7: MySQL планирует делать отдельный набор символов, где 5C представляет знак йены?
Это одно из возможных решений для проблемы знака йены, однако, это не будет в MySQL 5.1 или 5.2.
10.11.8: Какие проблемы я должен знать при работе с корейскими
