Кодировки

Как это не странно, но до сих пор очень часто многие начинающие задают вопрос о кодироках, вернее о «неправильном» отображении русских буковок. Постараю описать все по порядку, следуя данному списку инструкций у меня никогда не возникало проблем с кодировками.

Перый шаг — настройка вашего любимого редактора. Ищем пункт encoding (кодировки) и ставим utf-8. Очень советую использоать именно юникод, чтобы избежать проблем в дальнейшем. Конечно, у юникода есть ряд недостатков, но пользы гораздо больше. Ах, да, ещё пару советов по настройке редактора. Выставьте конец строки в стиле unix — \n, и используйте 4 пробела вместо табов.

Второй шаг — HTML. Добавляем строку

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

Третий шаг — РНР. Некоторые браузеры пренебрегают Content-Type и используют кодироку, посылаемую сервером, обычно по умолчанию iso-8859-1(latin1). Значит мы посылаем нужную нам —

header('Content-type: text/html; charset=utf-8');

Четвёртый шаг — базы данных. Обычно данные берутся из базы данных, поэтому при создание таблиц и полей не забываем указывать нужную кодировку — utf8_general_ci. Обратите внимание, что именно general_ci, а не bin, как любят многие, это позволяет работать с данными как со строками, а не с двоичными данными. Но хостере и здесь заготовили подвох, и по умолчанию чаще стоит другая кодировка. Поэтому предупредим MySQL, что собираемся работать именно с utf-8, для этого сразу после подключения посылаем запрос:

SET NAMES utf8

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

Пятый шаг — если таки данные берутся из другой кодироки, для этого используется функция iconv(), которая конвертирует данные из одной кодировки в другую. На некоторых хостингах нету сего полезного расширения, но я предлогаю игнорировать хостинги с ненастроенным РНР и неустановленными популярными расширениями.

Дерзайте, все неудачные попытки конспектируйте и задавайте вопросы.

p.s. Ещё статья по теме о зловредном BOM.

Кодировки: 11 комментариев

  1. Gavr

    норма написал ))
    только есть вопросик
    юзаю phpmyadmin и когда заношу русскую инфу в базу sql вроде все ок заносит а когда пытаюсь просмотреть аттуда много вапросикав!

  2. Wing

    2Gavr
    При импорте дампа через phpmyadmin можно указать предположительную (нужную) кодировку, если внутри самого sql файла она не указывается.

    Есть еще пара полезных функций – utf8_encode / utf8_decode – используются в случае если кодировку источника или страницы отображения не представляется возможным изменить самостоятельно.

  3. Wing

    Дальнейшее для популяризации топика ))
    Некоторые функции в php по умолчанию забирают данные в utf8, например, file_get_contents. И тут в начале может присуствовать идентификатор byte order mark (BOM), вот полезная php функция, ответ на вопрос как избавиться от BOM:
    function RemoveBOM( $data )
    {
    if(substr($data, 0,3) == pack(«CCC»,0xef,0xbb,0xbf))
    {
    $data=substr($data, 3);
    }
    return $data;
    }

  4. Wing

    Кстати у textarea id=»comment» проблемы с прокруткой – она, вроде, и есть и вроде ее нет, то есть при печати не прокручивается вниз.
    (Firefox 3.0.4)

    Это сообщение можно удалить после прочтения :)

  5. AmdY Автор записи

    Wing спасибо. Про входные данные я не подумал, кстати, эта тема достойна отдельного поста. Сейчас времени на блог нету, только отбился от военкомата, началась сессия, а ещё работа….

  6. Wing

    А еще некоторые проблемы с кодировкой удается решить на уровне настройки сервера.
    Далее из небольшого личного опыта так сказать ))
    Проблемы с кодировкой valuehost (валуехост) решаются добавлением в .htaccess директивы:

    CharsetSourceEnc utf-8

    (такая проблема часто возникает при установке WordPress)

    Проблемы кодировками (отличными от utf-8) у naunet (наунет) решаются добавлением в .htaccess директивы AddDefaultCharset, которая явно задает кодировку в ответе content-type, выглядит это примерно так:

    AddDefaultCharset cp1251

    Думаю, у прямых пользователей хостинга Зенон Н.С.П. могут быть такие же проблемы.
    Вот. Нашел в этом блоге несколько отличных идей, и решил оставить пару полезных комментариев ))

  7. Герц

    Раньше пользовал set names utf8, тоже предпочитаю именно эту кодировку, сейчас решил вместо этого настрочить конструктор в классе:

    connect = @mysqli_connect($db_host, $db_root, $db_pass, $db_name) or die («К базе зацепиться не можем»);
    $this->charset = @mysqli_set_charset($this->connect, «utf8»);
    }

    ?>

    Насчёт избавления от bom, интересная реализация, попробую на практике :) Хотя, в принципе, логичнее изначально сохранять файл без этой метки — меньше гемора в дальнейшем :)

    Вообще парни, тему красиво раскрыли :)

  8. oldoctober.com

    Мало что понял из написанного выше, но зато понял, что Вы понимаете толк в кодировках. В Google набрал «bin general_ci phphbb3» и получил всего несколько страниц, но ответа на свои вопросы не нашёл.

    Вопросы такие. В какой кодировке должны быть таблицы базы данных PHPBB3?
    Они у мне в utf8_bin (сравнение utf8_general_ci).

    Нужно ли перекодировать таблицы и из utf8_bin в utf8_general_ci?

    Если да, то как это можно сделать?

    Рассчитываю на Вашу помощь. Заранее благодарю!

    1. AmdY Автор записи

      bin указывает, что данные бинарные, по идее это должно давать скорость при поиске, utf8_general_ci учитывает кодировки, это замедлит поиск, но зато даст возможность регитронезависимого ( Вася == вася ), а при бинарном это не одно и то же.
      Советую всё же пользоваться utf8_general_ci

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *