Dlaczego nadal używamy CSV? [Zamknięte]

14

Dlaczego nadal używamy CSV?

Niedawno przeszedłem do pracy w dziedzinie zdrowia i pomimo wspaniałej pracy w standardach przesyłania danych, wszystkie przesyłane dane są w CSV , zarówno w celu raportowania do organizacji zewnętrznych, jak i migracji danych podczas wdrażania nowych systemów.

Niestety użycie CSV powoduje niekończące się powtarzanie tych samych głupich błędów przy tym samym marnowaniu czasu programisty. (złe ucieczka, brak obsługi pustych pól itp.)

Wiem, że możemy zrobić lepiej i wszystko między JSON a XML (w zależności od instancji) byłoby w porządku. (Przez większość czasu są to dane przesyłane z jednego MS SQLserver 2005 do drugiego!)

Mam wrażenie, że za każdym razem, gdy to widzę, dosłownie patrzę, jak jeden programista marnuje czas innym.

Dlaczego więc ciągle się nawracamy? Kiedy się zatrzymamy?

Stephen
źródło
20
Jeśli dopiero wchodzisz do domeny zdrowia i uważasz, że CSV jest zły ... poczekaj, aż napotkasz HL7!
G__
3
@Greg LOL, nie przerażaj go, niespodzianka jest zawsze najlepsza :)
James Love
47
-1 To jest anty-CSV rant przeciwko problemom nie spowodowanym przez CSV. Jak myślisz, co by się stało, gdybyś czytał i pisał XML bez biblioteki? Twoje problemy byłyby sto razy gorsze.
Jesse Millikan
12
„Więc dlaczego wciąż się nawracamy? Kiedy przestaniemy?” Nie wiem, gdzie pracuję, udaje nam się używać CSV w porządku, bez nikogo, kto mógłby zostać oszukany (w rzeczy samej - to etap XML jest o wiele bardziej frustrujący). Może ty i twoi współpracownicy robicie coś złego?
FrustratedWithFormsDesigner
3
W całej dotychczasowej dyskusji pomija się bardzo prawdziwy problem z CSV: znak ogranicznika prawdopodobnie pojawi się w danych, a CSV przyjmuje mniej niż optymalne podejście do tego problemu (umieszczanie cudzysłowów wokół danych popycha problem w dół) . Lepszym rozwiązaniem byłoby użycie plików rozdzielanych potokami.
Larry Coleman

Odpowiedzi:

10

W twoim przypadku wydaje się, że CSV nie jest dobrze dopasowany ze względu na brak twardej specyfikacji.

W przypadku nietrywialnych danych nie jest to właściwy wybór.

Dlaczego / Kiedy CSV jest dobrym wyborem? Prawdopodobnie zbyt wiele przypadków, aby wspomnieć, korzyści wynikające z prostoty płaskich danych są oczywiste. Tak długo, jak dane są odpowiednio odkażane / usuwane, nie ma żadnych problemów. Ogólnie rzecz biorąc, wszystkie te przypadki byłyby proste / trywialne. Oczywiście standardowy ogranicznik pojawiający się w treści jest często uciążliwy w kontaktach z CSV.

Ale jeśli robisz coś bardziej zaangażowanego niż pozyskiwanie nietechnicznego klienta do wysyłania danych z arkusza Excela lub innego podobnego przypadku użycia, CSV prawdopodobnie nie wystarcza do poważnego wykorzystania.

XML jest znacznie lepiej dopasowany (tak, nawet bardziej niż JSON), ponieważ możesz dla niego wykonać szczegółową znormalizowaną specyfikację schematu. (Nie wspominając o tym, że specyfikacje / schematy cieszą się elastycznością wielu stylów implementacji, XSD, DTD i Relax NG)

W przypadku systemów z zamkniętą pętlą, szczególnie tam, gdzie problemem jest przepustowość, JSON może lepiej pasować niż XML, ale brak języków specyfikacji schematu często wyklucza to z aplikacji na poziomie korporacyjnym.

ocodo
źródło
3
Rzeczywiście „tak długo, jak dane są odpowiednio dezynfekowane / usuwane”. Jednak droga dla wielu programistów wydaje się być w stanie to zrobić źle, pisząc własne (w pseudo-code write('"');write(fld1);write('"');ad nauseum). Potem brakuje im wstawiania cudzysłowów. Potem piszą własny parser ....
Gerry
3
Tak, ekipa roll-your-naprawdę naprawdę powinna zacząć korzystać z Internetu , a może nawet nauczyć się znaczenia słowa ... Biblioteka.
ocodo
dzielenie się informacjami! kod wielokrotnego użytku! głupie, nowomodne pomysły. Powtarzanie błędów innych ludzi było wystarczające dla mojego pradziadka ^ 50 i dla mnie wystarczało!
Steve314,
@ Steve314 - / me „robi minę zarówno z grozy, jak i rozrywki”.
ocodo
Ale CSV ma trudną specyfikację . Nasz problem jest teraz zwykły - program Excel nie jest w 100% z nim zgodny.
gbjbaanb
63

Pozwolę sobie wyrzucić kilka punktów na korzyść CSV:

  • CSV jest prosty (r niż jakakolwiek alternatywa sugerowana w OP) do wdrożenia i parsowania
  • CSV jest rozumiany przez prawie każde oprogramowanie na planecie (przeszłość i teraźniejszość)
  • CSV wymusza dość płaski, prosty schemat (istnieje jedna płaska lista pól)
  • CSV jest bardziej czytelny dla ludzi niż XML, JSON lub (UGH!) HL7 (V2.x, pre-xml)
SOL__
źródło
14
Nie musisz grać w „adwokata diabła” ... wszystkie te punkty, które robisz są w pełni uzasadnione i wyjaśniają, dlaczego CSV jest nadal używany. To jest po prostu prostsze.
GrandmasterB
7
@Stephen: Ile znasz różnych odmian CSV?
FrustratedWithFormsDesigner
3
@FrustratedWithFormsDesigner ile myślisz o konwencjach ucieczki?
Stephen
3
@Pierre 303 Chciałbym, żeby to był idiotyczny dowód. Byłbym szczęśliwy, gdyby był to dowód programisty.
Stephen
8
@ Pierre303, idiota dowód ... Jeśli uważasz, że coś zrobiłeś „idioto dowód”, nie przetestowałeś tego z wystarczającą liczbą idiotów.
ocodo
29

Kompatybilność wsteczna. Jeśli Twoja zewnętrzna usługa sieci web organizacji obsługuje CSV, a wszystkie istniejące narzędzia obsługują CSV, żadna ze stron nie ma motywacji, aby przejść do nowej usługi. Dlaczego Twój organ zewnętrzny miałby obsługiwać inny format? Nikt, z kim pracują, nie może z niego korzystać! Dlaczego zaczniesz produkować inny format? Żadna z organizacji, z którymi współpracujesz, nie akceptuje tego!

Prawdziwy problem widzę tu jest, dlaczego programiści toczenia własnego kodu CSV za każdym razem? Gdyby użyli stabilnej, solidnej biblioteki CSV, nie mieliby problemów, które opisujesz. Problemy są spowodowane przez deweloperów wprowadzających własne rozwiązania zamiast korzystania z biblioteki, i szczerze mówiąc, nie widzę, jak przejście do JSON lub XML magicznie to naprawia. Nadal będziesz mieć ludzi próbujących je regexować zamiast korzystać z biblioteki.

Zaraz.
źródło
4
+1 za wyrzucanie własnych za każdym razem. Widzę programistów, którzy się nie uczą, a nie wadliwy format danych. :-)
G__
„kompatybilność wsteczna” - oczywiście masz rację - ale nie posuwanie się naprzód kosztuje tysiące.
Stephen
Dobrze jest stworzyć własną bibliotekę CSV ... po prostu ponownie jej użyć !
GrandmasterB
5
@Stephen: Nie, ponowne wdrożenie CSV za każdym razem, gdy jest to potrzebne, kosztuje tysiące. Format CSV jest w porządku, problemem są programiści, którzy nie potrafią go poprawnie ustawić.
Anon.
6
@Stephen: Więc twój problem z CSV polega na tym, że jest to zbyt proste i chcesz czegoś bardziej złożonego?
Anon.
15

CSV jest nieco szybszy , mniejszy , bardzo łatwy w obsłudze (nawet w programie Excel) i wiele istniejących aplikacji to rozumie, jest to powszechnie stosowany standard .

Jest to nadal pierwszy wybór w wielu sytuacjach.

Osobiście nadal bardzo lubię ten format. Ale ja też używam JSON, ale do innych aplikacji, takich jak interfejs WWW.


źródło
1
Zgadzam się z tym wszystkim, z wyjątkiem początkowego użycia „trochę”.
Orbling
3
Może to być absolutna podstawa *** z Excelem, jeśli masz dane, które muszą zachować wiodące zera ... zapytaj mnie, skąd to wiem! ... poza tym Excel zapewnia dobry interfejs.
Dal
@Dal: Pracowałem w unii kredytowej i musiałem zajmować się plikami CSV, które zawierały numery kart kredytowych. Które mają 16 cyfr. Ten Excel zaokrąglił do 15.
dan04
Albo gorzej, że przekształciło je w notację naukową. :( Pamiętam, kiedy po raz pierwszy otrzymałem błąd w przetwarzaniu ACH, że zdalny numer konta jest nieprawidłowy, tylko po to, aby dowiedzieć się, że ktoś edytował plik csv w programie Excel (tylko w celu usunięcia wiersza) i zmienił kilka 30 cyfrowe numery kont na 2.3456356e29 itd.
cabbey
1
@Jeanne: Jeśli CSV rzeczywiście ma rozróżnienie liczb / ciągów, tak jak robi to JSON, byłoby dość łatwo powiedzieć Excelowi, jakiego typu są wartości. Problemy te są bardzo związane z ciągłym typowaniem CSV.
dan04
15

Przede wszystkim dlatego, że mimo spożywania dane CSV może być (nieznacznie) nietrywialne, generując go jest bardzo proste.

Chciałbym również zauważyć, że ani JSON, ani XML nie jest tak naprawdę łatwiejszy do uzyskania (zarówno dla producenta, jak i konsumenta). W rzeczywistości prawie wcale nie trzeba się rozglądać, aby wiedzieć, że wiele osób próbuje używać wyrażeń regularnych do analizowania danych XML, nawet jeśli absolutnie nie ma wątpliwości, że to nie może i nie będzie działać.

Większość problemów, które mogą (i robią) z CSV, mogą (i robią) również z JSON i XML. W szczególności XML dodaje wiele innych potencjalnych problemów. Biblioteka do analizy danych XML jest na ogół większa, wolniejsza i trudniejsza w użyciu niż podobna biblioteka dla danych CSV.

Jerry Coffin
źródło
1
wydaje się, że poprawnie go produkujemy jest niezwykle łatwe, zużywanie czegoś, co nie ma specyfikacji, nie jest trywialne, jeśli masz nietrywialne dane.
Stephen
2
@ Stephen: zwróć uwagę, że w pierwszym zdaniu nie wpisałem „poprawnie”. Jego pominięcie było celowe!
Jerry Coffin
4

Po pierwsze, zgadzam się, że istnieją bardzo realne problemy z formatem:

  • Jest ściśle napisany.
    • Bez rozróżnienia między tekstem a wartościami liczbowymi Excel zgadnie źle i zepsuje twoje kody pocztowe i numery kart kredytowych.
    • Nie ma standardowego sposobu reprezentowania danych binarnych.
    • Nie ma standardowego sposobu rozróżnienia między NULLi '', co stanowi problem podczas importowania plików CSV do baz danych SQL.
  • Słaba obsługa „znaków specjalnych”.
    • Brak odniesień do znaków numerycznych, takich jak (XML &#xNNNN;lub JSON \uNNNN) oznacza, że ​​nie ma standardowego sposobu reprezentowania znaków sterujących lub znaków spoza ASCII.
    • Wiele implementacji nie implementuje poprawnie podziałów linii w polu.
  • Brak standardu. Istnieje RFC 4180 , ale nie jest powszechnie stosowany.

Ale z drugiej strony:

  • Alternatywy są gorsze. JSON i XML, ponieważ są zaprojektowane wokół drzew, nie nadają się do danych tabelowych, szczególnie pod względem ...
  • ŚCISŁOŚĆ! W XML musisz mieć znacznik początkowy i końcowy dla każdej kolumny w każdym rzędzie. W CSV nagłówki kolumn zapisujesz tylko raz.
  • Plik CSV jest bardzo łatwy do wygenerowania.
  • Osoby niebędące programistami mogą otwierać pliki CSV w programie Excel.
dan04
źródło
w odwrotnej kolejności; użycie tych danych w programie Excel byłoby przestępstwem, którego można było dokonać, CSV łatwo jest źle wygenerować, zwartość nie stanowi problemu, drzewa lepiej nadają się do tych danych.
Stephen
4

Ponieważ wielu analityków korzysta z programu Excel (w przypadku tabel przestawnych itp.), A wyjście CSV jest znacznie łatwiejsze niż wyjściowy format Excel.

Przypis: biorąc pod uwagę liczbę problemów, jakie widziałem podczas obsługi plików CSV w programie Excel, takich jak usuwanie zer wiodących i utrata precyzji, jest to prawdopodobnie fałszywe poczucie, że jest łatwiejsze.

Scott McIntyre
źródło
To +1000. Excel to zabójcza aplikacja (jeśli ją znasz) do szybkiej i brudnej analizy danych. Możliwość eksportu do Excela daje ogromne możliwości nie-programistom w biznesie, badaniach itp. Excel prowadzi świat. Eksport CSV uruchamia Excel.
johannes
2

Jeśli jest coś nie tak z CSV, to znaczy, że CSV wydaje się tak prosty, że wielu programistów próbuje wymyślić własne parsery / programy piszące, a później obwinia CSV za niepoprawne obchodzenie się z ucieczką. Przy dobrym parserze CSV (wielu tam dobrych) nie będzie żadnego problemu.

Ktoś wspomniał, że CSV nie nadaje się do nietrywialnych danych, ale nie zgadzam się. XML pozwala na nietrywialne dane, ponieważ różne zestawy danych można umieszczać w różnych znacznikach „kontener”. Dzięki CSV możesz zawsze umieszczać różne dane w różnych plikach, aby osiągnąć ten sam efekt.

Co więcej, moim zdaniem, używanie XML do przesyłania danych zasadniczo stoi w sprzeczności z celem XML - transfer danych zwykle oznacza stabilną umowę między dostawcami a konsumentami, podczas gdy XML ma na celu przenoszenie rozszerzalnych informacji podlegających interpretacji, gdy są wykorzystywane.

Codism
źródło
1

Sądzę, że CSV są po prostu dobre, gdy masz tylko proste dane tekstowe, z przecinkami i średnikiem / końcem na końcu.

Dane w architekturze drzewa lub dane złożone nie mogą być używane w CSV.

CSV to po prostu zwykła tablica 2D jak w programie Excel, nic więcej ...

żart
źródło
1

Tutaj naprawdę chodzi o komputery mainframe.

Komputery mainframe, ponieważ te stare systemy wymyśliły sposób komunikacji przy użyciu CSV. Tak więc duże aplikacje, które zrzucają dane, mogą je odczytywać i zapisywać i nie mają powodu, aby je teraz zmieniać.

Excel, ponieważ może bezpośrednio otwierać pliki CSV. W rzeczywistości przejmuje rozszerzenie .csv podczas instalacji. Użytkownicy po prostu klikają nieco śmiesznie wyglądającą ikonę programu Excel, która otwiera się i tworzy fajną siatkę, z którą mogą się pokłócić.

Teraz nowoczesne wersje programu Excel są w stanie odczytywać, powiedzmy, XML bezpośrednio. Ale aby to zrobić, użytkownik musi zrozumieć coś więcej niż „podwójne kliknięcie na to zdjęcie”. Dwukrotne kliknięcie prawego zdjęcia może być zbyt wielkim pytaniem w niektórych branżach. . .

Wyatt Barnett
źródło
-1

Widziałem wiele technicznych odpowiedzi, ale podejrzewam, że ludzie używają CSV to ten sam powód, dla którego ludzie używają wielu innych technik / technologii: ponieważ jest to jedna z nich, którą najbardziej znają

Homde
źródło
-1

dlaczego z niego korzystam

  1. klient tego chce
  2. jest szybszy niż xml przez sieć (mniejsze obciążenie sieci)
  3. nic bardziej złożonego nie jest potrzebne do przekazywania danych
  4. między platformami
  5. czytelny dla człowieka
  6. łatwe do wdrożenia czytelników i pisarzy

itd itd.

jwenting
źródło