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

Question

Чем отличается UTF-8 от UTF-8 без спецификации ? Что лучше?

Answer 1

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

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

Не заставляйте себя ожидать спецификации для UTF8.

Answer 2

Одно практическое отличие состоит в том, что если вы напишите сценарий оболочки для Mac OS X и сохраните его как обычный UTF-8, вы получите ответ:

#!/bin/bash: No such file or directory

в ответ на строку shebang, указывающую, какую оболочку вы хотите использовать:

#!/bin/bash

Если вы сохраните как UTF-8, без спецификации (скажем, в BBEdit ) все будет хорошо.

Answer 3

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

Но это не тот случай, когда у нас есть текстовые CSV и XML-файлы в Windows или Linux.

Например, текстовый файл в Windows или Linux, одна из самых простых вещей, которые можно себе представить, это не (обычно) UTF-8.

Сохраните его как XML и объявите как UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

Он не будет отображаться (не будет читаться) правильно, даже если он объявлен как UTF-8.

У меня была строка данных, содержащая французские буквы, которые нужно было сохранить как XML для синдикации. Без создания файла UTF-8 с самого начала (изменение параметров в IDE и «Создать новый файл») или добавления спецификации в начале файла

$file="\xEF\xBB\xBF".$string;

Мне не удалось сохранить французские буквы в файле XML.

Answer 4

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

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

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

Я лично сохраняю файлы сценариев на стороне сервера (.asp, .ini, .aspx) с файлами спецификации и .html без спецификации .

Answer 5

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

Спецификация обычно полезна для определения порядка кодирования, что не требуется для большинства случаев использования.

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

Answer 6

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

Как уже упоминалось, любое использование спецификации UTF (метки порядка байтов) при определении того, является ли строка UTF-8 или нет, представляет собой сложную догадку. Если доступны правильные метаданные (например, charset="utf-8"), то вы уже знаете, что должны использовать, но в противном случае вам нужно будет проверить и сделать некоторые предположения. Это включает проверку, начинается ли файл с строки, начинается с шестнадцатеричного байтового кода, EF BB BF.

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

Почему не рекомендуется спецификация?

1. Программное обеспечение, не поддерживающее Юникод или плохо совместимое, может предполагать, что оно латинское-1 или ANSI, и не удаляет спецификацию из строки, что, очевидно, может вызвать проблемы.
2. Это на самом деле не нужно (просто проверьте, соответствует ли содержимое, и всегда используйте UTF-8 в качестве запасного варианта, когда не удается найти совместимую кодировку)

Когда следует кодировать с помощью спецификации?

Если вы не можете записать метаданные любым другим способом (через тег charset или мета файловой системы) и программы, используемые как спецификации, вам следует кодировать с помощью спецификации. Это особенно верно в Windows, где обычно предполагается, что что-либо без спецификации использует устаревшую кодовую страницу. Спецификация сообщает таким программам, как Office, что да, текст в этом файле - Unicode; вот используемая кодировка.

Когда дело доходит до этого, единственные файлы, с которыми у меня действительно возникают проблемы, это CSV. В зависимости от программы, она должна или не должна иметь спецификацию. Например, если вы используете Excel 2007+ в Windows, он должен быть закодирован с помощью спецификации, если вы хотите открыть ее плавно и не прибегать к импорту данных.

Answer 7

Часто задаваемые вопросы Unicode Метка порядка байтов (BOM) дает краткий ответ:

В: Как мне обращаться с спецификациями?

A: Вот несколько рекомендаций:

1. Для конкретного протокола (например, соглашения Microsoft для файлов .txt) может потребоваться использование спецификации в определенных потоках данных Unicode, таких как файлы. Когда вам необходимо соответствовать такому протоколу, используйте спецификацию.

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

   • Если известно, что поток текстовых данных представляет собой простой текст, но неизвестной кодировки, в качестве подписи может использоваться спецификация. Если нет спецификации, кодировка может быть любой.

   • Если известно, что поток текстовых данных представляет собой простой текст в кодировке Unicode (но не с прямым порядковым номером), то в качестве подписи может использоваться спецификация. Если там не спецификация, текст должен интерпретироваться как big-endian.

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

4. Если известен точный тип потока данных (например, Unicode с прямым порядком байтов или Unicode с прямым порядком байтов), спецификация не должна использоваться. В в частности, всякий раз, когда поток данных объявляется UTF-16BE, UTF-16LE, UTF-32BE или UTF-32LE BOM не должны использоваться.

Answer 8

Как упоминалось выше, UTF-8 с BOM может вызвать проблемы с программным обеспечением, не поддерживающим BOM (или совместимым). Однажды я отредактировал HTML-файлы, закодированные как UTF-8 + BOM, с помощью KompoZer на базе Mozilla, поскольку клиент требовал, чтобы программа WYSIWYG .

При сохранении макет всегда будет уничтожен. Мне потребовалось некоторое время, чтобы возиться с этим. Затем эти файлы хорошо работали в Firefox, но в Internet Explorer обнаружил причуду CSS, снова разрушающую макет. После нескольких часов бесполезной работы со связанными CSS-файлами я обнаружил, что Internet Explorer не нравится HTML-файл BOMfed. Никогда больше.

Кроме того, я только что нашел это в Википедии:

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

Answer 9

С http://en.wikipedia.org/wiki/Byte-order_mark:

Метка порядка байтов (BOM) - это Unicode символ, используемый для обозначения порядковый номер (порядок байтов) текстового файла или поток. Кодовая точка U + FEFF. Использование спецификации является необязательным, и, если используется, должен появиться в начале текста поток. Помимо его конкретного использования в качестве индикатор порядка следования байтов, спецификация символ может также указывать, какой из несколько представлений Unicode текст закодирован в.

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

Моя настоящая проблема с отсутствием спецификации заключается в следующем. Предположим, у нас есть файл, который содержит:

abc

Без спецификации это открывается как ANSI в большинстве редакторов. Поэтому другой пользователь этого файла открывает его и добавляет некоторые нативные символы, например:

abg-αβγ

Упс ... Теперь файл все еще находится в ANSI и угадайте, что, "αβγ" не занимает 6 байтов, но 3. Это не UTF-8, и это вызывает другие проблемы позже в цепочке разработки.

Answer 10

UTF с спецификацией лучше, если вы используете UTF-8 в файлах HTML, если вы используете сербскую кириллицу, сербскую латиницу, немецкий, венгерский или что-то экзотическое на той же странице. Это мое мнение (30 лет компьютерной и IT индустрии).