AJAX и проблемы с кодировкой. AJAX и проблемы с кодировкой Jquery кодировка из 1251 в utf 8
Когда я только начинал изучать тему разработки сайтов, кракозябры были одной из моих постоянных проблем. Создал HTML-страницу — в браузере кракозябры, установил денвер и попробовал создать сайт на PHP — снова вместо букв кракозябры. Скачал иностранную тему, подключился к базе данных — та же проблема.
На своих сайтах я обычно использую UTF-8 (это такая кодировка текста, она ещё называется юникод), соответственно она будет присутствовать во всех примерах в этой статье.
1. UTF-8 без BOMНачнём с самой простой проблемы. Вы создали какой-то HTML-файл, открыли его в браузере и получили:
Кракозябры (проблема с кодировкой).
Проблема актуальна в основном для пользователей Windows, на маке я с таким ни разу не сталкивался.
Решение проблемы зависит в основном от того, каким редактором вы пользуетесь. Для пользователей Windows я рекомендую бесплатный офигительный Notepad++.
Значит, открываем файл в Notepad++ и переходим в Кодировки > Преобразовать в UTF-8 без BOM. Вопрос — почему без BOM? Потому что с BOM у вас будут постоянно вставляться пустые символы (на самом деле они не пустые, у них тоже есть своя функция, но нам она в данном случае не нужна) куда не надо, а для PHP это уже критично.
Если вы сделали то, что я описывал в предыдущем шаге и ваша проблема не разрешилась, тогда самое время испробовать второй метод устранения кракозябров.
Всё, что нам требуется, это вставить следующий код между тегами сайта. Прежде всего проверьте, возможно этот метатег у вас уже присутствует. Если да, то посмотрите какое у него стоит значение параметра charset.
3. .htaccessЕсли русские буквы до сих пор отображаются кракозябрами, тогда открываем ваш.htaccess , который лежит в корне сайта и вставляем туда с новой строки это:
Важно! Этот код должен вставляться до того, как будет что-либо выведено на странице сайта, иначе — ошибка.
5. Проблемы с последним символом при обрезке строки
Как решить эту проблему?
Легко — всё что нам нужно, это найти функцию substr() в коде и поменять её на mb_substr() .
Если после этого у вас полезут ошибки на сайт, то скорее всего multibyte-функции не поддерживаются вашим хостингом, первое, что вам следует сделать, это написать в супорт и спросить, нельзя ли их подключить на ваш аккаунт. Если нет, меняем хостинг, например на тот, которым .
6. MySQLУ меня не раз бывало такое, что я подключался к MySQL, вытаскивал какие-нибудь данные, и при их выводе на сайте, текст отображался кракозябрами.
Вот уже полтора года в draft-ах пылился пост о надуманности проблем с кодировками и т.н. AJAX-ом.
Каждый раз, когда на форумах всплывали вопросы подобного характера, хотелось дать ссылку, на всякий всплеск заходов на блог по запросам “кодировка, ajax, проблема” хотелось его опубликовать, но мне казалось, что пост ещё не закончен, надо ещё чуть-чуть дописать…
Но вот буквально сегодня появился удивительно похожий пост – ajax, cp1251 . Похожий по содержанию, но совершенно противоположный по смыслу.
Посему свой черновичок я решил удалить, а поведать свою “истину” в форме критики совета fxposter-а.
Ни для кого ни секрет, что кодировкой получаемых через Ajax данных по-умолчанию принимается UTF-8.
На самом деле это секрет. Для многих секрет. И многие не понимают почему это так.
Внутреннее представление строк (и регулярных выражений) в JavaScript для всех не-ASCII последовательностей как раз UTF-8.
Отсюда и проистекает т.н. “проблема” – если кодировка не указана явно и используется нелатиница, она будет интерпретирована как utf-8 последовательность.
Update 29.11
Свежий воздух и Давид Мзареулян остудили пыл, поэтому спешу уточнить о чём именно будет идти речь ниже.
Итак – у вас есть некий ресурс в однобайтовой кодировке (к гадалке не ходи это будет windows-1251) и вы озаботились освоить новый buzzword по имени AJAX. Немного почитав, вы делаете первые робкие шаги в этом направлении и тут же наступаете на “детские грабли”, а затем, немного отдышавшись, мчитесь на форумы с криком о помощи. И вам эту помощь окажут – переделай мол, свой ресурс на utf-8… Конечно-конечно скажете вы и пойдёте переделывать…
Я же хочу остеречь от таких опрометчивых шагов.
Cтандартное решение, которое наперебой советуют все – “используй utf-8 и нет проблем”.
И советчики правы – проблем действительно не будет.
Просто трафик увеличится “вдвое”. Те же данные, тот же результат, а трафика “в два раза” больше. Ага?
Что вы там говорите насчёт порошка?!?
Если вам этот фактор кажется мало***щим, то на этом чтение надо прекратить и начать переделывать свой проект на использование UTF-X,
остальным же оставлю несколько рецептов, которые помогут избежать проблем при использовании однобайтовых кодировок в т.н. AJAX-приложениях:
- Первое, оно же главное – ВСЕГДА указывайте кодировку контента. В любом ответе сервера с текстовым контентом обязан быть заголовок Content-Type: your/type; charset=your-charset
.
Дешевле всего это сделать, настроив сервер (например в php через default_charset) - Указывайте charset при включении javascript в тело документа ()
- Указывайте ПРАВИЛЬНЫЙ charset
предварительно установив соответствующий заголовок – “Content-Type: text/html; charset=cp1251”
В данном конкретном взятом за жопу случае fxposter сам себе злобный буратина.
Any registered IANA charset may be used, but UTF-8 is preferred.
Ну нету среди any registered кодировки с названием cp1251…
Для полноты картины приведу пару проблемных моментов, с которыми столкнуться прийдётся:
- Не позволяйте AJAX-ответам, которые содержат “нелатиницу” оставаться в кеше браузера (при 304 Not Modified ответ поднимется из кеша, но в качестве charset “некоторые браузеры” используют utf-8)
Этим правилом НАГЛО пользуются производители различных библиотек для json_code, но браузерам (как мы выяснили ранее) главное кодировку указать, а там всё разрулится.
Отсюда и “проблема” – кодировать данные в JSON нужно вручную, распространнёные библиотечные функции на входе ожидают utf-8.
Мораль сей басни я жду от вас в комментариях.
AJAX и проблемы с кодировкой
Есть как минимум 4 варианта:
1. Написать собственную процедуру перекодировки.
В этом случае придется потратить время на изучение алгоритмов.
2. Можно использовать модуль Convert::Cyrillic , однако он испытывает зависимость от модуля Unicode::Map8 , который легко установить под *nix, но с поиском модуля под ActiveState Perl 5.8 могут возникнуть проблемы.
3. Можно использовать модуль Text::Iconv , который доступен как для Perl 5.6, так и для Perl 5.8.
My $unicodeTextHere; # какие-либо действия, устанавливающие в переменную # ... # $unicodeTextHere текст в кодировке UTF-8 use Text::Iconv; my $converter = Text::Iconv->new("UTF-8", "WINDOWS-1251"); my $winTextHere = $converter->convert($unicodeTextHere); # $winTextHere содержит текст в кодировке Windows-1251
4. Если Вы используете Perl 5.8, то конвертирование можно прозвести с помощью Encode :
My $unicodeTextHere; # какие-либо действия, устанавливающие в переменную # ... # $unicodeTextHere текст в кодировке UTF-8 use Encode; Encode::from_to($unicodeTextHere, "utf-8", "windows-1251"); # теперь $unicodeTextHere содержит текст в кодировке Windows-1251
Комментарии посетителей сайта| Дмитрий | 25.01.2012 15:46 |
Кодировка windows 1251 была создана в начале 90 годов для русификации программных продуктов, выпускаемых корпорацией Microsoft :
Кодировка является 8-битной и включает в себя символы славянской группы языков, в которую входят русский, белорусский, украинский, болгарский, македонский, сербский – это дает преимущество перед остальными кириллическими кодировками (ISO 8859-5, KOI8-R, CP866 ). Однако у 1251-кодировки имеются и весомые недостатки:
- 0xFF (25510) – это код, который зарезервирован для символа «я». В программах, которые не поддерживают чистый 8-ой бит, часто возникают непредсказуемые проблемы;
- Нет псевдографики, которая присутствует в KOI8 , CP866 .
Ниже приведены символы из Code Page 1251 или сокращенно СР1251 (числа под символами являются кодом в шестнадцатеричной системе такого же символа в Юникоде ):
Кодировка windows 1251 в htmlНередко у web-разработчиков и блогеров, обладающих различной квалификацией возникает проблема с кодировкой страниц: вместо подготовленного текста появляются неизвестные, нечитаемые символы. Чтобы разобраться с данной проблемой, необходимо понимать суть термина «кодировка страницы ».
Текст в памяти компьютера хранится в виде определенного количества байт, а не в том виде, в котором он отображается в текстовом редакторе. Каждый байт является кодом, который соответствует одному символу. Для того чтобы текст на странице отображался как следует, нужно сообщить браузеру, какую таблицу кодов для расшифровки и отображения он должен использовать.
Таблица кодировок не является универсальной, то есть, для расшифровки текста необходимо использовать ту, которая соответствует кодировке символов:
Для того чтобы html-документ корректно отобразился в браузере, необходимо указать используемую кодировку. Делается это следующим образом:
— между тегом и закрывающим его нужно прописать — исходя из этой строки, браузер будет использовать символы русского алфавита для отображения текста на странице.
Кодировка windows 1251 в PHPНи для кого не является тайной, что генерация страниц проходит путем выборки и использования какой-то части информации, которая хранится в базе данных. При написании сайта на PHP , чаще всего это mysql :
Нередко при смене хостинга возникает проблема: различные кодировки информации в базе данных и в шаблонах страниц. Из-за этого одна сгенерированная страница может одновременно содержать несколько кодировок. Если информация на сайте представлена в кодировке виндовс 1251 , то и чтение из базы данных должно осуществляться с помощью таблицы, в которой представлена win 1251 кодировка.
Для согласования расшифровки необходимо выполнить функцию mysql_query(«SET NAMES cp1251») – это означает, что преобразование из машинного кода будет осуществляться согласно таблице cp1251 .
Кодировка windows 1251 в htaccessПри создании сайта, предварительно настроив кодировки в шаблонах и базах данных, все равно может всплыть проблема некорректного отображения информации в браузере.
