Vlákno názorů k článku JavaFX: H2 databáze a manipulace s CSV soubory od ffffffffffuuuuuuuuu - CSV(Comma Separated Values) comma - ciarka teda ','...
-
xxxxx (neregistrovaný)
Protože CS/CZ/SK.
Protože pokud je parsován náš vstupní text (míněno z reálného neprogramátorského světa - tedy většina, pocházející z SK či CZ), tak čárka odděluje desetinné číslo a nadělala by tak pěknou neplechu.
Jo, bylo by fajn, pokud by bylo volitelné (či se dělalo automatické rozpoznávání) a počáteční default se bral třeba z locales. Pokud něco takového je, pro java /či java pod linux/, vůbec k dispozici jako API. Ale pokud nevolitelné, tak pokud je vstupem "normální" text, tak pro naše země je u CSV definován jako oddělovač středník - tak holt natvrdo. Zrovna v tomto bych chybu neviděl.
-
Ondra Satai NekolaZlatý podporovatelBrat to z locale je cesta do pekel. Pouzivat desetinou carku ve strojove zpracovatelnych souborech je cesta do pekel.
Spravne reseni je bud pouzivat natvrdo vzdy jednu variantu (a i kdyz to je carka, tak to neni zas takova tragedie, muzes mit pole ouvozovkovane "jedna, dva, tri"), nebo format, ktery i popisuje obsah (rekneme AVRO, ale moznosti je mnoho)
-
Pavel TišnovskýZlatý podporovatelOno je tam pastí ještě víc, namátkou z praxe:
1) konce řádků (CR, CRLF, dá se narazit i na něco jiného)
2) co s konci řádků ve fieldech? Quotování totiž není povinné, bohužel
3) co s řádky rozdílné délky? když se to zkombinuje s bodem 2, nikdy není moc jasné, kde se vlastně nacházíme
4) qoutování samotného znaku určeného pro quotování. Norma sice předepisuje zdvojení, ale dá se narazit i na céčkové \" \' atd. (dtto konce řádků ve fieldech někdo řeší přes \n)
5) kódování? no to odhaduju heuristikou, většinou je to Windows-1250, párkrát se dá narazit na UTF-8, dokonce i na UCS-2, no zmatek velebnosti :-)Ve výsledku je nutné přesně specifikovat, jak má formát vypadat; napsat jen "očekávají se data v CSV" znamená si zadělat na problémy.
-
Ondra Satai NekolaZlatý podporovatel
Tak, tak. Idealne se na obecne CSV vykaslat, pokud to jde, a bud pouzit neco jineho (AVRO...) nebo si dospecifikovat, co je potreba.
-
Ondra Satai NekolaZlatý podporovatel
Urcite. Ale tezko hledat neco srovnatelne problematickeho k CSV ;)
-
Já tedy nevím, ale IMHO je CSV poměrně jasně popsané, jak má vypadat a existují moře parserů/writerů, které ten standard dodržují. A to napříč snad všemi existujícími jazyky.
Jediné dvě/tři otevřené otázky, které "autor" formátů musí specifikovat jsou:
- oddělovač, to je v zásadě jediná věc, kterou může mít smysl měnit
- quote character (který je zároveň escape)
- kódování - s otazníkem, kdo dneska použije cokoliv jiného než UTF-8, je s prominutím babrákPokud někdo vytvoří skoro-něco-jako-CSV, za prvé si přidělává práci navíc, bo znovuvynalézá kolo. Za druhe si pochopitelně koleduje o problém, ale tak je to se všemi standardy, nebo ne?
-
Ondra Satai NekolaZlatý podporovatel
Ne, CSV neni jasne popsany.
Napriklad: According to RFC 4180, spaces outside quotes in a field are not allowed; however, the RFC also says that "Spaces are considered part of a field and should not be ignored." and "Implementors should 'be conservative in what you do, be liberal in what you accept from others' (RFC 793 [8]) when processing CSV files."
-
Pavel TišnovskýZlatý podporovatel
Je tam toho víc, včetně zmíněných konců řádků přímo v buňkách, numerických hodnot a časových údajů ovlivněných locale (to leze hlavně ze SW pro Windows) apod.
Ale zastavím se u Tvého
"- kódování - s otazníkem, kdo dneska použije cokoliv jiného než UTF-8, je s prominutím babrák"
Jedním z pěkných testů všech těch parserů, které prý ten standard dodržují (jak píšeš), je jim podstrčit soubor s BOMem. U přibližně 1/2 všech implementací jsou potom vidět věci, z kterých vstávají vlasy na hlavě (když si člověk uvědomí, kolik dat dnes proudí v CSV, a to prosím i na "enterprise" B2B úrovni).
