Diskuse:Unicode

Kódování pro češtinu

Proč je pro češtinu nejvhodnější kódování UTF-8? Jaké kódování je nejvhodnější pro angličtinu? Co je obsah sdělění "Pro češtinu je nejvhodnější kódování UTF-8?"

Pro angličtinu zřejmě také. Ta věta moc skutečného informačního obsahu asi nenese, ale imho vyjadřuje, že např. pro jazyky typu čeština je utf-8 vhodnější, než např. ucs-2, které je vhodné pro jazyky typu čínština. Mám dojem, že tam ta věta poměrně sedí, nevidím v tom moc problém. --Mormegil 19:21, 20. Čer 2004 (UTC)

Formulace "UTF-8 je nejvhodnější kódování" není optimální, ale je přibližně správná - pro drtivou většinu jazyků založených na latince. Jeho zásadní výhoda je, že je jednoznačně určené, takže se na něm shodnou všichni napříč různými operačními systémy. U všech ostatních běžných kódování (mimo GB18030) není jasně dané pořadí bytů, což je znehodnocuje. Využití klasických 8-bitových kódování vede v současném globalizovaném světě k velkým problémům. UTF-8 pro jazyky založené na latince zvětší velikost řetězců jen nepatrně, přitom se získá obrovská výhoda v přenositelnosti a kompatibilitě. Z hlediska zpracování je zde ta úžasná výhoda, že řetězce kódované v UTF-8 lze kopírovat úplně stejně jako normální ASCII texty, takže UTF-8 nevede ke zhroucení nebo zaseknutí starších programů. Pro azbuku toto kódování tak výhodné není, protože proti 8-bitovým systémům natáhne velikost textů na dvojnásobek, ale z běžně rozšířených kódování Unicode je i pro tyto jazyky nejvýhodnější. --Pteryx 09:21, 14. 1. 2008 (UTC)

Protože čeština má jen pár znaků navíc, takže je pro ni UTF-16 zbytečné.

Pro angličtinu je nevhodnější 7-bit, neboť nemá žádnou diakritiku.

-- Vít Zvánovec 09:21, 22. Čer 2004 (UTC)

To je poněkud silné tvrzení. I v anglickém textu se občas hodí mít nějaké podivné znaky, i kdyby to mělo být jen pár řeckých písmenek či “trocha typografie”. Ale myslím, že je to samozřejmé, takže si rozumíme. :-) --Mormegil 10:47, 22. Čer 2004 (UTC)

V případě podivných znaků už to není angličtina. -- Vít Zvánovec 14:25, 22. Čer 2004 (UTC)

Byte/bajt

Při přepisu článku jsem měl problémy se slovem "byte". Jak ho používat v češtině? Skloňovat? Když ano, jak? Nebo používat přepis "bajt", který se už dá skloňovat docela dobře? Poraďte. Mojža 15:25, 22. Čer 2004 (UTC)

Po pravdě řečeno mi tohle taky dělá trochu problémy. Dokonce jsem zjistil, že to tak nějak občas míchám. Jakkoli se mi bajt nelíbí nijak výrazně, je to asi jediná použitelná verze v běžném textu. A už je to i docela zaběhnutý termín (viz např. časopis). Ale samostatný článek (na který se chystám cobydup) by měl být nejspíš Byte, s přesměrováním z Bajt. Asi. Takže já bych byl asi pro používání něčeho ve stylu: „Vejde se tam spousta bajtů.“. --Mormegil 15:34, 22. Čer 2004 (UTC)

Byte je přeci jednotka. Máme snad nějaké džauly? Takže žádná další barbarisace. -- Vít Zvánovec 15:38, 22. Čer 2004 (UTC)

S tím celkem souhlasím, "bajt" se mi taky moc nelíbí, ale jak ho tedy používat v textu? Mojža 16:01, 22. Čer 2004 (UTC)

Souhlasit s tím, že bajt nezní moc hezky, jde snadno. Jenže co s tím? V současné podobě je např. článek UTF-8 prakticky nečitelný díky těm nesklonným byte (bajtům). Skloňovat byte, bytu, bytem, byte, ... je podle mě ještě horší než bajt, bajtu, bajtem, ... Apropos, už jsme tu měli i časopis Bajt. Takže co s tím? Nevím... --Mormegil 21:10, 22. Čer 2004 (UTC)

O UTF-8 jsem tak psal vědomě, jak to bude vypadat. Nic moc, ale zatím nevím, co s tím. Asi počkám na další názory (nebo to někdo zedituje). Mojža 21:59, 22. Čer 2004 (UTC)

Mně se nezdá tak hrozné. Také by bylo možné používat značku nebo přilepit českou koncovku. -- Vít Zvánovec 09:30, 23. Čer 2004 (UTC)

Ano, přesně takhle (jak to uvádí Mormegil); viz Mluvnice češtiny, svazek 2 - Tvarosloví, pasáže o cizích slovech s odlišnou výslovností (mělo by to být i v jednosvazkové Příruční mluvnici češtiny). --Malýčtenář 10:36, 23. Čer 2004 (UTC)

No tak OK, jde to. Jenom je potřeba poznat, že ten článek patří do informatiky a ne do stavebnictví. Značka se obecně používat nedá, protože narozdíl od oněch Joulů, kde se těžko setkáme se samostatným podstatným jménem Joule („Každý z Joulů má svůj význam.“), se se samostatným bytem setkáváme poměrně často („Každý z následujících bytů má nastavený horní bit.“). Byte totiž není jenom jednotka informace, ale i konkrétní entita té velikosti. To se u jiných jednotek obvykle nestává, tam není žádný Joule číslo 1 a Joule číslo 2. --Mormegil 11:12, 23. Čer 2004 (UTC)

Navazuju po 10 letech, jen zlehka: bajt je v pořádku, ničemu neškodí, ostatně se to už mezitím ukázalo. Ale hlavně si myslím, že diskutovat o bajtu je lepší u článku, kde je tématem.--Tosek (diskuse) 4. 9. 2014, 15:58 (UTC)

Problémy

Připadá mi, že tu někde kdysi byly některé relevantní informace o unicode, např. zmínka o kódování GB18030 (oficiální kódování v Číně), které je součástí standardu. Taky není pravda, že Unicode je 32 bitový, v současnosti norma povoluje i pro budoucí rozšíření max. 21 bitů (asi 2 miliony kódových bodů). Je absurdní, že více o terminologii unicode se člověk dozví v článku znaková sada --Pteryx 09:21, 14. 1. 2008 (UTC)

Kódování a BOM

(Přesunuto z Wikipedista diskuse:Mormegil) --Mormegil ✉ 12. 5. 2010, 07:55 (UTC)

Zdravim!

Nacali jsme skrze editace zajimavou debatu o Unicodu:

"to není pravda, BOM není v UTF-{32|16}BE ani UTF-{32|16}LE dovolen; UTF-8 je self-synchronizing, jak si můžete přečíst i v článku"

No, tak ted uz opravdu nevim, jestli vubec oba mluvime o tom samem?? Konkretne pro BMP:

• "BOM není v UTF-{32|16}BE ani UTF-{32|16}LE dovolen" - no a co ze to tam tedy na zacatku znamenaji ty dva byty "FF FE" ?! To prece prave je BOM! Vzdyt BOM je primo urceny k tomu, aby se hned na zacatku souboru vedelo prave ono "poradi bajtu".
• "UTF-8 je self-synchronizing" - tak to opravdu nevim, tenhle pojem mi ted nic nerika. Nicmene i ono "ala huffmanovo" delkove promenlive kodovani znaku ma prece svuj tribajtovy BOM: "EF BB BF" (nejen podle tabulky, ted jsem overoval spravnost hodnot), takze to prece take je BOM. ...identifikace, aby se vedelo, jaky zpusob kodovani znaku je dale v souboru pouzit.

Takze s cim/proc nesouhlasis? Kde je chyba? Nechapu. --Franta Oashi 11. 5. 2010, 14:25 (UTC)

Zaprvé, tahle debata patří na Diskuse:Unicode.

Hm, to vlastne ano. Takze to tam presunete? Ted kdyz o tom oba vime... --Franta Oashi 11. 5. 2010, 19:42 (UTC)

Teď k věci: Vezměme například UTF-32. To má tři varianty (encoding schemes), tři možnosti, jak se zajištuje serializace do posloupnosti bajtů: UTF-32BE, UTF-32LE a UTF-32. Pokud je nějaký dokument v kódování UTF-32BE (a víme to o něm například z HTTP hlavičky Content-Encoding), pak v takovém dokumentu není (a podle standardu ani nesmí být) BOM. Ditto UTF-32LE. Pouze pokud je dokument v kódování UTF-32, pak na začátku může být BOM (ale nemusí, endianitu můžeme implicitně předpokládat například podle platformy, na které běžíme). Totéž obdobně pro UTF-16.

A jeste jinak: "ze tam nesmi byt"... Kdyby tam nesmel byt, tak tam nejspis neni. Ale ja tu vidim na jednom systemu BOMy ve vsech trech souborech, kazdy s jinym kodovanim! Primo experimentalni dukaz. Takze to "tam nesmi byt" fakt nechapu. Co tim myslite? --Franta Oashi 11. 5. 2010, 19:50 (UTC)

Jo, takto, z HTTP... To ja zase vychazel z ukladani textu v soubotu. Tam se samo HTTP ani MIME neuplatni. A naopak, BOM je potreba ve vsech trech pripadech! Spojitost s HTTP mne nenapadla. Spis, nez ze "BOM tam nesmi byt" bych do clanku tyto dva pripady i nejak zminil a rozlisil: File / HTTP. --Franta Oashi 11. 5. 2010, 19:42 (UTC)

Ale to byl jen jeden ilustrační příklad, abyste to pochopil, žádný rozdíl v tom není. Zajímalo by mě, jak jste na tom systému vyrobil tři soubory, každý s jiným kódováním (a čím se liší). --Mormegil ✉ 12. 5. 2010, 07:55 (UTC)

Jak? To se udela snadno, napriklad v i jednoduchem XP notepadu: lze primo rici, jaky format/kodovani souboru chcete (save as). Takze jsem to i odzkousel, opravdu mam 3 ruzne Unicode soubory, vsechny prazdne, ale o velikosti 2, 2 a 3 Bajty. Obsahuji prave jen ty sve BOMy. Samozrejme navic i file o 0B, s neurcenym 1B kodovanim.

"žádný rozdíl v tom není" ... no, to mi prave neprijde, tedy ja rozdily a komplikace fakt vidim. Ad nize. --Franta Oashi 12. 5. 2010, 15:06 (UTC)

Míchání BOMu dohromady s proměnlivostí délky znaků v UTF-8 je zcela mimo, nemá to spolu nic společného.

Zase, ad predesle: Aby textovy editor (a treba i ten notepad@XP) rozlisil text sravne, BOM pouziva. A i ten tribajtovy BOM pro UTF-8 pak ma vyznam! Tedy aspon jako to chapu: Vzdyt vsechny ty tri pripady maji prave tyto dve vlastnosti: poradi bajtu a delka encodovaneho znaku: bud je delka fixni (a zalezi na poradi LE/BE), nebo je delka promenliva (ala huffmanovo zefektivneni podle frekvence, jak se na nej stale odkazuju). A z tohoto pohledu preci maji (stejny) vyznam vsechny 3 BOMy, aby se text z filu rozpoznal spravne. Tak snad "souborovy" pohled nejak objasnuje, jak to chapu / proc tohle podani nechapu.

Ma ten rozdil, ze jde o soubor, a ne o onlide prenos, vubec nejaky vyznam pro tuto debatu zde, nebo stale neco pomijim jen ja? Dost jste mne ted znejistil. --Franta Oashi 11. 5. 2010, 19:42 (UTC)

UTF-8 BOM dovoluje, byť v podstatě jen pro označení toho, že se jedná o UTF-8, původní účel (byte order mark) tu nemá význam. A přestaňte pořád mávat nějakou frekvencí a huffmanem, nebo si pro vás přijdou Číňani a vysvětlí vám, jak je to s frekvencí znaků.

Rovnou priznam, ze s UTF-32 zkusenost nemam, jen s 16b BMP. Ale at 32, nebo 16, a ikdyz je to stream (coz i file muze byt), stale nevidim tu detekci endianity, kdyz je tam BOM zakazany. U te treti (sporive) moznosti si tu heuristiku pro detekci nejak predstavit umim, ale LE/BE nemaji takovy rozdil, aby se dal detekovat. Tohle rozliseni bez BOM fakt nevidim, ani u tech zminenych streamu. :-/ Naopak, az dosud jsem cokoli v Unicode bez BOM povazoval za chybu... Bez BOMu to preci ma byt jednobajtove kodovani pres "kodovou stranku", horni pulka bajtu, takze vubec mimo problematiku Unicodu. Ze se pak pro nejakou platformu nektere z tech tri moznych kodovani Unicodu uprednostnuje, jako default, no prosim. Ale stale musi byt i prostor pro Unicode pripady "nedefaultni" z pohledu OS a i uplne non Unicode pripady. A bez BOM!? Nevidim to, neverim... ;) Mi to cele stavite vzhuru nohama. --Franta Oashi 11. 5. 2010, 19:42 (UTC)

Pokud vím, že se jedná o UTF-32LE, tak nepotřebuju žádnou detekci endianity (ani formátu); --Mormegil ✉ 12. 5. 2010, 07:55 (UTC)

Samozrejme, s apriorni informaci: predpokladat lze cokoli, ale ty potencialni nasledky... Jde mi o jistotu. Ad nize. --Franta Oashi 12. 5. 2010, 15:06 (UTC)

pokud nevím, v jakém formátu soubor je, tak mám vskutku problém. --Mormegil ✉ 12. 5. 2010, 07:55 (UTC)

A o tom prave mluvim! Neni treba nic "vedet" ani "predpokladat"! ...tedy nesmi to byt potreba, musi byt 100% jistota!

• Bud se ta informace o konkretnim kodovani da vycucat nejak z tech dat samotnych (je-li UTF-8 dost dlouhy, tak uz urcim, ze to neni 1B CP kodovani ala DOS, ale UTF-8, ale co kdyz je ten file prilis kratky?)
• nebo ta informace o kodovani musi byt recena explicitne, a pak zjevne pomoci BOMu! Tak to celou dobu chapu, vy mi to borite! ;)

Cely ten datovy svet nemuze byt postaven na nejkych predpokladech, uz proto ne, ze i ty neoznacene soubory cestuji mezi ruznymi soubory, kde "by se predpokladala" ruzna kodovani. V textove podobe jeste mozna (treba automaticka zmena poradi bajtu pri presunu po siti), ale uz by to nefungovalo u binarni formy textovch dat (ad treba zip). ...jde o podobne zmatky jako u CR/FL/CRLF.

A pokud chcete tvrdit, že jste v životě neviděl soubor v UTF-8 bez BOM, tak to jste toho asi moc neviděl. (Podívejte se třeba na zdrojáky v PHP, zcela namátkou svn:trunk/phase3/languages/messages/MessagesCs.php.) --Mormegil ✉ 12. 5. 2010, 07:55 (UTC)

Ze si nekde pouzivaji Unocide fily bez BOMu urcujicich konkretni kodovani, budiz maji sve (naplňované?) predpoklady a usetri si mnohotisickrat ty 2-3 Bajty v DB, ale obecne to tak delat prece nelze... Anebo mi to stale unika, a pak to tedy ukazte/vysvetlete. Klidne i primo do clanku: Jak tedy ten "BOMy zakazujici Unicode" funguje a jak resi vsechny ty me obavy zde popsane. Tohle chapani jsem si totiz nevymyslel ja, je spolecne v praci. Jednou uz se takove potize resily (svet pocitacu v 80-90's), ze byla nejaka 1B code page, a tech zmatku potom, jake kodvani ze protistrana pouzila... I jen Salamander jich ma "pro jistotu" hned 9 vestavenych. Tohle si Unicode nemuze dovolit, nejakou nejistotu! A urcite ani nedovoluje. Takze ceho/kdy presne se ten "zakaz BOMu" tyka? --Franta Oashi 12. 5. 2010, 15:06 (UTC)

Odolnost UTF-8 je zmíněna i v našem článku UTF-8. Jde o to, že kódování je vymyšleno tak chytře, že ztráta jednoho bajtu z proudu dat v UTF-8 poškodí pouze jeden znak. Oproti tomu pokud třeba ztratíte právě jeden bajt z proudu v UTF-16, máte celý zbytek dat totálně nečitelný.

--Mormegil ✉ 11. 5. 2010, 14:38 (UTC)

Dá se na to dívat různě. Co když vám z proudu dat v UTF-8 vypadne jeden bit? Nebo: když to máte nečitelné, aspoň zjistíte že něco vypadlo ;) Z hlediska přenositelnosti jsou jediná rozumná kódování UTF-8 a zde utajené GBK18030, nechápu jak někdo může používat něco jiného. UTF-32 má smysl pro vnitřní reprezentaci řetězců v počítači, pak se s tím pracuje stejně jako s klasickými znaky ASCII - jeden doubleword reprezentuje jeden znak. Microsoft hodně používá UTF-16, pro většinu věcí to vyhoví ale jakmile vylezete ze základní roviny tak budou problémy. Pro ukládání na disk nebo přenos po síti bych jednoznačně upřednostnil UTF-8. --Pteryx (diskuse) 7. 12. 2017, 11:22 (CET)

Poznámky

Když je ta stránka o Unicode obecně, pak mám dva postřehy.

• Chybí zmíňka nebo odkaz na zmíňku o kanonické a nekanonické reprezentaci znaků.
• Pojem byte má v kontextu dostatečně jistý význam? Ale nekoukal jsem do standardu, jestli používá pojem oktet, nebo byte, tak mě nebijte.

(marek na serveru jikos.cz) 90.182.25.114 22. 7. 2011, 08:06 (UTC)

• Děkujeme Vám, že se snažíte Wikipedii pomoci. Pokud máte dojem, že článek je potřeba vylepšit, nebojte se učinit v něm libovolné změny, které považujete za vhodné. Nováčci jsou vždy vítáni!
• „The term byte, as used in this standard, always refers to a unit of eight bits. This corresponds to the use of the term octet in some other standards.“ (Ne, že by na tom záleželo z hlediska encyklopedie.)

--Mormegil ✉ 22. 7. 2011, 08:40 (UTC)

Prosím opravte tabulku BOM

Chtěl jsem ji opravit sám, ale nenašl jsem ji ve zdrojáku stránky. Chyba je v řádku s

FE FF 32b, větší než BMP UTF-16, varianta UTF-16LE, (little-endian) 2B 1 až 2 4B

musí být

FF FE 32b, větší než BMP UTF-16, varianta UTF-16LE, (little-endian) 2B 1 až 2 4B

Díky --Sven (91.32.101.136 28. 1. 2012, 10:48 (UTC))

OK. Bylo to ukryto v Šablona:Kódování Unicode --Jx 28. 1. 2012, 19:11 (UTC)

Pěti- a šestibytové kódování znaku

Nejsem odborník zrovna na UTF, tak fakt nevím, co je správně: Z článku UTF-8:

V listopadu 2003 však bylo UTF-8 omezeno RFC 3629 na U+10FFFF kvůli shodnému omezení s UTF-16. Pěti- a šestibytové kódování znaku se tedy nevyskytuje.

Tady:

V UTF-8 se znaky kódují různě dlouhou (1–6 bajty) posloupností bajtů podle jejich pozice v Unicode.

Tady donedávna:

V UTF-8 se znaky kódují různě dlouhou (1–64 bajty) posloupností bajtů podle jejich pozice v Unicode.

Mohl by někdo tu informaci v těch článcích vyjasnit? Zagothal (diskuse) 8. 11. 2012, 13:34 (UTC)

Tristní stav článku

Když srovnám současný stav článku (leden 2015) se stavem z ledna 2012, tak konstatuji že ten současný je výrazně horší. A není to tím že by ty informace "nebyly aktuální". On se ten unicode už moc nemění, proč taky. V současné verzi je více vaty a hlavně se dozvíte v čem že je unicode horší proti 8bitovým abecedám. Jazykové roviny, kombinační znaky a normální formy, vztah k GB18030, poněkud problematická implementace "čínských" znaků společná pro Čínu/Koreu/Japonsko, to je českým uživatelům utajeno ... Připadá mi, že např. slovenská verze je méně s odpuštěním užvaněná a daleko lépe vystihuje o co jde, obsahuje více relevantních informací. --Pteryx (diskuse) 13. 1. 2015, 17:27 (CET)

Děkujeme Vám, že se snažíte Wikipedii pomoci. Pokud máte dojem, že článek je potřeba vylepšit, nebojte se učinit v něm libovolné změny, které považujete za vhodné. Nováčci jsou vždy vítáni! --Mormegil ✉ 13. 1. 2015, 17:45 (CET)

Z diskuse je vidět, že víte celkem dobře o co jde. Váš přístup, že kdo si hraje nezlobí vcelku chápu, můj diskusní příspěvek byl zbytečně ostrý. Informace v článku jsou pravdivé, jenže je tam dost věcí nadbytečných nebo duplicitních a dost věcí chybí. Pro detailní popis kódování je lepší se podívat na jejich stránky, polemika o "nevýhodách" unicode je spíše v rovině názorů a patří tedy spíše do diskuse, atp. atp. Český rybníček je strašně malý, počet používaných OS se zvětšuje, takže setrvávat u Win1250 je nesmysl a za vcelku povedený unicode můžeme jedině poděkovat. Nevím jestli a kdy se dostanu k tomu abych ten článek trochu poopravil, tak jsem aspoň naznačil směr kterým by to mohlo jít, pokud se k tomu někdo dostane dřív. Unicode je dost důležitý na to, že dokonce i správce by mohl přiložit ruku k dílu. --Pteryx (diskuse) 15. 1. 2015, 10:19 (CET)

+1 Kapitolka "Znaky Unicode" se podle svého obsahu týká zřejmě vlastností starého UCS-2 a o kus dále by si UCS-2 zasloužilo lepší vysvětlení. Kdybych netušil, o co jde, tak to z toho nepochopím. --Jx (diskuse) 13. 2. 2016, 09:31 (CET)

Uspořádání a doplnění článku

Milí přátelé, postupně zde značně narostlo množství informací o unicode. Což je chvályhodné, protože je to dnes univerzální forma kódování plaintextu a díky Bohu za to. Bohužel některé důležité věci se úplně ztratily, nebo zapadly. Pokusil jsem se to napravit, to je takový můj letošní vánoční dárek wikipedii. Tak to prosím příliš nerozvrtejte.

• zásadním rysem unicode je oddělení znakového repertoáru a kódování - tedy stejnou sekvenci znaků lze různě zakódovat
• celá Čína unicode používá v kódování GBK 18030, tj. používá znakový repertoár Unicode, ale úplně "přeházený" a odlišně kódovaný - opět se o tom zde nedozvíme NIC. Přitom GBK18030 je taky unicode
• dost důležitá věc pro češtinu: různé formy kódování diakritiky - dlouhé e lze zakódovat jako jeden znak, nebo znak e + znak diakritická čárka
• informace o "surrogate pairs" byla úplně zahrabaná, přitom je to důležitá část kódu

--Pteryx (diskuse) 8. 12. 2017, 16:17 (CET)

Zdravim, rad bych podotknul, ze podle me nejsem sam, kdo se ke strance dostane kvuli okamzite potrebe zjistit nejakou konkretni informaci, aniz nutne potrebuje pochopit celou ideu UNICODE. Tento ucel clanek nesplnuje. Nedovoluji si editovat primo clanek, protoze o problematice v podstate nic nevim. Predstavoval bych si priblizne tuto osnovu:

- Informace, ze UNICODE se tyka popisu a nazvoslovi pro znaky uzivane pro zapis textu. Netyka se konkretniho kodovani ani symbolu jako jsou noty nebo znaky pro šachové figury například. (na tuto otazku text odpovida vicemene dobre a relativne strucne)

- umoznuje zpusob zvoleny pro pojmenovavani znaku pridani jakehokoli (konecneho :-) ) poctu novych znaku nebo je nejaky strop?

- ta sama otazka u konkretnich kodovani - fakt by me zajimalo, jestli UTF-8 ma nejaky limit nebo ne. Jesne, ze to muzu zjistit studiem publikovanych norem, ale to jsem nemusel chodit na tuhle stranku

- vsechny pojmy je nutne predem definovat, pripadne napsat, znalost kterych pomu je predpokladana

predpokladem muze byt znalost pojmu: bit, decimalni, hexadecimalni, diadicky zpusob zapisu cisla, byte (je byte vzdy 8 bitu? ) atd

v textu se nahle zacne vyskytovat pojem "kodovy bod" pripadne "bod". Co to je? Uz jen nejistota, kterou ctenar ma pri cteni zbytku textu ztezuje pochopeni

hlavne kvuli tomuto v mem pripade nasleduje odchod na anglickou verzi hesla na wikipedii

Pres tuto kritiku autorum textu dekuji za jejich praci. I soucasny stav je lepsi nez nic (coz se o velke casti lidskeho snazeni obecne rici neda).

Diky!

Honza