Коли я тільки-но починав вивчати тему розробки сайтів, кракозябри були однією з моїх постійних проблем. Створив HTML-сторінку — у браузері кракозябри, встановив денвер та спробував створити сайт на PHP знову замість літер кракозябри. Скачав іноземну тему, підключився до бази даних — та сама проблема.

На своїх сайтах я зазвичай використовую UTF-8 (це таке кодування тексту, воно ще називається юнікод), відповідно воно буде присутнім у всіх прикладах цієї статті.

1. UTF-8 без BOM

Почнемо з найпростішої проблеми. Ви створили якийсь HTML-файл, відкрили його у браузері та отримали:

Кракозябри (проблема з кодуванням).

Проблема актуальна здебільшого для користувачів Windows, на маку я з таким жодного разу не стикався.

Вирішення проблеми залежить в основному від того, яким редактором ви користуєтеся. Для користувачів Windows я рекомендую безкоштовний офіційний Notepad ++.

Отже, відкриваємо файл у Notepad++ і переходимо в Кодування > Перетворити на UTF-8 без BOM. Питання чому без BOM? Тому що з BOM у вас постійно вставлятимуться порожні символи (насправді вони не порожні, у них теж є своя функція, але нам вона в даному випадку не потрібна) куди не треба, а для PHP це вже критично.

2. Мета тег charset

Якщо ви зробили те, що я описував у попередньому кроці, і ваша проблема не вирішилася, тоді саме час випробувати другий метод усунення кракозябрів.

Все, що нам потрібне, це вставити наступний код між тегами сайту. Насамперед перевірте, чи можливо цей метатег у вас вже присутній. Якщо так, то подивіться, яке у нього стоїть значення параметра charset.

3. .htaccess

Якщо російські літери досі відображаються кракозябрами, тоді відкриваємо ваш.htaccess, який лежить в корені сайту і вставляємо туди з нового рядка:

Важливо! Цей код повинен вставлятися до того, як буде виведено щось на сторінці сайту, інакше — помилка.

5. Проблеми з останнім символом при обрізанні рядка

Як вирішити цю проблему?

Легко - все, що нам потрібно, це знайти функцію substr() в коді і поміняти її на mb_substr().

Якщо після цього у вас будуть помилки на сайт, то швидше за все multibyte-функції не підтримуються вашим хостингом, перше, що вам слід зробити, це написати в суппорт і запитати, чи не можна їх підключити на ваш аккаунт. Якщо ні, міняємо хостинг, наприклад, на той, яким .

6. MySQL

У мене не раз бувало таке, що я підключався до MySQL, витягував якісь дані, і при їх виведенні на сайті текст відображався кракозябрами.

21.02.15 7.1K

Кодування windows 1251 було створено на початку 90 років для русифікації програмних продуктів, що випускаються корпорацією Microsoft:

Кодування є 8-бітним і включає символи слов'янської групи мов, до якої входять російська, білоруська, українська, болгарська, македонська, сербська – це дає перевагу перед іншими кириличними кодуваннями (ISO 8859-5, KOI8-R, CP866). Однак у 1251-кодування є і вагомі недоліки:

• 0xFF (25510) – код, який зарезервований для символу «я». У програмах, які не підтримують чистий восьмий біт, часто виникають непередбачувані проблеми;
• Немає псевдографіки, яка присутня в KOI8, CP866.

Нижче наведено символи з Code або скорочено СР1251 (числа під символами є кодом у шістнадцятковій системі такого ж символу в Юнікоді):

Кодування windows 1251 у html

Нерідко у web-розробників і блогерів, які мають різну кваліфікацію, виникає проблема з кодуванням сторінок: замість підготовленого тексту з'являються невідомі, нечитані символи. Щоб розібратися з цією проблемою, необхідно розуміти суть терміну кодування сторінки.

Текст у пам'яті комп'ютера зберігається у вигляді певної кількості байт, а не у вигляді, в якому він відображається в текстовому редакторі. Кожен байт є кодом, що відповідає одному символу. Щоб текст на сторінці відображався як слід, потрібно повідомити браузеру, яку таблицю кодів для розшифровки та відображення він повинен використовувати.

Таблиця кодувань не є універсальною, тобто для розшифрування тексту необхідно використовувати ту, що відповідає кодуванню символів:

Для того щоб html-документ коректно відобразився в браузері, необхідно вказати кодування, що використовується. Робиться це так:

- між тегом і закриває його потрібно прописати - виходячи з цього рядка, браузер використовуватиме символи російського алфавіту для відображення тексту на сторінці.

Кодування windows 1251 у PHP

Ні для кого не є таємницею, що генерація сторінок відбувається шляхом вибірки та використання якоїсь частини інформації, що зберігається у базі даних. При написанні сайту на PHP, найчастіше це mysql:

Нерідко при зміні хостингу виникає проблема: різні кодування інформації в базі даних та шаблонах сторінок. Через це одна згенерована сторінка може одночасно містити кілька кодувань. Якщо інформація на сайті представлена ​​в кодуванні віндовс 1251, то і читання з бази даних має здійснюватися за допомогою таблиці, в якій представлено win 1251 кодування.

Для узгодження розшифровки необхідно виконати функцію mysql_query («SET NAMES CP1251») – це означає, що перетворення з машинного коду буде здійснюватися згідно таблиці CP1251.

Кодування windows 1251 в htaccess

При створенні сайту, попередньо налаштувавши кодування в шаблонах і базах даних, все одно може виникнути проблема некоректного відображення інформації в браузері.

Цікаві рішення Perl. Запитання і відповіді Як конвертувати рядок з UTF-8 у Windows-1251?

Є як мінімум 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

Ось уже півтора роки в draft-ах припадав пилом пост про надуманість проблем з кодуваннями і т.зв. AJAX-ом.
Щоразу, коли на форумах спливали питання подібного характеру, хотілося дати посилання, на кожен сплеск заходів на блог за запитами “кодування, ajax, проблема” хотілося його опублікувати, але мені здавалося, що піст ще не закінчений, треба ще трохи дописати …
Але буквально сьогодні з'явився дивно схожий пост - ajax, CP1251. Схожий за змістом, але протилежний за змістом.
Тому свій черневічок я вирішив видалити, а розповісти свою "істину" у формі критики ради fxposter-а.

Ні для кого ні секрет, що кодуванням отриманих через Ajax даних за замовчуванням приймається UTF-8.

Насправді, це секрет. Багатьом секрет. І багато хто не розуміє чому це так.
Внутрішнє представлення рядків (і регулярних виразів) JavaScript для всіх не-ASCII послідовностей якраз UTF-8.
Звідси й походить т.зв. “проблема” – якщо кодування не вказано явно та використовується нелатиниця, воно буде інтерпретовано як utf-8 послідовність.

Update 29.11 Свіже повітря і Давид Мзареулян остудили запал, тому поспішаю уточнити про що саме йтиметься нижче.
Отже – у вас є якийсь ресурс в однобайтовому кодуванні (до ворожки не ходи це буде windows-1251) і ви перейнялися освоїти новий buzzword на ім'я AJAX. Трохи почитавши, ви робите перші боязкі кроки в цьому напрямку і відразу наступаєте на “дитячі граблі”, а потім, трохи віддихавшись, мчіться на форуми з криком про допомогу. І вам цю допомогу нададуть – перероби мовляв, свій ресурс на utf-8… Звісно, ​​звичайно скажете ви і підете переробляти…
Я ж хочу застерегти від таких необачних кроків.

Стандартне рішення, яке навперебій радять усі – "використовуй 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 сам собі злий буратин.

  Будь-який зареєстрований IANA charset може бути використаний, але UTF-8 є preferred.

  Ну немає серед any registered кодування з назвою CP1251…

Для повноти картини наведу кілька проблемних моментів, з якими зіткнутися доведеться:

• Не дозволяйте AJAX-відповідям, які містять “нелатиницю” залишатися в кеші браузера (при 304 Not Modified відповідь підніметься з кеша, але як charset “деякі браузери” використовують utf-8)

Цим правилом НАХЛА користуються виробники різних бібліотек для json_code, але браузерам (як ми з'ясували раніше) головне кодування вказати, а там все розрулиться.
Звідси і “проблема” – кодувати дані в JSON потрібно вручну, поширені бібліотечні функції на вході очікують на utf-8.

Мораль цієї байки я чекаю від вас у коментарях.

AJAX та проблеми з кодуванням