Список «испорченных персонажей» в utf8 - PullRequest
3 голосов
/ 12 мая 2011

У одного из моих клиентов есть веб-сайт, который был полностью испорчен хостинговой компанией, которая вынудила набор символов в полной базе данных.Раньше у нас были проблемы с наборами символов, но теперь это просто драма!

До сих пор я добавил charset = utf-8 к типу содержимого страницы и установил charset для подключения mysql кutf8.И теперь пришло время заменить всех персонажей.Пока что я нашел:

ö = ö
ë = ë
é = é

Данные в базе данных обновляются примерно так:

UPDATE table SET `fieldname` = REPLACE(`fieldname`, 'ö', 'ö');

Теперь мне просто нужно найти полный список всех символовкоторые запутались.Я попытался выполнить запрос MySQL для поиска field LIKE '%Ã%', но он возвращает мне все записи в базе данных.

Google также просто отображает пару символов (в основном 3 выше) в некоторых темах других людей, у которых возникли проблемыОднако, похоже, нигде нет полного списка этих символов (или, по крайней мере, наиболее распространенных), который я могу использовать, чтобы найти и заменить все данные для моего клиента.

Если кто-то, возможно, знает такое местоположение или можетЗавершив свой список, я, в свою очередь, создам страницу, содержащую эти символы, чтобы помогать другим (если только нет списка, о котором я не знаю, конечно).

// EDIT:

это было бы для наиболее распространенных европейских символов, таких как é è ë, á à ä, ö ó ò, ï, ü и, возможно, рингель-S (немецкий двойной S).Не так много для таких знаков как, например, ñ или ã, но если они где-то есть в списке, это было бы очень полезно.

// EDIT 2:

Я обновил базу данных MySQLи таблицы, использующие 2 запроса ALTER из первой части этой статьи: http://developer.loftdigital.com/blog/php-utf-8-cheatsheet.Я НЕ использовал функции mb_ до сих пор и не выполнял конфигурацию MB, как кажется.

В файлах все заголовки установлены в utf-8 (мне все еще нужно проверить заголовки длянекоторые сценарии ajax, хотя, не уверен, что это необходимо, но это не принесет вреда).И все файлы сохраняются как UTF8 без спецификации.Также PHPFreakMailer обновляется, устанавливая кодировку в utf-8.

Bad enough, у меня все еще есть эти странные символы.Я не думал, что они уйдут сами, но, по крайней мере, стоило на это надеяться :-) Так какой последний шаг я должен сделать?Продолжить использовать запрос REPLACE и вручную изменить все странные символы?

Заранее спасибо!

Ответы [ 4 ]

3 голосов
/ 12 мая 2011

Это немного безумно;в каком наборе символов, как вы думаете, находится "ö"?

Похоже, что это действительно правильная последовательность UTF-8 (так как это два байта), вы просто отображаете ее как ISO-8559-1.

Редактировать :

Исходя из вашего комментария, я думаю, что происходит следующее:

Я думаю (но на самом деле нетНа 100% уверен), что правильная двоичная последовательность UTF-8 хранится в базе данных.Но так как таблица помечена как ISO-8559-1, и вы запросили автоматическое преобразование набора символов.Поэтому он думает, что это ISO-8559-1 (который выглядит как ö), но затем пытается преобразовать его в UTF-8.

Вы должны быть в состоянии проверить это, если strlen ('ö')равно 4, а не 2. Если длина действительно равна 2, кодировка вашего браузера как-то облажается.

Чтобы исправить это, не устанавливайте MySQL для кодирования символов.

Опция 2

Данные также могут быть «дважды закодированы» в таблице.Чтобы проверить это, просто проверьте длину строки в базе данных.Если длина ö составляет 4 байта, это проблема.

Мой совет в этом случае - не пытаться создать большую карту «испорченных символов».Вы должны просто иметь возможность 'utf8_decode' строку.Обычно эта функция выводит строку ISO-8559-1, но в вашем случае ... она должна оказаться исходной действительной строкой UTF-8.

Надеюсь, это сработает!

Edit2

Хорошо, так эффективно, как я полагаю, произошло, вариант 2. Проще говоря, * php:

$output = utf8_encode(utf8_encode('string'));

Так что один utf8_decode () долженхватит.

Протестируйте это, прежде чем запускать сценарии миграции, хотя:)

1 голос
/ 12 мая 2011

Поскольку вы пометили этот вопрос как "php", я предполагаю, что вы прочитали базу данных и ее значения с помощью PHP? Если это так, пожалуйста, посмотрите на mb_convert_encoding , если у вас больше нет контроля над базой данных.

Лучшим решением было бы устранить несоответствие между данными и набором символов таблиц. Сделайте резервную копию базы данных (на всякий случай) и измените все таблицы и столбцы на UTF-8. Примечание : при использовании MySQL недостаточно , чтобы изменить кодировку таблицы, вам придется делать это для каждого столбца.

1 голос
/ 12 мая 2011

Если они вызвали изменение символа, почему ваша база данных не конвертируется?Являются ли ваши таблицы старым набором символов (см. Ваш phpMyAdmin в информации о таблицах).

Являются ли данные неверными, если они отображаются в вашем phpMyAdmin или только на вашей веб-странице?-> ваши имена и параметры сортировки должны измениться, а также заголовки и тип файла (безопасный файл как utf-8).

Или попробуйте:

ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

Я бы начал заменять символы только в том случае, еслине осталось вариантов изнутри MySQL.

0 голосов
/ 12 мая 2011

Почему бы вам не использовать: ä = ä, ö = ö, ...

Выполните htmlentities(); в php, и он преобразует все специальные символы в сущности.
Я думаю, что это будет самый простой способ сделать это.

...