2015-03-06 2 views
0

Я смущен! Недавно мой webhotel обновил php, и теперь мои старые таблицы визуализируют специальные символы по-разному (ошибочно). И мои таблицы , и мои входные/выходные-php-страницы установлены на utf-8, и поскольку это обновление, также входы от php обрабатываются по-разному; теперь мои специальные символы кодируются utf-8 при входе в базу данных. Так как это изменение, когда я просматриваю таблицы внутри phpMyAdmin, старые вставки имеют оригинальные (некодированные) специальные символы - новые сообщения имеют charfs с кодировкой utf-8 (также специальные).Специальные символы в mySQL (и php) - ОСНОВЫ

Итак, что бы я хотел сделать, это переписать ввод и вывод для вставки и отображения некодированных символов, но я не уверен, что это возможно без полного пропущения utf-8 (в php и mySQL). Но есть utf-8- способ отправки некодированных символов?

И - возможно, более принципиально - мне нужно понять, каковы возможные недостатки. Я использую датских персонажей, и я не собираюсь использовать какой-либо другой язык (для этого проекта). Поэтому, если возможно вставлять и выводить некодированные символы, используя utf-8 - . У меня возникнут неожиданные/разрушительные проблемы?

Я прочитал много сообщений о php/mySQL/специальных символах, но я еще не видел этого вопроса. Надеюсь, что я не дублирую Надеюсь, не потому, что он работал очень хорошо до обновления.

+0

Если у вас есть БД для тестирования, я бы попробовал [mb_convert_encoding] (http://php.net/manual/en/function.mb-convert-encoding.php). Я бы рекомендовал только попробовать это в тестовой БД, прежде чем вы знаете, что это работает. – SebHallin

+0

У меня нет тестирования db - но, возможно, мне может понадобиться по этой причине. Еще не решил. Но спасибо – morganF

ответ

2

Даже если вы используете только датские символы, вы также можете пойти utf8 полностью.

Есть много мест, где кодирование должно быть указано:

  • в верхней части HTML
  • Столбцы в базе данных (столбец CHARACTER SET по умолчанию из таблицы, которые по умолчанию из)
  • Кодирование в вашем PHP-коде.

Когда вы CREATE TABLE, наклейте на DEFAULT CHARACTER SET utf8. Если у вас есть существующие таблицы, без этого, говорите; нам, возможно, придется иметь дело с ними. Если вы хотите датскую сортировку, укажите также COLLATION utf8_danish_ci. Затем (если я правильно помню), aa сортирует после z. (По умолчанию utf8_general_ci, который не будет выполнять эту сортировку.) Укажите, какая кодировка у вас есть (или может быть) в вашем php-коде. Если у вас есть какой-нибудь текст с акцентами в нем, сделать это:

$hex = unpack('H*', $text); 
echo implode('', $hex) 

Если у вас есть utf8, а будет C3A5, для latin1 будет E5.

Независимо от того, какую кодировку в таблицах вы должны вызвать set_charset ('utf8') или set_charset ('latin1') в зависимости от того, какая кодировка находится в данных на PHP. MySQL будет с радостью перекодировать между latin1 и utf8, поскольку вещи передаются между PHP и MySQL. Для различных интерфейсов:

⚈ mysql: mysql_set_charset('utf8'); 
⚈ mysqli: $mysqli_obj->set_charset('utf8'); 
⚈ PDO: $db = new PDO('dblib:host=host;dbname=db;charset=UTF-8', $user, $pwd); 

Для более подробной информации см http://mysql.rjweb.org/doc.php/charcoll.

+0

С 'utf8_danish_ci', эти сортировки после' z', в показанных группах: 'Ä = Æ = ä = æ Ö = Ø = ö = ø Aa = Å = å Þ = þ' –

+0

Ну, что я действительно спрашивает; есть способ сохранить фактические специальные символы в db, используя utf-8. То, что я получаю сейчас, это «Ã|» вместо æ, «Ã~» вместо «Ø» и т. Д. Это кажется мне глупым; Я получаю разные специальные символы, вставленные в db **, когда я предпочел бы добавить «мои собственные» специальные символы **. Как я вижу, вы поручаете мне работать с (и принимать) кодировку, закодированную в utf, но я бы просто хотел это сделать, ЕСЛИ Я СОХРАНЯЛ, ЧТО ЭТО ОБЕСПЕЧИВАЕТ ОСУЩЕСТВУЮЩУЮ/НАСТОЯЩУЮ ЦЕЛЬ - ИЛИ ЕСЛИ ЭТО НЕОБХОДИМО? – morganF

+0

(Это обычная проблема, и она может быть исправлена). Кодировка utf8 для 'Ø' - это hex' C398'. Но когда этот гекс интерпретируется как latin1, он выходит 'Ã~'. Таким образом, проблема в том, что PHP имел байты в одной кодировке, но передача в/из MySQL предполагала другую кодировку. Эта несогласованность привела к ошибке либо на INSERTION, либо на SELECT. Сделайте 'SELECT HEX (col) ...', чтобы увидеть, что находится в таблице. Тогда мы можем преследовать, где лежит «ошибка». Мой блог описывает проблему и многое другое: http://mysql.rjweb.org/doc.php/charcoll. Я предоставил лакомые кусочки в этой теме. –

Смежные вопросы