Názory k článku
Utilita debvulns umožňuje sledovat zranitelnosti v distribuci Debian

O JSONu si myslím spoustu věcí, které mi na rootu nedovolí publikovat, ale aspoň je shoda na tom, co je a není validní dokument; a ani to schéma není neřešitelné. (Jasně, musím ho dostat bokem, ale existuje.) CSV znamená co kus, to originál. Můžu se spolehnout na to, že oddělovačem bude čárka? (Zdravíme MS Excel aj.) Apostrofy nebo uvozovky? Kolem všech polí nebo jen tam, kde jsou nutné? Oddělovač v poli escapovaný nebo oquotovaný? Přežije implementace znak nového řádku v poli, nebo zpracovává dokument po řádcích? Samé otázky...

Specifikace CSV (napr. baj voko dle Wikipedie) vam na vsechno tohle odpovi.

Existuje velice jasna sada pravidel, jak CSV soubor ma byt formatovan, aby carky, uvozovky ci newline prosli jako obsah.

To, ze existuje spousta SW ktery kompatibilni neni - a vytvari hnoje, nebo zpracovava prasacky vstup, neni problem formatu - ale lenost uzivatele. To same se muze stat napr. u xml/html, kdy zapomenete pouzit pro generovani htmlspecialchars() funkci pro escaping hodnoty, protoze bud jste amater, alzheimer, nebo ezo-vestec co si mysli ze neco bude jenom cislo a neni to treba.

Schema bych do toho netahal.

> Specifikace CSV (napr. baj voko dle Wikipedie) vam na vsechno tohle odpovi.

Cituji českou wikipedii: Pro tento formát neexistuje specifikace, popis formátu se však nachází (mimo jiné) v RFC 4180. A z příslušného RFC: While there are various specifications and implementations for the CSV format (...). Formát s desítkou navzájem nekompatibilních dialektů je na nic.

Jasně. Můžu být striktní a vyžadovat RFC 4180, a tudíž být obtížný, nespolupracující a každý den mít na talíři já to dělám z excelu, chybu musíš mít ty; anebo můžu být laxní a řešit všechny možné a nemožné problémy spojené s tím, že neexistuje jediná obecně platná norma toho, jak má CSV vypadat.

Nebo použiju jakýkoliv lépe specifikovaný formát, kde producent i konzument má daleko přesnější představu o tom, co může, nemůže a musí. Není to problém RFC 4180 (snad jen v tom smyslu, že na něj každý druhý dlabe), ale je to problém čehokoliv, co se tváří jako CSV. A že takových dokumentů je. Používat takový formát prostě znamená riziko...

Jste vytrhl z kontextu uvodni proslov. RFC4180 definuje presne jeden CSV format, ktery mate generovat a ktery mate zpracovat. Jestli u cteni pujdete nad ramec tohoto (napr. s podporou LF namisto CRLF, nebo stredniku/apostrofu namisto carky a uvozovek, je na vas, ale pokud u generovani nedodrzite RFC4180 tak jste sam za vola a nevim co si jako stezujete.

S CSV jsem nemel zadny problem - jiste, najdou se "csv" a ne RFC CSV soubory, ale ty lze resit na per-aplikacni bazi.

Vice nez s odlisnostma formatu, jsem se setkal s problemem nekterych zarizeni, ktere generuji poskozeny CSV soubor, jez je od mista poruchy neparsovatelny - dela to APC UPS s cetnosti cca jednou za rok (pri logu ktery se cte jednou za hodinu). Ale to neni problem samotneho CSV, spis tam maj nejaky jiny bug, ze se stream poskodi.

> Jste vytrhl z kontextu uvodni proslov. RFC4180 definuje presne jeden CSV format, ktery mate generovat a ktery mate zpracovat.

Nemyslím si. Moje pointa je přesně v tom, že RFC4180 je jen jedna z možných definic pro CSV, a na tom, že 4180 specifikuje CSV ani zdaleka nepanuje shoda.

Nehledě k tomu, že "Each line should contain the same number of fields throughout the file." Doktore, uzdrav se sám - ta specifikace ani nepoužívá normativní SHOULD. Co může kompatibilní implementace udělat, když najde chybějící pole nebo pole navíc? Shořet, doplnit NULL, prázdné řetězce, číselné nuly/NaNy? Ta specifikace výslovně nezakazuje, aby řádky neměly stejný počet záznamů. Validní podle 4180, ale i tak implementačně závislé. A hned o větu později skoro totéž - "Spaces are considered part of a field and should not be ignored.".

> ale pokud u generovani nedodrzite RFC4180 tak jste sam za vola a nevim co si jako stezujete.

Stěžuju si na to, že i když vyrobím CSV validní podle RFC4180, tak někdo bude nadávat, že mu to rozbilo cosi, protože CSV prostě nemá široce uznávanou specifikaci, která by mi kryla zadek - ať už jsem konzument nebo producent.

Stěžuju si na to, že nejrůznější programy za CSV schovávají navzájem nekompatibilní dialekty, a všem je to ukradený a formát dokumentu ohýbají a definují až na aplikační úrovni. Stěžuju si na to - viz výše - že ani když bude dokument validní podle 4180, a bude ho číst jiná implementace té samé definice, nemám jistotu, že ten dokument interpretuje tak, jak producent zamýšlel. Jasně, jsou to okrajový případy, ale je vinou toho RFC, že okrajový případy připouští jako validní dokument, a že to, co se normě pro CSV blíží nejvíc používá should...

Stěžuju si na to, že JSON je prostě JSON, XML je vždycky XML, ale CSV neimplikuje RFC4180.

> ale ty lze resit na per-aplikacni bazi.

Známka dobrého formátu, toto, fakt. Napište producentům, že jsou za voly, u světla. Nebo si ty voly laskavě nechte od cesty. Rozuměno?

Jestli nedokazete vygenerovat CSV podle pravidel v RFC4180 v objemu asi sesti vet, tak by jste se programovan, potazmo IT fakt nemel venovat.

Tady nejde o to, ze existuje nekolik CSV, ale o to, ze vas novy produkt, by mel umet jenom to RFC - a v pripade nekompatibility muzete bugreport uzavrit ze je chyba na strane prijimace a at to kouka upravit podle RFC.

CSV neni nutne 2D pole, takze specifikace jenom doporucuje vhodnost to tak delat, ale pro nektere aplikace onen comma-separated-values muzou byt klidne typovane recordy, s typem v prvnim sloupci, coz je takovy retro napr z danoveho systemu - "datove vety" (records)

Stejne tak se nedefinuje hlavicka a datova cast, a bezne potkavam CSV s hlavickou skrze asi 8 prvnich radku (a nemaji plny pocet sloupcu). Trapi me to? Nikoliv, mam tolerantni parser a vim co to je za data (pick and place koordinaty pro tistak).

To uz je horsi, kdyz napr. cinsky vyrobce vyzaduje CSV, kde jsou vsechny parametry komponenty v jednom fieldu .. coz je velike WTF, protoze vuci tomu delaj jakysi automagicky matching - a nedokazal jsem vytvorit zadny vhodny unicode oddelovac, ktery by jejich web vyrenderoval spravne a ty parametry komponenty se nezlili do sebe.. protoze oni z toho whitespace odmazou. A support proste nechape ktera bije.

Zkousel jste vubec hlasit ci pozadovat uprvavu CSV u toho, kde vas to jako ze trapi, nebo jenom remcate tak obecne, protoze muzete?

> Jestli nedokazete vygenerovat CSV podle pravidel v RFC4180 v objemu asi sesti vet, tak by jste se programovan, potazmo IT fakt nemel venovat.

Dokážete se věnovat meritu věci, nebo jen umíte kolem sebe házet ad hominem? Protože kdybych se sázel, vsadil bych nemalý obnos na tu druhou možnost.

Tohle všechno by platilo, kdyby CSV automaticky znamenalo RFC4180, stejně jako JSON znamená Tu Jedinou Normu Pro JSON, O Které Všichni Ví. Není to tak, a to RFC to samo přiznává. Můžete tento fakt rozporovat nějakým důkazem, aniž byste do toho zatahoval moji osobu? Protože ano, zkoušel jsem požadovat, aby příchozí dokumenty typu CSV odpovídaly RFC4180, a díky tomu, co následovalo, CSV nemusím.

Mimochodem, popisujete přesně to, co na dokumentech typu CSV shledávám problematické.

> Stejne tak se nedefinuje hlavicka a datova cast

VÁMI POŽADOVANÉ RFC definuje hlavičku - může to být první logická řádka.

> Trapi me to? Nikoliv, mam tolerantni parser

Jinými slovy, ani vy nedodržujete vámi vybranou normu. *sarkastický potlesk*

Ravise, máte úplnou pravdu, ale obávám se, že v této argumentaci nemůžete vyhrát. To by totiž onen ten, kdo pravil, že prý "JSON nenabízí nic proti CSV", musel nakonec napsat "aha". Obávám se, že to už se tady nestane, neboť jste předložil, co se dalo (já si to se zájmem čtu a jsem hrozně rád, že tu špinavou práci nemusím dělat sám), ale stále to není dostatečně přesvědčivé, protože protistrana se zkrátka zařekla sama sobě, že neustoupí, aby status pravdy držela ona i navzdory pravdě objektivní (nebojte, každému, kdo trošku ví, je jasné, že je to úplná blbost). Ponechme obhájce CSV tedy v tom, že JSON vzniknul po dekádách, aby nakonec nenabídnul proti němu vůbec, ale opravdu vůbec nic. To je tedy smůla, že?

> ale obávám se, že v této argumentaci nemůžete vyhrát

Taky se nesnažím přeargumentovat mé ctěné protivníky, ale ukázat náhodnému kolemjdoucímu, že s CSV si bere na svá bedra netriviální zátěž, a že se to může dost šeredně nevyplatit. Taky tu pindám ve svém volném čase, a ve chvíli, kdy mě to přestane bavit zvednu klobouk a odejdu západu slunce vstříc :)

PS: klidně si nechám tykat

PPS: kdyby někdo věděl o možnosti, jak mou nenávist k CSV zpeněžit, rád si o tom poslechnu

Zapominate na to, ze u "legacy systemu" se musi akceptovat stav veci jaky je.
To je pripad i toho nastroje, co vygeneoval CSV po svem - vadi to? Nikoliv - ten soubor bude vzdy stejny - a parseru nastavite vzdy stejny kontext. Do mlynku na kafe davate vzdy kafe. A malokterej vam semele i orechy ci cukr bez poskozeni. Natoz, aby jste do kavovaru sypal jinej matros.

A i kdyz mate nerozporovatelnou normu typu ISO BMFF, tak vzdy se najde nejaka firma, co video soubor vytvori s podivnymi atomy kde jim texty pretekaj mimo box - a kdyz si na takove vykuky nemuze dosahnout ani Apple, protoze ty soubory jsou QTFF (a porusuji i QTFF), tak co chcete po me?

Deal with it. Standardem v IT se bohuzel nebere "vyhovuje popisu", ale "je vzdy stejne spatne". Takove to.. Normalization of deviance.

> Zapominate na to, ze u "legacy systemu" se musi akceptovat stav veci jaky je.

Ten stav je beznadějně rozbitý a kvůli tomu je CSV rizikový.

> To je pripad i toho nastroje, co vygeneoval CSV po svem - vadi to? Nikoliv

Jen jeho autoři jsou za voly (které jsem do diskuse nepřinesl já), ale po vás nemám nic chtít. Aspoň už mám jasno. Teda, píšu jasno, ale myslím zataženo. Je to legacy výrazivo, takže věřím, že si s tím nějak poradíte.

> Do mlynku na kafe davate vzdy kafe.

Já teda kafe nepiju a s mlýnky nemám zkušenosti, ale jestli existuje formát, který je zároveň káva i ořechy, pak je to CSV.

> Standardem v IT se bohuzel nebere "vyhovuje popisu", ale "je vzdy stejne spatne".

Škoda, že nemáme formáty, které popisu vyhovují, a jsou vždy stejně dobře. Momentíček...

Porad nevim a nechapu, kde vidite to RIZIKO v uzavrenem systemu "nestandardni zdroj" + "vhodny/chapajici consumer".

Pokud nejste schopen zpracovat CSV - ktere je lidsky jednoduse citelne, tak je neco fakt spatne.

Mozna by jste se mel se svoji pitomou argumentaci zamerit prvne na to, ze TXT soubor (text/plain) je taky slusne nestandardni a neexistuje pro nej RFC kteremu systemy co generuji textove sobory vyhovuji. Protoze mame tady ruzne konce radku, ruzna kodovani, ruzne znakove sady. To vas jako vubec netankuje??

Me CSV vyhovuje rozhodne lepe nez JSON (pouzivam pro logovani u davkoveho zpracovani - a hledani chyb.. ma to vsechny dobre vlastnosti), pokud mam potrebu lepsiho formatu, jdu do XML.

Nahrazovat CSV treba JSONem je dost magorina, kdyz ty dialekty cili na neco uplne jineho.

Kde mám ten klobouk...

Pojďme na to deterministicky. Čeština je přeci jen trochu nebezpečná. Vycházím jednoduše z toho, že podle vás "JSON oproti CSV nenabízí nic". Mám tento JSON objekt:

{
"clovek": {
"ruce": {
"levaRuka": {
"prsty": {
"palec": "N\u011bjak divn\u011b rozpl\u00e1cnut­\u00fd",
"ukazovak": "Norm\u00e1ln\u0­0ed",
"prostrednik": "Je uprost\u0159ed.",
"prstenik": "V pohod\u011b",
"malicek": "Je opravdu mal\u00fd"
}
},
"pravaRuka": {
"prsty": {}
}
},
"hlava": {
"oci": {
"leve": {},
"prave": {}
},
"nos": {}
}
}
}

Dejte mi to prosím v CSVčku. Pokud je tak dobré, jako JSON, je to minimum práce. Pak to porovnáme, jo? Kdyby to náhodou nebylo tak jednoduché, kašlete na to. Akorát potom...: "Děkuji, nemám dalších otázek."

24. 6. 2026, 11:21 editováno autorem komentáře

Variant je nekolik (konkretni data vam doda LLM), ale z patra me napadaj minimalne 4 analogicke reprezentace:

flattened - (key/value), kde klicem je plna cesta s oddelovacem
dictionary / tree, kde je strom tvoren zpetnou referenci (pripominajici kompresi)
normalized - kde klic v ruzne urovni je v prvnich 1..MAX sloupcich (fixne), data v (MAX+1)
compacted - kde klic neni doplnen prazdnymi poli, variabilni pocet sloupcu per radek

Pokud mate potrebu srovnavat nevhodne formaty, tak nam muzete na oplatku predvest, jak se ulozi velike bajtove sekvence (blob data), napr. v B-tree, aby to melo pristupovou slozitost O(1) ,)

Ale zpet k praktickemu srovnani - JSON ma hlavne tu nevyhodu, ze ho nelze zpracovat nekde od prostredka (pokud neexistuje predem zname schema), protoze uroven zanoreni resp. aktualni kontext neznate. To brani napr. rychle vizualizaci dat. Zde CSV je na tom mnohem lepe (muzeme argumentovat, ze schema by melo mit alespon podminku ze datove pole neobsahuje newline).

Děkuji, tím jste vlastně potvrdil můj bod.

Ano, do CSV lze stromovou strukturu nějak převést — flattened cestou, normalizovanou tabulkou, parent-id referencemi atd. Jenže to už není „CSV oproti JSON nenabízí nic / JSON nenabízí nic navíc“. To je přesně naopak: musíme si nad CSV vymyslet dodatečnou konvenci, aby umělo reprezentovat něco, co JSON reprezentuje přirozeně.

CSV samo o sobě nese řádky a sloupce. Hierarchii, prázdné objekty, typy, zanoření a vztah rodič–potomek musí nést až externí dohoda. U JSONu je tato struktura součástí formátu.

Takže správnější tvrzení by podle mě bylo:

CSV může být výborné pro tabulková data, zejména díky jednoduchosti a rychlosti zpracování. JSON je výborný pro strukturovaná a hierarchická data. Obě věci lze převádět, ale v případě CSV ne beze ztráty jednoduchosti nebo bez dodatečného schématu. A já chci jediný samostatný soubor. Platí tedy, že libovolné CSV lze přirozeně uložit do JSON, zatímco obecný JSON nelze stejně přirozeně uložit do CSV bez zavedení dalších pravidel. Totéž pak platí pro validaci formátu.

A s tím bych neměl nejmenší problém.

PS: A to jsem myslel, že kdyžtak budu CSV opatrně hájit. Ovšem takhle ne...

Tak pozor, teď jsem si všiml takového malého detailu. A totiž, že tvrzení, o které se opírám (že "JSON nenabízí oproti CSV nic navíc"), jste vůbec nepsal vy, ale uživatel "bez přezdívky". Takže už tuším, že naše debata, ať by byla jakkoliv dlouhá, by prostě skončila na tom, že JSON není CSV a každý formát najde své využití jinde. To už jsme věděli předtím a pokud jste výše řečené nevyřkl vy, pak se nemám argumentačně o co opřít. Jinak je vidět, že problematice rozumíte, takže naprostý respekt, ale tohle je nedorozumění. Nemá cenu srovnávat jablka a hrušky. Ani jeden z formátů není jenom špatný nebo dobrý. Mně se tedy zrovna většinou víc hodí ten JSON.

JSON má jasná pravidla, nebezpečné znaky escapuje, může být vícerozměrný atd atd. Pokud budete pokračovat stylem, že JSON nenabízí proti CSV nic, tak... Byste mě asi nutil odpovídat arogantně, což bych nerad, ale pokud Vás něco zajímá ohledně JSON nebo CSV, klidně se ptejte. Dělám s těmito formáty sice jen desítky let, ale i tak jsem už něco málo pochytil.