Ve Fedoře 12 jsou defaultně prográmky zbarimg a zbarcam z commandlajny i gtk a qt frontendy, které QR čtou. Je to balíček zbar, zbar-gtk apod.
Obrázky z textu článku to spolehlivě přečte, jen písmena s nabodeníčky jsou v nějaké divné znakové sadě. Nevím, zda je to chyba zbarimg nebo zda to má blbě nakódované root.
tak to nejsou přímo frontendy, jen knihovny.
Co se týče kódování, tak problém s češtinou je s tím qrencode, nikoliv se čtečkou zbar. Qrencode některé znaky zvládá (latin1 subset, ýáí…), jiné ne (latin2 subset. ěščř…). Např místo znaku © qrencode vygeneruje nějaký japonský znak.
Presne tento problem jsem ocekaval a take jsem ocekaval, ze se mu autor clanku bude venovat. Mam takove neblahe tuseni, ze vetsina carovych kodovani si s formatem prenasenych dat hlavu vubec nelame.
Napriklad PDF417, ktere pouziva 602XML Filler a tedy i ceska statni sprava, je v tomto smeru naprosto impotentni. Takze aplikace to resi tak, ze vezmou prosty text v UTF-8, zakoduji jej do Base64 a teprve tuto posloupnost US-ASCII znaku prevedou do caroveho kodu. Prijemce dat to musi samozrejme vedet, jinak dostane nesmyslny retezec. Zadna metadata se neprenaseji.
Jeste usmevnejsi je, ze hardwarove ctecky techto kodu casto simuluji klavesnici. Zatimco v Linuxu se dekodovany znak dostane z jadra jako netransformovany symbol (protoze vstupni zarizeni ctecky ma nezavislou klavesovou mapu), tak ve Windows se udaje interpetuji globalni klavesou mapou jako stisk klavesy, takze nebohy urednik pouzivajici ceske rozlozeni dostane misto cisel ohackovana pismena, zameni se mu Y za Z a podobne.
Trochu špatně jsem se vyjádřil, ty programy fungují perfektně i s češtinou ( je v UTF-8; např ten Qr s dlaždičkama nebo ten japonský plakát), blbá je čeština v tom qr, které vytvořil autor článku.
Ostatně ten zbarcam je dokonalý – pustí kamerku a když jsem ji zaměřil na obrazovku a scrolloval text článku, postupně vysypával na terminál texty jednotlivých qr. Dokonce i toho, kde je barevně vyznačeno, co které pole znamená – je v tom adresa wikipedie.