Á, UTF-16, to je ta vyvážená kombinace paměťové úspornosti, endiánové nezávislosti a skvělé kompatibility s ASCII a C, které UTF-16 převzalo z UCS-4/UTF-32, a algoritmické jednoduchosti UTF-8? :o)
V mailing listu IETF jsem zahlédl tenhle postřeh:
"In a local file store, UTF-16 has some questionable advantages. Over the wire, it just decreases significantly the probability of interworking. The IETF and the UNIX operating system community had it just right when they chose to standardize on UTF-8 based interfaces."A to je, prosím, od lidí, co nám schvalují internetové standardy, jako je TCP/IP a podobně. Osobně myslím, že ideální stav je mít v paměti UCS-4 a na disku/na síti UTF-8.
Ovšem i u toho UCS-4 v paměti bych ještě byl s hodnocením opatrný. Člověk s tím sice získá indexaci znaků (no, spíš "znaků", co do praktického významu) řetězce v konstantním čase (kterou s UTF-16 obecně rozhodně nemá), ale pořád ještě tu jsou i v UTF-32 kombinující sekvence, které hatí indexovaný přístup k "logickým" znakům tak jako tak. Jestli se nepletu, spousta precomposed znaků prostě neexistuje, a první komponovaný znak zabije konstantní časový přístup ke komponovanému grafému. Přitom kodér a dekodér UTF-8 je tak triviální, že nestojí skoro žádný strojový čas, rozhodně ne v porovnání s šířkou pásma paměti, disku a sítě. Takže je sporné, co je vlastně rychlejší.
Dnešní doba díky hiearchii pamětí čím dál tím víc favorizuje kompaktní datové struktury, a v praxi je celá řada užitečných operací v UTF-8 pomalejší oproti UTF-32 v závislosti na velikosti reálných dat jen o tu konstantu, pokud není rovnou rychlejší kvůli kompaktnosti, a bůh ví, jak i poměrně normální operace typu délky řetězce ve znacích degenerují i na UTF-16/32. (Co třeba kanonická ekvivalence znaku U+216A a sekvence U+0058 U+0049? Nemusí to být jen diakritika...spousta zdánlivě stejných řetězců snadno může být "různě dlouhá", aplikací tradičního principu "spočítal jsem tu délku špatně, ale zato rychle". :o) U lineárního skenu ale může mít UTF-8 značnou výhodu, pokud je v něm daný text kompaktnější. To sice není zaručené, ale ve značné části světa to nakonec platí. A do přenosů dat na síti se aspoň nemotají ti odporní indiáni, což ocení každý technik. :-)))
:-D - doporučuju přečíst celé. ;-)Office worker: "why does Open Office take so long to load?"
IT guy: "That's because the routines were written by a German guy in his free time. I'm sorry, little-miss-everybody-should-speak-English, but this poor guy was working for free. What do you expect?"
Office worker: "what does the German language have to do with this?"
IT guy: "Your PC was built in Austin, Texas. German is its second language. See this routine here, öffnenSiediegroßeAkte()? Your American PC doesn't know what that means, and has to consult a dictionary each time it sees it. There's a group of teenagers translating it into English. They work on one word each for greater safety. One of them saw two words of the program and spent several weeks in the hospital."
Mně osobně se napříkald pracuje s komplikovanými regulárními výrazy dost špatně - hlavně co se týká hledání chyb a relativně malé flexibility. Mám radši nástroje, jejichž výrazové prostředky mi dovolí rychle se zorientovat v kódu, který jsem psal před týdnem a které mi např. nabídnou prostředky pro rychlé a pohodlné ladění. BTW, Ragel je z podobných prostředků IMHO poměrně mocný, přitom velmi "lightweight".
Rád bych ještě jednou zdůraznil, že v článku jde o zjednodušený příklad. Pokud byste to bral jako úplné zadání reálného problému, tak bych se já naopak mohl podivovat nad použitím regulárních výrazů jako nepřiměřeného prostředku. Pak by přece v podstatě stačily tři primitivní řetězcové operace: na řádku useknout úvodní a koncové uvozovky a rozdělit řádek na řetězce v místech, kde se vyskytuje ",". Na to přece regulární výrazy potřeba nejsou. :-)
#!/usr/bin/perl -w my $row; do { $row=<> } while $row !~ /^\s*$/; $row=<>; my @headers=map {$_=~/^"(.+)"$/ ? $1:$_} split ',',$row; while( $row=<> ) { my @data=map {$_=~/^"(.+)"$/ ? $1:$_} split ',',$row; printf "%s\n", join ', ', (map {"'".$headers[$_]."' => '".$data[$_]."'"} (0..@data-2)); }
"Navic to reseni v Ruby potrebuje knihovnu, kdezto to perlove si vystaci se zakladnimi jazykovymi konstrukcemi - tim padem odpada potreba knihovnu mit, inicializovat atd."To bude nějaký omyl, to řešení žádnou knihovnu nepoužívá - tedy pokud pomineme skutečnost, že se samo do knihovny dá zabalit. Ragel není knihovna, aby nedošlo k mýlce. :-)
Když chci mít něco rychle hotové, používám VBA či VBS (taková obdoba používání bashe a awk na unixech), na většinu ostatního C#. Pokud je to nutné, dovedu psát třeba v ASM, Perlu a dalších, ale z vlastní vůle tak nečiním
VBA je hodně pěkná technologie - ale není samostatná, je svázána s Microsoft Office - pokud potřebuji dostat data do databáze, tak protlačovat je tam skrz Excel je klasické drbání levou rukou (a bohužel se tak děje dost často). VBS je extrémně prostoduchý a pomalý jazyk - i když zmíněné parsování by se v něm asi zvládlo taky, a hlavně už je opravdu artefakt. Jinak, když v Unixu chcete mít něco rychle hotového, tak právě sáhnete po sedu, awku nebo třeba Pythonu - kdy dokážete s textovými daty poměrně čarovat (pokud víte jak na to). A pokud potřebujete výkon nebo robustnost, tak sáhnete spíše po Yacu. Obě platformy poskytují +/- podobné možnosti, GUI designer, debugger, IDE existují pro Perl, pro Python o Javě nemluvě. Mimochodem pomalost Javy už je naštěstí mýtem - v 6 zapracovali (konečně) a i k mému překvapení aplikace nad Javou 6 jedou srovnatelně s .NETem. Pokud mohu říci svůj názor - řekl bych, že dochází docela k zajímavé konvergenci - pár komerčních balíků komponent existuje jak pro .NET tak pro Javu. Historie o.s. do deseti let skončí. Nikoho moc nebude zajímat co je vespod. Pokud se bude volit mezi o.s. pak na základě politických rozhodnutí a nikoliv na základě technických kritérií, protože ta vzhledem k výkonu hw budou neadekvátní. V blogu Marka Olšavského se můžete dočíst, že k OSS se přiklánějí technicky zdatnější uživatelé, jelikož jim OSS poskytuje větší prostor pro seberealizaci a také nevýhody OSS jsou pro ně minoritní. Ostatní uživatelé budou preferovat uzavřený kód, kdy výhody OSS jsou pro ně nepodstatné (nedokáží je využít) a nevýhody markantní (a takových i mezi vývojáři bude většina). Takže nějaké preference tu budou, nicméně budou subjektivní - nikoliv objektivní. Co se týče přiblížení se IT obci - Linux už své udělal - bez webů a bez internetu by rozhodně počítače nebyly v každé rodině. A to ostatní - mám takový pocit, že nikdo moc neví jak dál - revoluce skončily, teď už se pokračuje evolučně, a přiznám se, že je mi jedno, jestli mám v mobilu Linux nebo Microsoft, pokud mi mobil jede a nezdržuje.
s = "some /relative/path" puts s.gsub(/ \//, ' ') # "some relative/path"tady zadne s.ReplaceAll("/"," ") nepomuze a vlastne ve stejne logice mozna mel postupovat autor clanku - stacilo treba nacist dany soubor do stringu (coz by snad nemel byt problem, tedy podle toho, jak jsou ty soubory velke), pomoci split na prazdnem radku jej rozdelit na dve casti, a tyto dve casti pak jednoduse zpracovat (viz reseni od VM, tusim - ty regexy jsou jednoduche a stejne by vypadaly i v Ruby, vlastne cele reseni by v Ruby bylo dost podobne, i kdyz celkove o dost citelnejsi) vysledkem jsou datove struktury (pole), obsahujici napriklad string " - 1 000 ", ktery se da zpracovat treba takto:
" - 1 000 ".gsub(' ', '').to_itakze fakt jednoduche, a o znalost Perlu ani tak nejde - spis jde o to, aspon trichu umet regularni vyrazy, nic vic, nic min
Pokud jste chtěl pouze upozornit na existenci Ragelu a jeho možnosti, měl jste zvolit úplně jiný přístup.
Na vašem postupu mi vadí právě to, že je bezkontextový. Každá hodnota se přeci pojí s nějakým sloupcem a k tím i s jeho deklaraci typu. Pokud vím, že sloupec musí být číselný, musí být konvertovatelný na číslo i kdyby byl zapsán exponenciálně.(S tím si váš parser poradí?) Podstatné je, že typ konverze se musí řídit deklarací sloupce a nikoliv pouhým obsahem. Vy snad neprovádíte validaci vstupních dat? A pokud jí chcete dělat poději, budete znovu spouštět parser?
Nevím, zda bych to nazval, že je to předepsáno. No, ale OK, jakž takž se to dá odhadnout. Přesnější specifikaci formátu bych ale docela uvítal - když už se např. z nějakých záhadných důvodů ignoruje pro zápis data norma ISO8601, nebylo by špatné mít alespoň jistotu, že rok, měsíc a datum jsou pořád ve stejném pořadí.
Co se týká oddělovačů, tak u CSV právě oddělovač se může v hodnotě vyskytovat - v tom případě musí být hodnota v uvozovkách.
Podle mého názoru je tomu právě naopak - můj postup je kontextový. Vždyť v okamžiku, kdy KA přijme hodnotu ji rovnou páruju se jménem sloupce. V tom okamžiku bych mohl udělat i převod na příslušný datový typ (včetně případných oprav chyb ve formátování čísel), validaci, atd. Po načtení celého řádku lze provést zápis do databáze, případně další operace (např. daná transkace se přiřazuje plátci/příjemci). Zdrojový kód pro převod datových typů, validaci, práci s databází apod. v příkladu (na rozdíl od skutečné aplikace) pochopitelně není, protože se primárně netýká popisu KA v Ragelu a tím ani tématu článku.
:-)
Regulární výrazy? Dokonce dva? Jde v nich určitě napsat hodně, ale pro tenhle případ je to IMHO kanón na vrabce. Proč používat složitou technologii, když úloha jde snadno převést na vyhledání podřetězce.
Tak třeba v Ruby by to bylo (uvádím jen vnitřek té smyčky, která iteruje po řádcích):
values << line[1..-4].split('","')
Pro ty, co nemluví Ruby: z řádku se odstraní první a poslední uvozovky, zbytek se řetězce se rozdělí v místech, kde je podřetězec uvozovky, čárka, uvozovky. To v Perlu nejde?
Omlouvám se za rýpnutí. :-)
Víme, to už jsi tu říkal. Ale ve skutečnosti jsem odpověděl na tvůj přínosný komentář čistě z pohodlnosti. Potom co jsem si přečet článek a pár příspěvků, potřeboval jsem tlačítko "Odpovědět". Tvoje reakce byla negativní a uprostřed obrazovky - použil jsem tě čistě jako ovládací prvek. Po pravdě - ani jsem to nečet, šlo mi jen o kontext a tvoje milé "OMG" na mě vykouklo.
Možná by bylo lepší, kdyby ses vrátil na ta nečeská fóra. Neber si to osobně, ale lidí, co plní diskuse skřeky o ničem je tu až až. Jen pro upřesnění, já - zjevně na rozdíl od tebe - komentuju vždycky k věci. Stačí se podívat co jsi ze sebe dostal ty a o čem jsem se tu s pár schopnými lidmi bavil já. Je úplně jedno, jestli jsi kéroval do autora nebo čtenářů - pořád to je jen trollí kérování.
Faktem zůstává, že autor je tupec a článek uvádí následovně:
Nedávno jsem dostal nelehký úkol: parsovat bankovní výpisy České spořitelny. Formátování vstupních dat je ale velmi nestandardní a často se nedrží ani vlastních pravidel. Hledal jsem proto vhodný parser, který by si s problémem poradil.
Načež se jal líčit, jak to nakonec vyřešil všeobecným parserem gramatik. Vstupní data jsou přitom v jednom z nejjednodušších formátů co existuje. Kdyby se to jmenovalo Úvod do Ragelu bla bla bla, tak je to něco jiného a docela bych to uvítal jako příjemnou změnu, ale i po tom jak je poslední rok dva root.cz na nic mě stále dostává, když tu vyvěsí článek nějakého začátečníka o tom, jak se pral s CSV formátem, který jinak rozparsuje i dítě. Vůbec nešlo o to, že bych to dokázal napsat líp nebo jinak, to by dovedl každý; bylo to prosté povzdechnutí nad kvalitou obsahu v souvislosti s tím, že se publikují články neschopných zelenáčů, kteří píší o něčem co se naučili při psaní článku. Tos nepochopil? Já fakt žasnu! Vážně jsi mě dostal. Nevěřil bych, že někdo může být tak natvrdlý a nepochopit jednu prostou poznámku k perexu.
Nakonec se to v diskusi snažil zahrát do outu, jakože mu šlo hlavně o Ragel, ale vypadá to blbě, protože o pár odstavců výš píše něco jiného. Ty jsi na tom ale ještě hůř, ze 104 komentářů jsou tvoje 3 a všechny se týkají tvé vlastní poznámky a jak jsi ji vlastně myslel. Měl by sis přiznat pravdu: nikoho to nezajímá, takové plky většina lidí přeskakuje. Jsem ale rád, že jsem si teď přečet i ty plky (tvé tři výtvory mezi nimi). Přišel bych o kopec srandy.
Mám v OpenOffice Calcu výpisy z účtu celé dva roky zpátky. Jak jste proboha přišel na to, že se nedají inteligentně načíst?
V otevíracím dialogu pro soubory *.cvs si zvolím znakovou sadu, oddělovací znak (v mém případě středník) a oddělovač textu (uvozovky). S takto načtenými daty rovnou pracuji. Sloupce obsahující datum, mají hned po načtení správný formát, ostatní buňky jsou přednastaveny na standardní číselný formát, který si mohu v každém sloupci libovolně změnit. Celý soubor má nyní 13 sloupců, v roce 2006 to bylo 12. Žádné chyby ani výjimky se po celé dva roky nekonaly.
Chápu, že jste chtěl demonstrovat vytvoření parseru pomocí Ragel, ale nešiřte při tom prosím poplašné zprávy.
S pozdravem FB
Je zajímavé, že docházíme stejným postupem k různým výsledkům.
Používám OpenOffice 2.0.4 na Debianu. Co se týče formátu sloupců, ve kterém se Vám načítá *.csv soubor, i ten lze zvolit v otevíracím dialogu. Nad náhledem tabulky se nalézá položka "Typ sloupce". Po označení sloupce v náhledu tabulky mohu vybrat jeho typ - formát. U mne jsou po základní instalaci OO všechny sloupce defaultně nastavené na "standardní" - což je číselný formát. Pokud mám v *.csv souboru čísla jako 3 500, načtou se mi správně tedy 3500.
Netuším, proč se to u vás načítá jako text, ale mohlo by to souviset s nastavením vlastních stylů.
Vyzkoušejte přímo službu nebo si stáhněte zdrojáky.
http://www.webconsult.cz/novinky/prevod-csv-ceske-sporitelny-do-abo-pro-money-s3.html