Как обнаружить символы UTF-8 в столбце с кодировкой Latin1-MySQL

Я собираюсь взять на себя утомительную и обременительную задачу преобразования базы данных из Latin1 в UTF-8.



На этом этапе я просто хочу проверить, какие данные я сохранил в своих таблицах, поскольку это определит, какой подход я должен использовать для преобразования данных.



В частности, я хочу проверить, есть ли у меня символы UTF-8 в Столбцах Latin1, как это лучше всего сделать? Если затронуты только несколько строк, то я могу просто исправить это вручную.



Вариант 1. Выполнить дамп MySQL и использовать Perl для поиска символов UTF-8?



Вариант 2. Использовать MySQL CHAR_LENGTH для поиска строк с многобайтовыми символами?
например SELECT name FROM clients WHERE LENGTH(name) != CHAR_LENGTH(name);
Этого достаточно?



На данный момент я переключил кодировку клиента Mysql на UTF-8.

677   4  

4 ответов:

Кодировка символов, как и часовые пояса, является постоянным источником проблем.

То, что вы можете сделать,-это поиск любых символов "high-ASCII", поскольку это либо символы с латинским акцентом 1, либо символы, либо первый из многобайтовых символов UTF-8. Сказать разницу будет нелегко, если вы не обманете немного.

Чтобы выяснить, какая кодировка правильна, вы просто SELECT две разные версии и сравните визуально. Вот пример: 

SELECT CONVERT(CONVERT(name USING BINARY) USING latin1) AS latin1, 
       CONVERT(CONVERT(name USING BINARY) USING utf8) AS utf8 
FROM users 
WHERE CONVERT(name USING BINARY) RLIKE CONCAT('[', UNHEX('80'), '-', UNHEX('FF'), ']')

Это сделано необычно сложно, потому что движок регулярных выражений MySQL, кажется, игнорирует такие вещи, как \x80 и делает его необходимым использовать метод UNHEX() вместо этого.

Это приводит к следующим результатам: 

latin1                utf8
----------------------------------------
Björn                Björn
41  
2014-02-26 23:00:25

Поскольку ваш вопрос не совсем ясен, давайте предположим некоторые сценарии:

  1. до сих пор неверное соединение: Вы неправильно подключались к базе данных, используя кодировку latin1, но сохранили данные UTF-8 в базе данных (кодировка столбца в данном случае не имеет значения). Это тот случай, который я описал здесь . В этом случае это легко исправить: сбросить содержимое базы данных в файл через соединение latin1. Это позволит перевести неправильно сохраненные данные в Неправильно Правильно сохраненный UTF-8, как это работало до сих пор (читайте вышеописанную Статью для кровавых деталей). Затем вы можете повторно импортировать данные в базу данных через правильно настроенное соединение utf8, и они будут сохранены так, как должны быть.
  2. до сих пор неверная кодировка столбца: данные UTF-8 были вставлены в столбец latin1 через соединение utf8. В таком случае забудьте об этом, данные исчезли. Любой не-латинский символ 1 должен быть заменен символом a. ?.
  3. до сих пор все нормально, отныне добавлена поддержка UTF-8: у вас есть данные Latin-1, Правильно сохраненные в столбце latin1, вставленные через соединение latin1, но вы хотите расширить его, чтобы также разрешить данные UTF-8. В этом случае просто измените кодировку столбца на utf8. MySQL преобразует существующие данные для вас. Затем просто убедитесь, что ваше соединение с базой данных установлено на utf8, когда вы вставляете данные UTF-8.
8  
2012-02-16 07:51:13

Есть скрипт на github, чтобы помочь с такого рода вещами.

3  
2013-01-28 21:29:41

Я бы создал дамп базы данных и grep для всех допустимых последовательностей UTF8. Где взять его оттуда, зависит от того, что вы получите. Есть несколько вопросов по SO об идентификации недопустимого UTF8; вы можете просто изменить логику.

Edit : таким образом, в принципе, любое поле, полностью состоящее из 7-битного ASCII, безопасно, и любое поле, содержащее недопустимую последовательность UTF-8, можно считать Latin-1. Остальные данные следует проверить-если повезет, горстка очевидные замены зафиксируют абсолютное большинство (замените " а "на латиницу-1" и т. д.).

0  
2012-02-16 08:20:24

Comments

    Ничего не найдено.
Click here to cancel reply.