Сегодня мы поговорим с вами про то, откуда берутся кракозябры на сайте и в программах, какие кодировки текста существуют и какие из них следует использовать. Подробно рассмотрим историю их развития, начиная от базовой ASCII, а также ее расширенных версий CP866, KOI8-R, Windows 1251 и заканчивая современными кодировками консорциума Юникод UTF 16 и 8. Оглавление:
Именно эти 128 символов из первоначального вариант ASCII стали стандартом, и в любой другой кодировке вы их обязательно встретите и стоять они будут именно в таком порядке.
Но дело в том, что с помощью одного байта информации можно закодировать не 128, а целых 256 различных значений (двойка в степени восемь равняется 256), поэтому вслед за базовой версией Аски появился целый ряд расширенных кодировок ASCII
, в которых можно было кроме 128 основных знаков закодировать еще и символы национальной кодировки (например, русской).
Тут, наверное, стоит еще немного сказать про системы счисления, которые используются при описании. Во-первых, как вы все знаете, компьютер работает только с числами в двоичной системе, а именно с нулями и единицами («булева алгебра», если кто проходил в институте или в школе). Один байт состоит из восьми бит, каждый из которых представляет из себя двойку в степени, начиная с нулевой, и до двойки в седьмой:
Не трудно понять, что всех возможных комбинаций нулей и единиц в такой конструкции может быть только 256. Переводить число из двоичной системы в десятичную довольно просто. Нужно просто сложить все степени двойки, над которыми стоят единички.
В нашем примере это получается 1 (2 в степени ноль) плюс 8 (два в степени 3), плюс 32 (двойка в пятой степени), плюс 64 (в шестой), плюс 128 (в седьмой). Итого получает 233 в десятичной системе счисления. Как видите, все очень просто.
Но если вы присмотритесь к таблице с символами ASCII, то увидите, что они представлены в шестнадцатеричной кодировке. Например, «звездочка» соответствует в Аски шестнадцатеричному числу 2A. Наверное, вам известно, что в шестнадцатеричной системе счисления используются кроме арабских цифр еще и латинские буквы от A (означает десять) до F (означает пятнадцать).
Ну так вот, для перевода двоичного числа в шестнадцатеричное
прибегают к следующему простому и наглядному способу. Каждый байт информации разбивают на две части по четыре бита, как показано на приведенном выше скриншоте. Т.о. в каждой половинке байта двоичным кодом можно закодировать только шестнадцать значений (два в четвертой степени), что можно легко представить шестнадцатеричным числом.
Причем, в левой половине байта считать степени нужно будет опять начиная с нулевой, а не так, как показано на скриншоте. В результате, путем нехитрых вычислений, мы получим, что на скриншоте закодировано число E9. Надеюсь, что ход моих рассуждений и разгадка данного ребуса вам оказались понятны. Ну, а теперь продолжим, собственно, говорить про кодировки текста.
Видите, в правом столбце цифры начинаются с 8, т.к. числа с 0 до 7 относятся к базовой части ASCII (см. первый скриншот). Т.о. русская буква «М» в CP866 будет иметь код 9С (она находится на пересечении соответствующих строки с 9 и столбца с цифрой С в шестнадцатеричной системе счисления), который можно записать в одном байте информации, и при наличии подходящего шрифта с русскими символами эта буква без проблем отобразится в тексте.
Откуда взялось такое количество псевдографики в CP866
? Тут все дело в том, что эта кодировка для русского текста разрабатывалась еще в те мохнатые года, когда не было такого распространения графических операционных систем как сейчас. А в Досе, и подобных ей текстовых операционках, псевдографика позволяла хоть как-то разнообразить оформление текстов и поэтому ею изобилует CP866 и все другие ее ровесницы из разряда расширенных версий Аски.
CP866 распространяла компания IBM, но кроме этого для символов русского языка были разработаны еще ряд кодировок, например, к этому же типу (расширенных ASCII) можно отнести KOI8-R
:
Принцип ее работы остался тот же самый, что и у описанной чуть ранее CP866 - каждый символ текста кодируется одним единственным байтом. На скриншоте показана вторая половина таблицы KOI8-R, т.к. первая половина полностью соответствует базовой Аски, которая показана на первом скриншоте в этой статье.
Среди особенностей кодировки KOI8-R можно отметить то, что русские буквы в ее таблице идут не в алфавитном порядке, как это, например, сделали в CP866.
Если посмотрите на самый первый скриншот (базовой части, которая входит во все расширенные кодировки), то заметите, что в KOI8-R русские буквы расположены в тех же ячейках таблицы, что и созвучные им буквы латинского алфавита из первой части таблицы. Это было сделано для удобства перехода с русских символов на латинские путем отбрасывания всего одного бита (два в седьмой степени или 128).
Из-за такого обилия кодировок русского языка, у производителей шрифтов и производителей программного обеспечения постоянно возникала головная боль, а у нас с вам, уважаемые читатели, зачастую вылезали те самые пресловутые кракозябры
, когда происходила путаница с используемой в тексте версией.
Очень часто они вылезали при отправке и получении сообщений по электронной почте, что повлекло за собой создание очень сложных перекодировочных таблиц, которые, собственно, решить эту проблему в корне не смогли, и зачастую пользователи для переписки использовали транслит латинских букв, чтобы избежать пресловутых кракозябров при использовании русских кодировок подобных CP866, KOI8-R или Windows 1251.
По сути, кракозябры, вылазящие вместо русского текста, были результатом некорректного использования кодировки данного языка, которая не соответствовала той, в которой было закодировано текстовое сообщение изначально.
Допустим, если символы, закодированные с помощью CP866, попробовать отобразить, используя кодовую таблицу Windows 1251, то эти самые кракозябры (бессмысленный набор знаков) и вылезут, полностью заменив собой текст сообщения.
Аналогичная ситуация очень часто возникает при создании и настройке сайтов, форумов или блогов, когда текст с русскими символами по ошибке сохраняется не в той кодировке, которая используется на сайте по умолчанию, или же не в том текстовом редакторе, который добавляет в код отсебятину не видимую невооруженным глазом.
В конце концов такая ситуация с множеством кодировок и постоянно вылезающими кракозябрами многим надоела, появились предпосылки к созданию новой универсальной вариации, которая бы заменила собой все существующие и решила бы, наконец, на корню проблему с появлением не читаемых текстов. Кроме этого существовала проблема языков подобных китайскому, где символов языка было гораздо больше, чем 256.
Сколько символов можно закодировать в UTF-16 с помощью 16 бит? 65 536 (два в степени шестнадцать), и именно это число было принято за базовое пространство в Юникоде. Помимо этого существуют способы закодировать с помощью нее и около двух миллионов знаков, но ограничились расширенным пространством в миллион символов текста.
Но даже эта удачная версия кодировки Юникода не принесла особого удовлетворения тем, кто писал, допустим, программы только на английском языке, ибо у них, после перехода от расширенной версии ASCII к UTF-16, вес документов увеличивался в два раза (один байт на один символ в Аски и два байта на тот же самый символ в ЮТФ-16).
Вот именно для удовлетворения всех и вся в консорциуме Unicode было решено придумать кодировку
переменной длины. Ее назвали UTF-8. Несмотря на восьмерку в названии, она действительно имеет переменную длину, т.е. каждый символ текста может быть закодирован в последовательность длиной от одного до шести байт.
На практике же в UTF-8 используется только диапазон от одного до четырех байт, потому что за четырьмя байтами кода ничего уже даже теоретически не возможно представить. Все латинские знаки в ней кодируются в один байт, так же как и в старой доброй ASCII.
Что примечательно, в случае кодирования только латиницы, даже те программы, которые не понимают Юникод, все равно прочитают то, что закодировано в ЮТФ-8. Т.е. базовая часть Аски просто перешла в это детище консорциума Unicode.
Кириллические же знаки в UTF-8 кодируются в два байта, а, например, грузинские - в три байта. Консорциум Юникод после создания UTF 16 и 8 решил основную проблему - теперь у нас в шрифтах существует единое кодовое пространство
. И теперь их производителям остается только исходя из своих сил и возможностей заполнять его векторными формами символов текста.
В приведенной чуть выше «Таблице символов» видно, что разные шрифты поддерживают разное количество знаков. Некоторые насыщенные символами Юникода шрифты могут весить очень прилично. Но зато теперь они отличаются не тем, что они созданы для разных кодировок, а тем, что производитель шрифта заполнил или не заполнил единое кодовое пространство теми или иными векторными формами до конца.
В случае сайта на Joomla 1.5 и выше, а также в случае блога на WordPress следует во избежании появления кракозябров выбирать вариант UTF 8 без BOM
. А что такое приставка BOM?
Дело в том, что когда разрабатывали кодировку ЮТФ-16, зачем-то решили прикрутить к ней такую вещь, как возможность записывать код символа, как в прямой последовательности (например, 0A15), так и в обратной (150A). А для того, чтобы программы понимали, в какой именно последовательности читать коды, и был придуман BOM
(Byte Order Mark или, другими словами, сигнатура), которая выражалась в добавлении трех дополнительных байтов в самое начало документов.
В кодировке UTF-8 никаких BOM предусмотрено в консорциуме Юникод не было и поэтому добавление сигнатуры (этих самых пресловутых дополнительных трех байтов в начало документа) некоторым программам просто-напросто мешает читать код. Поэтому мы всегда при сохранении файлов в ЮТФ должны выбирать вариант без BOM (без сигнатуры). Таким образом, вы заранее обезопасите себя от вылезания кракозябров
.
Что примечательно, некоторые программы в Windows не умеют этого делать (не умеют сохранять текст в ЮТФ-8 без BOM), например, все тот же пресловутый Блокнот Windows. Он сохраняет документ в UTF-8, но все равно добавляет в его начало сигнатуру (три дополнительных байта). Причем эти байты будут всегда одни и те же - читать код в прямой последовательности. Но на серверах из-за этой мелочи может возникнуть проблема - вылезут кракозябры.
Поэтому ни в коем случае не пользуйтесь обычным блокнотом Windows
для редактирования документов вашего сайта, если не хотите появления кракозябров. Лучшим и наиболее простым вариантом я считаю уже упомянутый редактор Notepad++, который практически не имеет недостатков и состоит из одних лишь достоинств.
В Notepad ++ при выборе кодировки у вас будет возможность преобразовать текст в кодировку UCS-2, которая по своей сути очень близка к стандарту Юникод. Также в Нотепаде можно будет закодировать текст в ANSI, т.е. применительно к русскому языку это будет уже описанная нами чуть выше Windows 1251. Откуда берется эта информация?
Она прописана в реестре вашей операционной системы Windows - какую кодировку выбирать в случае ANSI, какую выбирать в случае OEM (для русского языка это будет CP866). Если вы установите на своем компьютере другой язык по умолчанию, то и эти кодировки будут заменены на аналогичные из разряда ANSI или OEM для того самого языка.
После того, как вы в Notepad++ сохраните документ в нужной вам кодировке или же откроете документ с сайта для редактирования, то в правом нижнем углу редактора сможете увидеть ее название:
Чтобы избежать кракозябров
, кроме описанных выше действий, будет полезным прописать в его шапке исходного кода всех страниц сайта информацию об этой самой кодировке, чтобы на сервере или локальном хосте не возникло путаницы.
Вообще, во всех языках гипертекстовой разметки кроме Html используется специальное объявление xml, в котором указывается кодировка текста.
<
?
xml version=
"1.0"
encoding=
"windows-1251"
?
>
Прежде, чем начать разбирать код, браузер узнает, какая версия используется и как именно нужно интерпретировать коды символов этого языка. Но что примечательно, в случае, если вы сохраняете документ в принятом по умолчанию юникоде, то это объявление xml можно будет опустить (кодировка будет считаться UTF-8, если нет BOM или ЮТФ-16, если BOM есть).
В случае же документа языка Html для указания кодировки используется элемент Meta
, который прописывается между открывающим и закрывающим тегом Head:
<
head>
.
.
.
<
meta charset=
"utf-8"
>
.
.
.
<
/
head>
Эта запись довольно сильно отличается от принятой в стандарте в Html 4.01, но полностью соответствует новому внедряемому потихоньку стандарту Html 5, и она будет стопроцентно правильно понята любыми используемыми на текущий момент браузерами.
По идее, элемент Meta с указание кодировки Html документа лучше будет ставить как можно выше в шапке документа
, чтобы на момент встречи в тексте первого знака не из базовой ANSI (которые правильно прочитаются всегда и в любой вариации) браузер уже должен иметь информацию о том, как интерпретировать коды этих символов.
Ссылка на перво
). А здесь пойдёт речь о практической стороне использования UTF‑8.
В кодировке UTF‑8 вы можете непосредственно включать в документ любые символы из всего набора Unicode. Старинные кодировки (например, Windows‑1251 или KOI8‑R) предоставляли не более 256 символов, а в Unicode есть свыше 100 000 символов. Среди них - типографские знаки (тире, кавычки, многоточие, апостроф, неразрывный пробел, неразрывный дефис и пр.), специальные символы (№, §, ©, ‰, × и пр.), буквы с диакритическими знаками и лигатуры (é, è, Ü, Æ, ø, fi и пр.), символы почти всех существующих в мире алфавитов (α, Ω, א, ת, ѣ , 伲 , 儻 и пр.), пиктограммы и значки (→, ■, , ☺ и пр.) и множество других символов.
Загляните в «Таблицу символов» на своём компьютере. В кодировке UTF‑8 вы можете взять прямо из этой таблицы любой символ и вставить его непосредственно в свой документ. Если вам нужен знак копирайта, градуса или интеграла - не требуется искать особый шрифт, представлять этот знак в графическом формате или выдумывать ещё какие‑то ухищрения. В кодировке UTF‑8 любой символ, будь то дробь ⅓ или китайский иероглиф, можно использовать в документе точно так же, как латинскую букву «A», русскую «Ы» или знак «+».
В старых кодировках можно было вставить в документ особые символы с помощью подстановок (references ). Например, длинному тире соответствовала подстановка & mdash ; (а также & # 8212 ; или & # x2014 ; ), а греческой букве «пи» - подстановка & pi ; (а также & # 960 ; или & # x3c0 ; ). Для большинства символов существовали только числовые подстановки: например, для дроби ⅓ - & # 8531 ; или & # x2153 ; , для музыкального знака «бемоль» - & # 9837 ; или & # x266d ; , для неразрывного дефиса - & # 8209 ; или & # x2011 ; . Конечно, это очень неудобно. Во‑первых, слишком длинно: например, вместо одного символа «♭ » приходится вставлять семь: & # 9837 ; . Во‑вторых, документ с подстановками неприятно просматривать и редактировать. Гораздо удобнее, когда вы видите в документе непосредственно те символы, которые там должны быть, а не коды вроде & mdash ; или & # x3c0 ; .
Когда‑то давно разработчики веб‑страниц были вынуждены пользоваться такими громоздкими подстановками, потому что кодировки UTF‑8 ещё не существовало. Но теперь можно забыть как про подстановки, так и про старые кодировки.
Обсудив преимущества UTF‑8, стоило бы поговорить и о недостатках этой кодировки. А недостатков, представьте себе, у неё нет. Есть только мифы и легенды, а также слухи и домыслы, которые распространяют замшелые консерваторы и махровые ретрограды. Много лет назад некоторые недостатки действительно имели место, но сейчас они канули в Лету.
Говорят, что у некоторых пользователей всё ещё установлены старые браузеры, которые не способны отображать страницы в UTF‑8. Это полная ерунда. Даже Internet Explorer 4 и Netscape 4, которыми уже давно никто не пользуется, прекрасно понимают UTF‑8. А более современные браузеры - и подавно.
UTF‑8 - вовсе не «новомодная» или «молодая» кодировка, она успешно применяется более десяти лет. Если некий разработчик узнал о ней недавно или не знает до сих пор - это недостаток его квалификации, а не кодировки.
«Я поместил на сервер страницу в UTF‑8, а она отображается кракозябрами»,- так иногда жалуются начинающие разработчики. На самом деле, такая проблема случается с самыми разными кодировками и не связана ни с какими специфическими особенностями UTF‑8. Здесь неприятность в том, что страница сделана в одной кодировке, а сервер в заголовках HTTP сообщает другую. Надо привести настройки сервера в соответствие с действительной кодировкой веб‑страниц. Повторю, что это надо сделать при любой кодировке.
Говорят, что документы в UTF‑8 становятся в два раза больше, чем в старых кодировках. Это миф из разряда «слышал звон, да не знаю, где он». На самом деле - раз на раз не приходится. Например, если документ состоит только из символов ASCII (латинские буквы, цифры, знаки препинания и т. д.) - то в кодировке UTF‑8 он будет занимать ровно столько же байтов, сколько в любой другой. Если документ содержит только буквы русского алфавита и никаких других символов (что, согласитесь, бывает достаточно редко) - то в UTF‑8 он действительно станет в два раза больше. А если в нём, например, поровну русских и арабских букв - в UTF‑8 он будет в два раза меньше, чем, например, в Windows‑1251 или Asmo‑708.
Та самая страница, которую вы сейчас читаете, в кодировке UTF‑8 занимает 35 килобайтов. А если перевести её, например, в Windows‑1251, она будет занимать 26 килобайтов. Кстати, сравнивая страницы, посмотрите, насколько легче читается код в UTF‑8.
Рассуждая о «весе» веб‑страниц, следует отметить, что основную часть этого веса обычно составляет не код HTML, а изображения. (А также, возможно, другие объекты: ролики Flash, файлы JavaScript и т. д.) В результате даже в тех случаях, когда документ в UTF‑8 увеличивается - это практически незаметно в общем объёме данных. По‑моему, «разбухание» кода на несколько процентов - недорогая цена за UTF‑8, с которого мы начали.
Тем, кто заботится о «весе», следовало бы в первую очередь выкинуть из кода устаревшие атрибуты HTML (вроде cellpadding или valign) и подстановки для тех символов, которым они не нужны (например, & mdash ; для длинного тире или & nbsp ; для неразрывного пробела). Действительно, иногда доходит до маразма - некто упирается: «Не буду делать страницы в UTF‑8, потому что они от этого увеличиваются» - а сам при этом ваяет код с жуткими атрибутами и подстановками, который без них мог бы быть в пять раз короче.
Кто‑то скажет: «Всё это хорошо, пока мы имеем дело со статичными веб‑страницами. Но если мы пользуемся PHP и MySQL, про UTF‑8 лучше забыть». Это тоже неправда. В древности, действительно, некоторые языки программирования и системы управления базами данных не умели работать с UTF‑8. Но сейчас все современные языки программирования и базы данных находятся в прекрасных отношениях с этой кодировкой. А несовременными языками и базами пользоваться не стóит: чем древнее ваши системы, тем проще их взломать.
Однако не забывайте о том, что мир постоянно меняется. Возможно, в будущем возникнут причины, которые заставят нас отказаться от UTF‑8 и перейти на какую‑то ещё более совершенную кодировку. Когда это случится, я обязательно вам сообщу.
Последние несколько часов я провел на своем веб-сайте, чтобы проверить HTML 4.01 Strict, и я на самом деле преуспел в этом, но есть еще одно предупреждение, от которого я не могу избавиться. Предупреждение:
Несоответствие кодировки символов!
Кодировка символов, указанная в HTTP-заголовок (iso-8859-1) является отличается от значения в элемент (utf-8). Я буду использовать значение из заголовка HTTP (iso-8859-1) для это подтверждение.
Для получения общей информации о том, как изменить заголовок набора символов в разных сетевых стеках, см. http://www.w3.org/International/O-HTTP-charset
2018-05-25 13:30
Сервер четко маркирует документ как ISO-8859-1 в заголовках HTTP. Попробуйте сохранить default.html с использованием кодировки UTF-8 с помощью соответствующего редактора.
2018-05-25 03:07
Хорошо, я придумал частичное решение моей проблемы. Поскольку это был только файл default.html, который вызывал предупреждение, я предположил, что сервер делает что-то особенное для него из-за его имени. Поэтому я создал новый файл home.html с тем же содержимым, что и файл default.html, и указал файл.htaccess на новый файл (см. Строку 3 ниже).
# Use PHP5 as default AddHandler application/x-httpd-php5 .php DirectoryIndex home.html AddDefaultCharset UTF-8
Это устранило проблему, и все файлы теперь распознаются как UTF-8. Я все еще не уверен, что сервер делает с файлом default.html или где настройки, касающиеся этого, но по мере того, как моя проблема ушла, я забуду об этом.
Одной из самых частых проблем, с которой сталкивается начинающий Web-мастер (да и не только начинающие), это проблемы с кодировкой на сайте . Даже у меня постоянно появляется при создании сайтов "абракадабра ". Но, благо, я прекрасно знаю, как эту проблему решить, поэтому всё привожу в порядок в течение нескольких секунд. И в этой статье я постараюсь научить Вас также быстро решать проблемы, связанные с кодировкой на сайте .
Первое, что стоит отметить, это то, что все проблемы с появлением "абракадабры" связаны с несовпадением кодировки документа и кодировки, выставляемой браузером . Допустим, документ в windows-1251 , а браузер почему-то выставляет UTF-8 . А уже источником такого несовпадения могут быть следующие причины.
Неправильно прописан мета-тег content-type . Будьте внимательны, в нём всегда должна находиться та кодировка, в котором написан Ваш документ.
Вроде бы, мета-тег прописан так, как Вы хотите, и браузер выставляет именно то, что Вы хотите, но почему-то всё равно с кодировкой проблемы. Здесь, почти наверняка, виновато то, что сам документ имеет отличную кодировку. Если Вы работаете в Notepad++ , то внизу справа есть название кодировки текущего документа (например, ANSI ). Если Вы ставите в мета-теге UTF-8 , а сам документ написан в ANSI , то сделайте преобразование в UTF-8 (через меню "Кодировки " и пункт "Преобразовать в UTF-8 без BOM ").
И, наконец, последняя популярная причина - это проблема с кодировкой в базе данных . Во-первых, убедитесь, что все Ваши таблицы и поля написаны в одной кодировке, которая совпадает с кодировкой остального сайта. Если это не помогло, то сразу после подключения в скрипте выполните следующий запрос:
SET NAMES "utf8"
Вместо "utf8 " может стоять другая кодировка. После этого все данные из базы должны выходить в правильной кодировке.
В данной статье я, надеюсь, разобрал, как минимум, 90% проблем, связанных с появлением "абракадабры" на сайте . Теперь Вы должны расправляться с такой популярной и простой проблемой, как неправильная кодировка, в два счёта.
Для того, чтобы страницы вашего сайта отображались корректно во всех браузерах и на всевозможных устройствах, нужно позаботиться об установке правильной кодировки. Несоблюдение некоторых условий, о которых мы сегодня расскажем подробно, может привести к тому, что текст превратится в бессмысленный набор символов, прочитать которые просто невозможно (кракозябры).
Каждая страница вашего сайта должна иметь определенную кодировку. О том, какая кодировка используется в данный момент необходимо сообщать браузеру, передавая специальные заголовки (header). В этих заголовках необходимо указать кодировку, соответствующую той, которую вы используете в теле документов, размещенных на сайте (на его страницах).
Современные браузеры могут и сами определить кодировку документа, если вебмастер забыл указать ее в явном виде. Иногда случается так, что возникают несостыковки между «мнением» браузера и реальностью, отсюда и появляется набор символов, которые невозможно прочитать. Набор галиматьи может принимать разные виды, иногда это будут просто странные символы, похожие на древние иероглифы, а иногда - просто вопросики или же вопросики внутри черных ромбиков. По большому счету не так важно, какие именно кракозябры отображает браузер, а важно то, что человек их прочитать не может.
Если же вы столкнулись с проблемой некорректно указанной кодировки и видите на своем сайте то, что не в состоянии прочитать, в первую очередь воспользуйтесь специальным Декодером , разработанным в студии Артемия Лебедева. Для этого просто скопируйте текст, который хотите расшифровать, вставьте его в специальное поле и нажмите «Расшифровать». В случае успешного декодирования, вы увидите уже читаемый текст, а также исходную кодировку и путь, который пришлось пройти программе, чтобы вывести результат.
Все это нужно, скорее, для продвинутых пользователей, которым полученная информация сможет чем-то помочь. Возможно, результат действий программы натолкнет вас на мысль и вы сообразите, откуда на вашем сайте берутся кракозябры и быстро исправите ситуацию. А если же проделанные манипуляции совершенно ни о чем вам не говорят, то давайте просто двигаться дальше.
В рамках данной статьи мы не будем углубляться в то, какие кодировки бывают и чем они друг от друга отличаются, т.к. не хотим перегружать ни себя, ни вас лишней информацией, да и в целях сегодняшней статьи этого не было. Стоит отметить лишь тот факт, что на русскоязычном сайте нет совершенно никакого смысла устанавливать кодировку windows-1251 , исчерпывающе описанную в замечательной статье Википедии. Даже если все тексты на нем будут написаны исключительно на русском и не будет никаких вкраплений нестандартных символов. Вместо этого нужно просто выбрать универсальную кодировку UTF-8 , приняв это как данное, не забивая голову лишней информацией.
Дело в том, что нет смысла выбирать для своего сайта кодировку, которая поддерживает одни только символы славянских языков, таких как русский, украинский, белорусский, сербский, македонский и болгарский. Зачем изначально ограничивать себя и обрекать на возможные проблемы в дальнейшем. Что вы будете делать, если понадобится вставить символ, которого нет в поддерживаемых?
UTF-8 (от англ. Unicode Transformation Format) - восьмибитный формат преобразования Юникода, который получил всемирное признание и был стандартизирован как раз для избежания проблем, связанных с появлением кракозябров и неразберихой с нечитабельными текстами. Из чего можно смело сделать вывод, что в данном случае из двух зол нужно выбирать бóльшую и спать спокойно, не вникая в подробности, потому что тут и так все понятно. Посмотрите на размер Юпитера и Венеры для сравнения.
Довольно часто проблемы с кодировкой сайта возникают не потому что не было выполнено ни одного из условий, о которых мы вам сейчас расскажем, а достаточно не выполнить всего лишь одно из них, чтобы текст на вашем сайте начал отображаться некорректно. После того, как вы установите кодировку всеми перечисленными способами, задача будет решена с вероятностью 99.9%. К такому заключению мы пришли на основании многолетнего опыта работы с сайтами на всевозможных хостинг-площадках, с использованием самых разных систем администрирования и настроек серверов.
Прежде всего, вам нужно установить кодировку всех страниц сайта по умолчанию с помощью одной очень полезной директивы htaccess - AddDefaultCharset, которая в дословном переводе с английского языка означает «ДобавитьКодировкуПоУмолчанию». Делается это очень просто:
AddDefaultCharset UTF-8
Если вы не знаете что такое , то просто создайте текстовый файл в блокноте, а затем с помощью Total Commander-а переименуйте его в файл без названия, имеющий расширение HTACCESS ( - именно так и должно выглядеть полное имя вашего файла). После этого закачайте только что созданный файл в корневую директорию вашего сайта (в то же место, где находится главный исполняющий файл, например index.php
). И не забудьте вставить строку с кодировкой по умолчанию, которую мы только что приводили.
Метатеги способны отсылать браузеру информацию о странице в виде специальных заголовков, одним из которых как раз является тот, что нам нужен - charset
. Вообще метатеги могут иметь аж 4 различных атрибута:
На самом деле, из представленных четырех атрибутов только один является обязательным - content , но существуют и исключения. Например в нашем случае будет использоваться сокращенная версия записи и мы установим кодировку с помощью метатега именно так:
Старый же формат записи давно канул в Лету и использовать его больше смысла нет:
Как известно, метатеги принято размещать внутри контейнера head . Об этом, наверное, знают уже все без исключения. Проделайте эту операцию и мы перейдем к следующему пункту в нашем списке.
Данный способ подойдет лишь тем, у кого сайт реализован с помощью самого популярного на данный момент языка программирования, по большей части ориентированного на создание веб-сайтов - PHP (Hyper Text Preprocessor). Для решения задачи, поставленной в рамках данной статьи, мы воспользуемся замечательной встроенной функцией header() , предназначенной для передачи заголовков, аналогично метатегам, но с тем небольшим отличием, что действие производится из PHP-скрипта, а не посредством вывода HTML-кода.
Установить кодировку UTF-8 для файла при помощи функции header() довольно просто - нужно просто вставить приведенный код в самое начало страницы, но разумеется внутри области действия PHP, которая обозначается так: или же так - .
Header("Content-type: text/html; charset=utf-8");
Самым важным моментом здесь является то, что заголовки мы имеем право передавать только в том случае, если перед этим не было никакого вывода со стороны скрипта. Именно поэтому мы вставляем данный код в самое начало страницы. Делать это нужно с умом и хорошо понимать, что происходит, ведь вы можете быть уверены, что вставляете заголовок в начало файла, но можете не знать, что этот файл используется в другом файле, в который подтягивается с помощью функции require
или include
уже после того, как определенная информация была выведена на экран. Поэтому если вы не очень хорошо понимаете о чем сейчас идет речь, лучше перейдите к следующему шагу и вернитесь к этому, если 3 предыдущих не помогли установить правильную кодировку страниц вашего сайта.
Одной из, наверное, самых распространенных причин возникновения кракозябров на сайте является некорректное кодирование самих фалов, использующихся для генерации конечного документа. Чаще всего такая проблема возникает у начинающих программистов, которые только делают свои первые шаги в освоении искусства . Когда в качестве движка сайта выбрана одна из популярных на данный момент систем администрирования, данная проблема может возникать в очень редких случаях, но если используется , то такое случается чуть ли не в каждом третьем случае.
Как мы условились ранее, используемая нами кодировка на всех, даже на самых прожженных русскоязычных сайтах - UTF-8, поэтому и все файлы, составляющие движок сайта мы с вами будем кодировать в этом же формате. А для того, чтобы изменить кодировку самого файла, закачиваемого на сервер, обычного блокнота, предоставляемого операционной системой Windows будет конечно же не достаточно. Поэтому лучше воспользоваться сторонней программой, распространяемой бесплатно - Notepad++, которую можно скачать на официальном сайте без особых проблем.
Успешно пройдя несложный процесс установки, вы должны будете назначить эту программу редактором по умолчанию, произвести некоторые настройки на свой вкус и поменять кодировку некорректно отображаемого файла так же, как показано на скриншоте. Т.е. вам необходимо выбрать значение «Кодировать в UTF-8 (без BOM)». Хорошим признаком того, что причина была именно в этом, будет то, что изначально не будет выбран ни один из вариантов и вам будет предложено «Преобразовать в UTF-8 (без BOM)». Если вы это увидели, то будьте уверены, что до решения проблемы с кодировкой остались считанные секунды.
В дополнение хочется сказать лишь то, что выбирать нужно именно без BOM
. В противном случае, если кодировать просто в UTF-8 (с BOM), то в начале файла будут создаваться лишние байты. BOM - Byte Order Mark стараются не использовать именно в вебе при кодировании в формате UTF-8, т.к. это приводит к ошибкам из-за создания помех корректной PHP-интерпретации.
Ну а теперь, когда все необходимые действия выполнены, вы, скорей всего, на страницах вашего сайта увидите перед собой легко читаемый текст и вздохнете свободно 🙂
