Чому кома поганий роздільник запису / роздільник обмежень у файлах CSV?

Я читав цю статтю і мені цікаво правильна відповідь на це питання.

Єдине, що мені спадає на думку, це, мабуть, що в деяких країнах десятковий роздільник є комою, і це можуть бути проблеми при обміні даними в CSV , але я не дуже впевнений у своїй відповіді.

Специфікація формату CSV визначена в RFC 4180 . Ця специфікація була опублікована, оскільки

не існує офіційної специфікації, яка дозволяє проводити широкий спектр інтерпретацій файлів CSV

На жаль, з 2005 року (дата публікації RFC) нічого не змінилося. У нас все ще існує широкий вибір. Загальний підхід, визначений у RFC 4180, полягає у включенні полів, що містять символи, такі як коми у лапках, однак ця рекомендація не завжди відповідає іншому програмному забезпеченню.

Проблема полягає в тому, що в різних європейських локалях символ кома виступає в якості десяткової крапки, тому ви пишете 0,005замість 0.005. Однак в інших випадках коми використовуються замість пробілів для сигналізації знакових груп, наприклад 4,000,000.00(див. Тут ). В обох випадках використання коми може призвести до помилок при читанні даних з CSV-файлів, оскільки ваше програмне забезпечення насправді не знає, чи 0,005, 0,1є два чи чотири різні числа (див. Приклад тут ).

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

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

Технічно кома є такою ж доброю, як і будь-який інший символ, який використовується як роздільник. Назва формату безпосередньо посилається на те, що значення розділені комами (Значення, розділені комами).

В описі формату CSV використовується кома як роздільник.

Будь-яке поле, що містить коми, має бути подвійним цитуванням. Отже, це не спричиняє проблем з читанням даних. Дивіться пункт 6 з опису :

6. Поля, що містять розриви рядків (CRLF), подвійні лапки та коми повинні бути укладені у подвійні лапки.

Наприклад, функції read.csvта write.csvз R за замовчуванням використовують косу як роздільник.

Окрім того, що є роздільником цифр у числах, він також є частиною адреси (наприклад, адреса клієнта тощо) у багатьох країнах. Хоча деякі країни мають короткі чітко визначені адреси, у багатьох інших є адреси з довгими обмотками, включаючи, іноді, дві коми в одному рядку. Хороші файли CSV додають усі такі дані у подвійні лапки. Але занадто спрощені, погано написані аналізатори не забезпечують їх читання та розмежування. (Тоді виникає проблема використання подвійних лапок як частини даних, наприклад цитата з вірша).

Хоча відповідь @Tim правильна - я хотів би додати, що "csv" в цілому не має загального стандарту - особливо правила уникнення не визначені взагалі, що призводить до "форматів", які можна прочитати в одній програмі, але не в іншій . Це обумовлено тим, що кожен "програміст" під сонцем просто думає, "оооо, csv- я буду буду свій аналізатор!" а потім пропускає всі крайові випадки.

Більше того, у CSV повністю бракує можливості зберігати метадані або навіть тип даних стовпця - це призводить до декількох документів, які ви повинні прочитати, щоб не зрозуміти дані.

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

ASCII надає нам чотири символи "роздільника", як показано нижче у фрагменті зі сторінки "ascii (7) * nix man":

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

Ця відповідь дає гідний огляд їх наміченого використання.

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

Проблема не в комах; проблема - цитування. Незалежно від того, які роздільники записів та полів ви використовуєте, вам потрібно бути готовим до їх зустрічі у вмісті. Тож вам потрібен механізм цитування. І ТОТЕ вам потрібен спосіб для символів, що цитують, також з'являтися.

Дотримуючись стандарту RFC 4180, все простіше для всіх.

Мені особисто довелося написати сценарій, щоб, мабуть, виправити вихід з програми, яка помилилася, тому я трохи войовнича щодо цього. "ймовірно виправити" означає, що він працював для моїх даних, але я бачу ситуації, коли це не вдасться. (У захисті програми було написано перед стандартом.)