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

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

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

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

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

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

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

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

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

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

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

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

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

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

• CSV прост (чем любая альтернатива, предложенная в OP) реализовать и проанализировать
• CSV понимается почти каждым программным обеспечением на планете (в прошлом и настоящем)
• CSV вызывает довольно плоскую, простую схему (есть один плоский список полей)
• CSV более читабелен, чем XML, JSON или (UGH!) HL7 (V2.x, pre-xml)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т. д.