Что такое кодировка файла utf 8

Обновлено: 21.11.2024

В чем разница между UTF-8 и UTF-8 без спецификации? Что лучше?

UTF-8 лучше автоматически определяется по содержимому, чем по спецификации. Метод прост: попробуйте прочитать файл (или строку) в кодировке UTF-8 и, если это удастся, предположим, что данные в кодировке UTF-8. В противном случае предположим, что это CP1252 (или какая-то другая 8-битная кодировка). Любая восьмибитная кодировка, отличная от UTF-8, почти наверняка будет содержать последовательности, не разрешенные UTF-8. Чистый ASCII (7-битный) интерпретируется как UTF-8, но и в этом случае результат правильный.

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

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

UTF-8 не имеет спецификации. Когда вы помещаете кодовую точку U+FEFF в начало файла UTF-8, необходимо соблюдать особую осторожность при работе с ней. Это всего лишь одна из тех лжи Microsoft, например кодировка "Юникод", когда такой вещи не существует.

"Современные мейнфреймы (и AIX) поддерживают UTF-8 с прямым порядком байтов" UTF-8 не имеет конечности! нет перетасовки байтов, чтобы поместить пары или группы из четырех в правильный «порядок» для конкретной системы! Чтобы обнаружить последовательность байтов UTF-8, может быть полезно отметить, что первый байт многобайтовой последовательности «кодовая точка» (байты, которые НЕ являются «обычными» ASCII) имеет установленный бит MS и все от одного до трех еще последовательно меньшие значащие биты, за которыми следует бит сброса. Общее количество этих установленных битов на один меньше байтов, которые находятся в этой кодовой точке, и они ВСЕ будут иметь установленный старший разряд.

21 Ответ 21

Спецификация UTF-8 – это последовательность байтов в начале текстового потока (0xEF, 0xBB, 0xBF), которая позволяет читателю более надежно угадать, что файл закодирован в UTF-кодировке. 8.

Обычно BOM используется для обозначения порядка следования байтов в кодировке, но, поскольку порядок следования байтов не имеет отношения к UTF-8, в BOM нет необходимости.

Согласно стандарту Unicode, спецификация для файлов UTF-8 не рекомендуется:

2.6 Схемы кодирования

<р>. Использование спецификации не требуется и не рекомендуется для UTF-8, но может встречаться в контекстах, где данные UTF-8 преобразуются из других форм кодирования, использующих спецификацию, или когда спецификация используется в качестве подписи UTF-8. Дополнительную информацию см. в подразделе «Знак порядка следования байтов» в Разделе 16.8, Специальные предложения.

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

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

@bames53: Да, в идеальном мире сохранение кодировки текстовых файлов в качестве метаданных файловой системы было бы лучшим способом их сохранения. Но большинство из нас, живущих в реальном мире, не могут изменить файловую систему ОС, на которой запускаются наши программы, поэтому использование независимой от платформы подписи спецификации стандарта Unicode кажется лучшей и наиболее практичной альтернативой ИМХО.< /p>

@martineau Буквально вчера я наткнулся на файл со спецификацией UTF-8, которая не была UTF-8 (это был CP936). К сожалению, те, кто несет ответственность за огромную боль, вызванную спецификацией UTF-8, в значительной степени не обращают на это внимания.

Другие отличные ответы уже ответили на это:

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

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

Например, данные [EF BB BF 41 42 43] могут быть:

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

Кодировки нужно знать, а не угадывать.

@deceze Это, вероятно, лингвистически недопустимо: сначала ï (что допустимо), затем какие-то кавычки без пробела между ними (недопустимо). ¿ указывает на то, что это испанский язык, но ï не используется в испанском языке. Вывод: это не латиница-1 с уверенностью намного выше уверенности без нее.

@user Конечно, это не обязательно имеет смысл. Но если ваша система полагается на угадывание, вот тут-то и возникают неопределенности. Какой-то злонамеренный пользователь намеренно отправляет текст, начинающийся с этих трех букв, и ваша система внезапно предполагает, что она смотрит на UTF-8 со спецификацией, обрабатывает текст как UTF-8, где он должен использовать Latin-1, и имеет место некоторая инъекция Unicode. Просто гипотетический пример, но вполне возможный. Вы не можете судить о кодировке текста по его содержанию, и точка.

"Кодировки нужно знать, а не угадывать". Сердце и душа проблемы. +1, добрый сэр. Другими словами: либо стандартизируйте свой контент и скажите: «Мы всегда используем эту кодировку. Точка. Пишите так. Читайте так», либо разработайте расширенный формат, позволяющий хранить кодировку в виде метаданных. (Последнее, вероятно, также нуждается в какой-то «стандартной кодировке начальной загрузки». Например, сказать: «Часть, которая говорит вам, что кодировка всегда ASCII».)

Существует как минимум три проблемы с размещением спецификации в файлах с кодировкой UTF-8.

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

И, как уже упоминалось, не достаточно и не нужно иметь спецификацию, чтобы определить, что что-то является UTF-8:

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

Относительно пункта 1 «Файлы, не содержащие текста, больше не пусты, поскольку они всегда содержат спецификацию», это (1) объединяет уровень файловой системы ОС с интерпретируемым уровнем содержимого, а также (2) ошибочно предполагает, что использование одной спецификации также должен поместить спецификацию в каждый пустой файл. Практическое решение (1) состоит в том, чтобы не делать (2). По сути, жалоба сводится к тому, что «возможно нецелесообразно помещать спецификацию в пустой файл, что препятствует наиболее простому обнаружению логически пустого файла (путем проверки размера файла)». Тем не менее, хорошее программное обеспечение должно с этим справляться, поскольку оно имеет свое предназначение.

Относительно пункта 3: "Невозможно объединить несколько файлов вместе, потому что каждый файл теперь имеет спецификацию в начале", это просто неправильно. У меня нет проблем с объединением файлов UTF-8 с BOM, так что это вполне возможно. Я думаю, может быть, вы имели в виду, что Unix-land cat не даст вам чистый результат, результат, который имеет спецификацию только в начале. Если вы имели в виду это, то это потому, что кошка работает на уровне байтов, а не на уровне интерпретируемого содержимого, и аналогичным образом кошка не может работать, скажем, с фотографиями. Тем не менее, это не приносит большого вреда. Это связано с тем, что спецификация кодирует неразрывный пробел нулевой ширины.

Вот примеры использования спецификации, которые на самом деле вызывают серьезные проблемы, но многие люди не знают об этом.

BOM ломает скрипты

Сценарии оболочки, сценарии Perl, сценарии Python, сценарии Ruby, сценарии Node.js или любой другой исполняемый файл, который должен запускаться интерпретатором — все они начинаются со строки шебанга, похожей на одну из этих:

Символы шебанга представлены одними и теми же двумя байтами в расширенной кодировке ASCII, включая UTF-8, которая обычно используется для скриптов и других текстовых файлов в современных Unix-подобных системах. Однако файлы UTF-8 могут начинаться с необязательного знака порядка байтов (BOM); если функция «exec» специально определяет байты 0x23 и 0x21, то наличие спецификации (0xEF 0xBB 0xBF) перед шебангом предотвратит выполнение интерпретатора сценария. Некоторые специалисты рекомендуют не использовать метку порядка следования байтов в сценариях POSIX (Unix-подобных) [14] по этой причине, а также из соображений более широкой совместимости и философских соображений. Кроме того, в UTF-8 нет необходимости в отметке порядка следования байтов, поскольку в этой кодировке нет проблем с порядком байтов; он служит только для идентификации кодировки как UTF-8. [выделение добавлено]

Спецификация недопустима в JSON

Реализации НЕ ДОЛЖНЫ добавлять метку порядка следования байтов в начало текста JSON.

BOM является избыточным в JSON

Это не только незаконно в JSON, но и не нужно определять кодировку символов, потому что есть более надежные способы однозначно определить как кодировку символов, так и порядок следования байтов, используемые в любом потоке JSON (подробности см. в этом ответе).< /p>

BOM ломает синтаксические анализаторы JSON

Это не только запрещено в JSON и не нужно, но фактически ломает все программное обеспечение, определяющее кодировку с помощью метода, представленного в RFC 4627:

Определение кодировки и порядка следования байтов JSON, проверка первых четырех байтов на наличие байта NUL:

Теперь, если файл начинается с BOM, он будет выглядеть так:

UTF-32BE не начинается с трех NUL, поэтому он не будет распознан
UTF-32LE: за первым байтом не следуют три NUL, поэтому он не будет распознан
UTF-16BE имеет только один NUL в первых четырех байтах, поэтому он не будет распознан
UTF-16LE имеет только один NUL в первых четырех байтах, поэтому он не будет распознан

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

Кроме того, если реализация проверяет правильность JSON, как я рекомендую, она отклонит даже ввод, который действительно закодирован как UTF-8, поскольку он не начинается с символа ASCII

rfc7159, который заменяет rfc4627, на самом деле предполагает, что поддержка BOM может быть не такой уж плохой. По сути, отсутствие спецификации — это просто двусмысленный ляп, так что старое программное обеспечение Windows и Unix, не поддерживающее Unicode, все еще может обрабатывать utf-8.

Похоже, что JSON нуждается в обновлении, чтобы поддерживать его, то же самое со скриптами Perl, скриптами Python, скриптами Ruby, Node.js. Тот факт, что эти платформы решили не включать поддержку, не обязательно убивает использование BOM. Apple уже несколько лет пытается убить Adobe, и Adobe все еще существует. Но поучительный пост.

@EricGrange, вы, кажется, очень сильно поддерживаете спецификацию, но не понимаете, что это сделало бы вездесущий, универсально полезный формат оптимально-минимум «обычный текст» пережитком прошлое до UTF8! Добавление любого вида (внутриполосного) заголовка к потоку простого текста по определению налагает обязательный протокол на самые простые текстовые файлы, что делает его никогда более " самый простой"! И для какой выгоды? Для поддержки всех других древних кодировок CP, которые также не имели сигнатур, чтобы вы могли спутать их с UTF-8? (Кстати, ASCII — это тоже UTF-8. Значит, для них тоже спецификация? ;) Да ладно.)

Этот ответ и есть причина, по которой я задал этот вопрос! Я создал свои bash-скрипты в Windows и столкнулся с множеством проблем при публикации этих скриптов в Linux! То же самое с файлами jason.

В чем разница между UTF-8 и UTF-8 без BOM?

Краткий ответ: в UTF-8 спецификация кодируется как байты EF BB BF в начале файла.

Изначально предполагалось, что Unicode будет кодироваться в UTF-16/UCS-2. Спецификация была разработана для этой формы кодирования. Когда у вас есть 2-байтовые единицы кода, необходимо указать, в каком порядке находятся эти два байта, и общепринятым соглашением для этого является включение символа U+FEFF в качестве «метки порядка байтов» в начале данных. Символ U+FFFE постоянно не назначается, поэтому его присутствие можно использовать для обнаружения неправильного порядка байтов.

UTF-8 имеет одинаковый порядок байтов независимо от порядка следования байтов платформы, поэтому метка порядка байтов не требуется. Однако он может встречаться (как последовательность байтов EF BB FF ) в данных, которые были преобразованы в UTF-8 из UTF-16, или как «подпись», указывающая, что данные имеют формат UTF-8.

Без. Как ответил Мартин Кот, стандарт Unicode этого не рекомендует. Это вызывает проблемы с программным обеспечением, не поддерживающим спецификацию.

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

-1 относительно «Это вызывает проблемы с программным обеспечением, не поддерживающим BOM.», Это никогда не было проблемой для меня, но, наоборот, отсутствие спецификации вызывает проблемы с программным обеспечением, поддерживающим BOM (в частности, Visual C++) была проблема. Таким образом, это утверждение очень специфично для платформы, узкой точки зрения страны Unix, но представлено в заблуждение так, как будто оно применимо в целом. Чего нет.

Вы даже можете подумать, что у вас есть чистый ASCII-файл, просто взглянув на байты. Но это может быть и файл utf-16, где вам придется смотреть на слова, а не на байты. Современное программное обеспечение должно знать о спецификациях. Тем не менее чтение utf-8 может завершиться ошибкой при обнаружении недопустимых последовательностей, кодовых точек, которые могут использовать меньшую последовательность, или кодовых точек, которые являются суррогатными. Чтение utf-16 также может завершиться ошибкой, если есть потерянные суррогаты.

@Alf, я не согласен с вашей интерпретацией отношения, не связанного с спецификацией, как "специфичной для платформы, узкой точки зрения Unix". Для меня единственная причина, по которой ограниченность могла бы заключаться в «стране Unix», заключалась в том, что MS и Visual C++ появились раньше *NIX, чего не было. Тот факт, что MS (я полагаю сознательно) начала использовать спецификацию в UTF-8, а не в UTF-16, наводит меня на мысль, что они способствовали взлому sh , perl , g++ и многих других бесплатных и мощных инструментов. Хотите, чтобы все работало? Просто купите версии MS.MS создала проблему, специфичную для платформы, точно так же, как катастрофа с их диапазоном \x80-\x95.

UTF-8 с BOM лучше идентифицируется. Я пришел к этому выводу трудным путем. Я работаю над проектом, в котором одним из результатов является файл CSV, включающий символы Юникода.

Если CSV-файл сохранен без спецификации, Excel считает, что это ANSI, и отображает тарабарщину. Как только вы добавите «EF BB BF» впереди (например, повторно сохранив его с помощью «Блокнота» с кодировкой UTF-8 или Notepad++ с кодировкой UTF-8 и спецификацией), Excel откроет его нормально.

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

Это также полезно, если вы создаете файлы, которые содержат только ASCII, а позже к ним могут быть добавлены не-ASCII. Я только что столкнулся с такой проблемой: программное обеспечение, которое ожидает utf8, создает файл с некоторыми данными для редактирования пользователем. Если исходный файл содержит только ASCII, открывается в каких-то редакторах, а затем сохраняется, он оказывается в латинице-1 и все ломается. Если я добавлю спецификацию, она будет определена редактором как UTF8, и все будет работать.

Я нашел несколько инструментов, связанных с программированием, которые требуют, чтобы спецификация правильно распознавала файлы UTF-8. Visual Studio, SSMS, SoureTree.

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

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

Да, я потратил часы на выявление проблемы, вызванной файлом, закодированным как UTF-8 вместо UTF-8 без BOM. (Проблема обнаружилась только в IE7, так что это привело меня в погоню за гусем. Я использовал Django «include».)

Будущие читатели: обратите внимание, что проблема твита, о которой я упоминал выше, не была строго связана с BOM, но если бы это было так, то твит был бы искажен аналогичным образом, но в начале твита.

@user984003 Нет, проблема в том, что Microsoft ввела вас в заблуждение. То, что он называет UTF-8, не является UTF-8. То, что он называет UTF-8 без BOM, на самом деле является UTF-8.

@JoelFan Я уже не могу вспомнить, но я думаю, что каламбур мог быть задуман, несмотря на заявление автора :)

Вопрос. В чем разница между UTF-8 и UTF-8 без спецификации? Что лучше?

Вот несколько выдержек из статьи Википедии о метках порядка байтов (BOM), которые, как мне кажется, дают четкий ответ на этот вопрос.

О значении спецификации и UTF-8:

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

Аргумент в пользу НЕ использования спецификации:

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

Аргумент ЗА с использованием спецификации:

Что лучше, С или БЕЗ спецификации:

IETF рекомендует, чтобы, если протокол либо (а) всегда использовал UTF-8, либо (б) имел другой способ указать, какая кодировка используется, то он «СЛЕДУЕТ запретить использование U+FEFF как подпись.”

Мой вывод:

Используйте спецификацию только, если совместимость с программным приложением абсолютно необходима.

Также обратите внимание, что, хотя в упомянутой статье Википедии указано, что многие приложения Microsoft полагаются на спецификацию для правильного определения UTF-8, это не относится к всем приложениям Microsoft. Например, как указал @barlop, при использовании командной строки Windows с UTF-8 † команды такого типа и другие не ожидают наличия спецификации. Если спецификация присутствует, это может быть проблематично, как и для других приложений.

† Команда chcp предлагает поддержку UTF-8 (без спецификации) через кодовую страницу 65001.

Целевая аудитория: кодировщики 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 в целом, лучше избегать использования этой кодировки в общедоступном Интернете, поскольку она наносит ущерб функциональной совместимости и долгосрочному использованию.

Дополнительную информацию можно найти в нашем вводном руководстве по HTML и CSS для маркетологов.

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

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

Что такое UTF-8?

UTF-8 расшифровывается как «Формат преобразования Unicode — 8 бит». Нам это пока не поможет, поэтому давайте вернемся к основам.

Двоичный файл: как компьютеры хранят информацию

Для хранения информации компьютеры используют двоичную систему. В двоичном формате все данные представлены в виде последовательностей 1 и 0. Основной единицей двоичного кода является бит, представляющий собой одну единицу или 0. Следующая по величине единица двоичного кода, байт, состоит из 8 бит. Пример байта: «01101011».

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

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

ASCII: преобразование символов в двоичные

Американский стандартный код для обмена информацией (ASCII) был ранней стандартизированной системой кодирования текста. Кодирование — это процесс преобразования символов человеческого языка в двоичные последовательности, которые могут обрабатываться компьютером.

Библиотека ASCII включает все прописные и строчные буквы латинского алфавита (A, B, C...), все цифры от 0 до 9 и некоторые распространенные символы (такие как /, ! и ?). Каждому из этих символов присваивается уникальный трехзначный код и уникальный байт.

В таблице ниже показаны примеры символов ASCII с соответствующими кодами и байтами.

Точно так же, как символы объединяются в слова и предложения в языке, двоичный код делает то же самое в текстовых файлах. Итак, предложение «Быстрая коричневая лиса перепрыгивает через ленивую собаку». представленный в двоичном формате ASCII, будет:

Это мало что значит для нас, людей, но для компьютера это хлеб с маслом.

Количество символов, которые может представлять ASCII, ограничено количеством доступных уникальных байтов, поскольку каждый символ получает один байт. Если вы посчитаете, то обнаружите, что существует 256 различных способов сгруппировать восемь единиц и нулей вместе. Это дает нам 256 различных байтов или 256 способов представления символа в ASCII.Когда в 1960 году была введена ASCII, это было нормально, поскольку разработчикам требовалось всего 128 байт для представления всех нужных им английских букв и символов.

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

Юникод: способ хранения всех символов

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

Юникод теперь является универсальным стандартом для кодирования всех человеческих языков. И да, он даже включает смайлики.

Ниже приведены некоторые примеры текстовых символов и соответствующие им кодовые точки. Каждая кодовая точка начинается с «U» для «Unicode», за которой следует уникальная строка символов для представления символа.

Если вы хотите узнать, как генерируются кодовые точки и что они означают в Unicode, ознакомьтесь с этим подробным объяснением.

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

Однако Unicode сам по себе не хранит слова в двоичном формате. Компьютерам нужен способ перевода Unicode в двоичный код, чтобы его символы можно было хранить в текстовых файлах. Здесь на помощь приходит кодировка UTF-8.

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

UTF-8 – это система кодирования Unicode. Он может преобразовать любой символ Unicode в соответствующую уникальную двоичную строку, а также может преобразовать двоичную строку обратно в символ Unicode. В этом смысл «UTF» или «формата преобразования Unicode».

Помимо UTF-8, для Unicode существуют и другие системы кодирования, но UTF-8 уникальна, поскольку представляет символы в однобайтовых блоках. Помните, что один байт состоит из восьми битов, отсюда и «-8» в его имени.

В частности, UTF-8 преобразует кодовую точку (которая представляет один символ в Unicode) в набор от одного до четырех байтов. Первые 256 символов в библиотеке Unicode, включая символы, которые мы видели в ASCII, представлены как один байт. Символы, которые появляются позже в библиотеке Unicode, кодируются как двухбайтовые, трехбайтовые и, возможно, четырехбайтовые двоичные единицы.

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

Почему UTF-8 преобразовывает одни символы в один байт, а другие — в четыре байта? Короче, для экономии памяти. Используя меньше места для представления более распространенных символов (например, символов ASCII), UTF-8 уменьшает размер файла, позволяя использовать гораздо большее количество менее распространенных символов. Эти менее распространенные символы закодированы в два или более байта, но это нормально, если они хранятся экономно.

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

Еще одним преимуществом кодировки UTF-8 является ее обратная совместимость с ASCII. Первые 128 символов в библиотеке Unicode совпадают с символами в библиотеке ASCII, и UTF-8 переводит эти 128 символов Unicode в те же двоичные строки, что и ASCII. В результате UTF-8 может без проблем преобразовать текстовый файл, отформатированный в ASCII, в удобочитаемый текст.

Символы UTF-8 в веб-разработке

UTF-8 – это наиболее распространенный метод кодировки символов, используемый сегодня в Интернете, а также набор символов по умолчанию для HTML5. Более 95% всех веб-сайтов, включая ваш собственный, хранят символы таким образом. Кроме того, распространенные методы передачи данных через Интернет, такие как XML и JSON, кодируются в соответствии со стандартами UTF-8.

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

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

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

UTF-8 и UTF-16

Как я уже упоминал, UTF-8 — не единственный метод кодирования символов Unicode. Существует также UTF-16. Эти методы различаются количеством байтов, необходимых для хранения символа. UTF-8 кодирует символ в двоичную строку из одного, двух, трех или четырех байтов. UTF-16 кодирует символ Юникода в строку из двух или четырех байтов.

Это различие очевидно из их имен. В UTF-8 наименьшее двоичное представление символа составляет один байт или восемь бит. В UTF-16 наименьшее двоичное представление символа составляет два байта или шестнадцать бит.

И UTF-8, и UTF-16 могут преобразовывать символы Unicode в двоичные файлы, удобные для компьютера, и обратно. Однако они не совместимы друг с другом. Эти системы используют разные алгоритмы для преобразования кодовых точек в двоичные строки, поэтому двоичный вывод для любого заданного символа будет выглядеть по-разному при использовании обоих методов:

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

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

Расшифровка мира кодировки UTF-8

Это было много слов о словах, так что давайте подытожим то, что мы рассмотрели:

Компьютеры хранят данные, включая текстовые символы, в двоичном формате (1 и 0).
ASCII был одним из первых способов кодирования или преобразования символов в двоичный код, чтобы компьютеры могли их хранить. Однако в ASCII недостаточно места для представления нелатинских символов и чисел в двоичном формате.
Решением этой проблемы стал Unicode. Unicode присваивает уникальный «код» каждому символу в любом человеческом языке.
UTF-8 — это метод кодировки символов Unicode. Это означает, что UTF-8 берет кодовую точку для данного символа Unicode и переводит ее в двоичную строку. Он также делает обратное, читая двоичные цифры и преобразовывая их обратно в символы.
В настоящее время UTF-8 является самым популярным методом кодирования в Интернете, поскольку он может эффективно хранить текст, содержащий любой символ.
UTF-16 — это еще один метод кодирования, но он менее эффективен для хранения текстовых файлов (за исключением тех, которые написаны на некоторых языках, отличных от английского).

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

Но если вы обнаружите, что страницы вашего веб-сайта занимают слишком много места или если ваш текст замусорен символами ▢s и �s, пришло время применить ваши новые знания UTF-8 на практике.

UTF-8 — это умный способ кодирования текста Unicode. Я упоминал об этом пару раз в последнее время, но я не писал в блоге об UTF-8 как таковой. Вот так.

Проблему, которую решает UTF-8

Американские клавиатуры часто могут отображать 101 символ, что означает, что 101 символа будет достаточно для большинства текстов на английском языке. Семи бит было бы достаточно для кодирования этих символов, поскольку 2 7 = 128, и это то, что делает ASCII. Он представляет каждый символ 8 битами, поскольку компьютеры работают с битами в группах размеров, которые являются степенью двойки, но первый бит всегда равен 0, потому что он не нужен. Расширенный ASCII использует оставшееся пространство в ASCII для кодирования большего количества символов.

В общей сложности 256 символов могут подойти некоторым пользователям, но они не позволят вам представить, например, китайский язык. Первоначально Unicode хотел использовать два байта вместо одного байта для представления символов, что дало бы 2 16 = 65 536 возможностей, достаточных для охвата множества систем письма в мире. Но не все, поэтому Юникод расширился до четырех байт.

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

UTF-8 — это способ кодирования Unicode, при котором текстовый файл ASCII кодирует сам себя. Никакого лишнего пространства, кроме начального бита каждого байта, который ASCII не использует. И если ваш файл в основном представляет собой текст ASCII с добавлением нескольких символов, отличных от ASCII, символы, отличные от ASCII, просто сделают ваш файл немного длиннее.Вам не нужно внезапно заставлять каждый символ занимать в два или четыре раза больше места только потому, что вы хотите использовать, скажем, знак евро € (U+20AC).

Как это делает UTF-8

Поскольку первый бит символов ASCII равен нулю, байты с первым битом, равным 1, не используются и могут использоваться специально.

Когда программное обеспечение, читающее кодировку UTF-8, встречает байт, начинающийся с 1, оно подсчитывает, сколько единиц следует за ним, прежде чем встретится с 0. Например, в байте вида 110xxxxx за начальной 1 следует одна 1. Пусть < em>n — количество единиц между начальной 1 и первым 0. Оставшиеся биты в этом байте и некоторые биты в следующих n байтах будут представлять символ Unicode. Нет необходимости, чтобы n было больше 3 по причинам, о которых мы поговорим позже. То есть для представления символа Unicode с использованием UTF-8 требуется не более четырех байтов.

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

Байт вида 1110xxxx содержит четыре бита символа Unicode и говорит о том, что остальные биты приходятся на следующие два байта.

Байт вида 11110xxx содержит три бита символа Unicode и говорит о том, что остальные биты приходятся на следующие три байта.

После начального байта, уведомляющего о начале символа, распределенного по нескольким байтам, биты сохраняются в байтах формы 10xxxxxx. Поскольку начальные байты многобайтовой последовательности начинаются с двух битов 1, двусмысленности нет: байт, начинающийся с 10, не может обозначать начало новой многобайтовой последовательности. То есть кодировка UTF-8 является пунктуационной.

Поэтому многобайтовые последовательности имеют одну из следующих форм.

Если посчитать крестики в нижней строке, их 21. Таким образом, эта схема может представлять только числа длиной до 21 бита. Разве нам не нужны 32 бита? Оказывается, нет.

Хотя символ Юникода якобы является 32-битным числом, на самом деле для кодирования символа Юникода требуется не более 21 бита по причинам, описанным здесь. Вот почему n, количество единиц, следующих за начальной единицей в начале многобайтовой последовательности, должно быть только 1, 2 или 3. Схема кодирования UTF-8 может быть расширена, чтобы разрешить n = 4, 5 или 6, но это необязательно.

Эффективность

UTF-8 позволяет вам взять обычный файл ASCII и считать его файлом Unicode, закодированным с помощью UTF-8. Таким образом, UTF-8 так же эффективен, как ASCII, с точки зрения пространства. Но не по времени. Если программе известно, что файл на самом деле является ASCII-файлом, она может воспринимать каждый байт по номинальной стоимости, не проверяя, является ли он первым байтом многобайтовой последовательности.

И хотя обычный ASCII является допустимым для UTF-8, расширенный ASCII — нет. Таким образом, расширенные символы ASCII теперь будут занимать два байта вместо одного. Мой предыдущий пост был о путанице, которая может возникнуть из-за того, что программное обеспечение интерпретирует файл в кодировке UTF-8 как расширенный файл ASCII.

Читайте также: