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)

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)

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)