Является ли CSV хорошей альтернативой XML и JSON? [закрыто]

22

Считается ли CSV хорошим вариантом против XML и JSON для языков программирования?

Я обычно использую XML и JSON (или иногда простой текстовый файл) в качестве хранилища плоских файлов. Однако недавно я наткнулся на реализацию CSV в PHP . Я обычно видел, что CSV используется для ввода в файлы Excel , но я никогда не использовал его в программировании. Будет ли это лучше, чем XML или JSON в любом случае?

Вишвас Г
источник
3
Этот вопрос расплывчатый. Вы спрашиваете, делает ли CSV лучший формат в качестве системы хранения, или вы спрашиваете, есть ли причины использовать CSV поверх XML / JSON?
GrandmasterB
4
Любая структура сообщения CSV может быть сопоставлена ​​с форматом сообщения XML или JSON. Не все форматы сообщений XML / JSON могут быть сопоставлены с CSV. Таким образом, CSV охватывает только конкретный случай использования данных в табличном формате, где JSON и XML могут охватывать более сложные структуры сообщений.
Джон Рейнор
@JonRaynor: Я думаю, что любой формат XML или JSON может быть сопоставлен с CSV - но не совсем. Вы должны изобрести какой-нибудь способ представления древовидной структуры. Результат будет уродливым и почти наверняка не стоит реализовывать. Практически во всех практических целях вы правы.
Кит Томпсон,
@KeithThompson это было изобретено :)
Элиран Малка

Ответы:

41

Ответ, это зависит.

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

Это также действительно распространено в определенных отраслях, когда речь идет об устаревших системах и рабочих процессах. Попробуйте импортировать JSON в MS Excel.

ODI недавно прокомментировал CSV, назвав 2014 год «Годом CSV».

Для "правильного" форматирования CSV, рассмотрите использование типа mime CSV в ваших ответах HTTP.

Том
источник
2
+1 за унаследованные системы; в то время как традиционная система не может быть с помощью CSV в предполагаемому образом (я недавно имел дело с импортом CSV , который был, честно говоря, доклад, а не таблицы), мы действительно имеем дело с унаследованной информацией по всему миру ,
Брайан С.
1
CSV имеет преимущество потоковой передачи, что немаловажно: парсер CSV имеет гораздо меньше состояний, чем парсеры JSON или XML.
Мэтт
22

Конечно, нет.

CSV - это табличный формат, который очень хорошо отображается на наборы данных или другие табличные данные. Но не все данные являются табличными! В общем, мы хотим сериализовать графы объектов . Это может быть сложно в следующих случаях:

  • циркулярные ссылки
  • общие подграфы (например, два объекта, каждый из которых содержит один и тот же объект в качестве члена)
  • объекты разных типов для сериализации в один и тот же документ

Кроме того, мы хотим иметь возможность надежно десериализовать объекты из нашего формата хранения.

XML

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

JSON

Это прежде всего способ хранения простых объектных деревьев . Нет поддержки общих графиков. JSON не имеет понятия о типе, кроме примитивов string , integer , float , boolean , null и массива и объекта типов коллекций .

YAML

Наиболее легко понять как расширение JSON. Имеет понятие псевдонимов, которые позволяют создавать графы объектов произвольной сложности. Имеет понятие метаданных, таких как теги, которые можно использовать для правильной типизации.

CSV

Не имеет ничего, кроме одного стола. Если мы хотим хранить графы объектов, нам нужно будет использовать такую ​​схему, как

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

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

Есть много диалектов CSV, которые не согласны с разделителями, разделителями строк, кавычками, escape-символами и многими другими проблемами, которые делают его непригодным для общих (двоичных) данных. Все это затрудняет обработку данных в формате CSV.

Таким образом, в основном, простые вещи сложны или невозможны с CSV при использовании его в качестве общего формата сериализации.

Эта критика неприменима при использовании ее для хранения действительно табличных данных, таких как табели учета рабочего времени или серии измерений. Здесь CSV (часто в варианте значений, разделенных табуляцией) обычно более компактен и проще в использовании, чем другие форматы данных.

Амон
источник
1
Я думаю, что это справедливый аргумент. Они разные, поэтому используйте их для разных вещей, используйте каждый, где это лучше.
Бен
1
Без первой строки это был бы хороший ответ. CSV является хорошей альтернативой XML для табличной информации (распространяемый файл SQLite, вероятно, лучше, чем оба). Но, как вы объясните для табличных данных, это лучший выбор файлов.
4

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

Использование устаревшей системы и попытка использовать новый формат в чистом виде иногда могут быть проблемой, поскольку вы представили более сложную систему и имеете новую систему ввода для отладки. Я часто видел это, когда новые люди предпочитают что-то отличное от того, что существует, или когда появляется новый формат, и они хотят поэкспериментировать с этим. Это может быть или не быть хорошей идеей, это зависит от обстоятельств.

Несколько лет назад я работал над системой баз данных графов исследований, которая зависела от файлов CSV различных форматов. Импортер CSV-файлов построил бы для нас графики, и ему потребовалось много лет, чтобы отладить и оптимизировать код. Он был быстрым и гибким, и мы с радостью использовали бы его для запуска крупных исследовательских проектов. Когда XML появился на сцене, мы добавили импортер XML, но это не обязательно было улучшение с точки зрения скорости или выражения сложности, и, конечно, XML не был лучше в выражении структур графа, чем CSV. JSON намного лучше (и более лаконичен), чем XML, но во многих отношениях он похож, поэтому я ожидаю аналогичного результата при создании нового импортера в этой системе.

В какой-то момент у нас был заказчик, который вносил огромное количество данных в (как мы это назвали) формате «cobol», файлы с линиями переменной длины, содержащими маркеры, которые указывали, как интерпретировать байты, которые следуют в этой строке. Это произошло из-за того, что хранение было дорогим, поэтому требовалась компактность. Мы импортировали эти данные, преобразовав их в формат CSV на лету и загрузив в импортер CSV. Это было легко сделать и минимизировало количество отладки и обслуживания, и это хорошо. Если бы нам приходилось все время импортировать такие данные, мы могли бы встроить их в систему напрямую, чтобы повысить производительность и эффективность.

Таким образом, это зависит от того, что вы делаете, и от того, что делает базовая система. В моем примере импортер CSV был надежным и надежным. Я бы не решался сказать вам, что один формат был лучше или хуже, не понимая, что происходит в других слоях, которые я создаю. Я люблю JSON и предпочитаю его, но я знаю, что, учитывая определенные сложные структуры данных и достаточно большие наборы данных, файлы CSV также могут работать очень хорошо.

Фрэн К.
источник
3

Нет.

CSV на самом деле не единственный формат. Существует множество стилей для экранирования, разделителей и других проблем форматирования, которые встречаются во многих CSV-файлах.

Если вы собираетесь использовать это как хранилище плоских файлов, использование JSON поможет вам намного лучше. JSON отображает объекты на объекты с гораздо меньшими хлопотами, чем для этого потребуется CSV.

как зовут
источник
0

Я настоятельно советую против этого. Я мог бы быть в порядке, чтобы вывести CSV в какой-то момент (если пользователь запрашивает его). Но это плохо подходит для хранения / импорта. В основном это связано с тем, что «CSV» очень плохо определен. «C» означает «запятая» или «символ» разделены? Как вы относитесь к текстовым строкам, которые содержат управляющие символы, такие как «? Каждая проклятая реализация CSV по-разному обрабатывает управляющие символы и т. Д., Что приводит к файлам, которые могут быть исключены, но не импортированы и т. Д.

Excel - хорошая демонстрация: в английской версии он использует «,» в качестве разделителя. В Германии он использует «;». Таким образом, немецкая версия задыхается от английских файлов CSV, и наоборот ...

Его главная сила - удобочитаемость, которую нельзя сбрасывать со счетов. Но я бы не стал полагаться на него как на формат хранения, он слишком хрупкий для этой цели. Если вам нужно экспортировать файлы для людей, вы можете использовать CSV, но даже тогда я бы попытался использовать библиотеку, которая записывает в файлы xlsx (они доступны бесплатно).

Кристиан Зауэр
источник
3
Это «запятая», см. RFC 4180 . То, что Microsoft что-то сломало в Германии, не означает, что стандартизированный формат бесполезен ...
Бен
Нет, это не «запятая» - это также может означать «разделенный символ», и проблема не ограничивается Германией. Да, в RFC указано иное, но файл с именем «csv» может содержать множество различных разделителей, escape-стилей и т. Д. При попытке импортировать такой файл ваша программа будет импортировать ... что-то, но не то, что вам нужно.
Кристиан Зауэр
Этот ответ определяет важные подводные камни против CSV.
gdbj
-3

В общем нет. Зачем? JSON и XML существуют для того, чтобы избавиться от страшного CSV. Это структурированные подходы того, что было сделано неструктурированным с CSV в течение длительного времени. Да, в некоторых случаях использование CSV по-прежнему предпочтительнее, но в целом в 9 из 10 случаев лучше не использовать CSV.

Питер Б
источник
7
Если, конечно, данные, которые вы передаете, «плоские». Затем вы сэкономите огромную сумму, не передавая ненужные теги XML и т. Д.
Бен