FULLWIDTH ""
FF3C
3F
815F
3F
A1C0
WAVE DASH
301C
8160
3F
A1C1
3F
FULLWIDTH TILDE
FF5E
3F
8160
3F
A1C1
DOUBLE VERTICAL LINE
2016
8161
3F
A1C2
3F
PARALLEL TO
2225
3F
8161
3F
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 (┬е)?
Проблема возникает потому, что некоторые версии японских наборов символов (sjis и euc) обрабатывают 5C как reverse solidus (\ он же backslash), а другие обрабатывают это как знак йены (┬е).
MySQL следует только за одной версией JIS (Japanese Industrial Standards). В MySQL 5C всегда обратный слэш (\).
10.11.7: MySQL планирует делать отдельный набор символов, где 5C представляет знак йены?
Это одно из возможных решений для проблемы знака йены, однако, это не будет в MySQL 5.1 или 5.2.
10.11.8: Какие проблемы я должен знать при работе с корейскими наборами символов в MySQL?
В теории, хотя есть несколько версий набора символов euckr (Extended Unix Code Korea), только одна проблема была отмечена.
Мы используем ASCII-вариант EUC-KR, в котором код 0x5c указывает REVERSE SOLIDUS, \ вместо KS-Roman-варианта EUC-KR, в котором код 0x5c определяет WON SIGN(тВй). Это означает, что Вы не можете преобразовывать Unicode U+20A9 в euckr:
mysql> SELECT CONVERT('тВй' USING euckr) AS euckr,
– > HEX(CONVERT('тВй' USING euckr)) AS hexeuckr;
+-------+----------+
| euckr | hexeuckr |
+-------+----------+
| ? | 3F |
+-------+----------+
1 row in set (0.00 sec)
Графическая корейская диаграмма MySQL здесь: http://d.udm.net/bar/~bar/charts/euckr_korean_ci.html.
10.11.9: Почему я получаю сообщения об ошибке "Data truncated"?
Для иллюстрации мы создадим таблицу с одним столбцом Unicode (ucs2) и другим Chinese (gb2312):
mysql> CREATE TABLE ch
– > (ucs2 CHAR(3) CHARACTER SET ucs2,
– > gb2312 CHAR(3) CHARACTER SET gb2312);
Query OK, 0 rows affected (0.05 sec)
Мы пробуем помещать редкий символ ц▒М в обоих столбцах:
mysql> INSERT INTO ch VALUES ('Aц▒МB','Aц▒МB');
Query OK, 1 row affected, 1 warning (0.00 sec)
Имеется предупреждение. Давайте посмотрим, что там случилось:
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------+
| Warning | 1265 | Data truncated for column 'gb2312' at row 1 |
+---------+------+---------------------------------------------+
1 row in set (0.00 sec)
Так что это предупреждение только относительно столбца gb2312.
mysql> SELECT ucs2, HEX(ucs2), gb2312, HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| Aц▒МB | 00416C4C0042 | A?B | 413F42 |
+-------+--------------+--------+-------------+
1 row in set (0.00 sec)
Имеются несколько вещей, которые надлежит понять здесь:
Факт, что это является предупреждением, а не ошибкой, характерным для MySQL. Мы предпочитаем пробовать сделать то, что можем, чтобы получить метод наилучшего приближения, чем отказываться.
Символ ц▒М не находится в наборе символов gb2312. Мы рассматривали эту проблему ранее.
По общему признанию сообщение вводит в заблуждение. В этом случае не было никакого усечения: а произошла тривиальная замена символа на вопросительный знак. Авторы уже имели недовольство относительно этого сообщения (см. Глюк #9337 ). Но пока они придумывают кое-что получше, имейте в виду что сообщение 2165 может означать ряд вещей.