В каком месте файла может использоваться bom маркер последовательности байтов
Согласно спецификации Юникода, маркер может стоять только в самом начале файла или потока. Если же символ U+FEFF встречается в середине потока данных, он должен[ источник не указан 1018 дней ] интерпретироваться как «нулевой ширины неразрывный пробел» (по существу, неотображаемый и ничего не меняющий символ). Однако, большинство[ сколько? ] браузеров, кроме Opera версий 12 и ниже, воспринимают BOM в середине документа как символ, занимающий целую строку, после чего генерируют перенос строки[1].
Для неразрывного пробела нулевой ширины в Юникоде есть и отдельный специальный символ — U+2060, который и рекомендуется использовать в этом качестве, а маркер последовательности байтов U+FEFF рекомендуется использовать только по своему прямому назначению.
Если формат представления символов Юникода точно известен принимающей программе заранее, то по стандарту Юникода маркер ставить не следует. И если формат объявлен другим способом, маркер по стандарту ставить не полагается.
К чему приводит наличие символа BOM
- в файлах с расширением php часто высвечивается ошибка:
Warning: Cannot modify header information — headers already sent by (output started at …
- в файлах с расширением html сбиваются настройки дизайна, сдвигаются блоки, могут появляться нечитаемые наборы символов.
Исправляем проблему с кодировкой с помощью смены кодировки
Вместо смены шрифта, можно сменить кодировку, которая используется при работе cmd.exe.
Узнать текущую кодировку можно введя в командной строке команду chcp , после ввода данной команды необходимо нажать Enter .
Как видно на скриншоте, текущая используемая кодировка Windows-1251
Для изменения кодировки нам необходимо воспользоваться командой chcp , где – это сам код кодировки, на которую мы хотим переключиться. Возможные значения:
- 1251 – Windows-кодировка (Кириллица);
- 866 – DOS-кодировка;
- 65001 – Кодировка UTF-8;
Т.е. для смены кодировки на DOS, команда примет следующий вид:
Для смены кодировки на UTF-8, команда примет следующий вид:
Для смены кодировки на Windows-1251, команда примет следующий вид:
Решение
Спецификация UTF-8 представляет собой последовательность байтов в начале текстового потока (EF BB BF), которая позволяет читателю более надежно угадывать файл как кодированный в UTF-8.
Как правило, спецификация используется для сигнализации о порядке байтов кодирования, но, поскольку порядок байтов не имеет отношения к UTF-8, эта спецификация не нужна.
Согласно Стандарт Юникод, Спецификация для файлов UTF-8 не рекомендуется:
Как сменить кодировку в консоли windows?
Файл должен выводиться в utf-8, а в консоли — 866, в итоге в браузере отображаются ромбы.
После команды chcp 65001 ничего не поменялось.
Поскольку в консоли используется кодовая страница 866, то если в реестре поменять значение REG_SZ-параметра «866» под ключом [HKLMSYSTEMCurrentControlSetControlNlsCodePage] с «C_866.nls» (по умолчанию) на иное, то и кодировка в cmd также должна измениться.
Но у меня в CodePage таких файлов нет. Есть типы REG.SZ по умолчанию и 4 файла с номерами 932 936 949 950
Вариант постоянно изменять в консоли chcp не подходит, но и не работает. Lucida console подключен в консоли. Cygwin64 Terminal и Gitbash не запускает python server
Какие-то ещё есть варианты?
generate.py
Первый способ
- 1.
Откройте файл с помощью редактора Notepad++.
- 2.
Нажмите Кодировки — Кодировать в UTF-8 (без BOM):
Второй способ
Подключитесь к серверу по SSH:
Как подключиться по SSH?
Выполните команду для проверки всех файлов на наличие в них символов BOM:
Если хотите проверить только определенную директорию, то перейдите в нужный каталог.
Если такие файлы есть, запустите следующую команду для удаления символов BOM:
BOM ломает скрипты
Сценарии оболочки, сценарии Perl, сценарии Python, сценарии Ruby, сценарии Node.js или любой другой исполняемый файл, который должен запускаться интерпретатором — все начинается с линия Шебанга который выглядит как один из тех:
Смотрите Википедию, статья: шебанг, раздел: магическое число:
Символы Шебанга представлены теми же двумя байтами в
расширенные кодировки ASCII, включая UTF-8, который обычно используется для
скрипты и другие текстовые файлы в современных Unix-подобных системах. Тем не мение,
Файлы UTF-8 могут начинаться с дополнительной метки порядка байтов (BOM); если
Функция «exec» специально определяет байты 0x23 и 0x21, затем
наличие спецификации (0xEF 0xBB 0xBF) до того, как шебанг предотвратит
интерпретатор сценария от выполнения. Некоторые власти рекомендуют
против использования метки порядка байтов в сценариях POSIX (Unix-like), [14]по этой причине и для более широкого взаимодействия и философского
проблемы. Кроме того, метка порядка следования байтов не требуется в UTF-8,
поскольку у этой кодировки нет проблем с порядком байтов; это служит только для
идентифицировать кодировку как UTF-8. [выделение добавлено]
Настройка кодировки шрифтов в cmd/bat (иероглифы, кракозябры)
В некоторых случаях, когда используется неверная кодировка, могут возникать так называемые кракозябры или иероглифы, т.е. не читаемые символы, которые невозможно разобрать при работе с командной строкой. Эти проблемы могут также возникать и при запуске различных BAT-файлов. В данной статье мы расскажем о том, как можно сменить шрифт или кодировку, чтобы избавиться от этой проблемы. Пример таких не читаемых символов можно видеть на картинке ниже:
Не корректно отображается русский текст в cmd? решение есть!
Как корректно отобразить Русский текст в CMD. Проблемы с кодировкой могут возникнуть, например, при выполнении Bat файла, когда нужно вывести в консоль русский текст и при других обстоятельствах, о которых речь пойдёт далее.
Рассмотрим пример: когда нужно вывести в консоль Русский текст, скажем «Примет мир». Для этого создадим Bat файл с именем «1.bat». Используйте для этого обычный Блокнот Windows (Notepad.exe) Запишем в него следующие строки!
BOM ломает парсеры JSON
Не только это нелегальный в JSON и не нужно, это на самом деле ломает все программное обеспечение которые определяют кодирование с использованием метода, представленного в RFC 4627:
Определяем кодировку и порядковый номер JSON, исследуя первые 4 байта для байта NUL:
Теперь, если файл начинается с спецификации, он будет выглядеть так:
Обратите внимание, что:
- UTF-32BE не запускается с тремя NUL, поэтому он не будет распознан
- UTF-32LE, за первым байтом не следуют 3 NUL, поэтому он не будет распознан
- UTF-16BE имеет только 1 NUL в первых 4 байтах, поэтому он не будет распознан
- UTF-16LE имеет только 1 NUL в первых 4 байтах, поэтому он не будет распознан
В зависимости от реализации все они могут быть неверно интерпретированы как UTF-8, а затем неверно истолкованы или отклонены как недействительные UTF-8, или не распознаны вообще.
Кроме того, если реализация проверяет действительный JSON, как я рекомендую, он отклонит даже ввод, который действительно закодирован как UTF-8, потому что он не начинается с символа ASCII < 128 как положено по RFC.
Всегда добавляйте префикс к текстовому файлу Юникода с меткой порядка байтов, которая информирует приложение о получении файла о том, что файл является упорядоченным по байтам. Доступные метки порядка байтов перечислены в следующей таблице. Поскольку обычный текст в Юникоде представляет собой последовательность из 16-разрядных значений кода, он учитывает порядок байтов, используемый при написании текста.
Метка порядка байтов не является управляющим символом, который выбирает порядок байтов текста.
| Метка порядка байтов | Описание |
|---|---|
| EF BB BF | UTF-8 |
| FF FE | UTF-16, с прямым порядком байтов |
| FE FF | UTF-16, обратный порядок байтов |
| FF FE 00 00 | UTF-32, с прямым порядком байтов |
| 00 00 FE FF | UTF-32, с обратным порядком байтов |
Корпорация Майкрософт использует UTF-16 с прямым порядком байтов.
В идеале весь текст в Юникоде следует только одному набору правил порядка следования байтов. Однако это невозможно, поскольку микропроцессоры отличаются размещением наименее значимого байта. Процессоры Intel и MIPS сначала размещаются на наименее значащий байт, тогда как процессоры Motorola (и все файлы в формате Юникод с обратным байтом) располагают его последними. При использовании только одного набора правил порядка байтов пользователи одного типа микропроцессора вынуждены менять порядок байтов каждый раз, когда текстовый файл считывается или записывается, даже если файл никогда не передается в другую операционную систему на основе другого микропроцессора.
Предпочтительное место для указания порядка байтов находится в заголовке файла, но текстовые файлы не имеют заголовков. Поэтому в Юникоде определен символ (U + FEFF) и несимвольный (U + ФФФЕ) в качестве меток порядка байтов. Они представляют собой зеркально отображаемые байтовые изображения.
Поскольку последовательность U + FEFF превышена в начале обычного текстового файла в формате, отличном от Юникода, она может служить неявным маркером или сигнатурой для того, чтобы идентификатор файла определялся как файл Юникода. Приложения, считывающие текстовые файлы в Юникоде и не в Юникоде, должны использовать эту последовательность в качестве индикатора того, что файл, скорее всего, является файлом Юникода. Сравните этот метод с использованием маркера MS-DOS EOF для завершения текстовых файлов.
Когда приложение обнаруживает U + FEFF в начале текстового файла, оно обычно обрабатывает файл как файл Юникода, хотя он может выполнять дальнейшие эвристические проверки. Такая проверка может быть настолько простой, как тестирование, чтобы выяснить, является ли изменение в байтах нижнего порядка большим, чем изменение в байтах с высоким порядковым номером. Например, если текст ASCII преобразуется в текст в Юникоде, каждый второй байт равен 0. Кроме того, при проверке того, что символы перевода строки и возврата каретки (U + 000A; и U + 000D), а также для четного или нечетного размера файла, могут дать строгий показатель природы файла.
Когда приложение обнаруживает U + ФФФЕ в начале текстового файла, оно интерпретирует его как файл с обратным байтом в Юникоде. Приложение может либо поменять порядок байтов, либо предупредить пользователя о том, что произошла ошибка.
Поскольку символ метки порядка байтов Юникода не найден ни в одной кодовой странице, он исчезает, если данные преобразуются в ANSI. В отличие от других символов Юникода, он не заменяется символом по умолчанию при преобразовании. Если метка порядка байтов находится в середине файла, она не интерпретируется как символ Юникода и не влияет на вывод текста.
Значение Юникода U + FFFF недопустимо в текстовых файлах и не может передаваться между приложениями. Он зарезервирован для частного использования приложения.
Robots.txt - это текстовый файл, в котором прописаны указания (директивы) по индексации страниц сайта. С помощью данного файла можно указывать поисковым роботам, какие страницы или разделы на веб-ресурсе нужно сканировать и заносить в индекс (базу данных поисковой системы), а какие - нет.
Почему robots.txt важен для продвижения?
Этот файл дает поисковым системам важные указания, которые напрямую будут влиять на результативность продвижения сайта. Использование robots.txt может помочь:
- предотвращению сканирования дублированного контента и бесполезных для пользователей страниц (результаты внутреннего поиска, технические страницы и др.);
- сохранению конфиденциальности разделов веб-сайта (например, можно закрыть системную информацию CMS);
- избежать перегрузки сервера;
- эффективно расходовать краулинговый бюджет на обход полезных страниц.
С другой стороны, если robots.txt содержит ошибки, то поисковые системы будут неправильно индексировать сайт, и в результатах поиска окажется не та информация, которая нужна.
Можно случайно запретить индексирование важных для продвижения страниц, и они не попадут в результаты поиска.
Ниже приведены ссылки на инструкции по использованию файла robots.txt:
Содержание отчета
- Кнопка «обновить» - при нажатии на неё данные о наличии ошибок в файле robots.txt обновятся.
- Содержимое строк файла robots.txt.
- При наличии в какой-либо директиве ошибки Labrika дает её описание.
Ошибки robots.txt, которые определяет Labrika
Сервис находит следующие виды ошибок:
Директива должна отделятся от правила символом ":".
Пустая директива и пустое правило.
Недопустимо делать пустую строку в директиве User-agent. Это основная директива, которая указывает, для какого поискового робота прописаны дальнейшие правила индексации.
Не указан пользовательский агент.
Каждое правило должно содержать не менее одной директивы «Allow» или «Disallow». Disallow закрывает раздел или страницу от индексации, Allow открывает страницы сайта для индексации (например, разрешает сканирование подкаталога или страницы в закрытом для обработки каталоге). Эти директивы задаются в формате: directive: [path], где значение [path] (путь к странице или разделу) указывать не обязательно. Однако роботы игнорируют директивы Allow и Disallow без указания пути. В этом случае они могут сканировать весь контент. Пустая директива Disallow: равнозначна директиве Allow: / , то есть "не запрещать ничего".
Пример ошибки в директиве Sitemap:
Не указан путь к карте сайта.
Перед правилом нет директивы User-agent
Правило должно всегда стоять после директивы User-agent. Размещение правила перед первым именем пользовательского агента означает, что никакие сканеры не будут ему следовать.
Найдено несколько правил вида "User-agent: *"
Запись вида User-agent: * означает, что правило задается для всех поисковых роботов.
запрещает всем поисковым роботам индексирование всего сайта.
Должна быть только одна директива User-agent для одного робота и только одна директива вида User-agent: * для всех роботов. Если в файле robots.txt несколько раз указан один и тот же пользовательский агент с разными списками правил, то поисковым роботам будет сложно определить, какие из этих правил нужно учитывать. В результате возникает большая неопределенность в действиях роботов.
Неизвестная директива
Обнаружена директива, которая не поддерживается поисковой системой (например, не описана в правилах использования robots.txt Яндекса).
Причины этого могут быть следующие:
- была прописана несуществующая директива;
- допущены ошибки синтаксиса, использованы запрещенные символы и теги;
- эта директива может использоваться роботами других поисковых систем.
Директивы «Disalow» не существует, допущена ошибка в написании слова.
Количество правил в файле robots.txt превышает максимально допустимое
Поисковые роботы будут корректно обрабатывать файл robots.txt, если его размер не превышает 500 КБ. Допустимое количество правил в файле - 2048. Контент сверх этого лимита игнорируется. Чтобы не превышать его, вместо исключения каждой отдельной страницы применяйте более общие директивы.
Например, если вам нужно заблокировать сканирование файлов PDF, не запрещайте каждый отдельный файл. Вместо этого запретите все URL-адреса, содержащие .pdf, с помощью директивы:
Правило превышает допустимую длину
Правило не должно содержать более 1024 символов.
Некорректный формат правила
В файле robots.txt должен быть обычный текст в кодировке UTF-8. Поисковые системы могут проигнорировать символы, не относящиеся к UTF-8. В таком случае правила из файла robots.txt не будут работать.
Чтобы поисковые роботы корректно обрабатывали инструкции в файле robots.txt, все правила должны быть написаны согласно стандарту исключений для роботов (REP), который поддерживают Google, Яндекс и большинство известных поисковых машин.
Использование кириллицы и других национальных языков
Использование кириллицы запрещено в файле robots.txt. Согласно утверждённой стандартом системе доменных имен название домена может состоять только из ограниченного набора ASCII-символов (буквы латинского алфавита, цифры от 0 до 9 и дефис). Если домен содержит символы, не относящиеся к ASCII (в том числе буквы национальных алфавитов), его нужно преобразовать с помощью Punycode в допустимый набор символов.
Возможно, был использован недопустимый символ
Допускается использование спецсимволов «*» и «$». Они применяются для указания шаблонов адресов при объявлении директив, чтобы не прописывать большой перечень конечных URL для блокировки. Например:
запрещает индексировать любые php файлы.
- Звездочка «*» обозначает любую последовательность и любое количество символов.
- Знак доллара «$» означает конец адреса и ограничивает действие знака «*».
Например, если /*.php соответствует всем путям, которые содержат .php., то /*.php$ соответствует только тем путям, которые заканчиваются на .php.
Символ «$» прописан в середине значения
Знак "$" можно использовать только один раз и только в конце правила. Он показывает, что стоящий перед ним символ должен быть последним.
Правило начинается не с символа "/" и не с символа "*".
Правило может начинаться только с символов «/» и «*».
Значение пути указывается относительно корневого каталога сайта, на котором находится файл robots.txt, и должно начинаться с символа слэш «/», обозначающего корневой каталог.
Правильным вариантом будет:
в зависимости от того, что вы хотите исключить из индексации.
Некорректный формат URL файла Sitemap
Sitemap - это карта сайта для поисковых роботов, которая содержит рекомендации того, какие страницы необходимо обходить в первую очередь и с какой частотой. Наличие карты сайта помогает роботам быстрее индексировать нужные страницы.
Некорректное имя главного зеркала сайта
Директива Host указывала роботу Яндекса главное зеркало сайта, если к веб-ресурсу был доступ по нескольким доменам. Остальные поисковые роботы её не воспринимали.
С марта 2018 года Яндекс отказался от директивы Host. Вместо неё используется раздел «Переезд сайта» в Вебмастере и 301 редирект.
Некорректный формат директивы «Crawl-delay»
Директива Crawl-delay задает роботу минимальный период времени между окончанием загрузки одной страницы и началом загрузки следующей.
Использовать директиву Crawl-delay следует в тех случаях, когда сервер сильно загружен и не успевает обрабатывать запросы поискового робота. Чем больше устанавливаемый интервал, тем меньше будет количество загрузок в течение одной сессии.
При указании интервала можно использовать как целые значения, так и дробные. В качестве разделителя применяется точка. Единица измерения – секунды:
К ошибкам относят:
- несколько директив Crawl-delay;
- некорректный формат директивы Crawl-delay.
С 22 февраля 2018 года Яндекс перестал учитывать директиву Crawl-delay. Чтобы задать скорость, с которой роботы будут загружать страницы сайта, используйте раздел «Скорость обхода сайта» в Яндекс.Вебмастере.
Google также не поддерживает эту директиву. Для Google-бота установить частоту обращений можно в панели вебмастера Search Console. Однако роботы Bing и Yahoo соблюдает директиву Crawl-delay.
Некорректный формат директивы «Clean-param»
Директива используется только для робота Яндекса. Google и другие роботы не поддерживают Clean-param.
Директива указывает, что URL страниц содержат GET-параметры, которые не влияют на содержимое, и поэтому их не нужно учитывать при индексировании. Робот Яндекса, следуя инструкциям Clean-param, не будет обходить страницы с динамическими параметрами, которые полностью дублируют контент основных страниц.
Labrika определяет некорректный формат директивы Clean-param, например:
В именах GET-параметров встречается два или более знака амперсанд "&" подряд:
Правило должно соответствовать виду "p0[&p1&p2&..&pn] [path]". В первом поле через символ «&» перечисляются параметры, которые роботу не нужно учитывать. Во втором поле указывается префикс пути страниц, для которых применяется правило. Параметры отделяются от префикса пути пробелом.
Имена GET-параметров должны содержать только буквы латинского алфавита, цифры, нижнее подчеркивание и дефис.
Префикс PATH URL для директивы Clean-param может включать только буквы латинского алфавита, цифры и некоторые символы: ".", "-", "/", "*", "_".
Ошибкой считается и превышение допустимой длины правила — 500 символов.
Строка содержит BOM (Byte Order Mark) — символ U+FEFF
BOM (Byte Order Mark - маркер последовательности байтов) — символ вида U+FEFF, который находится в самом начале текста. Этот Юникод-символ используется для определения последовательности байтов при считывании информации.
При создании и редактировании файла с помощью стандартных программ редакторы могут автоматически присвоить ему кодировку UTF-8 с BOM меткой.
BOM – это невидимый символ. У него нет графического выражения, поэтому большинство редакторов его не показывает. Но при копировании этот символ может переноситься в новый документ.
При использовании маркера последовательности байтов в файлах .html сбиваются настройки дизайна, сдвигаются блоки, могут появляться нечитаемые наборы символов, поэтому рекомендуется удалять маркер из веб-скриптов и CSS-файлов.
Как избавиться от BOM меток?
Избавиться от ВОМ довольно сложно. Один из простых способов это сделать - открыть файл в редакторе, который может изменять кодировку документа, и пересохранить его с кодировкой UTF-8 без BOM.
Например, вы можете бесплатно скачать редактор Notepad++, открыть в нём файл с ВОМ меткой и выбрать во вкладке меню «Кодировки» пункт «Кодировать в UTF-8 (без BOM)».
Метка порядка байтов ( BOM ) является частным использование специального Unicode символа, U + FEFF байтовый порядок MARK , чей внешний вид как магическое число в начале текстового потока может сигнализировать несколько вещей к программе чтения текста:
- Порядок байтов, или порядок байтов , текстового потока в случаях 16-битного и 32-битного кодирования;
- Тот факт, что кодировка текстового потока - Unicode, с высокой степенью достоверности;
- Какая кодировка символов Unicode используется.
Использование спецификации не является обязательным. Его присутствие мешает использованию UTF-8 программным обеспечением, которое не ожидает байтов, отличных от ASCII, в начале файла, но которое в противном случае могло бы обрабатывать текстовый поток.
Последовательность байтов спецификации различается в зависимости от кодировки Unicode (включая те, которые выходят за рамки стандарта Unicode, такие как UTF-7 , см. Таблицу ниже ), и ни одна из последовательностей, вероятно, не появится в начале текстовых потоков, хранящихся в других кодировках. Следовательно, размещение закодированной спецификации в начале текстового потока может указывать на то, что текст является Unicode, и определять используемую схему кодирования. Такое использование символа спецификации называется «подписью Unicode».
СОДЕРЖАНИЕ
использование
Если символ спецификации появляется в середине потока данных, Unicode говорит, что его следует интерпретировать как « неразрывный пробел нулевой ширины » (запрещает разрыв строки между глифами слов). В Unicode 3.2 это использование не рекомендуется в пользу символа « Word Joiner », U + 2060. Это позволяет использовать U + FEFF только в качестве спецификации.
UTF-8 , представление спецификации является ( шестнадцатеричное ) последовательность байтов 0xEF,0xBB,0xBF .
Стандарт Unicode разрешает спецификацию в UTF-8 , но не требует и не рекомендует ее использование. Порядок байтов не имеет значения в UTF-8, поэтому его единственное использование в UTF-8 - это сигнализировать в начале, что текстовый поток закодирован в UTF-8 или что он был преобразован в UTF-8 из потока, который содержал необязательная спецификация. Стандарт также не рекомендует удалять спецификацию, если она есть, чтобы при циклическом переключении между кодировками информация не терялась, и чтобы код, который на нее полагается, продолжал работать. IETF рекомендует, чтобы если протокол либо (а) всегда использует UTF-8, либо (б) имеет другой способ указать, какая кодировка используется, то ему «СЛЕДУЕТ запретить использование U + FEFF в качестве подписи».
Отсутствие спецификации позволяет обеспечить обратную совместимость текста с некоторым программным обеспечением, не поддерживающим Unicode. Примеры включают языки программирования, которые разрешают байты, отличные от ASCII, в строковых литералах, но не в начале файла.
UTF-8 - это разреженная кодировка в том смысле, что большая часть возможных комбинаций байтов не приводит к правильному тексту UTF-8. Двоичные данные и текст в любой другой кодировке могут содержать последовательности байтов, недопустимые как UTF-8. Практически единственное исключение - это когда текст состоит исключительно из байтов ASCII-диапазона. Поскольку все современные кодировки используют байты диапазона ASCII для представления символов ASCII, текст, содержащий только ASCII, можно безопасно интерпретировать как UTF-8, независимо от того, какая кодировка была предназначена системой, которая выдала байты. По этим соображениям эвристический анализ может с высокой степенью уверенности определить, используется ли UTF-8, без необходимости в спецификации.
Компиляторы и интерпретаторы Microsoft , а также многие части программного обеспечения в Microsoft Windows, такие как Блокнот, обрабатывают спецификацию как необходимое магическое число, а не используют эвристику. Эти инструменты добавляют спецификацию при сохранении текста как UTF-8 и не могут интерпретировать UTF-8, если только спецификация не присутствует или файл не содержит только ASCII. Windows PowerShell (до 5.1) добавит спецификацию при сохранении XML-документов UTF-8. Однако PowerShell Core 6 добавил переключатель -Encoding в некоторые командлеты, называемые utf8NoBOM, чтобы документ можно было сохранить без спецификации. Google Docs также добавляет спецификацию при преобразовании документа в простой текстовый файл для загрузки.
UTF-16
В UTF-16 BOM ( U+FEFF ) может быть помещен в качестве первого символа файла или потока символов, чтобы указать порядок байтов (порядок байтов) всех 16-битных единиц кода файла или потока. Если будет сделана попытка прочитать этот поток с неправильным порядком байтов, байты будут переставлены местами, таким образом доставляется символ U+FFFE , который определяется Unicode как « несимвольный », который никогда не должен появляться в тексте.
- Если 16-битные блоки представлены в порядке обратного байта, спецификация будет отображаться в последовательности байтов как 0xFE 0xFF
- Если в 16-битных единицах используется прямой порядок байтов , спецификация будет отображаться в последовательности байтов как 0xFF 0xFE
Ни одна из этих последовательностей не является допустимой UTF-8, поэтому их наличие указывает на то, что файл не закодирован в UTF-8.
Если нет спецификации, можно угадать, является ли текст UTF-16 и его порядок байтов, путем поиска символов ASCII (т. Е. Байта 0, смежного с байтом в диапазоне 0x20-0x7E, также 0x0A и 0x0D для CR и LF). Большое число (т.е. намного большее, чем случайный шанс) в одном и том же порядке является очень хорошим индикатором UTF-16, а то, находится ли 0 в четных или нечетных байтах, указывает порядок байтов. Однако это может привести как к ложным срабатываниям, так и к ложноотрицательным результатам.
Пункт D98 о соответствии (раздел 3.10) стандарта Unicode гласит: «Схема кодирования UTF-16 может начинаться или не начинаться с спецификации. Однако, когда нет спецификации и в отсутствие протокола более высокого уровня, порядок байтов в схеме кодирования UTF-16 - обратный порядок байтов ". Вопрос о том, действует ли протокол более высокого уровня или нет, открыт для интерпретации. Файлы, локальные для компьютера, для которых собственный порядок байтов является прямым порядком байтов, например, можно утверждать, что они неявно закодированы как UTF-16LE. Таким образом, презумпция прямого порядка байтов широко игнорируется. Стандарт кодирования W3C / WHATWG, используемый в HTML5, указывает, что контент с меткой «utf-16» или «utf-16le» должен интерпретироваться как little-endian «для работы с развернутым контентом». Однако, если присутствует метка порядка байтов, то эта спецификация должна рассматриваться как «более авторитетная, чем что-либо еще».
Программы, которые интерпретируют UTF-16 как байтовую кодировку, могут отображать искаженный беспорядок символов, но символы ASCII будут распознаваться, потому что младший байт представления UTF-16 совпадает с кодом ASCII и, следовательно, будет отображаться так же . Старший байт 0 может отображаться как ничего, пробел, точка или какой-либо другой неизменяющийся глиф.
UTF-32
Хотя спецификацию можно использовать с UTF-32 , эта кодировка редко используется для передачи. В остальном применимы те же правила, что и для UTF-16 .
Спецификация для UTF-32 с прямым порядком байтов представляет собой тот же шаблон, что и спецификация с прямым порядком байтов UTF-16, за которой следует символ NUL, что является необычным примером того, что спецификация является одним и тем же шаблоном в двух разных кодировках. Программисты, использующие спецификацию для определения кодировки, должны будут решить, какой первый символ - UTF-32 или NUL - более вероятен.
Метки порядка байтов по кодировке
В этой таблице показано, как символ спецификации представлен как последовательность байтов в различных кодировках и как эти последовательности могут отображаться в текстовом редакторе, который интерпретирует каждый байт как устаревшую кодировку ( CP1252 и обозначение курсора для элементов управления C0 ):
Читайте также: