iconv генератор UTF-16 с спецификацией

Вдохновленный этим вопросом , могу ли я использовать iconvкоманду для генерации вывода UTF-16 с спецификацией и указанным порядком байтов?

Команда iconvпреобразует текст из одной кодировки в другую.

Например:

echo hello | iconv -f ascii -t utf-16

генерирует UTF-16 представление "hello\n".

Файлы UTF-16 часто, но не всегда, начинаются с метки порядка байтов (BOM), которая представляет собой 2-байтовую кодировку символа Unicode U+FEFF. Вы можете определить порядковый номер файла UTF-16 с BOM, проверив, являются ли первые два байта FE FFили FF FE.

Команда iconvимеет несколько опций для генерации вывода UTF-16:

$ iconv --list | grep -i utf-16
UTF-16//
UTF-16BE//
UTF-16LE//

Эта команда:

echo hello | iconv -f ascii -t utf-16be

генерирует UTF-16 с прямым порядком байтов без спецификации ; кажется, предполагается, что если вы указали порядковый номер, вам не нужно указывать его в выводе. Точно так же utf-16leгенерирует UTF-16 с прямым порядком байтов без спецификации.

Это:

echo hello | iconv -f ascii -t utf-16

генерирует (в моей системе x86 Ubuntu) UTF-16 с прямым порядком байтов с BOM - но я видел отчет о похожей команде, генерирующей UTF-16 с прямым порядком байтов с BOM, даже в системе с прямым порядком байтов.

Я всегда могу использовать utf-16beили utf-16leи предварительно добавить спецификацию вручную, но я ищу решение, которое просто использует iconvкоманду.

Другой обходной путь, если вы знаете, что -t utf-16порождает порядок байтов :

echo hello | iconv -f ascii -t utf-16 | dd conv=swab 2>/dev/null

Я хотел бы использовать что-то вроде:

iconv -f ascii -t utf-16bebom # big-endian with BOM
iconv -f ascii -t utf-16lebom # little-endian with BOM

но iconvне поддерживает это.

РЕДАКТИРОВАТЬ :

Может ли кто-то, имеющий доступ к системе Mac OSX x86, опубликовать комментарий, показывающий (скопированный и вставленный) вывод следующей команды?

echo hello | iconv -f ascii -t utf-16 | od -x

Нет , если вы указываете порядок байтов, iconvспецификация не вставляется.

Это из Консорциума Unicode

Q: Как я должен иметь дело с спецификациями?

A: Вот несколько рекомендаций, которым нужно следовать:

1. Определенный протокол (например, соглашения Microsoft для файлов .txt) может потребовать использования спецификации для определенных потоков данных Unicode, таких как файлы. Когда вам нужно соответствовать такому протоколу, используйте спецификацию.
2. Некоторые протоколы допускают наличие дополнительных спецификаций в случае нетегированного текста. В этих случаях
   • Если известно, что поток текстовых данных представляет собой простой текст, но неизвестной кодировки, в качестве подписи может использоваться спецификация. Если спецификация отсутствует, кодировка может быть любой.
   • Если известно, что поток текстовых данных представляет собой простой текст в Юникоде (но не с прямым порядком байтов), то в качестве подписи может использоваться спецификация. Если спецификация отсутствует, текст следует интерпретировать как big-endian.
3. Некоторые байтовые протоколы ожидают символы ASCII в начале файла. Если UTF-8 используется с этими протоколами, следует избегать использования спецификации в качестве подписи формы кодирования.
4. Если известен точный тип потока данных (например, Unicode с прямым порядком байтов или Unicode с прямым порядком байтов), спецификация не должна использоваться. В частности, всякий раз , когда поток данных объявляется UTF-16BE, UTF-16LE, UTF-32BE или UTF-32LE, BOM не должен использоваться.

(мой акцент)

Я ожидаю, что iconvпытается быть верным последнему из этих руководящих принципов.

Обновить.

Отступление

По моему мнению:

1. Возможность указать спецификацию, безусловно, будет полезной дополнительной функцией для iconv.

2. Файл UTF-16LE без BOM является полезным в Windows, хотя и с дополнительными усилиями иногда. Например, диалоговое окно «Открыть файл» в блокноте позволяет выбрать «Unicode», который является именем Microsoft для «UTF-16LE» и (что неудивительно) работает с файлами без спецификации.

3. Я могу открыть тестовый файл UTF-16LE (без BOM) или тестовый файл UTF-8 (без BOM) в Windows Notepad (XP) обычным способом, например, дважды щелкнув имя файла в проводнике. Это кажется полезным для меня. Я знаю, что иногда Windows будет неправильно угадывать кодировку - в этом случае вы должны указать Notepad кодировку при открытии файла. Это неудобство означает, что включение спецификации предпочтительнее для текстовых файлов, предназначенных для использования в Windows.

4. Если конкретное приложение не будет работать ни с чем, кроме файла UTF-16LE с спецификацией, то я согласен, что файл UTF-16LE без спецификации не может использоваться для этого конкретного приложения.

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

Однако ответ на вопрос « могу ли я использовать команду iconv для генерации вывода UTF-16 с спецификацией и указанным порядком байтов » в настоящее время « Нет ».