MySQL: добавление поддержки азиатских символов в существующую базу данных - PullRequest
Новая
       31

MySQL: добавление поддержки азиатских символов в существующую базу данных

0 голосов
/ 02 апреля 2011

Я ищу наилучший подход для добавления поддержки азиатских наборов символов в существующую базу данных.У нас есть существующие таблицы в кодировке latin1: 

show create table books
CREATE TABLE `books` (
  `id` varchar(255) NOT NULL,
  `category` varchar(255) default NULL,
  `contactEmail` varchar(255) default NULL,
  `description` text,
  `price` varchar(255) default NULL,
  PRIMARY KEY  (`id`),
) ENGINE=MyISAM DEFAULT CHARSET=latin1

В настоящее время, когда мы вводим символы UTF8 для поля description, мы возвращаемся '?'символы для азиатских символов в оба конца.Символы Latin1 работают просто отлично.

Могу ли я просто преобразовать эту таблицу с помощью чего-нибудь подобного? 

ALTER TABLE books CONVERT TO CHARACTER SET utf8

Я понимаю, что это волшебным образом не исправит данные, уже присутствующие в таблице.Я просто хочу, чтобы он работал правильно для новых данных в будущем.

Нужно ли беспокоиться о сопоставлении?Я понятия не имею, как это будет работать для нелатинских символов.

Имеет ли смысл сделать utf8 значением по умолчанию для базы данных?Есть ли какие-либо предостережения по этому поводу?

Спасибо

Ответы [ 2 ]

0 голосов
/ 01 мая 2012

То, что ты возвращаешься?хороший знак, так как предполагает, что символы, отсутствующие в Latin-1, были правильно преобразованы в заменяющие символы.Прежде чем приступить к проекту по преобразованию данных, убедитесь, что все в порядке.Это особенно важно, если в базу данных записано более одного приложения и языка программирования.

Один из самых простых способов сделать грубую проверку готовности - это проверить длину символа по длине байта.

SELECT length(foo), char_length(foo) FROM bar

Первое возвращаемое значение - это длина строки в байтах , второе - длина строки в символах .Если там есть какие-нибудь многобайтовые символы, эти два значения будут различаться.

Существует множество руководств по конвертации, доступных в Интернете, и среди них я нашел одно, в частности быть невероятно полезным.

0 голосов
/ 02 апреля 2011

У меня нет большого опыта работы с наборами символов в MySQL, но у меня есть опыт работы с наборами символов в целом.

В настоящее время, когда мы вводим символы UTF8 для поля описания, мы возвращаемся '?' символы для азиатских символов в оба конца. Символы Latin1 работают просто отлично.

Поскольку ваша таблица использует latin1 для кодирования, она может хранить только те символы, которые присутствуют в наборе символов latin1. Latin1 является сокращением для ISO-8859-1, вы можете увидеть, какие символы у него - без азиатских символов, поэтому они не будут храниться. Я немного удивлен, что MySQL не выдает ошибку при таком вводе.

Имеет ли смысл использовать utf8 по умолчанию для базы данных? Есть ли какие-либо предостережения по этому поводу?

UTF-8 будет хорошим выбором, если вам нужно хранить символы из нескольких языков. UTF-8, как кодировка Unicode, позволит вам хранить любые символы Unicode (их буквально тысячи) на многих языках. Вы можете хранить строку "Dog café θλφ 你好", используя UTF-8. UTF-8 широко используется и способен кодировать практически все, что я настоятельно рекомендую.

Я бы пролистал Интернет, чтобы найти литературу по преобразованию таблиц MySQL, чтобы убедиться, что нет никаких ошибок. Если это производственные данные, протестируйте автономный набор данных - таблицу разработки или таблицу QA.

Наконец, вы, кажется, указываете на то, что в вашей БД каким-то образом хранятся полусохраненные азиатские символы. Я бы выяснил, что явно хранится : если это последовательность UTF-8 для азиатского символа, но база данных считает, что это latin1 (классический случай mojibake ), некоторое восстановление может быть возможно Я бы беспокоился, что преобразование может попытаться преобразовать кодовые блоки UTF-8, как если бы они были латиницей1, что привело бы к очень интересному выводу. Тест Тест Тест.

...