Как настроить кодировки для работы с PHP фреймворком CodeIgniter

29 января, 2008

Поддержка кодировок в CodeIgniter
Недавно я столкнулся с проблемой.

Создал базу данных и в ней таблицу. Во время создания явно задал кодировку (utf-8).

После этого, установил и настроил CodeIgniter. Все представления (views) тоже были в кодировке utf-8, и, естественно, был добавлен мета-тег:

  1. <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

Т.е. кириллица в браузере отображалась правильно.

Начинаю добавлять данные в БД (с помощью scaffolding). Все отлично работает, буквы отображаются правильно.

Но, через некоторое время мне понадобилось сделать дамп базы. Запускаю phpMyAdmin, экспортирую базу и вижу вместо кириллицы «кракозябры»! При просмотре данных в phpMyAdmin – те же «кракозябры». Ввожу данные через phpMyAdmin – в нем все нормально, но на сайте – знаки вопроса.

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

Самое непонятное заключалось в том, что тут же была база данных, созданная WordPress, с теми же самыми кодировками. И в ней все работало отлично, и на сайте, и в phpMyAdmin.

В общем, после недолгих поисков, решение нашлось. Предложил его mihailt.

Идея заключается в том, что нужно выполнить “SET NAMES UTF8” для каждого соединения.

Для это в конфигурационный файл базы данных (/system/application/config/database.php) добавляем

  1. $db[default][‘charset’] = "UTF8";

А в файле /system/database/DB.php добавляем строку

  1. $DB->query(“SET NAMES ?”, $params[‘charset’]);

(сразу после $DB =& new $driver($params);).

Все тут же отлично заработало.

Для справки. Кодировки БД были такими:
character_set_client – utf8
character_set_connection – utf8
character_set_database – utf8
character_set_filesystem – binary
character_set_results – utf8
character_set_server – utf8
character_set_system – utf8
collation_connection – utf8_unicode_ci
collation_database – utf8_general_ci
collation_server – utf8_general_ci

Примечание. Эти данные можно получить с помощью запросов

  1. SHOW VARIABLES LIKE 'character%'
  2. SHOW VARIABLES LIKE 'collation%'

Понравилась статья? Подпишитесь на продолжение rss link !

]]>

Добавьте эту страницу в google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

]]>

Опубликовано в CodeIgniter, PHP

]]>

Комментарии (7)

Вы можете отслеживать обсуждение записи с помощью RSS 2.0 rss link

Вы также можете оставить комментарий, или трекбек с Вашего сайта.

  1. mihailt 29.01.2008 в 12:55 (Ответить)

    Такая модификация позволяет использовать не только UTF-8, а какую угодно кодировку просто изменив параметр в конфиге.

    На некоторых хостах не смотря, на то что всё работает пишет в лог num_rows() ошибку.
    Решить можно заменой :
    $DB->query
    на
    $DB->simple_query

  2. MAX 29.01.2008 в 13:10 (Ответить)

    В 1.6 используется немного другая схема. В конфиге появились строчки

    $db['default']['char_set'] = "utf8";
    $db['default']['dbcollat'] = "utf8_general_ci";

    Соотвественно при создании таблиц нужно указывать эти два параметра.

    $charset = $CI->db->char_set ? $CI->db->char_set : 'utf8';
    $collate = $CI->db->dbcollat ? $CI->db->dbcollat : 'utf8_general_ci';

    1. mihailt 29.01.2008 в 13:21 (Ответить)

      в CI 1.6 много вещёй немного меняют в лучшую сторону, но к сожалению он ещё сыроват ;)

    2. Владимир 29.01.2008 в 15:58 (Ответить)

      Насколько я знаю, версия 1.6 еще в разработке, и, значит, могут быть изменения.

      И, честно говоря, не очень мне нравится эта схема с передачей данных. Т.е. ручная установка кодировок, конечно, нужна, но и CI мог бы в автомате попытаться их настроить. Ведь вся информация о кодировках может быть получена с помощью SQL запросов.

  3. MAX 29.01.2008 в 16:45 (Ответить)

    Делов том, что в 1.6 довольно серьезные изменения. Касается это внутренней структуры, а также самого кода. Так что есть смысл уже сейчас использовать новую схему, иначе потом придется еще раз переделывать. Кроме этого SET NAMES передавать вовсе не обязательно каждый раз, если при создании таблицы была верно указана collation и charset. Таким образом ваш способ становится просто бессмысленным. К тому же если при создании таблиц кодировка не указывалась, то она создается в кодировке по-умолчанию. Для наших хостингов это как правило cp1251. Поэтому если вы выполняете set names utf8, то данные в такую базу попадают совсем не в той кодировке, в которой они предназначены, а это вызывает сразу массу проблем. Например сортировка или бэкап будут неверными.

    1. mihailt 29.01.2008 в 22:55 (Ответить)

      В том то и дело что для ваших - для наших 3 языка давно уже стандарт соответственно делать что либо не в utf-8 очень не хорошо.

      Насчёт изменений я так полагаю, что достаточно много проектов так и останутся в предидущей версии.

    2. Владимир 30.01.2008 в 12:42 (Ответить)

      У меня возникли проблемы именно при указанных collation и charset, т.е. в запросе создания БД было
      …DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci
      и при создании таблицы
      …ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci

      Кроме того, сервер MySQL устанавливался с utf8 по-умолчанию.

      Пока не выполнил SET NAMES нормально не заработало.

      P.S. Подробно кодировки я привел в конце поста.

Оставить комментарий

Введите ваш комментарий

* - обязательные для заполнения поля

Quicktags:

]]>