Názory k článku ČTÚ zveřejnil první otevřená data: ceny operátorů, roamingu či počty stížností
-
Ale jo, chválím snahu. Jen mě trošku překvapilo, když jsem se na něco z toho chtěl podívat, že kódování souboru je v CP1250. Za prvé jsem toto kódování nikdy za moc standardní nepovažoval (když jsme tu měli ISO-8859-2) ale za druhé - a to hlavně - bych čekal, že dneska nejjednodušší je to prostě uložit v UTF-8 a hotovo...
A jo, překódovat si to samozřejmě i v rámci nějakého dalšího automatizovaného zpracování umím, jen mě to prostě v dnešní době trochu překvapilo.
-
Ahá, tak ono se to dělá kvůli Excelu... A já myslel, že pokud na tom někdo bude stavět nějakou službu, tak si to třeba bude pravidelně načítat nějakým skriptem... Tak nic no. Pokud to Excel neumí, tak ten soubor před otevřením můžete převést do jiného kódování nějakým specializovaným nástrojem, takových programů existuje přehršel.
Není to od Windows trochu schizofrenní, když názvy souborů v NTFS už mají také v Unicode (akorát tedy ne v UTF8, ale v UTF16), ale co se týče obsahu souboru, pořád očekávají takové obskurní kódování, jako je CP1250?
Jinak zajímavé je, že třeba Gnumeric nebo Calc z Libre/Open Office nemají nejmenší problém se při otevírání CSV zeptat na kódování a také pak v daném kódování soubor otevřít.
-
Ono je nějak možné přinutit i Excel, aby se zeptal na kódování - ale nejde to přes jednoduché otevření souboru.
Pokud jdou ve Windows-1250 uložit všechna potřebná data, nevidím v použití toho kódování žádný problém. Pokud to někdo bude pravidelně načítat nějakým skriptem, s tím kódováním si bez problémů poradí. A pokud to bude chtít někdo jednorázově otevřít v Excelu, usnadní mu to práci.
Budu mnohem radši, když těch zveřejněných dat ve strojově zpracovatelném formátu bude mnohem víc a oželím, že je to jenom CSV a kódování Windows-1250. Než aby všechna otevřená data byla zveřejňována v té nejvyšší možné kvalitě, jako XML s verzovaným a dokumentovaným XSD, v Unicode - ale s tím, že takhle zveřejněných datasetů bude pár.
-
S argumentem "lepší něco, než nic", samozřejmě souhlasím. Jen jsem si prostě říkal, že pokud to vytvářeli teď někdy, tak že to neudělali rovnou tak, jak je to obvyklé v 21. století...
Jinak já osobně mám třeba raději to CSV, než XML, aspoň na tabulární data. Snadněji se to parsuje. Na XML to bez nějaké knihovny snad ani nemá cenu (resp. dovedu si představit zajímavější úkoly, než psát vlastní XML parser). U CSV je to tak jednoduché, že by si to snad každý programátor měl alespoň jednou zkusit napsat (a pak samozřejmě pro reálné používání ať používá raději nějakou ověřenou knihovnu). :-)
-
Takže preferujete své pohodlí před správností výstupu. A přesně z toho samého důvodu je to ve Windows-1250 – pro uživatele Excelu je to pak pohodlnější, a oželí se to, že Windows-1250 dnes není „správné“ kódování.
Mimochodem, každý, kdo tvrdí, že CSV je jednoduché na parsování, by si měl zkusit ten parser napsat – i s tím, že si to poradí s textovými položkami, ve kterých mohou být uvozovky nebo konce řádků…
-
Bohužel ono to tak je. Nejde o nějaká "správná" data, ale o to, aby ty data šla těm obyčejným uživatelům zobrazit. Co naplat, že se použije na dnešní dobu již nepoužitelné Windows-1250. Kdyby se to udělalo správně a na dnešní poměry, tedy v UTF-8 a třeba s těmi čárkami, pak by uživatelé nadávali, co za nesmysly se jim to zobrazuje.
-
x (neregistrovaný)
O to aby sla ta data nejak zobrazi obycejnym ovcanum nejde vubec. To je holej nesmysl. Ty ta data, natoz v nejakym csv nezajimaj. Naopak jde o to, aby ta data mohl kdokoli automatizovane zpracovavat - a tady je jednim ze zasadnich pozadavku i prave kodovani.
Zkuste si predstavit, ze vas bude rekneme zajimat, kolik pokut se rozda v jednotlivych clenskych zemich EU. Nejen ze budete muset pro kazdou zvlast vymejslet parsovani tech dat, ale jeste jako bonus budete pro kazdou zvlast muset resit kodovani tech dat ... to jiste potesi. A kdyz to kombinujete s dalsim zdrojem ve stejne zemi, tak muzete ve finale resit desitky ruznych charsetu, protoze nekde pouzijiu win, onde iso, tamhle utf ... tuhle si nekdo vzpomene na kameniky ... a voiala, gulasek je na svete. Samo idealne jeste tak, ze kazdy urad bude kazdy soubor poskytovat v libovolnem kodovani, ktere zrovna napadlo tvurce ...
-
Tak pro obyčejné ovčáky to samozřejmě není, i když si ty data také mohou přečíst. Jenže existuje jedna skupina, která s těmito daty může pracovat. A tím jsou analytici. A tito rozhodně nejsou nějací programátoři, aby si ty data nějak kódově zpracovali. Hádám, že většina z nich pracuje skrze Excel. Otevřou si tyto data v Excelu a pomoci jejich funkcí a analýz si vypreparuji co potřebuji. Pravda. Tito asi s jistotou budou vědět, jak otevřít "nepodporované" CSV. Takže je tu pořád otázka, co vedlo tvůrce uložit data v CP1250 a ne v UTF8. Jak jsem již tady psal. Pokud myslí jako já, tak je to asi reflex z toho, že když exportuji do CSV, tak ho vyexportovat do jakéhosi "kompatibilního" formátu, aby si to mohl přečíst i Excel ;)
To já plně chápu. Měli se třeba v rámci EU nějak domluvit na univerzálním formátu, které by si přečetli všichni. Ale asi taková dohoda neexistuje. Tudíž jaksi nezáleží na tom, v čem ty data jsou ;)
-
No když píšete "měli se dohodnout": Od čeho třeba jsou ISO standardy?
Ještě než se objevily různé varianty UNICODE (jako třeba to UTF8), tak tu pro nás bylo ISO 8859-2. No a M$ stejně musel používat jiná kódování - na názvy souborů CP852 (ještě z DOSu) a na obsah souborů pak CP1250 (někdy příznačně nazývané WINDOWS-1250). To byl tehdy gulášek...
A já si právě od jisté doby naivně myslel, že už tohle nebudu muset řešit - asi někdy v té době, kdy jsem právě s názvy souborů přešel z ISO-8859-2 na UTF8... No a pak zrovna u tohoto narazím na CP1250, tak jsem si dovolil se tomu trochu podivit. Ale hned se sesype spousta lidí, kteří toto rozhodnutí budou obhajovat. Fajn, rozpoutala se aspoň diskuse. Některé argumenty jsou validní (a já i některé respektuji), některé ale méně...
-
Jedna věc tedy je, zda je zrovna v tomhle případě zvoleno nejlepší řešení. A druhá věc je, co dělat pro to, aby se to obecně muselo řešit co nejméně. Podle mne se nedá spoléhat na to, že bude ten jediný správný standard pro kódování – ostatně i to Unicode je možné serializovat v různých kódováních. Problém vidím spíš v tom, že k tomu souboru nejsou přiložené všechny potřebné metainformace – tedy i mime-typ a kódování.
Bohužel ani ve 21. století není běžné v souborových systémech udržovat všechna metadata o souborech. Paradoxně kdyby se soubor stahoval přímo z webu, byly by tyhle informace v HTTP hlavičkách. Jenže soubory jsou na webu zabalené v zipu, ten tyhle metainformace neukládá.
-
S těmi HTTP hlavičkami to vůbec není špatná myšlenka. Překódování samotné opravdu není problém, na to dnes nástroje jsou. Ale kdo má zjišťovat, v jakém kódování to zrovna je. (To to mám jako otevírat v různých kódováních a dívat se, jestli je to ok? A ještě třeba vzhledem k podobnosti ISO-8859-2 a CP1250 to je něco, co opravdu dělám hrozně rád.) Oni to nemají napsané ani na tom webu samotném. A co když třeba ten export bude příště dělat někdo jiný, koho zrovna napadne použít jiné kódování...
Jinak nevím, jestli jste se díval i na ty ostatní soubory, než jenom hned na tu první položku v seznamu, ale právě ta první položka a pak ještě myslím třetí je v ZIPu, všechno ostatní jsou rovnou CSV.
K těm souborům tam nabízí i podrobnější popis sloupců (říkají tomu schéma), ale ten je také v CSV bez nějaké specifikace kódování.
-
Viděl jsem jenom ty v zipu. Ty CSV vrací správně mime-typ text/csv, ale kódování tam chybí. Čemuž se nedivím – ty údaje samozřejmě z výše uvedených důvodů nejsou uložené ani v souborovém systému serveru, takže server mime-typ ve skutečnosti doplňuje podle přípony. Pro HTML to bývá vyřešené, že se serveru řekne, že všechny .html soubory jsou v nějakém kódování. Stejně by musel ČTÚ nakonfigurovat server i pro CSV, ale je otázka, zda opravdu všechny CSV na serveru mají ve Windows-1250.
Pro detekci kódování je lepší použít existující nástroje. A nebo samozřejmě lidé, kteří s počítači pracovali od 90. let, poznají kódování souboru na první pohled :-)
-
x (neregistrovaný)
Ten gulasek ovsem ve widlich existuje dodnes ... stim ze vsude mozne bude cp850/win-1250/unicode je treba neustale pocitat a byt "vzdy pripraven" ...
Kuprikladu sem si psal script .. v naivni vire ze to prece musi fungovat ... na nahradu diaktitiky za znaky bez nabodenicek ... a samozrejme to nefungovalo. Protoze ten script byl ulozen jako utf8 ... jenze filesystem v radce stale vraci cp850.
-
V Excelu je problém myslím jen v tom CSV a možná i v tom starém binárním formátu XLS. Unicode Excel umí, akorát jen v těch nových formátech a tam, kde je vnitřně uvedeno kódování. Což de facto jsou jen různé varianty XML.
A aby to byla ještě větší sranda, tak v případě CSV a Excelu je nutné dodržovat i předepsaný tvar jako oddělovače, uvozovky a tak. Pokud je jiný formát, tak to sice otevře, ale nedokáže to rozdělit. Takže opět nepoužitelné.
Prostě v tomto to Microsoft poněkud posral. Si myslí, že CSV je jen jeden formát. Přitom ostatní nabízí při otevření možnosti zobrazení.Vždycky, když dělám webovou aplikaci a jsou v něm i exporty dat, tak je to pak sranda. Místo abych jednoduše vygeneroval výstup, tak v případě CSV musím data v UTF-8 překódovat do CP1250. Bych se na to vykašlal, ale Excel je přece jen poněkud používanější. Je možné, že takto mysleli i programátoři pro ČTÚ.
-
Zkuste příště v Excelu vytvořit nový list, na záložce „Data“ zvolit „Z textu“ (platí pro verzi 2010) a zvolit si příslušný CSV soubor. Můžete si vybrat jak kódování, tak oddělovače a typy sloupců. Pohodlné to není ani náhodou, ale není pravda, že to Excel neumí a že je pro překódování a přeformátování potřeba používat externí programy.
Na straně producenta je samozřejmě potřeba ten soubor připravit v tom formátu, kterému Excel rozumí při klasickém otevření, protože ten výše uvedený postup nezná každý (důkazem je tahle diskuse).
-
Když už jsme u toho Excelu, tak u něj mi nejvtipnější přišlo to, že formát CSV vlastně ani nepodporuje - protože to by mělo znamena "comma separated values". Jenže Excel, když už člověk chce takový soubor třeba uložit, místo čárek (comma) používá středníky (semicolon). Takže by se to asi mělo jmenovat spíš SSV... Ale kdo ví, možná to dělá jen ten náš "evropský" Excel - tzn. tam, kde čárku používají na oddělování desetinných čísel místo tečky.
Ale když už sám Excel to při uložení ukládá takto v různých variantách, bylo by fajn, kdyby s tím počítal i při otevírání souborů. On to sice umí rozlišit, jen se nesmí jít přes Soubor -> Otevřít, ale přes ten import dat z textu... Podobně to má vlastně ten Gnumeric. Jen Open/Libre Office raději stejný dialog (tzn. s možnostmi nejrůznějšího nastavení) zobrazí i při "obyčejném" otevírání souboru (tzn. přes něco jako Soubor -> Otevřít)...
ČLÁNKY DO MAILU