). А здесь пойдёт речь о практической стороне использования 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 предпочтительнее, но решать что выбрать - это дело разработчика проекта. А для облегчения этого выбора используйте сравнительную таблицу особенностей обеих кодировок.

Свойство UTF-8 Windows 1251 Общего характера Многоязычность Кодировка позволяет использовать разные языки как в публичной, так и в административной части сайта. Смена кодировки действующего крупного сайта с Windows-1251 на UTF-8 может вызвать серьёзные дополнительные трудовые и финансовые издержки. Русский и английский без проблем работают с Windows-1251, если точно не будет потребности в других языках, то и нет потребности в UTF-8. Большое число символов. Возможность использования спецсимволов. Есть. Но надо учитывать возможности браузеров. Штатно нет. Есть возможность замены спецсимволов на "костыли", например, © на &cорy; или × (знак умножения) на &timеs;. Однако это повышает требования к уровню подготовки контент-менеджера и создаёт проблемы при переносе данных из другой базы данных. Кроме того, в Bitrix Framework есть поля, которые не используют визуальный редактор, например, название страницы или название элемента инфоблока. Это также усложняет поддержку проекта силами низкоквалифицированных сотрудников. Скорость работы При работе сайта идет подмена всех функций работы со строками на mb_* . Это значит, что весь текст будет перекодироваться в кодировку сайта. utf strlen зависит от длины строки, соответственно обычный strlen работает в 3 раза быстрее мультибайтового: 0.0004 против 0.0013 на тысяче итераций. По замерам на это выливается в 10-15% разницу в скорости работы реального сайта. Минимизация объема проекта. Проект на UTF-8 будет заведомо "тяжелее", в силу того что строки в этой кодировке занимают в два раза больше места, чем строки в однобайтной Windows-1251. Размер сайта и базы данных будет в 1,2 - 1,5 раз больше. Поддержка большинством js-фреймворков Поддерживается без проблем. Сложности в реализации. Поддержка MS SQL По техническим причинам, данные в MS SQL должны храниться и хранятся в Windows-1251. Требуется дополнительная настройка. Нет проблем. Импорт CSV Excel не сохраняет в UTF-8. Требуется пересохранение созданного файла в этой кодировке с помощью другого редактора. Нет проблем. Импорт из 1С Сайты на UTF-8 работают без проблем при интеграции через SOAP с такими системами как, например, 1С. Вебвизор Яндекс.Метрики Вебвизор корректно записывает действия посетителей. Возможны ошибки в записи. Связанные с Bitrix Framework Возможность сделать сайты в разной кодировке по системе многосайтовости. Невозможно. Все сайты на одном ядре должны быть в одной кодировке. Поддержка на различных хостингах При работе с Bitrix Framework необходимо подключение опции php mbstring.func_overload в значении большем или равном 2 . Это . Работает на любых хостингах. Размещение продуктов на виртуальной машине BitrixVM . По умолчанию. Требует дополнительных действий по настройке. Корректное отображение пунктов меню сайта При использовании данной кодировки такая проблема возможна. Решается пересохранением каждого файла в UTF-8. (Если быть точным, то рекомендуется проверить кодировку всех файлов, а не только файлов меню и, при необходимости, перекодировать и их.) Импорт исходников в IDE, например, в eclipse pdt При выставленном в настройках проекта UTF-8, в коде ядра Bitrix Framework портятся комментарии. Нет проблем. Разные мелочи Взаимодействие с WordPress (блог-клиенты, trackback и ping"и) Есть Нет Редактирование файлов по FTP через FAR FAR поддерживает UTF только с версии 2.0. Возможно Поддержка большинством редакторов Требуется редактор, который поддерживает кодировку UTF-8 без BOM . Нет проблем.

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

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

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

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

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

define("BX_UTF", true);

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 {} \;

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

Формы кодирования

Компьютеры оперируют числами не просто как абстрактными математическими объектами, а как комбинациями единиц хранения и обработки информации фиксированного размера - байтов и 32-разрядных слов. Стандарт кодировки должен это учитывать при определении способа представления

В компьютерных системах целые числа хранятся в ячейках памяти размером 8 бит (1 байт), 16 или 32 бит. Каждая форма кодирования Юникода определяет, какая последовательность ячеек памяти представляет целое число, соответствующее конкретному символу. В стандарте представлены три различные формы кодирования символов Юникода: 8, 16 и 32-битными блоками. Соответственно, они носят название UTF-8, UTF-16 и UTF-32. Название UTF расшифровывается как формат преобразования Юникода. Каждая из трёх форм кодирования является равноправным средством представления символов Юникода, имеет преимущества в различных областях применения.

Данные кодировки могут быть использованы для представления всех символов стандарта Юникод. Таким образом, они полностью совместимы для решений, по разным причинам использующих разные формы кодирования. Каждая кодировка может быть однозначно преобразована в любую из двух других без потери данных.

Принцип неналожения

Каждая из форм кодирования Юникода разработана с учётом недопустимости частичного наложения. Например, Windows-932 формирует символы из одного или двух байтов кода. Длина последовательности зависит от первого байта, поэтому значения лидирующего байта в последовательности из двух байтов и одиночного байта не пересекаются. Однако значения одиночного байта и замыкающего байта последовательности могут совпадать. Это означает, например, что при поиске символа D (код 44) можно ошибочно найти его входящим во вторую часть последовательности из двух байтов символа «Д» (код 84 44). Чтобы выяснить, какая последовательность является правильной, программа должна учесть предыдущие байты.

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

Формат преобразования Юникода позволяет избежать данной проблемы, потому что значения ведущей, замыкающей и одиночной единицы хранения информации не совпадают. Благодаря этому все кодировки Юникода подходят для поиска и сравнения, никогда не давая ошибочного результата из-за совпадения разных частей кода символов. Тот факт, что данные формы кодирования соблюдают принцип неналожения, отличает их от других многобайтовых восточноазиатских кодировок.

Другим аспектом непересечения является то, что каждый символ имеет чётко определяемые границы. При этом отпадает необходимость в сканировании неопределённого числа предыдущих символов. Данную особенность кодировок иногда называют самосинхронизацией. Искажение одной единицы кода введёт к искажению только одного символа, а окружающие символы остаются нетронутыми. В 8-битном формате преобразования, если указатель ссылается на байт, начинающийся с 10xxxxxx (в двоичной кодировке), для поиска начала символа потребуется от одного до трёх обратных переходов.

Согласованность

Консорциум Юникода в полной мере поддерживает все 3 формы кодировок. Важно не противопоставлять UTF-8 и Юникод, ведь все форматы преобразования - одинаково правомерные воплощения форм кодирования символов стандарта Юникод.

Байт-ориентация

Для представления символа UTF-32 понадобится одна 32-битная единица кода, которая совпадает с кодом Юникода. UTF-16 - от одной до двух 16-битных единиц. А UTF-8 использует до 4 байт.

Кодировка UTF-8 создана для совместимости с байт-ориентированными системами на основе ASCII. Большая часть существующего программного обеспечения и практика информационных технологий длительное время опирались на представление символов в виде последовательности байтов. Множество протоколов зависит от неизменности и использует либо избегает специальные управляющие символы. Простым способом адаптировать Юникод к таким ситуациям можно, применив 8-битное кодирование для представления символов Юникода, эквивалентных любому или управляющему символу. Для этого и предназначена кодировка UTF-8.

Переменная длина

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

ASCII

UTF-8-кодировка полностью поддерживает коды ASCII (0x00-0x7F). Это значит, что символы Юникода U+0000-U+007F конвертируются в единственный байт 0x00-0x7F UTF-8 и таким образом становятся неотличимыми от ASCII. Более того, чтобы избежать многозначности, значения 0x00-0x7F не используются больше ни в одном байте представления символов Юникода. Для кодирования неидеографических символов, отличных от ASCII, используется последовательность из двух байтов. Символы диапазона U+0800-U+FFFF представлены тремя байтами, а дополнительные с кодами больше U+FFFF требуют четырёх байтов.

Область применения

Кодировке UTF-8 обычно отдаётся предпочтение в протоколе HTML и ему подобным.

XML стал первым стандартом с полной поддержкой кодировки UTF-8. Организации, занимающиеся стандартизацией, тоже её рекомендуют. Проблема поддержки в адресах URL, отличных от ASCII-символов, была решена, когда консорциум W3С и инженерная группа IETF пришли к соглашению о кодировании всех исключительно в UTF-8.

Совместимость с ASCII облегчает переход к новому программному обеспечению. С UTF-8 работает большинство текстовых редакторов, в том числе JEdit, Emacs, BBEdit, Eclipse и "Блокнот" операционной системы Windows. Ни одна другая форма кодирования Юникода не может похвалиться такой поддержкой со стороны инструментальных средств.

Преимущество кодировки заключается в том, что она состоит из последовательности байтов. Со строками UTF-8 легко работать в C и других языках программирования. Это единственная форма кодирования, не требующая метки порядка байтов BOM или объявления кодировки в XML.

Самосинхронизация

В окружении, использующем 8-битную обработку символов, по сравнению с другими многобайтными кодировками, UTF-8 обладает следующими преимуществами:

• Первый байт последовательности кода содержит информацию о его длине. Это повышает эффективность прямого поиска.
• Упрощено нахождение начала символа, так как начальный байт ограничен фиксированным диапазоном значений.
• Отсутствует пересечение значений байтов.

Сравнение преимуществ

UTF-8-кодировка компактна. Но при применении для кодирования восточноазиатских символов (китайских, японских, корейских, использующих знаки китайского письма) используются 3-байтные последовательности. Также UTF-8-кодировка уступает другим формам кодирования по скорости обработки. А двоичная сортировка строк даёт тот же результат, что и двоичная сортировка Юникода.

Схема кодировки символов

Схема кодировки символов состоит из формы кодирования символов и способа побайтного расположения единиц кода. Для определения схемы кодирования стандартом Юникода предусмотрено использование начальной метки порядка байтов (BOM, Byte order mark).

При включении BOM в UTF-8 функция метки ограничивается только указанием на использование формы кодирования. Проблемы определения порядка байтов у UTF-8 нет, так как её размер единицы кодирования равен одному байту. Использование BOM для данной формы кодирования не является ни обязательным, ни рекомендуемым. BOM может встречаться в текстах, конвертированных из других кодировок, использующих метку порядка байтов, или для сигнатуры кодировки UTF-8. Представляет собой последовательность из 3 байтов EF 16 BB 16 BF 16 .

Как задать кодировку UTF-8

В UTF-8 устанавливается с помощью следующего кода:

˂meta http-equiv="Content-Type" content="text/html; charset=utf-8"˃

В PHP кодировка UTF-8 задаётся с помощью функции header() в самом начале файла после задания значения уровня вывода ошибок:

error_reporting(-1);

Charset=utf-8");

Для подключения к базам данных MySQL кодировка UTF-8 устанавливается так:

mysql_set_charset("utf8");

В CSS-файлах кодировка символов UTF-8 указывается так:

@charset "utf-8";

При сохранении файлов всех типов выбирается кодировка UTF-8 без BOM, иначе сайт работать не будет. Для этого в программе DreamWeave нужно выбрать пункт меню «Модификации - Свойства страницы - Заголовок/Кодировка», изменить кодировку на UTF-8. Затем следует перезагрузить страницу, убрать галочку из пункта «Подключить Юникод сигнатуры (BOM)» и применить изменения. Если какой-либо текст на странице или в базе данных был введён другой формой кодирования, то его нужно ввести заново или перекодировать. При работе с регулярными выражениями обязательно использовать модификатор u.

В текстовом редакторе Notepad++, если кодировка отлична от UTF-8, через пункт меню «Преобразовать в UTF-8 без BOM» изменить кодировку и сохранить в кодировке UTF-8.

Альтернативы нет

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

• поддерживает широкий диапазон инструментальных средств, в том числе совместимость с кодировкой ASCII;
• обладает устойчивостью к искажению данных;
• проста и эффективна при обработке;
• не зависит от платформы.

С появлением UTF-8 дискуссии о том, какая форма кодирования или набор символов лучше, стали бессмысленны.

Причиной разобраться в том, как же работает UTF-8 и что такое Юникод заставил тот факт, что VBScript не имеет встроенных функций работы с UTF-8. А так как ничего рабочего не нашел, то пришлось писть/дописывать самому. Опыт на мой взгляд полезный в любом случае. Для лучшего понимания начну с теории.

О Юникоде

До появления Юникода широко использовались 8-битные кодировки, главные минусы которых очевидны:

• Всего 255 символов, да и то часть из них не графические;
• Возможность открыть документ не с той кодировкой, в которой он был создан;
• Шрифты необходимо создавать для каждой кодировки.

Так и было решено создать единый стандарт «широкой» кодировки, которая включала бы все символы (при чем сначала хотели в нее включить только обычные символы, но потом передумали и начали добавлять и экзотические). Юникод использует 1 112 064 кодовых позиций (больше чем 16 бит). Начало дублирует ASCII, а дальше остаток латиницы, кирилица, другие европейские и азиатские символы. Для обозначений символов используют шестнадцатеричную запись вида «U+xxxx» для первых 65k и с большим количеством цифр для остальных.

О UTF-8

Когда-то я думал что есть Юникод, а есть UTF-8. Позже я узнал, что ошибался.
UTF-8 является лишь представлением Юникода в 8-битном виде. Символы с кодами меньше 128 представляются одним байтом, а так как в Юникоде они повторяют ASCII, то текст написанный только этими символами будет являться текстом в ASCII. Символы же с кодами от 128 кодируются 2-мя байтами, с кодами от 2048 - 3-мя, от 65536 - 4-мя. Так можно было бы и до 6-ти байт дойти, но кодировать ими уже ничего.
0x00000000 - 0x0000007F: 0xxxxxxx 0x00000080 - 0x000007FF: 110xxxxx 10xxxxxx 0x00000800 - 0x0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx 0x00010000 - 0x001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Кодируем в UTF-8

Порядок действий примерно такой:

• Каждый символ превращаем в Юникод.
• Проверяем из какого символ диапазона.
• Если код символа меньше 128, то к результату добавляем его в неизменном виде.
• Если код символа меньше 2048, то берем последние 6 бит и первые 5 бит кода символа. К первым 5 битам добавляем 0xC0 и получаем первый байт последовательности, а к последним 6 битам добавляем 0x80 и получаем второй байт. Конкатенируем и добавляем к результату.
• Похожим образом можем продолжить и для больших кодов, но если символ за пределами U+FFFF придется иметь дело с UTF-16 суррогатами.

Function EncodeUTF8(s) Dim i, c, utfc, b1, b2, b3 For i=1 to Len(s) c = ToLong(AscW(Mid(s,i,1))) If c < 128 Then utfc = chr(c) ElseIf c < 2048 Then b1 = c Mod &h40 b2 = (c - b1) / &h40 utfc = chr(&hC0 + b2) & chr(&h80 + b1) ElseIf c < 65536 And (c < 55296 Or c > 57343) Then b1 = c Mod &h40 b2 = ((c - b1) / &h40) Mod &h40 b3 = (c - b1 - (&h40 * b2)) / &h1000 utfc = chr(&hE0 + b3) & chr(&h80 + b2) & chr(&h80 + b1) Else " Младший или старший суррогат UTF-16 utfc = Chr(&hEF) & Chr(&hBF) & Chr(&hBD) End If EncodeUTF8 = EncodeUTF8 + utfc Next End Function Function ToLong(intVal) If intVal < 0 Then ToLong = CLng(intVal) + &H10000 Else ToLong = CLng(intVal) End If End Function

Декодируем UTF-8

• Ищем первый символ вида 11xxxxxx
• Считаем все последующие байты вида 10xxxxxx
• Если последовательность из двух байт и первый байт вида 110xxxxx, то отсекаем приставки и складываем, умножив первый байт на 0x40.
• Аналогично для более длинных последовательностей.
• Заменяем всю последовательность на нужный символ Юникода.

Function DecodeUTF8(s) Dim i, c, n, b1, b2, b3 i = 1 Do While i <= len(s) c = asc(mid(s,i,1)) If (c and &hC0) = &hC0 Then n = 1 Do While i + n <= len(s) If (asc(mid(s,i+n,1)) and &hC0) <> &h80 Then Exit Do End If n = n + 1 Loop If n = 2 and ((c and &hE0) = &hC0) Then b1 = asc(mid(s,i+1,1)) and &h3F b2 = c and &h1F c = b1 + b2 * &h40 Elseif n = 3 and ((c and &hF0) = &hE0) Then b1 = asc(mid(s,i+2,1)) and &h3F b2 = asc(mid(s,i+1,1)) and &h3F b3 = c and &h0F c = b3 * &H1000 + b2 * &H40 + b1 Else " Символ больше U+FFFF или неправильная последовательность c = &hFFFD End if s = left(s,i-1) + chrw(c) + mid(s,i+n) Elseif (c and &hC0) = &h80 then " Неожидаемый продолжающий байт s = left(s,i-1) + chrw(&hFFFD) + mid(s,i+1) End If i = i + 1 Loop DecodeUTF8 = s End Function 3 голоса

Здравствуйте, уважаемые читатели моего блога. Сегодня мы поговорим с вами про кодировку. Если вы читали мою статью о том, то знаете, что любой документ в интернете хранится не в том виде, в каком мы привыкли его видеть. Он записан при помощи непонятных человеку символов и знаков. С текстом все точно также.

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

Кодировка windows-1251 – что это такое, какое значение она имеет при создании сайта, какие символы будут доступны и является ли она лучшим решением на сегодняшний день? Обо всем этом в сегодняшней статье. Как всегда, простым языком, максимально понятно и с минимальным количеством терминов.

Немного теории

Любой документ на компьютере или в интернете, как я уже сказал, хранится в виде двоичного кода. К примеру, если вы используете кодировку ASCII, то буква «К» будет записана как 10001010, а windows 1251 под этим числом скрывается символ – Љ. В итоге, если браузер или программа обратится к другой таблице и считает вместо ASCII коды windows 1251, то читатель увидит совершенно непонятные ему символ.

Логичен вопрос, нафига было придумывать множество таблиц с кодами? Дело в том, что помимо русского алфавита существует еще и английский, немецкий, китайский. По некоторым подсчетам, существует около 200 000 символов. Хотя, я не очень доверяю этой статистике, вспоминая про японский.

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

Чем больше в таблице символов, тем длиннее код каждого из них, а значит и вес документа становится больше.

Представьте, если бы одна книга весила 4 Гб! Она бы очень долго загружалась, занимала все свободное место на компьютере. Решение о скачивании представлялось бы делом нелегким.

Если вспомнить о сайтах, то вообще страшно подумать, что бы произошло. Каждая страничка открывалась даже на скоростном оптоволокне по часу с лишним! Думаю, мобильные телефоны можно было бы смело выкидывать. Пользоваться ими на улице даже с 4G? Сомневаюсь.

По этим причинам каждый программист в свое время старался придумать свою таблицу символов. Чтобы было удобно для использования и вес сохранялся оптимальным.

Microsoft, к примеру, для русскоязычного сегмента создали windows-1251. В ней, конечно же, есть свои достоинства и недостатки. Как и у любого другого продукта.

Сейчас уже, лишь 2% всех страниц в интернете написано на 1251. Большинство веб-мастеров используют UTF-8. Почему так?

Недостатки и достоинства

UTF-8, в отличие от windows-1251 универсальная кодировка, в ней содержатся буквы различных алфавитов. Существует даже UTF-128, где есть вообще все языки – теулу, суахили, лаосский, мальтийский и так далее.

UTF-8 победнее, буквы занимают в разы меньше места и занимают всего один байт памяти, как и в 1251. В УТФ есть редкие символы из других языков или специальные символы. Они-то и весят по 5-6 байтов, но в документе используются крайне редко.

Эта кодировка более продумана, а потому ее использует большинство приложений по умолчанию. То есть, если вы не указываете программе, какую кодировку вы используете, то первым делом он проверит именно UTF-8 .

Когда вы создаете html документ для сайта, то указываете браузерам на какую таблицу им обращать внимание при расшифровке записей.

Для этого необходимо вставить в тег head следующие данные. После символов «charset=» идет либо утф, либо виндовс, как в примере ниже.

<meta http-equiv = "Content-Type" content = "text/html; charset=windows-1251" >

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

Если вас заинтересовало правильное создание сайта, то я могу порекомендовать вам курс Михаила Русакова «Создание и Раскрутка сайта от А до Я ».

Он содержит в себе очень много – 256 уроков, затрагивающих , JavaScript, и XML. Помимо языков программирования вы сможете понять как монетизировать сайт, то есть скорее и больше получать прибыль. Один из немногих курсов, в котором было бы так подробно разъяснено все, что нужно.

Сам я вот уже год обучаюсь в школе блоггеров Александра Борисова . Это занимает в разы больше времени, конца и края пока не видно, но зато не менее исчерпывающе и дисциплинирует. Мотивирует продолжать разработку.

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

Что-то я отошел от темы. Давайте вернемся к кодировкам.

Базы банных

Когда речь идет о php, все вообще страшно. Я уже рассказывал про базы данных, они используются для ускорения работы сайта. Обычно, вы к ним не обращаетесь, но когда появляется необходимость в переносе сайта становится не по себе.

Сложности случаются у всех, не важно какой у вас опыт работы, стаж и выслуга лет. Некоторые странички в базе могут содержать в себе все доступные символы для виндовс-1251, другие, к примеру, в шаблонах страниц, в другой кодировке.

Пока не нужен перенос все работает и функционирует, хоть и не совсем правильно. Но после переезда начинаются неприятности. В идеале вы должны использовать либо только УТФ, либо виндовс-1251, но по факту всегда и у всех случаются вот такие недочеты.

Чтобы расшифровка согласовалась необходимо вписать код mysql_query(«SET NAMES cp1251»). В этом случае преобразование будет осуществлять по другому протоколу – cp1251.

Htaccess

Если на сайте вы настойчиво решили использовать именно 1251, то вам следует найти или создать файл htaccess. Он отвечает за настройки конфигурации. В него придется добавить еще три строчки, чтобы все сошлось.

DefaultLanguage ru; AddDefaultCharset windows-1251; php_value default_charset "cp1251"

DefaultLanguage ru; AddDefaultCharset windows-1251; php_value default_charset "cp1251"

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

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

До новых встреч и удачи в ваших начинаниях.