Чи повинні файли CSV UTF-8 містити BOM (знак байтового порядку)?

Наше програмне забезпечення для бізнесу дозволяє користувачеві зберігати певні дані як CSV . Оскільки в дикій природі використовується безліч різних форматів (усіх називають "CSV"), ми вирішуємо, як повинен виглядати "формат за замовчуванням".

Що стосується розділювачів лінії та поля та втечі, то ми можемо використовувати стандарт: RFC 4180 .
Що стосується кодування тексту, то, здається , UTF-8 з'явився в останнє десятиліття як "формат текстового файлу за замовчуванням", тому ми будемо використовувати його.

Одне питання, залишене відкритим, це: чи слід додати BOM на початку чи ні? Я читав багато думок і плюсів / мінусів щодо використання BOM в цілому, але чи є "офіційна" рекомендація чи хоча б якийсь консенсус спільноти щодо використання BOM у файлах CSV?

— Хайнці
джерело

Якщо він має BOM, то це не UTF-8. Але якого формату хочуть програми. Якщо їм потрібна BOM (в основному мікроліній), то вам потрібно додати її, але UTF-8 + BOM ≠ UTF-8.

— ctrl-alt-delor

Навіть незважаючи на те, що CSV, мабуть, простіше генерувати, є так багато проблем сумісності, особливо якщо ви збилися з чистого 7-бітного ASCII, що я б дуже, дуже настійно рекомендую вам генерувати фактичний XLSX, якщо мета полягає у тому, щоб користувачі його відкривали в Excel (замість того, щоб повторно імпортувати його в іншому програмному забезпеченні; в цьому випадку вам доведеться надати варіанти роздільників, кодування тощо). Існують бібліотеки для більшості мов, і ви заощадите вас та ваших користувачів багато часу.

— jcaron

Якщо ви рухаєтесь по маршруту CSV, перевірте, що відбувається, коли ви відкриєте файл на Mac та ПК, в ідеалі з декількома версіями Excel. Також пам’ятайте, що деякі версії Excel не ведуть себе однаково, коли ви двічі клацніть по файлу, щоб відкрити його або відкрити файл через меню.

— jcaron

Чому це важливо, якщо він відкривається правильно в Excel? У запитанні нічого не зазначено, що Excel повинен вміти розбирати створений файл ...

— rubenvb

Відповіді:

Не для UTF-8 , але дивіться різні застереження у коментарях.

Це непотрібно (UTF-8 не має порядку байтів) на відміну від UTF-16/32 і не рекомендується в стандарті Unicode . Також досить рідко можна побачити UTF-8 з BOM "в дикій природі", тому, якщо у вас немає поважних причин (наприклад, як прокоментовано, ви будете працювати з програмним забезпеченням, яке очікує, що BOM) я рекомендував би метод BOM-менше .

У Вікіпедії згадується головне програмне забезпечення Microsoft, яке змушує і очікує BOM, але якщо ви не працюєте з ними, не використовуйте його.

— Каяман
джерело

Існує також широко розповсюджене програмне забезпечення, яке вимагає BOM: Excel потребує BOM, щоб правильно ідентифікувати файл CSV як UTF-8, а не "ANSI", тобто локальну локальну сумісність. (Але Excel також робить дивні речі, зберігаючи такий файл, тому радимо користувачам використовувати наш "справжній" експорт Excel замість експорту CSV, якщо вони хочуть відкрити файл за допомогою Excel.)

— Heinzi

@Heinzi Давно я дізнався, що ти не можеш реально виграти, працюючи з CSV та Excel. Це просто паршивий читач CSV. Шкода, що звичайні користувачі очікують.

— труба

@Voo: Вимога BOM для UTF-8, безумовно, порушує стандарт, вважаючи, що це " не потрібно і не рекомендується ".

— Дедуплікатор

@ Дедуплікатор: системи MS-DOS та Windows мають велику базу застарілих текстових файлів у кодуваннях, відмінних від UTF-8. Якісні програми дозволяють користувачеві визначати, як текстовий файл кодується під час його відкриття, але часто містять опцію "авто". Якщо користувач вибере "UTF-8", файл UTF-8 буде відкрито правильно з BOM або без нього. Якщо користувач вибере "авто", деякі файли UTF-8, які не мають BOM, можуть бути неправильно ідентифіковані як використання деяких інших кодувань. Я не впевнений, що можна очікувати, що програма поступить інакше, оскільки файли, які "неправильно ідентифікуються", можуть бути розрізнені ідентичні ...

— supercat

@Voo: Це суперечить багатьом іншим вимогам, що стосуються формату, коли BOM є незаконним. Наприклад, скрипт оболонки з BOM перед символом #!недійсний. У кращому випадку BOM в UTF-8 "дозволено, коли жодна вимога, що стосується формату / додатку не перешкоджає цьому", не "дозволена", і як таке не слід використовувати. Стандарти насправді зрозумілі, ЧОГО НЕ БУДЕ.

— R ..

Досі не існує широко розповсюдженої конвенції AFAIK, хоча, безумовно, UTF-8 зараз загальновизнаний.

BOM - жахливий артефакт:

Він невидимий (простір нульової ширини).

Деяке програмне забезпечення може порушити назву першого стовпця, що містить не лише літери, але і дивну BOM спереду.

Рядок заголовка може бути скопійований для рядків значення, що пошкоджують перше значення.

Потрібно лише деякому програмному забезпеченню Windows, щоб розподілити між одним з кодувань ANSI, використовуваним на цій локальній машині Windows, та UTF-8. Блокнот, Excel.

Тож сумна річ, що треба підтримувати БОМ. Можливо, необов’язковий.

Використовуйте схему іменування для файлів (...- utf8.txt, ...- utf8bom.txt).

У багатьох випадках ми могли використовувати HTML як альтернативу експорту. Це дозволяє встановити кодування у файлі. Додатковою особливістю є фарбування фону / переднього плану рядків та комірок. Що підвищує якість експорту.

— Джоп Егген
джерело

Від того, чи буде форматування "підвищено якість експорту", дуже залежить від використання файлу. CSV часто використовується як простий машиночитабельний формат, а перетворення одержувача на розгляд HTML замість цього буде великим недоліком у цьому випадку.

— IMSoP

Якщо ви вибираєте схему іменування, пам’ятайте про аудиторію. -utf8-windows.csvкраще. Практично всі знають, що таке Windows у контексті комп'ютерів, але набагато менше користувачів знає, що таке марка порядку байтів.

— MSalters

@Davislor так, якщо це широко відомий стандарт. Інакше надходитимуть повідомлення про помилки щодо tschÃ¼ÃŸсміття, тоді як tschüßповинні бути написані. У StackOverflow багато ІТ-помилок стосуються кодування. Кінцеві користувачі також матимуть проблеми.

— Joop Eggen

@JoopEggen "Широко переданий відомий стандарт" у якій саме спільноті? Я займаюся розробкою програмного забезпечення вже майже 10 років, і ніколи цього не бачив - навіть у Windows і, звичайно, не в Linux або OSX, де ви майже завжди маєте справу з utf-8.

— Кубік

@JustinTime так, навіть з деяких років, але не раніше. Розробники MS не такі вже й погані (відповідність Posix, тепер підтримка UTF-8).

— Joop Eggen