Чи хороша альтернатива CSV для XML та JSON? [зачинено]

Чи вважається CSV хорошим варіантом проти XML та JSON для мов програмування?

Я, як правило, використовую XML та JSON (або іноді звичайний текстовий файл) як плоське зберігання файлів. Однак нещодавно я натрапив на реалізацію CSV в PHP . Я, як правило, бачив CSV, який використовується для введення у файли Excel , але я ніколи не використовував його для програмування. Чи було б краще, ніж XML чи JSON будь-яким способом?

Відповідь - це залежить.

CSV відмінно підходить для певних випадків використання. Наприклад, як "потоковий" формат для великих наборів даних, це простіше в потоці, ніж XML / JSON, а файли CSV займають набагато менше місця для зберігання. Я використовую його для передачі наборів даних у діапазоні гігабайт, де інші формати недоцільно.

Це також дуже часто зустрічається в певних галузях промисловості при роботі зі застарілими системами та робочими потоками. Спробуйте імпортувати JSON в MS Excel.

ДНЗ нещодавно прокоментував CSV, назвавши 2014 рік "роком CSV"

Для "правильного" форматування CSV, подумайте про використання типу mime CSV у відповідях HTTP.

Більшість звичайно ні.

CSV - це формат таблиці, який дуже добре відображає набори даних або інші табличні дані. Але не всі дані є табличними! Найчастіше ми хочемо серіалізувати об’єктні графіки . Це може бути важким у таких випадках:

• кругові посилання
• спільні підграграфи (наприклад, два об'єкти, які містять один і той же об’єкт як член)
• об'єкти різних типів, що підлягають серіалізації до одного документа

Крім того, ми хочемо надійно дезарисовувати об'єкти з нашого формату зберігання.

XML

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

JSON

Це насамперед спосіб зберігання простих дерев об'єктів . Немає підтримки для загальних графіків. JSON не має поняття типу за межами примітивів string , integer , float , boolean , null та масив та об'єкт типів колекції .

ЯМЛ

Найпростіше розуміти як розширення JSON. Має поняття псевдонімів, які дозволяють створювати об'єктивні графіки довільної складності. Має концепцію метаданих, як теги, які можна використовувати для правильного введення тексту.

CSV

Не має нічого, крім однієї таблиці. Якщо ми хочемо зберігати графіки об'єктів, нам доведеться використовувати подібну схему

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

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

Таким чином, легкі речі важко чи неможливо з CSV при використанні його як загального формату серіалізації.

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

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

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

Роки тому я працював над системою бази даних дослідницьких графіків, яка залежала від файлів CSV різних форматів. Імпортер файлів CSV створив би графіки для нас, і для роботи налагодження та оптимізації коду було багато років роботи. Це було і швидким, і гнучким, і ми із задоволенням використовуємо його для завантаження великих дослідницьких проектів. Коли на сцені з'явився XML, ми додали імпортера XML, але це не обов'язково було покращенням швидкості чи складності вираження, і, звичайно, XML не був кращим для вираження графічних структур, ніж CSV. JSON набагато приємніший (і терміновіший), ніж XML, але багато в чому схожий, тому я б очікував подібного результату при створенні нового імпортера в цій системі.

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

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

Ні.

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

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

Я б настійно радив проти цього. Я можу бути в порядку, щоб вивести CSV в якийсь момент (якщо користувач цього вимагає). Але це погано підходить для цілей зберігання / імпорту. Це здебільшого пов’язано з тим, що "CSV" дуже погано визначений. Чи "С" вказує на "кома" чи "символ" відокремлено? Як ви обробляєте текстові рядки, які містять символи евакуації на зразок "? Кожна проклята реалізація CSV трактує символи втечі тощо по-різному, що призводить до файлів, які можуть бути ex-, але не імпортовані тощо.

Excel - хороша демонстрація: в англійській версії він використовує "," як роздільник. У Німеччині він використовує ";". Так німецька версія задихається у файлах CSV англійської мови та навпаки ...

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

Загалом НІ. Чому? JSON та XML є в основному, щоб позбутися жахливого CSV. Вони структуровані підходи до того, що вже давно неструктуровано з CSV. Так, є деякі випадки використання, коли CSV все-таки є кращим, але загалом у 9 з 10 випадків вам краще не використовувати CSV.