Должен ли тип сортировки MySQL соответствовать типу кодировки страницы PHP? - PullRequest
Новая
       22

Должен ли тип сортировки MySQL соответствовать типу кодировки страницы PHP?

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

Я начал отладку своего канала RSS, потому что в нем есть несколько странных символов (то есть глиф отсутствующего символа). Я начал с двух отличных ресурсов для начинающих:

Причина, по которой я считаю, что у нашего RSS-канала возникают проблемы, заключается в том, что пользователи копируют и вставляют документы MS Word в текстовую область на сайте, а наши страницы PHP используют кодировку "iso-8859-1", которая несовместима со специальной "Windows". -1252 "кодировки для таких вещей, как маркеры и умные кавычки, используемые в MS Word.

Так что я надеюсь исправить проблему, все, что мне нужно сделать, это начать использовать «utf-8» на страницах, которые принимают / дают пользовательский ввод ??. То есть установите следующее в разделе HEAD: 

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

Однако настоящая причина, по которой я поднимаю этот вопрос, заключается в том, что мои поля БД, в которых хранятся мои пользовательские данные, находятся в "latin1_swedish_ci", и я хочу знать, НУЖНО ЛИ Я преобразовать их в "utf8_general_ci"? MySQL действительно не заботится о кодировке, не так ли? Он просто видит кучу байтов, и если я добавлю Unicode в поле, сопоставленное с латиницей, оно все равно вернется как Unicode, верно? Изменение поля будет утомительным, потому что поле является частью индекса FULLTEXT, где другие поля также нуждаются в изменении параметров сортировки, что означает удаление индекса и его перестроение (что немалая задача, когда задействовано большое количество TEXT).

Ответы [ 4 ]

6 голосов
/ 12 мая 2009

Реальная причина, по которой я поднимаю этот вопрос, заключается в том, что мои поля БД, в которых хранятся мои пользовательские данные, находятся в "latin1_swedish_ci", и я хочу знать, НУЖНО ли мне конвертировать их в "utf8_general_ci"?

Нет. latin1_swedish_ci и utf8_general_ci - это сопоставления, а не кодировки. Параметры сортировки не влияют на способ хранения символов или ввода / вывода. Он только управляет тем, как сортирующие функции упорядочивают свои результаты. Параметры сортировки - чтобы работать должным образом - должны соответствовать кодировке хранилища. Поэтому, если ваши таблицы хранятся в utf8, вы должны использовать сопоставление utf8.

Кодировка хранилища для mysql напрямую не связана с кодировкой в ​​php. Вы можете использовать utf8 как набор символов для хранения Mysql, в то время как iso-8859-1 в php. В этом случае вам нужно сообщить об этом Mysql, установив кодировку на соединение (set names XXX). Mysql будет конвертировать по мере необходимости. Если вы не используете один и тот же набор символов в Mysql и php, вы получите емкость набора символов, которая является наименьшим знаменателем dommon, поэтому даже если строки хранятся в utf8, у вас не будет полного диапазона символов Юникода имеется в наличии. Поэтому вы должны использовать utf8 в и Mysql и php.

1 голос
/ 13 мая 2009

Чтобы сэкономить время на поиске правильного изменения кодировки набора соединений mysql с помощью pdo / mysql, вот как я это делаю: 

$dbc = new pdo('mysql:dbname=DBNAME;host=DBHOST', $user, $pw, array(PDO::MYSQL_ATTR_INIT_COMMAND => sprintf( "SET NAMES %s", $charset ) ) );
1 голос
/ 12 мая 2009

Нет - определенно нет. Поскольку MySQL обладает способностью на лету преобразовывать строки из одного набора символов в другой, важно, чтобы ваш сервер MySQL знал, с каким набором символов вы работаете на стороне клиента (сторона клиента = сценарий PHP, НЕ клиент, получающий доступ к вашей веб-странице). Это можно сделать, выполнив запрос 

SET NAMES 'utf8';

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

Пожалуйста, ознакомьтесь с руководством по MySQL:

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

В HTTP кодировка символов объявляется параметром charset в поле заголовка Content-Type ответа HTTP. Другие объявления перезаписываются объявлением в заголовке HTTP :

[…] ПАгенты должны соблюдать следующие приоритеты при определении кодировки символов документа (от наивысшего приоритета к наименьшему):

  1. HTTP-параметр "charset" в поле "Content-Type".
  2. Объявление META с "http-equiv", установленным на "Content-Type", и значением, установленным для "charset".
  3. Атрибут charset, установленный для элемента, который обозначает внешний ресурс.

Кроме того, вы должны явно объявить принятую кодировку символов с атрибутом accept-charset в элементе form. В противном случае пользовательский агент может принять (но не должен) кодировку символов, используемую в документе формы для кодирования входных данных:

Значением по умолчанию для этого атрибута является зарезервированная строка «НЕИЗВЕСТНО». Пользовательские агенты могут интерпретировать это значение как кодировку символов, которая использовалась для передачи документа, содержащего этот элемент FORM.

Это должно дать вам максимальную вероятность того, что входящие данные закодированы правильно. Но это не гарантировано. Поэтому лучше проверить, действительно ли данные кодируются с помощью UTF-8 (для этого есть функции / алгоритмы).

...