Удалить бомбу из файла
Обновлено: 07.07.2024
Я столкнулся с проблемой, связанной со спецификацией (меткой порядка байтов) перед строковыми данными UTF-8.
Мы импортируем некоторые файлы CSV из PayPal.
Теперь они включают спецификацию перед данными CSV в кодировке UTF-8.
Эта спецификация вызывает некоторые проблемы.
Я считаю, что это ошибка в преобразовании байтовых данных во внутреннее строковое представление ruby.
Есть обходной путь, но его необходимо задокументировать:
Но я прошу улучшить обработку UTF-BOM:
- Спецификация используется только для кодирования передачи на уровне потока байтов.
- Спецификация НЕ ДОЛЖНА быть частью строки во внутреннем представлении.
Кстати: stdlib::CSV подавляет спецификацию
Я бы хотел добавить код для обходного пути:
Связанные задачи
Обновлено shevegen (Robert A. Heiler) больше 3 лет назад
Кстати: stdlib::CSV подавляет спецификацию
Я не могу сказать, насколько это распространено или есть ли ошибка; но в том случае,
что может быть, и вариант использования или ситуация, связанная с ошибкой или ошибочным
поведением, влияющим на других рубиновых хакеров, я согласен в этом случае, что CSV
вероятно должен быть в состоянии для обработки записей, относящихся к спецификации, тем или иным
способом (будь то автоматически или через другой API).
Я также согласен с тем, что об этом можно было бы где-нибудь упомянуть, будь то документация по
csv или где-то еще.
Обходной путь: я предполагаю, что вы имели в виду только решение, если другие столкнутся
с аналогичной проблемой, а не постоянное добавление к классу String, да?
(Я спрашиваю об этом, потому что постоянное добавление определенного метода в класс String в
ruby может быть намного сложнее сделать и получить одобрение, тогда как расширение в
CSV ruby, скорее всего, проще и возможно. )
Обновлено nobu (Nobuyoshi Nakada) больше 3 лет назад
- Параметр Назначена изменен на 13939
- Описание обновлено (Разница(diff))
foonlyboy (Эйке Диркс) написал:
Я считаю, что это ошибка в том, как байтовые данные преобразуются во внутреннее строковое представление ruby.
Да, спецификацию следует удалять при преобразовании, чтении из потока данных.
Есть обходной путь, но его необходимо задокументировать:
Он задокументирован на IO.new, и вы также можете использовать его на CSV.open.
rdoc файла CSV.open:
Вы должны передать имя файла и при желании можете добавить режим для open() Ruby.
rdoc из Kernel.open:
Полную документацию по директивам строки режима см. в документации IO.new.
Если используется "BOM|UTF-8", "BOM|UTF-16LE" или "BOM|UTF16-BE", Ruby проверяет
спецификацию Unicode во входном документе, чтобы помочь определить кодировка. Для кодировок
UTF-16 режим открытия файла должен быть двоичным. При наличии спецификация
удаляется и используется внешнее кодирование из спецификации. Когда спецификация
отсутствует, заданная кодировка Unicode используется как ext_enc . (Опция кодировки BOM-set
нечувствительна к регистру, поэтому "bom|utf-8" также допустима.)
Приветствуются исправления для улучшения документации.
- Спецификация используется только для кодирования передачи на уровне потока байтов.
Это правда наполовину.
Если символ BOM появляется в середине потока данных, Unicode говорит, что его следует интерпретировать как "неразрывный пробел нулевой ширины"
Символ в другом месте не называется "BOM".
- Спецификация НЕ ДОЛЖНА быть частью строки во внутреннем представлении.
Да, его нужно удалить при чтении, это единственный шанс правильно удалить спецификацию.
Обновлено foonlyboy (Eike Dierks) больше 3 лет назад
Я изучил его более внимательно:
io.c делает это в
который вызывается:
Он задокументирован на IO.new, и вы также можете использовать его на CSV.open.
Да, я знал об этом.
Я также согласен с тем, что преобразование должно происходить при открытии файла.
И я не смог найти способа применить к нему io_strip_bom(),
даже через StringIO.
(но Ruby все равно не для применения трюков)
Мне кажется, нобу тоже согласен с тем, что спецификацию всегда следует удалять.
Если символ BOM появляется в середине потока данных, Unicode говорит, что его следует интерпретировать как "неразрывный пробел нулевой ширины"
Меня это пока не особо волнует.
(хотя я могу себе представить, что это произойдет при объединении файлов.)
Но давайте сначала исправим более простые проблемы.
Я думаю, что спецификация используется в байтовых потоках по двум причинам:
- магическое число для данных в кодировке UTF (которое может применяться даже к UTF-8)
- магическое число для различения порядка байтов UTF при использовании UTF-16, UTF-32, UTF-36?
Но в мире ruby у нас есть String
Мы должны удалить все артефакты из любой внешней кодировки.
Я считаю, что для этого может потребоваться много изменений, а не только одно место в коде,
но я считаю, что это должно быть полностью совместимо с кодом большинства клиентов.
Это все равно должно соответствовать спецификации ruby,
потому что нигде не было заявлено, что String хранит спецификацию.
Простите меня за длинное письмо,
но я думал, что эти проблемы с кодировкой остались в прошлом.
Мы также можем рассмотреть другие языки.
Создает хороший розетт-код .
Здравствуйте!
Я разработал веб-сайт с помощью Vim, работающего как на Linux, так и на Windows, и
у меня никогда не было проблем. На днях кому-то еще нужно было отредактировать некоторые
файлы, и он попытался использовать Mac и Windows. Судя по всему, в файлах, которые он
редактировал, есть эта метка порядка следования байтов. Я обнаружил это только с помощью
валидатора w3c, который выдал мне следующее предупреждение:
"В файле UTF-8 обнаружена метка порядка байтов. Известно, что метка порядка байтов Unicode
(BOM) в файлах с кодировкой UTF-8 вызывает проблемы для некоторых текстовых
редакторов и старых браузеров. . Возможно, вы захотите отказаться от его использования,
пока он не будет лучше поддерживаться."
Единственным способом решить проблему было использование notepad++, в котором
есть возможность явного сохранения файла без спецификации. Есть ли способ
сделать то же самое в Vim? Может быть, даже отображать эту спецификацию?
Нил Берд
> Единственный способ решить проблему — это использовать notepad++, в котором
> есть возможность явно сохранить файл без спецификации. Есть ли способ
> сделать то же самое в Vim? Может быть, даже отображать эту спецификацию?
Выполните ':set nobomb' перед сохранением, чтобы удалить спецификацию.
Тони Мечелинк
08.09.11, 13:37, Карло Тримарчи написал:
> Привет,
> Я разработал веб-сайт с помощью Vim, работая как на Linux, так и на Windows, и
> никогда не имел любые проблемы. На днях кому-то еще нужно было отредактировать некоторые
> файлы, и он попытался использовать Mac и Windows. Судя по всему, в файлах, которые он
> редактировал, есть эта метка порядка следования байтов. Я обнаружил это только с помощью
> валидатора w3c, который выдал мне это предупреждение:
>
> "В файле UTF-8 найдена метка порядка байтов. Метка порядка байтов Unicode
> (BOM) в файлах с кодировкой UTF-8, как известно, вызывает проблемы для некоторых текстовых
> редакторов и старых браузеров. Вы можете рассмотреть возможность избегать его использования
> до тех пор, пока он не будет лучше поддерживаться."< /p>
Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode,
включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью
стандарта HTML. Некоторые текстовые редакторы (такие, как я думаю, Блокнот)
задыхаются от этого, но ответ на этот вопрос заключается в использовании лучшего редактора, такого как Vim или
даже WordPad, которые знают о спецификации и обрабатывают ее. правильно, даже в
UTF-8.
Для некоторых других типов текстовых файлов (например, для большинства исходных файлов и сценариев оболочки) лучше сохранять файл без спецификации, но для
самых "сетевых" форматов, включая HTML , CSS и, кажется, XML, XHTML и т. д.,
спецификация не представляет проблемы и даже может помочь (например, в случае, если веб-сервер
неправильно устанавливает кодировку или вообще не устанавливает ее в его заголовок Content-Type).
>
> Единственный способ решить проблему — это использовать notepad++, в котором
> есть возможность явно сохранить файл без спецификации. Есть ли способ
> сделать то же самое в Vim? Может быть, даже для отображения этой спецификации?
>
> Спасибо,
> Карло
>
Чтобы сохранить файл без спецификации:
:setlocal nobomb
:w
Чтобы узнать у Vim, есть ли спецификация:
Ответ: бомба для "присутствует спецификация" или nobomb для "отсутствует спецификация".
Обратите внимание, что независимо от состояния параметра "бомба" спецификация может
существовать только в том случае, если "кодировка файла" является одной из UTF-8, UTF-16 (или ее UCS-2,
подмножество) или UTF-16 (он же UCS-4), любой из них (кроме UTF-8, для которого
порядок байтов не важен) с любым порядком байтов. Для других значений 'fileencoding'
параметр 'bomb' не имеет значения.
Чтобы отобразить наличие или отсутствие спецификации в строке состояния:
С уважением,
Тони.
--
Джордж Оруэлл был оптимистом.
Кристиан Брабандт
Во вторник, 9 августа 2011 г., 17:13, Тони Мехелинк написал:
> Чтобы сохранить файл без спецификации:
>
> :setlocal nobomb
> :в
:w ++bin
также должен работать с IIRC.
Карло Тримарчи
> Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode,
> включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью
> стандарта HTML.
Ну, со спецификацией весь макет веб-сайта оказался нарушенным в
Internet Explorer 7. Нет проблем с Firefox. Тем не менее, кажется,
это не проблема недооценивать.
> Для некоторых других типов текстовых файлов (большинство исходных файлов и сценариев оболочки, для экземпляра
>) лучше сохранять файл без спецификации, а для большинства "веб"
> форматы, включая HTML, CSS и, я думаю, XML, XHTML и т. д., спецификация не представляет
> проблемы и даже может помочь (например, в случае, если веб-сервер неправильно устанавливает кодировку
> или вообще не в его заголовке Content-Type).
Это был файл php, так что, возможно, проблема в нем.
> Чтобы сохранить файл без спецификации:
>
> :setlocal nobomb
> :w
>
> Чтобы спросить Vim, есть ли спецификация :
>
> :setlocal bomb?
>
> Ответ: bomb для "BOM присутствует" или nobomb для "отсутствует BOM".
>
>
Спасибо за всю информацию и команды. Очень полезно.
Бен Фриц
9 августа, 10:13, Тони Мехелинк
написал:
> 08.09.11 13:37, Карло Тримарчи написал:
>
> > Привет,
> > Я разработал веб-сайт с помощью Vim, работающий как на Linux, так и на Windows. и
> > никогда не было проблем. На днях кому-то еще нужно было отредактировать несколько
> > файлов, и он попытался использовать Mac и Windows. Судя по всему, в файлах, которые он
> > редактировал, есть эта метка порядка следования байтов. Я обнаружил это только с помощью валидатора
> > w3c, который выдал мне следующее предупреждение:
>
> > "В файле UTF-8 найдена метка порядка байтов. Метка порядка байтов Unicode < br />>> (BOM) в файлах с кодировкой UTF-8, как известно, вызывает проблемы для некоторых текстовых
> > редакторов и старых браузеров. Вы можете рассмотреть возможность избегать его использования,
> > до тех пор, пока он не будет лучше поддерживается».
>
> Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode,
> включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью
> стандарта HTML. Некоторые текстовые редакторы (такие, как я думаю, Блокнот)
> задыхаются от этого, но ответ на этот вопрос заключается в использовании лучшего редактора, такого как Vim или
> даже WordPad, которые знают о спецификации и обрабатывать его правильно, даже в
> UTF-8.
>
Неправда. W3C по-прежнему явно рекомендует не использовать спецификацию для
UTF-8 (но я не помню ссылку навскидку, извините, я думаю, что она была
либо в спецификации HTML4.01, либо где-то в спецификации HTML5) . Даже современные браузеры,
такие как Firefox и Opera, не могут использовать спецификацию в файлах UTF-8 для XHTML,
подаваемого как XML. Использование спецификации для UTF-8 в Интернете — плохая идея.
Однако спецификация рекомендуется и полезна для UTF-16 или UTF-32 и
подобных.
панорама
Во вторник, 9 августа 2011 г., в 23:13, Тони Мечелинк
написал:
>
> Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode,
> включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью
> стандарта HTML.
BOM — это стандарт для UCS2 или UTF-16, а не для UTF-8.
BOM для utf-8 вызовет проблемы для большинства программ, которые ожидают текстовые
потоки. gcc — хороший пример, большинство утилит GNU CLI отклонят
utf-8 с BOM.
Конечно, валидатор W3C будет жаловаться на это.
Тони Мечелинк
08.10.11, 02:18, pansz написал:
> Во вторник, 9 августа 2011 г., 23:13, Тони Мечелинк
> написал:
>>< br />>> Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode
>>, включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью
>> стандарта HTML.
>
> Спецификация является стандартом для UCS2 или UTF-16, а не для UTF-8.
>
> Спецификация для utf-8 вызовет проблемы для большинства программ, которые ожидают текстовые
> потоки. gcc — хороший пример, большинство утилит GNU CLI отклонят
> utf-8 с BOM.
В части, которую вы вырезали, я прямо упомянул, что для некоторых других типов текста,
отличных от HTML или CSS (таких, как я сказал, исходные файлы и
скрипты оболочки) лучше сохранить файл без спецификации.
>
> И валидатор W3C, конечно, будет жаловаться на это.
>
С уважением,
Тони.
--
"Мой вес идеально подходит для моего роста, который варьируется"
Бен Фриц
10 августа, 6:19, Тони Мехелинк
написал:
>
> >> Это сообщение устарело. Спецификация поддерживается во всех кодировках Unicode,
> >> включая UTF-8, всеми "достаточно новыми" браузерами. Он также является частью стандарта
> >> HTML.
>
> > Спецификация является стандартом для UCS2 или UTF-16, а не для UTF-8.
>
> BOMs?", пункт 3.
>
>
>
> > BOM для utf-8 вызовет проблемы для большинства программ, которые ожидают текст
> > потоки. gcc — хороший пример, большинство утилит GNU CLI отклонят
> > utf-8 с BOM. видов
> текста, чем HTML или CSS (таких, как я сказал, исходные файлы и
> скрипты оболочки), лучше сохранять файл без спецификации.
>
>
>
> > И валидатор W3C, конечно, будет жаловаться на это.
>
> . с предупреждением, а не с ошибкой; и Тиди не будет.
>
При разработке TOhtml я столкнулся с проблемами в некоторых браузерах при
использовании UTF-8 с BOM. Если я правильно помню, браузеры, которые на самом деле
правильно обрабатывают XHTML, такие как Opera и Firefox, интерпретировали
BOM как символы, появляющиеся перед прологом XML
Я реализовал процесс, связанный с файловой операцией в бизнесе, но из файла UTF-8 (с спецификацией). Теперь, когда вы узнали, как удалить спецификацию, я подытожу ее на будущее.
Что такое спецификация?
Прежде всего, кто такая спецификация?
Грубо говоря со спецификацией ** Метка в начале файла, созданного с кодом символа Unicode **. В UTF-8 он представлен 3 байтами ** 0xEF 0xBB 0xBF **. Спецификацию обычно нельзя увидеть в Блокноте, но на самом деле она находится в начале содержимого файла. У него есть спецификация, и когда он считывается компьютером, он интерпретируется и выполняется таким образом. И у него есть две основные роли ориентира.
- Чтобы показать, что он написан в кодировке Юникод.
- Для указания порядка битов, называемого порядком байтов в кодировках UTF-16 и UTF-32. В зависимости от порядка расположения ・ С прямым порядком байтов (порядок, начиная со старшего байта) ・ С прямым порядком байтов (порядок, начиная с младшего байта) Существует два типа
Почему существует кодировка UTF-8 (с спецификацией)?
При связывании с символами с кодом символа длиной 2 байта и более, такими как UTF-16 и UTF-32, спецификация используется для указания порядка следования байтов. Однако при связывании с 1-байтовым символьным кодом, таким как UTF-8, вам не нужно указывать порядок байтов. Так почему же существует UTF-8 (с спецификацией)?
После расследования я обнаружил, что причиной была спецификация, когда Excel открывал CSV. Когда Excel открывает CSV, он пытается открыть с помощью Shift-JIS, поэтому UTF-8 без спецификации. Когда я пытаюсь прочитать записанный файл, символы искажаются. Чтобы предотвратить это, даже при открытии CSV с помощью BOM используйте кодировку символов Unicode. Вам нужно указать, чтобы прочитать его.
Как удалить спецификацию
Теперь я объясню, как удалить спецификацию, которая является основной темой. Java не предполагает, что UTF-8 изначально имеет спецификацию. Поэтому при чтении файла со спецификацией используйте спецификацию в качестве другого символа. Рассматривайте его как аналогичный и не удаляйте спецификацию. Поэтому, если вы хотите удалить спецификацию, вам нужно реализовать такой процесс отдельно.
Java
Другой способ — использовать библиотеку классов, предоставляемую apache. Подробные характеристики см. ниже.
Целевая аудитория: программисты XHTML/HTML (использующие редакторы или скрипты), разработчики скриптов (PHP, JSP и т. д.), кодировщики CSS, менеджеры веб-проектов и все, кому нужно лучше понять, что такое спецификация и как она влияет на HTML.
Вопрос
Что такое метка порядка байтов и что мне нужно знать о ней при создании HTML?
Ответить
Что такое метка порядка байтов?
В начале страницы, использующей кодировку символов Unicode, вы можете найти несколько байтов, представляющих кодовую точку Unicode U+FEFF BYTE ORDER MARK (сокращенно ).
Имя BYTE ORDER MARK является псевдонимом исходного имени символа ZERO WIDTH NO-BREAK SPACE (ZWNBSP). С введением U+2060 WORD JOINER больше нет необходимости когда-либо использовать U+FEFF для его эффекта ZWNSP, поэтому с этого момента и с появлением формального псевдонима имя ZERO WIDTH NO-BREAK SPACE больше не помогает, и мы будем использовать здесь псевдоним.
При правильном использовании спецификация невидима.
До появления UTF-8 в начале 1993 года для передачи текста в формате Unicode предполагалось использовать 16-битные единицы кода с кодировкой UCS-2, которая позже была расширена до UTF-16. 16-битные кодовые единицы могут быть выражены в виде байтов двумя способами: сначала старший байт (big-endian) или младший значащий байт (little-endian). Чтобы сообщить, какой порядок байтов использовался, U+FEFF (метка порядка байтов) использовалась в начале потока как магическое число, которое логически не является частью текста, представляемого потоком.
На рисунке ниже показаны байты, используемые в последовательности двухбайтовых символов. Каждое двузначное шестнадцатеричное число представляет собой байт в потоке текста. Вы можете видеть, что порядок двух байтов, представляющих один символ, обратный для хранения с прямым порядком байтов и прямым порядком байтов. Метка порядка байтов указывает, какой порядок используется, чтобы приложения могли немедленно декодировать содержимое.
В кодировке UTF-8 наличие спецификации не обязательно, поскольку, в отличие от кодировок UTF-16, в символе нет альтернативной последовательности байтов.Однако спецификация может по-прежнему встречаться в кодированном тексте UTF-8 либо как побочный продукт преобразования кодировки, либо потому, что она была добавлена редактором, чтобы пометить содержимое как UTF-8. В этой ситуации спецификацию часто называют .
Что мне нужно знать о спецификации?
В большинстве случаев вам не придется беспокоиться о метке порядка байтов в UTF-8. Вы обнаружите, что некоторые редакторы (например, Блокнот в Windows) всегда будут добавлять спецификацию при сохранении файла в кодировке UTF-8, другие предложат вам выбор.
В HTML5 браузеры должны распознавать спецификацию UTF-8 и использовать ее для определения кодировки страницы, а последние версии основных браузеров обрабатывают спецификацию должным образом при использовании страниц в кодировке UTF-8.
Кроме того, существует ряд ситуаций, когда спецификация, особенно из-за ее невидимости, может вызвать проблемы. Дополнительную информацию о них см. в разделе ниже.
Если вы используете кодировку UTF-16 для своей страницы (и мы настоятельно рекомендуем вам этого не делать), есть некоторые дополнительные соображения.
Обнаружение спецификации
Вы можете узнать, содержит ли страница спецификацию в начале или ниже по содержанию, с помощью средства проверки интернационализации W3C. Спецификация в начале страницы будет отображаться на информационной панели. Спецификация, включенная в страницу внизу (обычно из-за того, что содержимое добавляется на страницу из внешнего источника), будет отражена в разделе «Подробный отчет».
Вы можете попытаться найти подпись UTF-8 в своем контенте в своем редакторе, но если ваш редактор правильно обрабатывает спецификацию, вы, вероятно, не сможете ее увидеть. В двоичном редакторе, способном отображать шестнадцатеричные значения байтов в файле, подпись UTF-8 отображается как EF BB BF.
Кроме того, ваш редактор может сообщить вам в строке состояния или меню, в какой кодировке находится ваш файл, включая информацию о наличии или отсутствии подписи UTF-8. Например, если вы используете «Сохранить как» в Dreamweaver и в начале вашего файла есть спецификация, вы увидите флажок в поле «Включить подпись Unicode (BOM)». Вы также можете указать в настройках (см. иллюстрацию), должны ли новые документы использовать спецификацию по умолчанию.
Возможные проблемы со спецификацией UTF-8
Ниже приведены некоторые ситуации, когда известно, что метка порядка байтов вызывает проблемы.
В целом эти проблемы исчезают по мере того, как люди переходят на новые версии браузеров и инструментов редактирования. О них стоит знать, если ваша пользовательская база все еще использует более старые технологии. Однако дело не только в устаревших проблемах.
PHP включает
Во время написания этой статьи, если вы включаете какой-либо внешний файл на страницу с использованием PHP, и этот файл начинается с спецификации, это может создавать пустые строки.
Это связано с тем, что спецификация не удаляется перед включением на страницу и действует как символ, занимающий строку текста. См. пример. В примере пустая строка, содержащая спецификацию, появляется над первым элементом включенного текста.
Следует убедиться, что включаемые файлы не начинаются с спецификации.
Обработка программным кодом
Необходимо соблюдать осторожность и учитывать спецификацию в сценариях или программном коде, которые автоматически обрабатывают файлы, начинающиеся с спецификации. Например, при сопоставлении с шаблоном в начале файла, начинающегося с спецификации, вам потребуется дополнительный код для проверки наличия спецификации и игнорирования ее, если она найдена.
Кодировка UTF-8 без спецификации имеет то свойство, что документ, содержащий только символы из диапазона US-ASCII, кодируется побайтно так же, как тот же документ, закодированный с использованием кодировки US-ASCII. Такой документ можно обрабатывать и понимать, если он закодирован либо как UTF-8, либо как US-ASCII. Добавление спецификации вставляет дополнительные байты, отличные от ASCII, так что это уже не так. Если у вас есть процессы или сценарии, которые предполагают, что содержимое состоит только из символов US-ASCII, вам нужно будет избегать спецификации.
На момент написания этой статьи не все браузеры делали это, поэтому пока не следует полагаться на то, что все читатели вашей страницы получат от этого пользу.
Другие проблемы
Если вы используете приложения или сценарии в серверной части вашего сайта, убедитесь, что они также могут распознавать и обрабатывать спецификацию.
Мы настоятельно рекомендуем вам не менять кодировку файла UTF-8 с кодировки Unicode на кодировку, отличную от Unicode, но если по какой-то исключительной причине вы это сделаете, убедитесь, что спецификация удалена. Если вы этого не сделаете, либо браузер продолжит обрабатывать ваш контент как кодировку UTF-8, либо вы увидите странные символы в начале страницы.
Удаление спецификации
Если вам нужно удалить спецификацию, проверьте, позволяет ли ваш редактор указать, добавлять или сохранять подпись UTF-8 при сохранении файла.Такой редактор позволяет удалить подпись, просто прочитав файл, а затем снова сохранив его. Например, в таких редакторах, как Notepad++ для Windows и TextWrangler для Mac, можно выбрать кодировку из списка при использовании функции «Сохранить как». В списке есть варианты сохранения в формате UTF-8 со спецификацией или без нее. Просто выберите вариант без спецификации и сохраните.
Одним из преимуществ использования сценария является то, что вы можете быстро удалить подпись из нескольких файлов. На самом деле сценарий может запускаться автоматически как часть вашего процесса. Если вы используете Perl, вы можете использовать простой скрипт, созданный Мартином Дюрстом.
Примечание. Необходимо проверить влияние удаления подписи на процесс. Возможно, какая-то часть вашего процесса разработки контента зависит от использования подписи, чтобы указать, что файл находится в UTF-8. Имейте также в виду, что страницы с большим количеством латинских символов могут внешне выглядеть правильно, но случайные символы за пределами диапазона ASCII (от U+0000 до U+007F) могут быть закодированы неправильно.
Дополнительная информация
Вот несколько дополнительных примечаний для тех, кто кодирует свои HTML-страницы с помощью UTF-16. Обратите внимание, что для HTML рекомендуется использовать UTF-8 и избегать UTF-16. Поэтому для большинства людей этот раздел будет академическим.
Согласно RFC 2718 и стандарту Unicode, если вы объявляете кодировку символов своей страницы с использованием HTTP как "UTF-16LE" или "UTF-16BE", вам не следует использовать метку порядка байтов в начале страница. Только если страница помечена в HTTP с использованием имени набора символов IANA «UTF-16», соответствующая метка порядка байтов.
Обратите внимание, что речь идет исключительно о маркировке контента. Конечно, фактическая последовательность байтов одинакова, независимо от того, помечаете ли вы контент как UTF-16 и добавляете спецификацию, или помечаете ли вы его как UTF-16LE или UTF-16BE.
В настоящее время спецификация HTML5 запрещает использование любого другого текстового объявления кодировки в документе для страниц, использующих кодировку UTF-16. По сути, это означает, что спецификация сама по себе является объявлением, которое вы должны добавить.
Знак порядка следования байтов также используется для текста с пометкой UTF-32 и не должен использоваться для текста с пометкой UTF-32BE или UTF-32LE. Однако использование UTF-32 для HTML-контента настоятельно не рекомендуется, а некоторые реализации убрали его поддержку, поэтому до сих пор мы даже не упоминали об этом.
Читайте также: