Почему браузеры до сих пор поддерживают множество различных кодировок
Обновлено: 05.07.2024
На пути к конечному месту хранения во Всемирной паутине персонажи проходят через различные уровни программных интерфейсов и могут пересекать границы программного и аппаратного обеспечения. В этой статье приводятся полезные советы и рекомендации по точной передаче символьных данных из браузера в базу данных и обратно.
Содержание
Большинство операционных систем, языков разработки приложений и платформ прошли долгий путь интернационализации. Некоторые вещи сделать легко, например, ввести свое имя в текстовое поле Swing. Клавиатуры, методы ввода и хост-программа совместно создают правильные символы, независимо от того, зовут ли вас Джон, Хосе или (Танака). К сожалению, хотя ввод текста в формате, отличном от ASCII, в браузере может быть таким же простым, как ввод его в компонент Swing, точная передача его через Интернет может оказаться сложной задачей. Поскольку ни один отраслевой стандарт не регламентирует кодирование данных приложения в командах GET или POST, путешествие по различным уровням программных интерфейсов может превратить символьные данные в бессмысленную тарабарщину. Кроме того, администраторы веб-серверов и баз данных часто очень мало знают о преобразованиях кодировки символов, которые влияют на точность данных при перемещении текста из браузера в базу данных.
Отображение в браузере и отправка формы
Современные браузеры могут правильно отображать большую часть текста, если HTML-страница предоставляет браузеру достаточно подсказок для выбора и использования подходящих шрифтов и кодировок для интерпретации символов. На следующем изображении показан возможный экран, когда вы не предоставляете никакой информации о кодировке символов в браузере. В этом случае символы принимаются через HTML-страницу без потери данных, но впоследствии интерпретируются неправильно.
Рис. 1. Нет информации о кодировке символов для браузера
На следующем изображении браузер (Firefox 1.07) ошибочно интерпретирует содержимое файла как текст в кодировке ISO 8859-1, что неверно. Хотя большинство браузеров позволяют пользователю изменять или переопределять эти настройки для любого конкретного документа, это ожидание неразумно для обычных пользователей.
Рис. 2. Неверная информация о кодировке символов
Текст на самом деле является текстом UTF-8 (кодировка Unicode). После размещения этой информации в HTML-коде в виде тега браузер корректно отображает японское приветствие «Hello, World!»
Рис. 3. Правильная информация о кодировке символов для браузера
Ниже показан правильно описанный HTML-файл. Обратите внимание, что тег содержит атрибут содержимого, который сообщает браузеру, что файл имеет тип text/html с charset=UTF-8. Ключевое слово charset используется в атрибуте содержимого для передачи кодировки символов HTML-файла. Используйте языковые теги везде, где это возможно, чтобы браузеры могли находить и использовать глифы для конкретного языка, когда это необходимо. Например, и в китайском, и в японском языках используются одни и те же иероглифы. Поскольку глифы для некоторых символов в этих и других языках значительно различаются, языковые теги помогают браузерам находить наиболее подходящие шрифты для представления.
Тег японского языка
Если вы создаете страницы с помощью технологии JavaServer Pages (JSP), вы все равно должны указать кодировку символов сгенерированной HTML-страницы. Вы можете сделать это либо с помощью директивы страницы JSP, либо с помощью тега HTML. Тег страницы JSP должен быть первым элементом вашего файла JSP и должен содержать атрибут contentType с настройкой charset. Атрибут pageEncoding используется компилятором JSP, чтобы узнать кодировку самой страницы JSP.
В следующем JSP показана страница, на которой указано, что ее содержимое закодировано как ISO-8859-1, широко используемая кодировка символов, которая обрабатывает языки и сценарии, используемые во многих странах Западной Европы и Америки. Страница генерирует HTML-форму, которая запрашивает имя пользователя. При отправке эта же страница обрабатывает входящую команду GET и печатает приветствие пользователю, указанному в параметре NAME.
Введите «Джон» и нажмите кнопку «Отправить». Браузер создает и использует следующий URL-адрес для отправки информации на сервер:
Пока нормально. Теперь введите Хосе и нажмите кнопку «Отправить». Результирующий URL снова показан ниже:
Несмотря на то, что результирующий параметр NAME выглядит немного иначе, он правильный. Строка %E9 представляет собой символ в кодировке URL: шестнадцатеричное целое значение кодовой точки символа в кодировке ISO 8859-1. Серверы, которые ожидают данные GET и POST в кодировке 8859-1, без проблем декодируют этот URL-кодированный объект.
Кратко говоря, URL-кодирование — это веб-стандарт для URL-адресов, который требует, чтобы все символы, отличные от ASCII, и определенные символы ASCII кодировались как шестнадцатеричные строки в форме %HH . К сожалению, тот же стандарт не предписывает, какую кодировку использовать при кодировании данных.
Что происходит, когда кодировка страницы не содержит символов, введенных в форму? Представьте, что пользователь из Японии, Кореи или Китая вводит свое имя на той же JSP-странице, показанной выше. Символы, скорее всего, не отображаются в кодировке ISO 8859-1. Кодирование их в ISO 8859-1 создаст серьезную проблему для браузера, и каждый браузер решает эту проблему по-своему.
Учитывая японское имя (Tanaka), браузер Firefox версии 1.07 выдает следующий URL-адрес GET:
Чтобы устранить эту проблему, всегда выбирайте кодировку HTML-страницы, которая поддерживает все символы, которые вы собираетесь обрабатывать. Если вы предполагаете иметь многоязычных пользователей и надеетесь обрабатывать несколько сценариев, используйте кодировку символов, представляющую эти сценарии. UTF-8 — это кодировка символов Unicode, и она может правильно представлять все символы, активно используемые во всем мире. Используя UTF-8 на странице вместо 8859-1, браузер создает другой URL.
Это правильно закодированный параметр NAME, использующий кодировку UTF-8. UTF-8 кодирует 3 байта на символ. Поскольку каждый байт имеет значение вне диапазона ASCII, браузер URL-кодирует значения, создавая форму %HH для каждого байта, как показано выше. Сервер, который ожидает данные формы UTF-8, сможет правильно обработать этот параметр.
Обработка веб-сервером
Хотя современные браузеры получают подсказки из кодировки страницы или формы и отправляют данные формы обратно на сервер в той же кодировке, большинство веб-серверов остаются в блаженном неведении о выборе кодировки символов. Обычно они предполагают, что используется кодировка ISO-8859-1. Даже если приложение сталкивается с проблемой URL-кодирования параметра GET в UTF-8 , сервер (скажем, Tomcat 5.5.9 или Sun Java System Application Server 8.1) примет кодировку 8859-1. В результате текстовые данные почти сразу же искажаются при перемещении по различным уровням даже простого веб-приложения.
При изменении кода предыдущей технологии JSP для использования кодировки UTF-8 новый код выглядит следующим образом.
Теперь введите "Хосе" и отправьте. URL-адрес GET будет выглядеть следующим образом.
%C3%A9 – это URL-кодировка имени Хосе в кодировке UTF-8. Без проблем. Браузер берет подсказку из настройки contentType, где в качестве кодировки символов указывается UTF-8. Браузер отображает следующий текст.
Рис. 4. Кодировка символов UTF-8
Обратите внимание на текст ответа: Привет, Хосе! Это не правильно. Что случилось? Хотя браузер правильно отправляет данные GET, веб-сервер неправильно принял кодировку символов 8859-1, поскольку он считывал параметр NAME Jos%C3%A9 из URL-адреса. С его точки зрения, объект %C3 представляет закодированное значение 0xC3 (Ã) в ISO-8859-1. %A9 — это 0xA9 (©) в ISO-8859-1. Хм, но тип содержимого был явно задан в теге JSP!
Нет опубликованного стандарта, предписывающего, как сообщать о выборе набора символов для данных GET и POST. Как это должно быть решено? Некоторые серверы пытаются решить эту проблему. Установка URIEncoding="UTF-8" в настройках соединителя Tomcat в файле server.xml передает выбранную кодировку символов на веб-сервер, и сервер Tomcat правильно считывает параметры URL GET. Затем он отправляет «Привет, Хосе!» или как ожидалось. В сервер приложений Sun Java System Application Server 8.1 можно включить
в файле sun-web.xml. Правильная интерпретация URL показана на следующем изображении.
Рис. 5. Интерпретация URL
Что делать, если вы хотите отправить данные, отличные от ASCII? Все хорошо, так как вы установили этот флаг URIEncoding, верно? Неправильно. Tomcat не использует флаг URIEncoding для данных формы POST. Итак, что он использует? ИСО-8859-1.
Итак, вы вернулись к тому, с чего начали, и простое приложение по-прежнему приветствует Mr. ç°ä вместо Mr. Нехорошо.Однако сервер приложений Sun правильно интерпретирует как данные GET, так и данные POST после установки тега кодировки параметра, как показано ранее, поэтому такое кодирование хорошо работает для пользователей этой системы.
К сожалению, эти решения полностью зависят от сервера, и вы не всегда можете контролировать, где будут развернуты ваши приложения. К счастью, существуют независимые от сервера решения.
Возможно, самое простое решение, независимое от сервера, — установить параметр контекста, указывающий выбор кодировки символов для всех форм в приложении. Затем ваше приложение может прочитать параметр контекста и установить кодировку символов запроса перед чтением каких-либо параметров запроса. Вы можете установить кодировку запроса либо в сервлете Java, либо в синтаксисе JSP.
Настройка параметра контекста выполняется в файле WEB-INF/web.xml.
Добавьте следующий код непосредственно перед чтением каких-либо параметров в предыдущем файле JSP.
Мы рассмотрим подробности через минуту, а пока давайте просто скажем, что кодировка символов – это способ представления букв, цифр и других символов в числовых значениях, понятных компьютеру.
Файл — например, HTML-документ — сохраняется с определенной кодировкой символов. Информация о форме кодирования, которую использует файл, отправляется браузерам и другим пользовательским агентам, чтобы они могли правильно интерпретировать биты и байты. Если заявленная кодировка не соответствует кодировке, которая фактически использовалась, браузеры могут отображать вашу драгоценную веб-страницу как абракадабру. И, конечно же, поисковые системы тоже не могут в этом разобраться.
В чем разница?
Почему так важно, какую форму кодирования мы выбираем? Что произойдет, если мы выберем «неправильный» вариант?
Выбор кодировки символов влияет на диапазон буквенных символов, которые мы можем использовать на веб-странице. Обычные латинские буквы редко бывают проблемой, но некоторым языкам требуется больше букв, чем другим, а некоторым языкам нужны различные диакритические знаки над или под буквами. Затем, конечно, некоторые языки вообще не используют латинские буквы. Если нам нужна правильная — типографски правильная — пунктуация и специальные символы, выбор кодировки также становится более важным.
Сущности или NCR работают так же хорошо, как литеральные символы, но они занимают больше байтов и затрудняют чтение разметки. Они также склонны к опечаткам.
Что влияет на выбор?
Прежде чем выбрать форму кодирования, необходимо принять во внимание ряд параметров, в том числе:
- Какие символы я буду использовать?
- В каких кодировках мой редактор может сохранять файлы?
- Какие кодировки поддерживаются различными компонентами в моей издательской цепочке?
- Какие кодировки поддерживаются браузерами посетителей?
Давайте рассмотрим каждый из этих вопросов по очереди.
Диапазон символов
Первый параметр, который нам нужно учитывать, — это диапазон символов, которые нам понадобятся. Очевидно, что сайт, написанный на одном языке, использует более ограниченный набор символов, чем многоязычный сайт, особенно тот, где латинские буквы смешаны с кириллицей, греческим, ивритом, арабским, китайским и так далее.
Если мы хотим использовать типографически правильные кавычки, тире и другие специальные знаки препинания, «обычные» кодировки не подходят. Это также верно, если нам нужны математические или другие специальные символы.
Возможности текстового редактора
Некоторые авторы предпочитают использовать обычные текстовые редакторы, такие как Notepad или Vim; другим нравится WYSIWYG-инструмент типа «укажи и щелкни», например Dreamweaver; некоторые используют сложную систему управления контентом (CMS). Независимо от личных предпочтений, выбор редакторов влияет на выбор кодировки. Некоторые редакторы умеют сохранять только в одной кодировке, а в какой даже не скажут. Другие могут сохранять в десятках различных кодировок, но требуют, чтобы вы знали, какая из них соответствует вашим потребностям.
Другие компоненты
Каждый из этих компонентов может повлиять на выбор кодировки. Возможно, база данных может хранить данные только в одной конкретной кодировке, или язык сценариев, который вы используете, не поддерживает определенные кодировки.
В этой статье невозможно перечислить возможности всех различных редакторов, баз данных и т. д., потому что их слишком много. Перед выбором используемой кодировки необходимо ознакомиться с документацией по компонентам.
Поддержка браузера
Некоторые кодировки, такие как US-ASCII, серия ISO 8859 и UTF-8, широко поддерживаются. Другие нет. Вероятно, лучше избегать более эзотерических кодировок, особенно на сайте, предназначенном для международной аудитории.
Что такое кодировка символов?
Символ — это наименьшая единица письма, способная передавать информацию. Это абстрактное понятие: у персонажа нет внешнего вида.«Прописная латиница A» отличается от «строчной латиницы a», а также от «заглавной кириллицы A» и «заглавной греческой альфа».
Визуальное представление символа называется глифом. Определенный набор глифов называется шрифтом. «Заглавная латиница A», «заглавная кириллица A» и «заглавная греческая альфа» могут иметь одинаковые глифы, но это разные символы. В то же время глифы для «заглавной латиницы А» могут выглядеть очень по-разному в Times New Roman, Gill Sans и Poeticachancery italic, но они по-прежнему представляют один и тот же символ.
Набор доступных персонажей называется репертуаром персонажей. Расположение (индекс) данного символа в репертуаре известно как его кодовая позиция или кодовая точка.
Метод численного представления кодовой точки в заданном репертуаре называется кодировкой символов. К сожалению, термин "набор символов" или "кодировка" использовался как для репертуаров, так и для кодировок, поэтому лучше вообще его избегать.
Кодировки обычно выражаются в виде октетов. Октет — это группа из восьми двоичных цифр, то есть восьми единиц и нулей. Октет может выражать числовой диапазон от 0 до 255 или от 0x00 до 0xFF, если используется шестнадцатеричная система счисления.
Краткая история
У первых компьютеров не было стандартизированной кодировки символов, но это не имело большого значения, поскольку в то время компьютеры редко могли взаимодействовать друг с другом. Когда стало возможным межкомпьютерное взаимодействие, необходимость в стандартах кодирования стала очевидной. Распространенным ранним репертуаром/кодированием был EBCDIC, другим был Американский стандартный код для обмена информацией, также известный как ASCII. Версия для США, US-ASCII, стандартизирована как ISO 646.
ASCII использует только семь битов (единицы и нули), что означает, что он может представлять 128 чисел: от 0 до 127 включительно. Диапазон 0–31 зарезервирован для управляющих символов C0, а диапазон 127 зарезервирован для DEL (удаление), в результате чего остается 95 печатных символов. Этого достаточно для английского алфавита в верхнем и нижнем регистре, плюс цифры и некоторые распространенные (и, надо признать, некоторые менее распространенные) знаки препинания. Но недостаточно принять знаки с ударением и диакритические знаки, необходимые для многих европейских языков, не говоря уже о любой письменности, в которой не используются латинские буквы. Взаимно несовместимые национальные версии ASCII раньше были обычным явлением, но они не подходят для международного обмена информацией.
Самой распространенной версией для западных языков является ISO 8859-1, также известная как ISO Latin-1. Он содержит несколько версий гласных с ударением, а также различные специальные символы. В настоящее время он заменен стандартом ISO 8859-15 для размещения знака евро (€,&евро;).
ASCII и серия ISO 8859 представляют собой репертуары символов и кодировки. Кодовые точки находятся в диапазоне от 0 до 127 для ASCII и от 0 до 255 для ISO 8859. Кодирование является простым взаимно-однозначным, поскольку один октет может удобно выразить весь диапазон. «Прописная латиница A» имеет кодовую точку 65 (0x41) и кодируется как 65 (01000001).
Microsoft, которая никогда не следовала чужому стандарту, когда могла создать свой собственный, также создала ряд репертуаров/кодировок символов. В DOS они назывались «кодовыми страницами», а CP850 была кодовой страницей, используемой для западных языков.
Один из наиболее распространенных репертуаров/кодировок Microsoft известен как Windows-1252. Хотя он очень похож на ISO 8859-1, он не идентичен. Диапазон, зарезервированный для управляющих символов C1 в кодировках ISO, используется корпорацией Майкрософт для предоставления определенных удобных символов, недоступных в кодировках ISO, таких как типографски правильные кавычки и тире.
Для языков, в которых не используются латинские буквы, были разработаны аналогичные специализированные репертуары/кодировки. Проблема заключалась в том, что не существовало репертуара/кодировки, которые можно было бы использовать для комбинаций таких языков.
Юникод/ISO 10646
Решение этой проблемы называется Unicode — репертуар символов, который содержит большинство символов, используемых в языках мира. Он может вместить миллионы символов, а уже содержит сотни тысяч. Юникод разбит на «плоскости» по 64К символов. В большинстве случаев используется только первый уровень, известный как базовый многоязычный уровень или BMP.
Первые 256 кодовых точек в Unicode совместимы со стандартом ISO 8859-1, что также означает, что первые 128 кодовых точек совместимы с US-ASCII. Кодовые точки в Unicode записываются в шестнадцатеричном формате с префиксом заглавной буквы «U» и знаком «плюс» (например, U+0041 для «верхней латиницы A» (кодовая точка 65 или 0x41)).
Версия Unicode, стандартизированная ISO, называется ISO 10646 (номер неслучайный; сравните с ISO 646 US-ASCII). Между Unicode и ISO 10646 есть небольшие различия, но нам, простым смертным, не о чем беспокоиться.
ISO 10646 важен, потому что это репертуар символов, используемый HTML.
Но ISO 10646 — это всего лишь репертуар. Нам нужна кодировка, чтобы идти с ним. Поскольку репертуар может представлять миллионы кодовых точек, однозначное кодирование было бы очень неэффективным. Нам потребовалось бы 32 бита (четыре октета) для каждого символа, и это было бы пустой тратой времени, особенно для западных языков. Такая кодировка (UTF-32) существует, но используется редко. Другой — UTF-16, в котором для каждого символа используется два октета, но он не совсем прижился.
Вместо этого рекомендуется использовать более эффективную (для западных языков) кодировку, известную как UTF-8. Он использует переменное количество октетов для представления различных символов. Диапазон ASCII (от U+0000 до U+007F) кодируется один к одному. Для других символов необходимы два, три или четыре октета. Теоретически UTF-8 может использовать до шести октетов для кодирования определенных символов.
Какую кодировку выбрать?
Для англоязычного сайта это не имеет большого значения. Если вы не хотите использовать некоторые типографски правильные знаки препинания (фигурные кавычки и т. д.), будет достаточно простого старого US-ASCII. ISO 8859-1 стал своего рода стандартом де-факто для западных сайтов и может представлять интерес, если вы предпочитаете такие варианты написания, как "наивный", "роль" или "шведский стол".
Для тех из нас, кому нужно писать на другом западноевропейском языке, например на французском, испанском, португальском, итальянском, немецком, шведском, норвежском, датском или финском, стандарт ISO 8859-1 вполне подойдет. Те, кому нужны диакритические знаки чешского или польского языков, или совершенно разные алфавиты, такие как греческий или кириллица, могут выбирать из других версий серии ISO 8859.
Как я уже упоминал, существуют специальные кодировки для иврита, арабского и восточного письма. Но что, если вам нужно смешать английский, русский, греческий и японский языки на одном сайте? Или даже на той же странице?
Я бы рекомендовал использовать кодировку UTF-8 везде, где это возможно, так как она может представлять любой символ из репертуара ISO 10646. Даже если вы пишете только на английском языке, UTF-8 дает вам прямой доступ к типографски правильным кавычкам, нескольким дефисам, многоточиям и многому другому. А если вам нужно писать на греческом или японском, вы можете сделать это, не возясь с сущностями или НКР.
На многоязычном сайте, безусловно, можно использовать разные кодировки для разных страниц, но подумайте о кошмаре обслуживания. Почему бы не использовать кодировку UTF-8 для всего и перестать беспокоиться?
К сожалению, даже в наши дни с использованием UTF-8 связано несколько незначительных проблем.
Проблемы с UTF-8
Первая проблема с использованием UTF-8 заключается в том, что не все редакторы или средства публикации поддерживают ее. Можно подумать, что спустя столько лет все программы будут поддерживать UTF-8, но, к сожалению, это не так.
Следующая проблема связана с меткой порядка байтов или спецификацией. Это последовательность из двух (UTF-16) или трех (UTF-8) октетов, которая сообщает компьютеру, какой октет следует старше или наименее значащий. Некоторые браузеры не понимают спецификацию и выводят ее в виде текста. Другие редакторы не позволят нам пропустить спецификацию.
Небольшая проблема заключается в том, что некоторые старые браузеры не поддерживают UTF-8 (даже без спецификации). Однако в наши дни их должно быть немного.
Проблемы с ISO 8859
Если вы публикуете материалы на английском, французском и немецком языках и сталкиваетесь с проблемами, связанными с кодировкой UTF-8, вы можете выбрать наш старый надежный друг: ISO 8859-1. Но есть еще несколько подводных камней, на которые следует обратить внимание.
Многие редакторы под Windows будут использовать Windows-1252 в качестве кодировки по умолчанию (или только!) Если вы сохраняете файлы как Windows-1252 и объявляете кодировку ISO 8859-1, это обычно работает. Это потому, что они очень похожи.
Но если вы используете определенные буквальные символы, такие как типографски правильные кавычки, тире, многоточия и т. д., у вас возникнут проблемы. Эти символы не являются частью ISO 8859-1. В Windows-1252 они расположены в диапазоне, который кодировка ISO резервирует для управляющих символов C1 — другими словами, эти кодовые точки недействительны в ISO 8859-1. Копирование из другого приложения Windows, например Word, является наиболее вероятной причиной проблем.
Проверка HTML W3C будет обнаруживать эти типы недопустимых символов и сообщать о них как об ошибках.
Проблемы с другими кодировками
UTF-8 и серия ISO 8859 хорошо поддерживаются современными браузерами. Большинство браузеров также поддерживают довольно много других кодировок, но если вы выберете экзотическую кодировку, вы рискуете, что некоторые посетители не смогут прочитать ваш контент.
В некоторых странах, где латинский алфавит не используется, веб-разработчики могут использовать шрифт, содержащий необходимые символы, и вообще не заботиться о кодировке. Это очень неразумно. Любой посетитель, у которого не установлен этот конкретный шрифт, не увидит ничего, кроме тарабарщины. И эти "посетители" включают Google и другие поисковые системы.
Указание кодировки
После того как вы выбрали кодировку, которую будете использовать, необходимо убедиться, что в браузеры, поисковые системы и т. д. передается правильная информация.
Для HTML информация о кодировке должна отправляться веб-сервером с использованием заголовка Content-Type:
Для Microsoft IIS этот параметр должен находиться в его многочисленных диалоговых окнах.
Для XML, включая правильно обслуживаемый XHTML, кодировка должна быть указана в объявлении XML в верхней части файла. В этих случаях заголовок Content-Type вообще не должен содержать никакой информации о кодировке. Парсеры XML должны поддерживать только UTF-8 и UTF-16, что несколько облегчает выбор:
Обратите внимание, что это не относится к XHTML, используемому как text/HTML, потому что это вообще не XHTML, поэтому объявление XML не работает.
Обзор
Важно выбрать правильную кодировку символов. Если вы выберете кодировку, неподходящую для вашего сайта (например, используя ISO 8859-1 для китайского сайта), вам придется использовать множество сущностей или NCR, что приведет к излишнему увеличению размеров файлов.
К сожалению, выбрать кодировку не всегда просто. Отсутствие поддержки в различных компонентах цепочки публикации может помешать вам использовать кодировку, которая лучше всего подходит для вашего контента.
По возможности используйте кодировку UTF-8 (без спецификации), особенно для многоязычных сайтов.
И, пожалуй, самое главное: объявленная вами кодировка должна совпадать с кодировкой, которую вы использовали при сохранении файлов!
Целевая аудитория: кодировщики HTML (использующие редакторы или скрипты), разработчики скриптов (PHP, JSP и т. д.), кодировщики CSS, менеджеры веб-проектов и все, кто плохо знаком с кодировками символов и нуждается в ознакомлении с тем, как выбирать и применить кодировку символов.
Вопрос
Какую кодировку символов следует использовать для моего контента и как ее применить к своему контенту?
Контент состоит из последовательности символов. Символы представляют собой буквы алфавита, знаки препинания и т. д. Но содержимое хранится в компьютере в виде последовательности байтов, которые представляют собой числовые значения. Иногда для представления одного символа используется более одного байта. Подобно кодам, используемым в шпионаже, способ преобразования последовательности байтов в символы зависит от того, какой ключ использовался для кодирования текста. В этом контексте этот ключ называется кодировкой символов.
В этой статье предлагаются простые советы о том, какую кодировку символов использовать для вашего контента и как ее применять, т.е. как на самом деле создать документ в этой кодировке.
Если вам нужно лучше понять, что такое символы и кодировки символов, см. статью Кодировки символов для начинающих .
Быстрый ответ
Выберите UTF-8 для всего контента и рассмотрите возможность преобразования любого контента в устаревших кодировках в UTF-8.
Если вы действительно не можете использовать кодировку Unicode, убедитесь, что выбранная вами кодировка страницы широко поддерживается браузерами и что эта кодировка не входит в список кодировок, которых следует избегать согласно последним спецификациям.< /p>
В дополнение к объявлению кодировки документа внутри документа и/или на сервере вам необходимо сохранить текст в этой кодировке, чтобы применить ее к вашему контенту.
Разработчикам также необходимо убедиться, что различные части системы могут взаимодействовать друг с другом.
Подробнее
Применение кодировки к вашему контенту
Авторы содержания должны объявить кодировку символов своих страниц, используя один из методов, описанных в разделе Объявление кодировок символов в HTML.
Однако важно понимать, что простое объявление кодировки внутри документа или на сервере фактически не изменит байты; вам нужно сохранить текст в этой кодировке, чтобы применить его к вашему контенту. (Объявление просто помогает браузеру интерпретировать последовательности байтов, в которых хранится текст.)
При необходимости установите кодировку UTF-8 по умолчанию для новых документов в вашем редакторе. На рисунке ниже показано, как это можно сделать в настройках редактора, такого как Dreamweaver.
Информацию о «Форме нормализации Unicode» см. в разделе Нормализация в HTML и CSS . Сведения о подписи Unicode (BOM) см. в разделе Знак порядка байтов (BOM) в HTML .
Разработчикам также необходимо убедиться, что различные части системы могут взаимодействовать друг с другом. Веб-страницы должны иметь возможность беспрепятственно взаимодействовать с внутренними сценариями, базами данных и т.п. Конечно, все они лучше всего работают и с UTF-8. Разработчики могут найти подробный набор моментов, которые следует учитывать, в статье Миграция на Unicode .
Зачем использовать кодировку UTF-8?
Страница HTML может быть только в одной кодировке. Вы не можете кодировать разные части документа в разных кодировках.
Кодировка на основе Unicode, такая как UTF-8, может поддерживать многие языки и может вмещать страницы и формы на любом сочетании этих языков. Его использование также устраняет необходимость в логике на стороне сервера для индивидуального определения кодировки символов для каждой обслуживаемой страницы или каждой входящей отправки формы. Это значительно упрощает работу с многоязычным сайтом или приложением.
Кодировка Unicode также позволяет смешивать на одной странице гораздо больше языков, чем любая другая кодировка.
Поддержка данной кодировки, даже кодировки Unicode, не обязательно означает, что пользовательский агент будет правильно отображать текст. Многочисленные шрифты, такие как арабский и индийский, требуют дополнительных правил для преобразования последовательности символов в памяти в соответствующую последовательность глифов шрифта для отображения.
В наши дни любые барьеры для использования Unicode очень низки. Фактически, в январе 2012 года Google сообщил, что более 60% Интернета в их выборке из нескольких миллиардов страниц теперь используют UTF-8. Добавьте к этому цифру для веб-страниц, состоящих только из ASCII (поскольку ASCII является подмножеством UTF-8), и эта цифра возрастет примерно до 80%.
Существует три различных кодировки символов Unicode: UTF-8, UTF-16 и UTF-32. Из этих трех для веб-контента следует использовать только кодировку UTF-8. В спецификации HTML5 говорится: "Авторам рекомендуется использовать UTF-8. Специалисты по проверке соответствия могут посоветовать авторам не использовать устаревшие кодировки. Инструменты разработки должны по умолчанию использовать UTF-8 для вновь создаваемых документов".
В частности, обратите внимание, что все символы ASCII в кодировке UTF-8 используют те же байты, что и в кодировке ASCII, что часто способствует взаимодействию и обратной совместимости.
Дополнительная информация
Информация в этом разделе относится к вещам, которые обычно вам не нужны, но которые включены сюда для полноты картины.
Что делать, если я не могу использовать кодировку UTF-8?
Если вы действительно не можете избежать использования кодировки символов, отличной от UTF-8, вам придется выбирать из ограниченного набора имен кодировок, чтобы обеспечить максимальную совместимость и максимально длительный срок удобочитаемости вашего контента, а также минимизировать безопасность. уязвимости.
До недавнего времени реестр IANA был местом, где можно было найти имена для кодировок. Реестр IANA обычно включает несколько имен для одной и той же кодировки. В этом случае вы должны использовать имя, обозначенное как «предпочтительное».
Новая спецификация Encoding теперь содержит список, протестированный на реальных реализациях браузера. Список можно найти в таблице в разделе Кодировки. Лучше всего использовать имена из левого столбца этой таблицы.
Обратите внимание, однако, что наличие имени в любом из этих источников не обязательно означает, что можно использовать эту кодировку. В следующем разделе приведены кодировки, которых следует избегать.
Избегайте этих кодировок
Спецификация HTML5 указывает на ряд кодировок, которых следует избегать.
В документах не должны использоваться JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (кодовая страница Windows 1361), кодировки на основе ISO-2022 или кодировки на основе EBCDIC. Это связано с тем, что они позволяют кодовым точкам ASCII представлять символы, отличные от ASCII, что представляет угрозу безопасности.
Кроме того, в документах не должны использоваться кодировки CESU-8, UTF-7, BOCU-1 или SCSU, поскольку они никогда не предназначались для веб-контента, а спецификация HTML5 запрещает браузерам их распознавать.
Спецификация также настоятельно не рекомендует использовать UTF-16, а использование UTF-32 «особенно не рекомендуется».
Заменяющая кодировка, указанная в спецификации кодировки, на самом деле не является кодировкой; это запасной вариант, который сопоставляет каждый октет с кодовой точкой Unicode U+FFFD REPLACEMENT CHARACTER . Очевидно, что передавать данные в такой кодировке бесполезно.
Определяемая пользователем кодировка x – это однобайтовая кодировка, младшая половина которой – это ASCII, а верхняя – сопоставлена с частной областью использования Unicode (PUA). Как и в случае с PUA в целом, лучше избегать использования этой кодировки в общедоступном Интернете, поскольку она наносит ущерб функциональной совместимости и долгосрочному использованию.
Без видеокодеков никогда не было бы придумано «Netflix и охлаждение». Эти инструменты сжатия, состоящие из двух частей, позволяют дистрибьюторам сжимать видеофайл для доставки через Интернет с помощью процесса, называемого кодированием видео. Благодаря кодекам мы можем так легко проводить деловые встречи в Zoom и смотреть телепередачи на наших телефонах — даже при ограниченной пропускной способности.
Благодаря кодекам Netflix удается передавать более 404 000 часов контента каждую минуту.А чтобы направлять эти потоки на различные устройства, с которых настраиваются конечные пользователи, Netflix должен использовать как новые, так и проверенные временем кодеки.
Что включает в себя кодирование видео и как работают видеокодеки? Мы углубимся ниже и рассмотрим наш список лучших видеокодеков для потоковой передачи.
Содержание
Что такое кодирование видео?
Кодирование видео — это процесс преобразования необработанного видео в цифровой формат, совместимый со многими устройствами. Когда дело доходит до потоковой передачи, видео часто сжимаются с гигабайтов данных до мегабайтов данных. Кодирование видео необходимо для прямых трансляций, помогая обеспечить быструю доставку и воспроизведение.
Кодирование может выполняться в браузере или мобильном приложении, на IP-камере, с помощью программного обеспечения или автономного устройства. Популярные варианты программного обеспечения включают Vmix, Wirecast и бесплатную OBS Studio.
Чтобы сжать необработанное видео до более удобного размера, кодировщики используют видео- и аудиокодеки, которые применяют алгоритмы для сжатия объемного видео для доставки. Проще говоря: кодирование описывает процесс сжатия, тогда как кодеки описывают средства для этого.
Что такое кодек?
Распространители контента используют технологию сжатия видео, называемую кодеком, для сжатия видео до размера, пригодного для потоковой передачи. Кодеки позволяют нам сильно сжимать объемные потоки для доставки и хранения.
Буквально «кодер-декодер» или «компрессор-декомпрессор». Кодеки применяют алгоритмы к видео и создают его факсимиле. Когда дело доходит до потоковой передачи, кодеки используют сжатие с потерями, отбрасывая ненужные данные. Видео сокращается для хранения и передачи, а затем распаковывается для просмотра.
Потоковая передача требует использования как аудио-, так и видеокодеков. H.264, также известный как AVC (Advanced Video Coding), является наиболее распространенным видеокодеком; AAC (Advanced Audio Coding) — наиболее распространенный аудиокодек.
Но подождите, почему H.264 также обозначается AVC? И как нам разобраться в таком количестве запутанных аббревиатур? Эксперт по потоковым кодекам Ян Озер объясняет это так:
«H.264/AVC и H.265/HEVC имеют два названия, поскольку каждый кодек был стандартизирован как MPEG, так и Международным союзом электросвязи (ITU). Универсальное кодирование видео, или VVC, также является H.266 по той же причине».
Для ясности я буду включать оба названия при первом упоминании каждого кодека в подразделах этой статьи.
Что такое формат видеоконтейнера?
После сжатия компоненты потока упаковываются в оболочку или формат файла. Эти файлы содержат аудиокодек, видеокодек, скрытые субтитры и любые связанные метаданные. Общие контейнеры включают .mp4, .mov, .ts и .wmv.
Контейнеры часто могут вводить несколько типов кодеков. Тем не менее, не все платформы воспроизведения принимают все контейнеры и кодеки. Вот почему многоформатное кодирование имеет решающее значение при потоковой передаче на широкий спектр устройств.
Например: файлы .mov и файлы .wmv могут содержать одни и те же данные и кодеки. Но файл .mov будет использоваться для воспроизведения в проигрывателе Macbook QuickTime, а файл .wmv будет использоваться для воспроизведения в проигрывателе Windows Media на ПК.
Подпишитесь и будьте в курсе
Подробнее о кодеках и протоколах, последних тенденциях в области потокового вещания и многом другом.
Видеокодеки и контейнеры: в чем разница?
Кодек воздействует на видео как в источнике для его сжатия, так и перед воспроизведением для его распаковки. Это делается с помощью сжатия с потерями, при котором все ненужные данные отбрасываются.
Сжатие с потерями во многом похоже на Wonkavision в «Чарли и шоколадной фабрике». Это позволяет уменьшить размер большой коллекции данных для переноса на экран:
С другой стороны, формат видеоконтейнера хранит видеокодек, аудиокодек и метаданные, такие как субтитры или изображения для предварительного просмотра. Контейнер объединяет все компоненты и определяет, какие программы могут принимать поток.
Лучшие видеокодеки для потоковой передачи
Доставка видео через Интернет на различные устройства начинается с кодирования с помощью различных кодеков. Кодеки нового поколения повышают эффективность и качество кодирования, а устаревшие кодеки позволяют воспроизводить файлы на устаревших компьютерах.
Возьмите это у крупнейшего дистрибьютора потокового видео: Netflix.
«Netflix говорит, что использует обширный набор кодеков, которые можно использовать для потоковой передачи совместимых форматов на устройства отображения. Хотя Netflix постоянно добавляет новые и улучшенные кодеки, он никогда не отказывался от них — он продолжает поддерживать кодек VC1, с которого начал работу в первом потоковом устройстве Netflix — проигрывателе LG Blu-ray 10-летней давности».
< /цитата>Приведенный ниже список видеокодеков включает как старые, так и новые кодеки.Хотя лидеры отрасли продолжают совершенствовать и разрабатывать новейшие инструменты сжатия, они также используют более старые кодеки, такие как H.264/AVC, для доставки на устаревшие устройства.
Для просмотра этого видео включите JavaScript и рассмотрите возможность перехода на веб-браузер, поддерживающий видео в формате HTML5
Давайте рассмотрим наиболее распространенные технологии кодирования в 2021 году.
H.264/AVC
Большая часть выходных кодированных данных сегодня представлена в виде файлов H.264, также называемых AVC (Advanced Video Coding). Этот широко поддерживаемый кодек был разработан Международным союзом электросвязи и Группой экспертов по движущимся изображениям Международной организации по стандартизации/Международной электротехнической комиссии (ISO/IEC) — вау, какая прелесть.
H.264 также широко распространен на рынках, не связанных с потоковой передачей, таких как диски Blu-ray и кабельное вещание. Он часто используется вместе с аудиокодеком AAC и может быть упакован в контейнеры .mp4, .mov, .F4v, .3GP и .ts.
H.264 воспроизводится практически на любом устройстве, обеспечивает высокое качество видеопотоков и позволяет минимизировать лицензионные отчисления. Это не значит, что это не приносит гонораров, просто издатели контента знают, чего ожидать — что не всегда так. Из-за широкой поддержки устройств H.264 остается наиболее часто используемым вариантом. В отчете Bitmovin для разработчиков видео за 2020 год колоссальный 91% опрошенных указали, что они его используют.
Источник: Отчет разработчиков видео Bitmovin за 2020 г.
Тем не менее, хотя стандарт H.264 прекрасно работает на всех основных рынках потребления видео (браузеры, мобильные устройства, Smart TV), он не подходит для видео 4K или контента с расширенным динамическим диапазоном (HDR).
Скорее всего, H.264, как самый быстрый кодек, описанный в этом блоге, лучше подходит для потоковой передачи с малой задержкой, чем для доставки видео 8K. Ян Озер из Streaming Media объясняет:
H.264 также является старейшим форматом кодирования видео в этом списке. Многие предсказывали, что к настоящему времени он устарел. Но если учесть его вычислительную мощность и стоимость, H.264 трудно превзойти. Кроме того, количество устройств, которые могут кодировать и декодировать H.264, не может быть больше, включая IP-камеры, телевизионные приставки, мобильные устройства и устройства с низким энергопотреблением.
TL;DR
H.264 – это эффективная и широко распространенная технология сжатия видео, используемая для добавления, распространения и доставки потоков. Он особенно хорошо подходит для рабочих процессов с малой задержкой.
Компания Google разработала VP9 как бесплатную альтернативу H.265 с открытым исходным кодом. Принадлежащая Google платформа YouTube и браузер Chrome поддерживают VP9, а также все телефоны Android, Mozilla Firefox, Apple Safari и все новые устройства iOS. Этот кодек также используется во многих рабочих процессах WebRTC: более 90% видео WebRTC, закодированного в Chrome, используют VP9 или его предшественник VP8.
VP9 был выпущен в 2013 году, что делает его средним по возрасту. Тем не менее, это лучший вариант, чем большинство по нескольким причинам. Во-первых, VP9 работает примерно так же, как H.265/HEVC. Это делает его хорошо подходящим для видео 4K, особенно при публикации на YouTube.
Кроме того, VP9 уступает только H.264/AVC с точки зрения совместимости между браузерами и устройствами. Его поддерживают Samsung, Sony, LG, Roku и многие другие известные имена. Кроме того, внедрение кодека Google в YouTube и его использование Netflix для некоторого контента будут и впредь поддерживать эту тенденцию.
Воспринимайте VP9 как AV0 или более раннюю версию AV1. Оба имеют открытый исходный код, и оба утверждают, что не требуют авторских отчислений (хотя в этом есть некоторые сомнения). На данный момент VP9 также является лучшей альтернативой AV1, поскольку его поддерживает больше устройств.
Хотя мы поместили VP9 на второе место в этом списке, он идет рука об руку с H.265/HEVC, о котором мы поговорим далее.
TL; ДР
VP9 — это более продвинутая и качественная технология сжатия, чем H.264/AVC, которая имеет большую совместимость, чем многие из ее альтернатив, и хорошо работает для потоковой передачи 4K.
H.265/HEVC
Экспертная группа по движущимся изображениям ISO/IEV разработала H.265 в качестве преемника H.264. Этот кодек, также называемый HEVC (High Efficiency Video Coding), направлен на повышение эффективности сжатия и поддержку разрешения 8K. Он создает файлы меньшего размера, чем H.264, что снижает пропускную способность, необходимую для просмотра этих потоков. Это делает его идеальным кодеком для потоковой передачи с высоким разрешением.
Тем не менее, только около 10 % закодированных файлов имеют формат H.265. Неопределенность в отношении гонораров задушила усыновление. В частности, распространители контента недовольны отсутствием прозрачности в отношении того, сколько им придется платить за использование этого кодека.
Драма о патентах и роялти вокруг H.265 напрямую привел к разработке кодека AV1 (о котором мы расскажем далее) Alliance for Open Media, а также к его несовместимости с воспроизведением через браузер. Почему? Лидеры отрасли, такие как Google, Microsoft и Mozilla, не были заинтересованы в добавлении поддержки дорогостоящего кодека в Chrome, Edge и Firefox. В результате только около 18,08 % браузеров принимают видео в формате H.265.
Единственное место, где H.265 остается лучшим вариантом, чем VP9 или H.264, — это доставка видео 4K и HDR на устройства в гостиной, поскольку они почти повсеместно поддерживаются на Smart TV.
TL;DR
Если вы доставляете OTT-контент премиум-класса на устройства в гостиной, лучшим выбором будет H.265, но будьте готовы платить лицензионные платежи.
Недовольные лицензионными отчислениями, связанными с H.265, Amazon, Netflix, Google, Microsoft, Cisco и Mozilla сформировали Alliance for Open Media. Цель? Создайте бесплатную альтернативу с открытым исходным кодом под названием AV1.
Несмотря на то, что работа над кодеком завершена, эта инициатива по демократизации доставки и воспроизведения высококачественного видео все еще находится в стадии реализации.
По словам Джонатана Розенберга, технического директора группы технологий для совместной работы в Cisco, «создание передового бесплатного видеокодека имеет первостепенное значение для постоянного успеха продуктов и услуг для совместной работы. Вот почему Cisco присоединилась к AOMedia в качестве члена-основателя и почему Cisco вложила средства в то, чтобы сделать AV1 эффективным и доступным для интернет-сообщества».
AV1 заявляет, что он на 30 % эффективнее, чем H.265, но эти утверждения еще требуют проверки независимыми источниками. Также потребуется некоторое время, прежде чем возможности аппаратного декодирования AV1 будут интегрированы в массовом масштабе. Даже устройства Apple не поддерживают этот кодек, несмотря на то, что Apple присоединилась к Альянсу еще в январе 2018 года.
Другими словами, когда дело доходит до AV1, отрасль все еще находится в постоянном движении.
"Единственным недостатком на данный момент является то, что [AV1] просто новый", – объясняет Энн Аарон, директор по технологиям кодирования в Netflix. «H.264 — действительно хороший кодек, который разрабатывался более десяти лет, а AV1 — новый, поэтому в реализации все еще есть перегибы».
Потребуется некоторое время, прежде чем возможности аппаратного декодирования AV1 будут интегрированы в массовом масштабе. Хотя руководители Netflix, Facebook и других компаний планируют перейти на AV1, нельзя игнорировать ограничения воспроизведения. Кодек AV1 также требует длительного времени кодирования, а время — деньги. По этой причине это экономичное решение только при кодировании видео для массового потребления.
В недавнем блоге, посвященном кодеку, Ян Озер заключил: "Даже если вы работаете на YouTube, если видео не наберет несколько миллионов просмотров, увеличение стоимости кодирования вряд ли приведет к окупится за счет экономии полосы пропускания».
TL; ДР
AV1 — это новейшая и лучшая технология кодирования видео с открытым исходным кодом. Тем не менее, еще слишком рано говорить о том, как повлияет внедрение, и длительное время кодирования в настоящее время приводит к высоким затратам на кодирование.
H.266/VVC
Спецификация H.266/VVC (Versatile Video Coding), самая новая разработка в области сжатия видео, была завершена только в 2020 году. Хотя она предназначена для того, чтобы узурпировать H.265 и H.264, у нее те же проблемы с лицензионными отчислениями. как и его предшественники.
В 2008 году главный технический директор Beamr Дрор Гилл объяснил: "Выплачивать лицензионные платежи — это нормально, если вы знаете, сколько и когда вам нужно заплатить. С H.264 было очень ясно, сколько вам нужно заплатить, был один орган, собирающий все гонорары, и это стало самым известным видеокодеком в мире. То же самое может произойти и с VVC, если они соберутся вместе, прежде чем выпустить стандарт».
И все же ставка роялти H.266/VVC в настоящее время остается загадкой. Непредвиденные проблемы на фронте лицензирования висят в воздухе, и мы также ждем, чтобы увидеть, как сработает внедрение кодека.
Коротко говоря, эксперт по кодекам Ян Озер:
«В целом разработчики кодеков H.266/VVC добились больших успехов в обеспечении обещанной экономии полосы пропускания, хотя окончательная производительность не будет известна до тех пор, пока не будут установлены правила оплаты роялти и мы не узнаем, какие инструменты находятся в каких профилях. Кроме того, учитывая широкий спектр других действующих факторов, в настоящее время невозможно узнать, достигнет ли ВВК критической массы».
TL; ДР
Все еще зарождающаяся технология, H.264/VVC даже не будет рассматриваться большинством издателей контента как минимум до 2022 года, поскольку вокруг кодека слишком много неизвестного, чтобы делать какие-либо прогнозы.
Рекомендации по кодированию
Рекомендации по кодированию не ограничиваются выбранным вами кодеком. Вам также необходимо учитывать частоту кадров, интервал между ключевыми кадрами и битрейт.
К счастью, прямую трансляцию всегда можно преобразовать в другой формат, как только она попадет на сервер. Это можно сделать с помощью программного обеспечения для потоковой передачи и ваших собственных серверов или в облаке для профессионально управляемой доставки.
Кодирование и транскодирование
Так что же такое транскодирование? Транскодирование включает в себя взятие закодированного файла и его декодирование, чтобы каким-то образом изменить его. Это может быть перекодирование данных в более распространенный кодек, преобразование видео в более низкое разрешение, преобразование файла в другой битрейт или преобразование его в более масштабируемый протокол.
После завершения процесса медиасервер повторно сжимает обработанный файл для доставки.
Транскодирование позволяет преобразовать видео с кодировкой H.264 в видео с кодировкой VP9 или H.265. Таким образом, ваш контент будет оптимизирован для потоковой передачи 4K конечным пользователям, а также выиграет от быстрого добавления видео.
Думайте о кодировании и перекодировании как об этапах подготовки к отпуску. Сначала вы сжимаете (кодируете) свою одежду в сумку для удобной транспортировки туда, куда направляетесь. По прибытии в пункт назначения вы распаковываете вещи, выбрасываете вещи, которые вам больше не нужны, добавляете безделушки, собранные во время путешествий, а затем снова упаковываете сумку для следующего этапа путешествия. Это транскодирование.
Доставка видео с несколькими кодеками
Вот оно. Видеокодеки — это то, что позволяет нам брать безграничный мир, снимать его кусочек через объектив нашей камеры и сжимать его для доставки через Интернет.
Поскольку существуют проприетарные кодеки и видеоконтейнеры, очень важно предоставлять зрителям несколько разных версий прямых трансляций.
К счастью, мы предлагаем программное обеспечение Wowza Streaming Engine для доставки видео с несколькими кодеками с использованием ваших собственных серверов — как локальных, так и на сторонней облачной платформе. Тем, кто хочет быстро приступить к работе без каких-либо проблем, лучше подойдет сервис Wowza Streaming Cloud.
Таким образом, вы можете преобразовывать потоки по мере необходимости, перекодируя данные в новые кодеки или трансмуксируя в другие форматы кодирования видео.
Читайте также:
