Как это не странно, но до сих пор очень часто многие начинающие задают вопрос о кодироках, вернее о «неправильном» отображении русских буковок. Постараю описать все по порядку, следуя данному списку инструкций у меня никогда не возникало проблем с кодировками.
Перый шаг — настройка вашего любимого редактора. Ищем пункт 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.
норма написал ))
только есть вопросик
юзаю phpmyadmin и когда заношу русскую инфу в базу sql вроде все ок заносит а когда пытаюсь просмотреть аттуда много вапросикав!
2Gavr
При импорте дампа через phpmyadmin можно указать предположительную (нужную) кодировку, если внутри самого sql файла она не указывается.
Есть еще пара полезных функций – utf8_encode / utf8_decode – используются в случае если кодировку источника или страницы отображения не представляется возможным изменить самостоятельно.
Дальнейшее для популяризации топика ))
Некоторые функции в 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;
}
Кстати у textarea id=»comment» проблемы с прокруткой – она, вроде, и есть и вроде ее нет, то есть при печати не прокручивается вниз.
(Firefox 3.0.4)
Это сообщение можно удалить после прочтения 🙂
Wing спасибо. Про входные данные я не подумал, кстати, эта тема достойна отдельного поста. Сейчас времени на блог нету, только отбился от военкомата, началась сессия, а ещё работа….
А еще некоторые проблемы с кодировкой удается решить на уровне настройки сервера.
Далее из небольшого личного опыта так сказать ))
Проблемы с кодировкой valuehost (валуехост) решаются добавлением в .htaccess директивы:
CharsetSourceEnc utf-8
(такая проблема часто возникает при установке WordPress)
Проблемы кодировками (отличными от utf-8) у naunet (наунет) решаются добавлением в .htaccess директивы AddDefaultCharset, которая явно задает кодировку в ответе content-type, выглядит это примерно так:
AddDefaultCharset cp1251
Думаю, у прямых пользователей хостинга Зенон Н.С.П. могут быть такие же проблемы.
Вот. Нашел в этом блоге несколько отличных идей, и решил оставить пару полезных комментариев ))
Раньше пользовал 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, интересная реализация, попробую на практике 🙂 Хотя, в принципе, логичнее изначально сохранять файл без этой метки — меньше гемора в дальнейшем 🙂
Вообще парни, тему красиво раскрыли 🙂
Млин, полфункции обрезало 🙁
Мало что понял из написанного выше, но зато понял, что Вы понимаете толк в кодировках. В Google набрал «bin general_ci phphbb3» и получил всего несколько страниц, но ответа на свои вопросы не нашёл.
Вопросы такие. В какой кодировке должны быть таблицы базы данных PHPBB3?
Они у мне в utf8_bin (сравнение utf8_general_ci).
Нужно ли перекодировать таблицы и из utf8_bin в utf8_general_ci?
Если да, то как это можно сделать?
Рассчитываю на Вашу помощь. Заранее благодарю!
bin указывает, что данные бинарные, по идее это должно давать скорость при поиске, utf8_general_ci учитывает кодировки, это замедлит поиск, но зато даст возможность регитронезависимого ( Вася == вася ), а при бинарном это не одно и то же.
Советую всё же пользоваться utf8_general_ci
Спасибо! А как перекодировать из bin в general_ci?