iconv генерує UTF-16 з BOM

Надихнувшись цим питанням , чи можу я використовувати iconvкоманду для генерації виводу UTF-16 з BOM та із заданою витримкою?

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 з великим ендіаном без BOM ; начебто припускають, що якщо ви вказали ендіанси, вам не потрібно вказувати це у висновку. Аналогічно utf-16leгенерує малоконтензивний UTF-16 без BOM.

Це:

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

генерує (в моїй системі x86 Ubuntu) маленький ендіанський UTF-16 з BOM - але я бачив звіт аналогічної команди, що генерує UTF-16 з великим ендіаном з BOM, навіть у системі з малою ендіанією.

Я завжди можу використовувати utf-16beабо utf-16leдоповнювати BOM вручну, але я шукаю рішення, яке просто використовує 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це не підтримує.

Редагувати:

Чи може хтось із доступом до системи x86 Mac OSX розмістити коментар із зазначенням (скопійованого та вставленого) висновку наступної команди?

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

Ні , якщо ви вказуєте впорядкування байтів, iconvне вставляйте BOM.

Це від консорціуму Unicode

Питання: Як я маю поводитися з ВОМ?

Відповідь: Ось декілька вказівок, яких слід дотримуватися:

1. Конкретний протокол (наприклад, конвенції Microsoft для файлів .txt) може вимагати використання BOM у певних потоках даних Unicode, таких як файли. Коли вам потрібно відповідати такому протоколу, використовуйте BOM.
2. У деяких протоколах можливі необов'язкові BOM-файли у випадку без тегів тексту. У цих випадках
   • Якщо текстовий потік даних, як відомо, є звичайним текстом, але невідомого кодування, BOM може використовуватися як підпис. Якщо немає BOM, кодуванням може бути що завгодно.
   • Якщо текстовий потік даних, як відомо, являє собою звичайний текст Unicode (але не той, який є ендіан), то BOM може використовуватися як підпис. Якщо немає BOM, текст слід інтерпретувати як big-endian.
3. Деякі протоколи, орієнтовані на байт, очікують символів ASCII на початку файлу. Якщо UTF-8 використовується з цими протоколами, слід уникати використання BOM як підпису форми кодування.
4. Там, де відомий точний тип потоку даних (наприклад, Unicode big-endian або Unicode little-endian), BOM не слід використовувати. Зокрема, щоразу , коли потік даних оголошується UTF-16BE, UTF-16LE, UTF-32BE або UTF-32LE, BOM не повинен використовуватися.

(мій акцент)

Я очікую, що iconvце намагання бути вірним останньому з цих вказівок.

Оновлення.

Відступ

На мою думку:

1. Варіант визначення BOM, безумовно, стане корисною додатковою функцією для iconv.

2. Файл UTF-16LE без BOM є корисним в Windows, хоча і з додатковими зусиллями іноді. Наприклад, діалогове вікно відкриття файлу блокнота дозволяє вибрати "Unicode", що є ім'ям Microsoft для "UTF-16LE", і (не дивно) працює на файли без BOM.

3. Я можу відкрити тестовий файл UTF-16LE (без BOM) або тестовий файл UTF-8 (без BOM) у Блокноті Windows (XP) звичайним способом, наприклад, двічі клацнувши ім'ям файлу в Explorer. Це мені здається корисним. Я знаю, що іноді Windows вгадає кодування неправильно. У такому випадку вам потрібно повідомити Блокнот про кодування під час відкриття файлу. Ця незручність означає, що BOM є кращим для текстових файлів, призначених для використання в Windows.

4. Якщо конкретна програма не працюватиме з будь-яким іншим, крім файлу UTF-16LE з BOM, тоді я погоджуюся, що файл UTF-16LE без BOM не використовується для цієї конкретної програми.

5. Я підозрюю, що якщо ви можете змусити все працювати з UTF-8 (без BOM), це найкраще рішення в довгостроковій перспективі.

Однак відповідь на питання "чи можу я використовувати команду iconv для генерації виводу UTF-16 з BOM та із заданою цінністю " наразі " Ні ".