MySQL: руководство профессионала
Шрифт:
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 может означать ряд вещей.
С SQL_MODE=TRADITIONAL имелось бы сообщение об ошибке, но вместо ошибки 2165 Вы будете видеть: ERROR 1406 (22001): Data too long for column 'gb2312' at row 1.
10.11.10: Почему мой внешний GUI-интерфейс или окно просмотра не отображает символы CJK правильно в моей прикладной программе, использующей Access, PHP или другой API?
Получите прямое подключение к серверу, применяя клиент mysql (в Windows: mysql.exe), и попытайтесь выполнить тот же самый запрос там. Если mysql отвечает правильно, то проблема может быть в том, что Ваш интерфейс прикладной программы требует инициализации. Используйте mysql, чтобы понять, какой набор символов это использует с помощью инструкции SHOW VARIABLES LIKE 'char%';. Если Вы используете Access, то Вы наиболее вероятно соединяетесь с MyODBC. В этом случае Вы должны проверить конфигурацию ODBC. Если, например, Вы используете big5, Вы ввели бы SET NAMES 'big5'. Обратите внимание, что ; не требуется в этом случае. Если Вы используете ASP, Вы могли бы добавить SET NAMES в код. Имеется пример, который работал в прошлом:
<%
Session.CodePage=0
Dim strConnection
Dim Conn
strConnection="driver={MySQL ODBC 3.51 Driver}; \
server=server;uid=username;" \
"pwd=password; \
database=database; \
stmt=SET NAMES 'big5';"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open strConnection
%>
Аналогичным способом, если Вы используете любой набор символов, другой, чем latin1 с Connector/NET, Вы должны определить набор символов в строке подключения. Если Вы используете PHP, опробуйте это: