Почему конвертирование моей базы данных в UTF-8 сокращает записи?

Я запускаю WordPress 4.1.1. Мой сайт размещен на сайте NearlyFreeSpeech.

Я использую свой блог WordPress с тех пор, как он закодировал информацию в latin1 кодировке. На этой неделе я понял, что некоторые сообщения в моем блоге (например: 1 – 2 – 3 ) не отображали японских символов – символы либо отображались как вопросительные знаки, либо как строки таких символов, как æ- ¥ 本語 ,

Очевидно, что это ошибка кодирования. Глядя на мою базу данных в phpMyAdmin, у меня есть много таблиц и столбцов в моей базе данных с их настройкой на latin1_swedish_ci . Я попытался исправить это, изменив базу данных на UTF-8 различными способами. Все они имели тот же результат.

Как я пытался изменить кодировку базы данных на UTF-8:

  1. Использование плагина конвертера UTF-8
  2. Следуйте этому руководству для экспорта базы данных, замените все экземпляры «latin1» на «UTF8»,
  3. Используйте сценарий SQL для преобразования таблиц и столбцов в blob, а затем в текст UTF-8 (подробнее здесь )
  4. Используйте сценарий SQL для преобразования таблиц и столбцов в тип данных, которые они содержат, затем в blob, а затем в текст UTF-8 (подробнее здесь )

Ожидаемые результаты:

Мой сайт выглядит так же, как и выше, со всеми темами и настройками нетронутыми, но теперь корректно отображает японские символы.

Фактические результаты для всех вышеперечисленных методов:

Японский язык пока не отображается правильно. Более того, записи в базе данных заканчиваются внезапно; например, некоторые записи в post_content пропускают некоторые или большинство их исходного контента. Пользовательские короткие коды, определенные плагином Shortcoder и хранящиеся в строке wp_options в wp_options , wp_options , потому что запись wp_options резко обрезается. Параметры моей темы, включая пользовательские CSS и шрифты, по-видимому, были сброшены или повреждены, что, скорее всего, связано с аналогичным резким усечением записей в базе данных.

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

Когда я сравниваю измененные данные в post_content с оригиналом, я замечаю что-то: почти все усеченные строки начинаются со специального символа. Например, сообщение, которое когда-то читалось:

Сегодня это было приятное 72 ° и солнечное.

будет в измененной базе данных читать:

Сегодня было приятным 72

Я не прошел и нашел все мои усеченные сообщения – я ничего не знаю о mySQL, поэтому мне пришлось бы это делать вручную, и это было бы упражнением в терпении. Однако из выборки из 8 сообщений, которые были усечены, 6 из них были четко усечены с особым символом.

Что мне нужно сделать, чтобы правильно преобразовать мою базу данных так, чтобы японские символы отображались правильно, не вызывая потери данных, или, не допуская полного решения, что я могу сделать, чтобы правильно диагностировать, что происходит?

Спасибо.

Обновление: Дополнительная информация

Еще несколько вещей.

Раньше у меня было много сообщений в моем блоге, которые отображали строки, такие как Iâ € ™ m, а не я , na na, а не наивные . Как я уже упоминал выше, японцы показывали такие длинные строки, как æ- ¥ 本語 вместо 日本語. Я прошел и заменил эти строки, где я их увидел, заменив à ¯ надлежащим ï (например).

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

Когда я смотрю на эти записи в базах данных, которые я изменил … они отображаются правильно . Они не усекаются. Все искаженные символы легко переводились в их «правильные» эквиваленты. Даже японцы обратились.

В сообщениях, где я вернулся и «исправил» искаженные символы, однако, где я наивный и не наивный , содержимое в базе данных усекается при импорте, как описано выше.

Solutions Collecting From Web of "Почему конвертирование моей базы данных в UTF-8 сокращает записи?"

Вопрос был одним из смешанных кодировок. В некоторых полях содержатся данные, закодированные должным образом как UTF-8; другие содержали данные, закодированные как что-то еще, возможно, ISO-8859-1. При импорте в новую базу данных UTF-8 это вызывало усечение.

Мои шаги для решения этой проблемы:

  1. Скопируйте исходную базу данных wordpress в новую базу данных wordpress2 . Убедитесь, что для сортировки wordpress2 установлено значение UTF-8.
  2. Для преобразования таблиц и столбцов wordpress2 в UTF-8 выполните один из шагов выше. Это приведет к усечению.
  3. Для каждой строки в wordpress содержащей записи, в которых данные при преобразовании в UTF-8 были не такими же, как данные при преобразовании в ASCII, обновите соответствующую строку в wordpress2 с помощью данных wordpress , преобразованных в UTF-8. Ниже приведен пример сценария.

Сценарий:

 UPDATE wordpress3.wp_options wp3 INNER JOIN wordpress.wp_options wp ON (wp.option_id = wp3.option_id AND convert(wp.option_value using utf8) != convert(wp.option_value using ascii)) SET wp3.option_value = convert(wp.option_value using utf8); 

Более знающий друг написал для меня ряд сценариев, которые запросили information_schema чтобы найти все столбцы, содержащие записи, в которых convert(value using utf8) != convert(value using ascii) , и затем генерировать версии сценария выше для них.

Результаты:

Это сработало! В моей новой базе данных я могу сохранить японский язык, не превращая его в вопросительные знаки (потому что набор символов успешно настроен на UTF-8), и все неправильно закодированные поля, которые вызывают усечение данных, были исправлены.

Есть несколько сообщений, содержащих помеченные символы, но поскольку я могу найти почти все эти строки, ища â, Ã, Â или æ, я могу просто зайти и вручную заменить их.