mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
8 rows in set (0.03 sec)
Это типичные параметры настройки набора символов для международно-ориентируемого пользователя (обратите внимание на использование utf8 Unicode), связанного с сервером на западе (latin1 является набором символов западной Европы и значением по умолчанию для MySQL).
Хотя Unicode (обычно вариант utf8 на Unix и ucs2 в Windows) предпочтителен для Latin, это часто не то, что Ваши утилиты операционной системы поддерживают лучше всего. Много пользователей Windows находят, что набор символов Microsoft, типа cp932 для Japanese Windows, подходит им лучше.
Если Вы не можете управлять параметрами настройки сервера, и Вы понятия не имеете, каков Ваш основной компьютер, то пробуйте изменить набор символов на общий для страны, в которой Вы находитесь (euckr = Korea; gb2312 или gbk = People's Republic of China; big5 = Taiwan; sjis, ujis, cp932 или eucjpms = Japan; ucs2 or utf8 = где угодно). Обычно необходимо изменить только параметры настройки пользователя, результатов и подключение. Имеется простая инструкция, которая изменяется все три сразу: SET NAMES. Например:
SET NAMES 'big5';
Если только установка правильна, Вы можете делать это постоянным, редактируя my.cnf или my.ini. Например Вы могли бы добавлять строки, походящие на эти:
[mysqld]
character-set-server=big5
[client]
default-character-set=big5
Также возможно, что имеются проблемы с установкой конфигурации API, используемой в вашей прикладной программе.
10.11.2: Какие китайские (GB) наборы символов понимает MySQL?
MySQL поддерживает два общих варианта GB GB ( Guojia Biaozhun или национального эталона) набора символов, которые являются официальными в КНР: gb2312 и gbk. Иногда люди пробуют вставлять символы gbk в gb2312, и это работает в большинстве случаев, потому что gbk является надмножеством gb2312, но в конечном счете они пробуют вставлять старые китайские символы, и это не работает (см. Глюк #16072).
Здесь мы пробуем разъяснять точно, какие символы являются законными в gb2312 или gbk в отношении официальных документов. Пожалуйста, проверьте эти ссылки перед сообщением об ошибках в gb2312 или gbk.
Для полной распечатки символов gb2312, упорядоченных согласно объединению gb2312_chinese_ci: http://d.udm.net/bar/~bar/charts/gb2312_chinese_ci.html.
MySQL gbk в действительности Microsoft code page 936. Это отличается от официального gbk для символов A1A4 (middle dot), A1AA (em dash), A6E0-A6F5 и A8BB-A8C0. Для получения распечатки различий см. http://recode.progiciels-bpi.ca/showfile.html?name=dist/libiconv/gbk.h.
Для получения распечатки отображений gbk/Unicode см. http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT .
Для получения распечатки MySQL-символов gbk см. http://d.udm.net/bar/~bar/charts/gbk_chinese_ci.html.
10.11.3: Какие проблемы я должен знать при работе с китайским набором символов Big5?
MySQL поддерживает набор символов Big5, который является общим в Гонконге и на Tайване (Republic of China). MySQL big5 в действительности кодовая страница Microsoft 950, которая очень похожа на оригинальный набор символов big5. Пакет перешео на этот набор символов, начиная с MySQL 4.1.16/5.0.16 (в результате Глюка #12476). Например, следующие инструкции работают в текущих версиях MySQL, но не в старых версиях:
mysql> CREATE TABLE big5 (BIG5 CHAR(1) CHARACTER SET BIG5);
Query OK, 0 rows affected (0.13 sec)
mysql> INSERT INTO big5 VALUES (0xf9dc);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM big5;
+------+
| big5 |
+------+
| хл║ |
+------+
1 row in set (0.02 sec)
Просьба о добавлении расщирения HKSCS была зарегистрирована. Те, кто нуждается в этом расширении, могут найти интересной предложенную заплатку для Глюка #13577 .
10.11.4: Почему японские преобразования набора символов терпят неудачу?
MySQL поддерживает наборы символов sjis, ujis, cp932 и eucjpms так же, как Unicode. Общая потребность состоит в том, чтобы преобразоваться между наборами символов. Например, есть Unix-сервер (обычно с sjis или ujis) и Windows-клиент (а здесь почти всегда встречается cp932).
В следующей таблице преобразования столбец ucs2 представляет источник, а столбцы sjis, cp932, ujis и eucjpms представляют адресатов, то есть последние 4 столбца обеспечивают шестнадцатеричный результат, когда Вы используете CONVERT(ucs2) или назначаете столбец, содержащий значение ucs2, столбцу в sjis, cp932, ujis или eucjpms.
Имя символа
ucs2
sjis
cp932
ujis
eucjpms
BROKEN BAR
00A6
3F
3F
8FA2C3
3F
FULLWIDTH BROKEN BAR
FFE4
3F
FA55
3F
8FA2
YEN SIGN
00A5
3F
3F
20
3F
FULLWIDTH YEN SIGN
FFE5
818F
818F
A1EF
3F
TILDE
007E
7E
7E
7E
7E
OVERLINE
203E
3F
3F
20
3F
HORIZONTAL BAR
2015
815C
815C
A1BD
A1BD
EM DASH
2014
3F
3F
3F
3F
REVERSE SOLIDUS
005C
815F
5C
5C
5C
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 |
