Почему мы продолжаем использовать CSV? [закрыто]

13

Почему мы продолжаем использовать CSV?

Недавно я переключился на работу в области здравоохранения, и, несмотря на прекрасную работу в области стандартов передачи данных, вся передача данных осуществляется в CSV , как для отчетов внешним организациям, так и для миграции данных при внедрении новых систем.

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

Я знаю, что мы можем сделать лучше, и что-нибудь между JSON и XML (в зависимости от экземпляра) будет в порядке. (В большинстве случаев это данные, передаваемые с одного MS SQLserver 2005 на другой!)

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

Так почему же мы продолжаем поддерживать друг друга? Когда мы остановимся?

Стивен
источник
20
Если вы только попадаете в область здравоохранения и думаете, что CSV - это плохо ... просто подождите, пока не столкнетесь с HL7!
G__
3
@Greg LOL, не пугай его, сюрприз всегда лучший :)
Джеймс Лав
47
-1 Это анти-CSV разглагольствование против проблем, не вызванных CSV. Как вы думаете, что именно произойдет, если вы будете читать и писать XML без библиотеки? Ваши проблемы будут в сто раз хуже.
Джесси Милликен
12
«Так почему же мы продолжаем поддерживать друг друга? Когда мы остановимся?» Я не знаю, где я работаю, нам удается использовать CSV очень хорошо, без чьего-либо вмешательства (на самом деле - это этап XML, который гораздо более разочаровывает). Может быть, вы и ваши коллеги делаете что-то не так?
FrustratedWithFormsDesigner
3
Все обсуждения до сих пор пропускают очень реальную проблему с CSV: символ разделителя, вероятно, появится в данных, а CSV использует неоптимальный подход к этой проблеме (размещение кавычек вокруг данных просто выдвигает проблему вниз по течению) , Лучшим подходом будет использование файлов с разделителями каналов.
Ларри Коулман

Ответы:

10

В вашем случае кажется, что CSV не очень подходит из-за отсутствия жестких спецификаций.

Для нетривиальных данных это не правильный выбор.

Почему / Когда CSV хороший выбор? Вероятно, слишком много случаев, чтобы упомянуть, преимущества простоты для плоских данных очевидны. Пока данные очищены / экранированы должным образом, никаких проблем не возникает. Вообще говоря, все эти случаи были бы простыми / тривиальными. Конечно, стандартный разделитель, появляющийся в контенте, часто является проблемой при работе с CSV.

Но если вы делаете что-то более сложное, чем получение нетехнического клиента для отправки данных из листа Excel или другого подобного варианта использования, то CSV, вероятно, недостаточно для любого серьезного использования.

XML гораздо лучше подходит (да, даже лучше, чем JSON), поскольку вы можете сделать для него подробную стандартизированную спецификацию схемы. (Не говоря уже о том, что спецификации / схемы обладают гибкостью нескольких стилей реализации, XSD, DTD & Relax NG)

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

ocodo
источник
3
Действительно "Пока данные очищены / сброшены должным образом". Однако многим программистам кажется, что они могут ошибиться, написав свое собственное (в псевдокоде и write('"');write(fld1);write('"');до тошноты). Затем они упускают кавычки вокруг чего-то. Затем они пишут свой собственный парсер ....
Джерри,
3
Да, съемочная группа действительно должна начать использовать эту интернет- штуку, может быть, даже узнать значение слова ... Библиотека.
ocodo
обмена информацией! повторно используемый код! глупые новомодные идеи. Повторять ошибки других людей было достаточно хорошо для моего прадеда, и этого достаточно для меня!
Steve314
@ Steve314 - / me "делает лицо ужасом и развлечением".
ocodo
Но CSV имеет жесткую спецификацию . Наша проблема сейчас обычная - Excel не соответствует ей на 100%.
gbjbaanb
63

Позвольте мне высказать несколько моментов в пользу CSV:

  • CSV прост (чем любая альтернатива, предложенная в OP) реализовать и проанализировать
  • CSV понимается почти каждым программным обеспечением на планете (в прошлом и настоящем)
  • CSV вызывает довольно плоскую, простую схему (есть один плоский список полей)
  • CSV более читабелен, чем XML, JSON или (UGH!) HL7 (V2.x, pre-xml)
ГРАММ__
источник
14
Вам не нужно играть в «адвоката дьяволов» ... все эти замечания абсолютно верны и объясняют, почему CSV все еще используется. Это просто проще.
GrandmasterB
7
@Stephen: Сколько разных вариаций CSV вы знаете?
FrustratedWithFormsDesigner
3
@FrustratedWithFormsDesigner, сколько условных обозначений вы можете выбрать?
Стивен
3
@Pierre 303 Хотелось бы, чтобы это было доказательство идиота. Я был бы счастлив, если бы это было доказательство разработчика.
Стивен
8
@ Pierre303, доказательство идиота ... Если вы думаете, что что-то "доказали идиотом", вы не проверили это с достаточным количеством идиотов.
ocodo
29

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

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

Anon.
источник
4
+1 каждый раз за свои собственные. Я вижу разработчиков, которые не учатся, а не некорректный формат данных. :-)
G__
«обратная совместимость» - вы, конечно, правы - но не продвижение вперед стоит тысяч.
Стивен
Это хорошо, чтобы свернуть свою собственную библиотеку CSV ... просто используйте ее снова !
GrandmasterB
5
@ Стефан: Нет, переопределение CSV каждый раз, когда вам нужно, стоит тысячи. CSV как формат - это хорошо, проблема в том, что разработчики не могут понять его правильно.
Анон.
6
@Stephen: Итак, ваша проблема с CSV в том, что это слишком просто, и вы хотите что-то более сложное?
Анон.
15

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

Это все еще первый выбор во многих ситуациях.

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


источник
1
Я согласен со всем этим, кроме первоначального использования «немного».
Orbling
3
Это может быть абсолютным преимуществом в Excel, если у вас есть данные, которые должны сохранять лидирующие нули .... спросите меня, откуда я знаю! ... кроме этого Excel предоставляет хороший интерфейс.
Даль
@Dal: Раньше я работал в кредитном союзе и имел дело с CSV-файлами, которые содержали номера кредитных карт. Которые имеют 16 цифр. Это Excel округлил до 15.
Dan04
Или хуже того, что это преобразовало их в научную запись. :( Я помню, как в первый раз я получил ошибку при обработке ACH, что номер удаленной учетной записи был недействительным, только чтобы узнать, что кто-то отредактировал CSV в Excel (только для удаления строки), и он изменил кучу 30 цифры номера счета в 2.3456356e29 и т. д.
таксист
1
@Jeanne: Если бы у CSV действительно было различие чисел / строк, как у JSON, было бы очень легко сказать Excel, какой тип значения. Эти проблемы во многом связаны с тем, что CSV строго типизирован.
Ден04
15

Прежде всего, потому что, хотя потребление CSV-данных может быть (немного) нетривиальным, его создание чрезвычайно просто.

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

Большинство проблем, которые могут (и могут) возникнуть с CSV, могут (и возникают) также с JSON и XML. В частности, XML добавляет еще много потенциальных проблем. Библиотека для анализа данных XML, как правило, больше, медленнее и сложнее в использовании, чем аналогичная библиотека для данных CSV.

Джерри Гроб
источник
1
появляясь правильно производить его очень легко, потребляя то , что не хватает спецификации нетривиально , когда у вас есть нетривиальные данные.
Стивен,
2
@ Стефан: обратите внимание, что я не включил «правильно» в это первое предложение. Его упущение было преднамеренным!
Джерри Гроб
4

Во-первых, я согласен, что с форматом есть некоторые очень серьезные проблемы:

  • Это строго типизировано.
    • Без различия между текстовыми и числовыми значениями Excel будет неправильно угадывать и испортить ваши почтовые индексы и номера кредитных карт.
    • Там нет стандартного способа представления двоичных данных.
    • Не существует стандартного способа различать NULLи '', что является проблемой при импорте файлов CSV в базы данных SQL.
  • Плохая поддержка «специальных символов».
    • Отсутствие ссылок на числовые символы, такие как (XML &#xNNNN;или JSON \uNNNN), означает, что не существует стандартного способа представления управляющих символов или символов, отличных от ASCII.
    • Многие реализации неправильно реализуют разрывы строк в поле.
  • Отсутствие стандарта. Есть RFC 4180 , но он не всегда соблюдается.

Но с другой стороны:

  • Альтернативы хуже. JSON и XML, разработанные на основе деревьев, плохо подходят для табличных данных, особенно с точки зрения ...
  • КОМПАКТНОСТЬ! В XML вы должны иметь начальный тег и конечный тег для каждого столбца в каждой строке. В CSV заголовки столбцов пишутся только один раз.
  • CSV очень легко генерировать.
  • Непрограммисты могут открывать файлы CSV в Excel.
dan04
источник
в обратном порядке; использование этих данных в Excel было бы оскорбительным преступлением, CSV легко генерировать плохо, компактность не проблема, деревья лучше подходят для этих данных.
Стивен
4

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

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

Скотт Макинтайр
источник
Это +1000. Excel - приложение-убийца (если вы его знаете) для быстрого и грязного анализа данных. Возможность экспорта в Excel дает огромные возможности не разработчикам в области бизнеса, исследований и т. Д. Excel управляет миром. CSV экспортирует запустить Excel.
Johannes
2

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

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

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

Codism
источник
1

Я думаю, что CSV просто хороши, когда у вас есть только простые текстовые данные, только запятые и точка с запятой / конец в конце.

Древовидные архитектурные данные или составные данные вряд ли можно использовать с CSV.

CSV - это простой 2D-массив текста, как в Excel, ничего особенного ...

jokoon
источник
1

Это действительно все о мэйнфреймах и превосходстве здесь.

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

Excel, потому что он может открывать CSV напрямую. Фактически, при установке он принимает расширение .csv. Пользователи просто щелкают по слегка забавной иконке Excel, и она открывается и создает красивую сетку, с которой они могут ссориться.

Теперь современные версии Excel вполне способны читать, скажем, XML напрямую. Но чтобы сделать это, пользователь должен понимать немного больше, чем «двойной щелчок по этой картинке». А двойной щелчок на правом изображении может быть слишком сложным в некоторых отраслях. , ,

Уайетт Барнетт
источник
-1

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

Homde
источник
-1

почему я использую это?

  1. клиент хочет это
  2. это быстрее, чем XML по сети (меньшая нагрузка на сеть)
  3. ничего более сложного не требуется, чтобы получить данные через
  4. кроссплатформенный
  5. человек читаемый
  6. легко реализовать читателей и писателей для него

и т. д.

jwenting
источник