Кодовая таблица utf 8. HTML кодировка

). А здесь пойдёт речь о практической стороне использования 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?

Говорят, что у некоторых пользователей всё ещё установлены старые браузеры, которые не способны отображать страницы в UTF‑8. Это полная ерунда. Даже Internet Explorer 4 и Netscape 4, которыми уже давно никто не пользуется, прекрасно понимают UTF‑8. А более современные браузеры - и подавно.

UTF‑8 - вовсе не «новомодная» или «молодая» кодировка, она успешно применяется более десяти лет. Если некий разработчик узнал о ней недавно или не знает до сих пор - это недостаток его квалификации, а не кодировки.

С UTF‑8 возникают проблемы на веб‑сервере?

«Я поместил на сервер страницу в UTF‑8, а она отображается кракозябрами»,- так иногда жалуются начинающие разработчики. На самом деле, такая проблема случается с самыми разными кодировками и не связана ни с какими специфическими особенностями UTF‑8. Здесь неприятность в том, что страница сделана в одной кодировке, а сервер в заголовках HTTP сообщает другую. Надо привести настройки сервера в соответствие с действительной кодировкой веб‑страниц. Повторю, что это надо сделать при любой кодировке.

Файлы в UTF‑8 занимают много места?

Говорят, что документы в 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, потому что они от этого увеличиваются» - а сам при этом ваяет код с жуткими атрибутами и подстановками, который без них мог бы быть в пять раз короче.

Серверные языки программирования и базы данных плохо поддерживают UTF‑8?

Кто‑то скажет: «Всё это хорошо, пока мы имеем дело со статичными веб‑страницами. Но если мы пользуемся PHP и MySQL, про UTF‑8 лучше забыть». Это тоже неправда. В древности, действительно, некоторые языки программирования и системы управления базами данных не умели работать с UTF‑8. Но сейчас все современные языки программирования и базы данных находятся в прекрасных отношениях с этой кодировкой. А несовременными языками и базами пользоваться не стóит: чем древнее ваши системы, тем проще их взломать.

Однако не забывайте о том, что мир постоянно меняется. Возможно, в будущем возникнут причины, которые заставят нас отказаться от UTF‑8 и перейти на какую‑то ещё более совершенную кодировку. Когда это случится, я обязательно вам сообщу.

Перед создателем сайтов всегда встает проблема: в какой кодировке создавать проект. В русскоязычном интернете используются две кодировки:

UTF-8 (от англ. Unicode Transformation Format ) - в настоящее время распространённая кодировка, реализующая представление Юникода, совместимое с 8-битным кодированием текста.

Windows-1251 (или cp1251 ) - набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows.

UTF-8 более перспективна. Но у любой вещи есть недостатки. И решение об использовании какой-то кодировки только потому, что она перспективна, без учета многих других факторов, не представляется правильным. Выбор будет оптимальным только тогда, когда он полностью учитывает все нюансы конкретного проекта. Другое дело, что предусмотреть все нюансы - само по себе весьма не просто.

Мы считаем, что использование UTF-8 предпочтительнее, но решать что выбрать - это дело разработчика проекта. А для облегчения этого выбора используйте сравнительную таблицу особенностей обеих кодировок.

Как перевести сайт с кодировки win1251 в UTF-8

Общий порядок действий:

1. Перекодировать всю базу данных в UTF-8 (вероятнее всего придётся обращаться за помощью к администратору сервера).

2. Перекодировать все файлы сайта в UTF-8 (можно сделать своими силами).

3. В файл /bitrix/php_interface/dbconn.php добавить строки:

4. В файл /.htaccess добавить строки:

Php_value mbstring.func_overload 2 php_value mbstring.internal_encoding UTF-8

Перекодировать все файлы сайта в UTF-8 (второй пункт) можно выполнив команду через SSH в корневой папке сайта:

Find . -name "*.php" -type f -exec iconv -fcp1251 -tutf8 -o /tmp/tmp_file {} \; -exec mv /tmp/tmp_file {} \;

Задаём набор символов

Мета-тег

Нужно добавить на каждую страницу (или в шаблон шапки) специальный мета-тег, сообщающий браузеру о том, какой набор символов ему использовать для отображения текстов. Тег этот стандартный и выглядит обычно так:

charset=UTF-8 » />

charset=»utf-8″ /> (вариант для HTML 5)

Надо вставить его в раздел — лучше в самое начало, сразу после открывающего :

Мета-тег кодировки

Через.htaccess (если ничего не помогает)

Обычно первых двух вариантов достаточно и браузеры отображают текст как надо . Но с некоторыми из них могут быть проблемы и поэтому можно прибегнуть к помощи файла.htaccess .

Для этого в нём нужно прописать такую строчку:

AddDefaultCharset utf-8

Вот и всё. Если вы примените последовательно 3 этих способа задания кодировки на своём проекте, то вероятность того, что всё будет отображено как надо , близка к 100 %.

Как «увидеть», что скрывается за непонятными символами на сайте?

Если вы зашли на веб-страницу, видите «кракозябры» и хотите увидеть нормальный текст, то тут только два пути:

• сообщить сайтовладельцу, чтобы всё настроил как следует
• попытаться угадать кодировку самостоятельно. Делается это стандартными средствами браузеров. В Chrome, например, нужно в меню щёлкнуть «Инструменты => Кодировка» и из огромного списка выбрать подходящий набор символов (т.е. угадать).

К счастью, практически все современные веб-проекты делаются в кодировке UTF-8, которая является «универсальной» для разных алфавитов и поэтому всё менее и менее вероятно увидеть эти непонятные символы в Интернет.

Первая серьёзная проблема, с которой сталкиваются большинство новичков при , связана с набором символов (англ. character set ). Выражается эта проблема с кодировкой в, так называемых, «кракозябриках», которые мы получаем вместо указанных в HTML-файле символов. В данной статье я хочу остановиться на проблеме с кодировкой подробнее, постараться расставить всё по полочкам и дать варианты решения.

• Что такое кодировка?
• Кодировка файла (редактирование в Notepad++)
• Кодировка отображения (просмотр в браузере)
• Как указать кодировку HTML-страницы? (метатег charset)
• Всё ещё есть проблема с кодировкой? (header charset в php)

Что такое кодировка?

Условно говоря, каждый символ (знак) состоит из кода и картинки . Здесь код - это уникальный идентификатор символа в наборе символов, который определяется выбранной кодировкой , а картинка - это визуальное представление символа, которое содержится в файле шрифта в соответствующей коду символа ячейке.

Другими словами, кодировка (англ. charset ) - это набор взаимосвязей кодов символов с их визуальными представлениями в шрифте.

Кодировка файла

HTML-страница представляет собой обычный текстовый файл, кодировка которого выбирается при его создании и/или сохранении на запоминающее устройство (жёсткий диск, флэшка и т.д.) .

В случае с Notepad++, кодировка нового документа задаётся в настройках текстового редактора. Выбираем в меню: Опции > Настройки… - и переходим на вкладку «Новый документ ». Здесь нас интересует секция «Кодировка ». По умолчанию, выбрана кодировка ANSI .

Напомню, что это кодировка, в которой будет храниться HTML-файл.

Впрочем, Вы всегда можете преобразовать кодировку HTML-страницы, используя соответствующие функции текстового редактора. Например, в Notepad++ для этого кликните пункт меню «Кодировки » и выберите нужное преобразование.

В данном случае файл был в кодировке ANSI и я преобразовал его в UTF-8 (без BOM) . О том, что такое этот BOM Вы можете прочитать в моей статье: PHP: как удалить BOM в WordPress - проследовав по .

Кодировка отображения

Важно разделять кодировку файла и кодировку отображения . Независимо от того, в какой кодировке хранится файл, он может быть отображен и в любой другой кодировке. Это и является одной из причин проблем с кодировкой.

Например, если Вы сохранили HTML-страницу в кодировке ANSI и откроете её в браузере, вместо русских символов Вы можем получить, так называемые, «кракозябрики».

В данном случае нам надо убедиться, что кодировка файла совпадает с кодировкой отображения файла в браузере. Для этого в Firefox кликните иконку меню, а потом пункт «Кодировка ». Если такого у Вас нет, кликните пункт «Изменить » и добавьте элемент «Кодировка » в меню.

Как вы видите, браузер отображает файл в кодировке «Юникод » (например, UTF-8 ) , в то время как файл был сохранён в кодировке ANSI (например, Windows-1251 ) . Выбрав нужную кодировку, мы получим нужный нам результат.

В случае с Notepad++ также имеется возможность выбора кодировки отображения. Для этого кликните пункт меню «Кодировки », а потом нужный вариант используемой для отображения кодировки.

В данном случае я изменил кодировку отображения ANSI на UTF-8 (без BOM) .

Как указать кодировку HTML-страницы?

И так, мы уже разобрались с тем, что такое кодировка и в чём состоит отличие кодировки файла и кодировки отображения. Теперь нам нужно решить проблему с кодировкой, которая заключается в неправильной интерпретации браузером (или любым другим клиентом) кодировки HTML-страницы.

Почему возникают проблемы с кодировкой? Определить кодировку HTML-страницы не просто, а зачастую и не возможно, т.к. у того же браузера нет информации о ней или она указана неправильно.

Для того чтобы указать кодировку HTML-страницы используется специальный метатег. В HTML5 он имеет следующий урезанный вид:

В данном случае указана кодировка UTF-8 (Юникод) .

В более старых версиях HTML этот метатег имеет следующий вид:

Этот метатег создаёт HTTP-заголовок Content-Type , в котором указывается тип документа text/html и его кодировка Windows-1251 (ANSI) .

Лично я рекомендую использовать именно этот вариант, т.к. с ним будет меньше всего проблем. Главное чтобы такой метатег присутствовал в секции HEAD , и указанная в нём кодировка соответствовала кодировке файла. В большинстве случаев этого будет достаточно.

Всё ещё есть проблема с кодировкой?

В некоторых случаях указать метатег с кодировкой HTML-страницы будет недостаточно. Такая проблема может быть вызвана настройками самого сервера, на котором находится файл HTML-страницы. Дело в том, что сервер способен выдавать свой HTTP-заголовок Content-Type , который будет, условно говоря, иметь приоритет перед метатегом.

В данном случае эту проблему можно решить путём внесения изменений в настройки сервера. Я не буду вдаваться в детали данного вопроса и порекомендую лишь отключать всю эту перекодировку через файл .htaccess , например:

CharsetDisable Off

Также можно производить изменения HTTP-заголовка Content-Type и программными средствами. В том же PHP для этого используется функция header() , например:

header("Content-Type: text/html; charset=UTF-8");

Обращаю Ваше внимание на то, что указание HTTP-заголовков должно идти до вывода какой-то информации на экран, в противном случае Вы получите сообщение об ошибке.

Одной из самых частых проблем, с которой сталкивается начинающий Web-мастер (да и не только начинающие), это проблемы с кодировкой на сайте . Даже у меня постоянно появляется при создании сайтов "абракадабра ". Но, благо, я прекрасно знаю, как эту проблему решить, поэтому всё привожу в порядок в течение нескольких секунд. И в этой статье я постараюсь научить Вас также быстро решать проблемы, связанные с кодировкой на сайте .

Первое, что стоит отметить, это то, что все проблемы с появлением "абракадабры" связаны с несовпадением кодировки документа и кодировки, выставляемой браузером . Допустим, документ в windows-1251 , а браузер почему-то выставляет UTF-8 . А уже источником такого несовпадения могут быть следующие причины.

Первая причина

Неправильно прописан мета-тег content-type . Будьте внимательны, в нём всегда должна находиться та кодировка, в котором написан Ваш документ.

Вторая причина

Вроде бы, мета-тег прописан так, как Вы хотите, и браузер выставляет именно то, что Вы хотите, но почему-то всё равно с кодировкой проблемы. Здесь, почти наверняка, виновато то, что сам документ имеет отличную кодировку. Если Вы работаете в Notepad++ , то внизу справа есть название кодировки текущего документа (например, ANSI ). Если Вы ставите в мета-теге UTF-8 , а сам документ написан в ANSI , то сделайте преобразование в UTF-8 (через меню "Кодировки " и пункт "Преобразовать в UTF-8 без BOM ").

Третья причина

Четвёртая причина

И, наконец, последняя популярная причина - это проблема с кодировкой в базе данных . Во-первых, убедитесь, что все Ваши таблицы и поля написаны в одной кодировке, которая совпадает с кодировкой остального сайта. Если это не помогло, то сразу после подключения в скрипте выполните следующий запрос:

SET NAMES "utf8"

Вместо "utf8 " может стоять другая кодировка. После этого все данные из базы должны выходить в правильной кодировке.

В данной статье я, надеюсь, разобрал, как минимум, 90% проблем, связанных с появлением "абракадабры" на сайте . Теперь Вы должны расправляться с такой популярной и простой проблемой, как неправильная кодировка, в два счёта.