Pátá verze standardu Unicode uvolněna (diskuse)

[pingu]

To musí být panečku balík obrázku...

[melkors]

A Klingoni jsou vosk?

[Václav "Darm" Novák]

Tengwar taky stále chybí...

[zde]

Podle mne je Unicode jedno z nejhorších selhání v IT. Nestabilní (pátá verze, hahaha), neefektivní (32 bitů je jim málo), někde nepochopitelně volný (asi 10 způsobů kódování, žádný jeden z nich není "default" nebo aspoň "recommended"), jinde zas hloupě restriktivní (mnoho rezervovaných intervalů, zbytečně složité korektní parsování UTF-8). Za tohle bych fakt ty dědky postavil ke zdi (nebo aspoň poslal do důchodu).

[Filip Jirsák]

Nestabilní (pátá verze, hahaha)

Pokud je mi známo, updaty se týkají jen přidávání znaků, že by se znak na jedné pozici vzal a nahradil jiným se snad nedělá. Asi nebylo možné zahrnout na počátku všechny možné znaky – jednak nemusela být kapacita všechny je sehnat, jednak mohou vznikat znaky nové (třeba €).

neefektivní (32 bitů je jim málo)

Unicode je znaková sada, tedy přiděluje jednotlivým znakům čísla. A když těch znaků je víc než 2^16, tak na se holt musí přidělovat i vyšší čísla. Momentálně má Unicode téměř 100 000 znaků, takže do 2^32 se vejde vpohodě. Kódovat se dá Unicode klidně do 8 bitů – viz UTF-8.

asi 10 způsobů kódování, žádný jeden z nich není "default" nebo aspoň "recommended"

UTF-8, UTF-16 a UTF-32 – to jsou 3, ne?

Daleko horší je, že je ještě stále spousta programů, které Unicode nerozumí. Ostatně, jak byste vámi zmíněné "chyby" řešil?

[Luboš Doležel (Doli)]

Ještě se určitě používá UCS2.

[Filip Jirsák]

Ale to už právě nepochází přímo ze specifikace Unicode. A to že si někdo třetí vytvořil své kódování pro Unicode nelze dávat za vinu specifikaci Unicode.

[Miloslav Ponkrác]

Ještě vím o UTF-7, UCS2, UCS4. Kromě toho skoro každé kódování má tři varinaty - variantu pro little endian, pro big end. a s BOM znakem na začátku, takže existuje třeba UTF-16 LE, UTF-16 BE a další odvozeniny.

[deda.jabko]

The nice thing about standards is that there are so many of them to choose from.
Andrew S. Tanenbaum

[zde]

takže do 2^32 se vejde vpohodě

Ano, vejde. Zatím. V tomto bodu se omlouvám, nějak jsem se domníval že UTF-32 je stejně jako UTF-7, UTF-8 a UTF-16 multibyte, a ono není. Aby to ale nebylo tak jednoduché tak podle Unicode standardu mezi UCS-32 a UTF-8 přesto existují podstatné rozdíly (principielně zbytečné, samozřejmě, přesto však nadefinované).

UTF-8, UTF-16 a UTF-32 – to jsou 3, ne?

No, podle Wiki je jich 11, takže jsem se téměř trefil.

* UTF-7 * UTF-8 * CESU-8 * UTF-16/UCS-2 * UTF-32/UCS-4 * UTF-EBCDIC * SCSU * Punycode * GB 18030

Daleko horší je, že je ještě stále spousta programů, které Unicode nerozumí. Ostatně, jak byste vámi zmíněné "chyby" řešil?

0-0x7f vzít z ASCII, nad to naskládat různé národní sady postupně od těch nejkratších po ty nejdelší. Encoding definovat jen jeden, multibyte, podobný UTF-8, ale drobet jednodušší- zrušit bit č. 6, který je v UTF-8 zbytečně použit pro rozlišení prvního znaku v multibyte sekvenci od ostatních, a při enkódování jednoduše zabránit alisování- asi takhle:

def encode(c):
        r = ''
        l = 0x80
        while c >= l:
                c -= l
                r = chr(0x80 + c % 0x80) + r
                c /= 0x80
                l /= 2
        return chr(0x100 - l - l + c) + r

[zde]

mezi UCS-32 a UTF-8 přesto existují podstatné rozdíly

Do háje... samozřejmě jsem myslel mezi UCS-32 a UTF-32.

[Miloslav Ponkrác]

Já považuji UTF-8 v současné podobě za skvělé kódování, které má skvělé vlastnosti a minimum problémů. Jedna z vlastností je, že i uprostřed proudu dat je možné najít začátek znaku. Nerad bych tuto vlastnost rušil.

Navíc do 32 bitů se to rozhodně vejde. Slovo zatím je blbost. Nedokážu si představit vyčerpání 4 miliard možných znaků.

[zde]

uprostřed proudu dat je možné najít začátek znaku.

Hmm, možná to k něčemu je (umožnit iteraci směrem doleva).. Ale režie 3 bitů z 8 (38%) mi fakt už přijde dost extrémní.. To už bych možná spíš zrušil kódování délky v prvním byte. Lexikografické uspořádání po memcmp() stejně nikdo neočekává, tak proč se o to snažit.. Režie by se snížila na 2 bity (jeden pro odlišení od ASCII, druhý pro označení prvního byte v sekvenci..

[Miloslav Ponkrác]

A taky iteraci zprava doleva, i když bude asi potřeba méně často. Chlape, zaplaťpámbů, že nenavrhujete standardy. Průserů stylu "šetřím bajtíky" už bylo tolik, že by se snad lidstvo mohlo poučit. Viz Y2K aféra, viz Unicode a jejich 16 bitů. UTF-8 má a respektuje asi deset velmi praktických cílů, a ty naplňuje. Vaše úprava by vedla jinam. Jestli chcete šetřit bitíky, zvolte jiné kódování, UTF-8 o šetření místem není, protože znak tam může mít až 6 bajtů. UTF-8 je skvělý portable formát s mnoha pěknými vlastnostmi.

[Miloslav Ponkrác]

A taky iteraci zprava doleva, i když bude asi potřeba méně často. Chlape, zaplaťpámbů, že nenavrhujete standardy. Průserů stylu "šetřím bajtíky" už bylo tolik, že by se snad lidstvo mohlo poučit. Viz Y2K aféra, viz Unicode a jejich 16 bitů. UTF-8 má a respektuje asi deset velmi praktických cílů, a ty naplňuje. Vaše úprava by vedla jinam. Jestli chcete šetřit bitíky, zvolte jiné kódování, UTF-8 o šetření místem není, protože znak tam může mít až 6 bajtů. UTF-8 je skvělý portable formát s mnoha pěknými vlastnostmi.

[zde]

Chlape, zaplaťpámbů, že nenavrhujete standardy.

Dobré standardy nikdo nenavrhuje, ty vznikají samy.

[Filip Jirsák]

Ano, rostou na standardovníku, stačí jen dost slunce a hodně zalévat

[Filip Jirsák]

Tím vynecháním rezervovaných prostorů byste stejně nic neušetřil, protože rozsah znakové sady je dobré zarovnat na nějaký násobek 8 bitů, a pod 2^16 byste se stejně nedostal. To kódování by pak neumožňovalo kdekoliv najít začátek znaku, což by třeba znemožňovalo zotavení po chybě apod. A pro čínštinu apod. není UTF-8 asi nejlepší kódování, tam bude asi efektivnější UTF-16. Navíc podpora různých kódování má být součástí základní knihovny a programátor by se o to už neměl starat. Takže nevím, k čemu by byly vaše úpravy dobré…

[Miloslav Ponkrác]

Unicode je omezeno na 21 bitů, jinak by nefungovalo UFT-16 a další.

UTF-8 je jedno z nejlepších kódování, navíc totálně portable a compatible se starými string funkcemi. Jako bonus i trochu komprimuje texty.

Za co bych se přimlouval je uzákonění 32 bitů pro znak a odstavení 16 bitových kódování. Protože Unicode si vytvořilo bordel na počátku zvaný "šetřím bajtíky" a zvolilo 16 bitů na znak, i když přemýšlivému tvoru by došlo, že to velmi rychle bude málo. A tak vznikly různé 16 bitové mezistupně, které to dodnes opravdu zabordelují. A tento stav je pak konzervativně a blbě držet Javou, C#, Win32 API, typem wchar_t v C++ (i když ten může být iu 32 bitů) a dalšími, kteří "uzákonili" 16 bitový řetězec jako normu.

Pokud by zmizely z Unicode 16 bitové paskvily, bylo by to krásně jednoduché a přehledné.

[Luboš Doležel (Doli)]

Na druhou stranu: jsem sám, komu připadá, že je Unicode plný tuny znaků, které už snad nikdo nepoužívá?

[Miloslav Ponkrác]

Nepřipadá Vám, že v C a C++ jsou funkce a konstrukce jazyka, které nikdo nepoužívá?

Nepřipadá vám, že TCP/IP protokoly obsahují věci, které nikdo nepoužívá?

Nepřipadá Vám, že Unix a Linux obsahuje spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že procesory x86 obsahují spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že počítač PC obsahuje věci, které nikdo nepoužívá?

Nepřipadá Vám, že zákony tohoto státu obsahují věci, které nikdo nepoužívá?

... úděl standardů a důsledek skvělé věci zvané backward compatibility

[Miloslav Ponkrác]

Nepřipadá Vám, že v C a C++ jsou funkce a konstrukce jazyka, které nikdo nepoužívá?

Nepřipadá vám, že TCP/IP protokoly obsahují věci, které nikdo nepoužívá?

Nepřipadá Vám, že Unix a Linux obsahuje spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že procesory x86 obsahují spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že počítač PC obsahuje věci, které nikdo nepoužívá?

Nepřipadá Vám, že zákony tohoto státu obsahují věci, které nikdo nepoužívá?

... úděl standardů a důsledek skvělé věci zvané backward compatibility

[Miloslav Ponkrác]

Nepřipadá Vám, že v C a C++ jsou funkce a konstrukce jazyka, které nikdo nepoužívá?

Nepřipadá vám, že TCP/IP protokoly obsahují věci, které nikdo nepoužívá?

Nepřipadá Vám, že Unix a Linux obsahuje spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že procesory x86 obsahují spoustu věcí, které nikdo nepoužívá?

Nepřipadá Vám, že počítač PC obsahuje věci, které nikdo nepoužívá?

Nepřipadá Vám, že zákony tohoto státu obsahují věci, které nikdo nepoužívá?

... úděl standardů a důsledek skvělé věci zvané backward compatibility

[ivan]

Chapete nekdo tohle? Mac OS X’s filesystem uses an unpopular version of UTF-8 (NFD; Normalization Form D), which is slightly different from the popular version of UTF-8 (NFC; Normalization Form C). At present, Emacs does not support NFD. In NFD, diacritical marks (accents, diaresis, cedille, tilde, etc.) are decomposed into two sequences; for example, ü is decomposed into the character u and the diaresis ¨ combining character [1]. In a conforming Unicode implementation, these two would be combined back to ü. But Emacs doesn’t support that, yet. This is why you will see “u” and an empty box in the dired-mode buffer of Carbon Emacs.

PS: Vite ze MS pouziva BOM i u UTF-8? UTF-8 BOM bohuzel nepodporuje emacs, takze se v nem nektery UTF-8 dokumenty nedaji editovat..

[Miloslav Ponkrác]

Co je na tom k nepochopení? Mac OS X neprovádí nic co by nebylo v souladu se standardem. Unicode přikazuje, že si programu musí umět jak s dekompovanými znaky, tak s komponovanými.

Koukám, že ten emacs je asi na houby a dobře, že ho nepoužívám. Jednak si neporadí se standardním UTF-8 a jednak si neporadí s BOM znakem. Ve vimu problému nejsou. UTF-8 s BOM znakem na začátku, což produkuje třeba Windows notepad bez problémů rozpoznává. Je to proto, že vim ctí standard Unicode a co je ve standardu to bere. Pokud emacs ne, pak je potřeba natvrdo říci, že emacs nepodporuje standard Unicode.

Jediné co mi u vimu vadí je, že nedokáže ve Windows zobrazit znaky mimo 8 bitový font jinak, než jako čtverečky, ale třeba je na to nějaké obezlička.

[thingie]

Přimlouval bych se za uzákonění zákazu uzákoňování tvrdých, pevných hranic v datových strukturách, které tu mají být déle jak do konce desetiletí

[Abraxis]

Clovece, tobe bych pral pracovat v oblasti programovani a tiskaren pred 10-15 lety... Rika ti neco (bez Wikipedie) kodovani Kamenicky?

Diky bohu za Unicode!

[zde]

Samozřejmě... jediné pořádné kódování češtiny. Udělej něco správně, a nikdo to nebude používat.. takový je život.

[kyknos]

Otázka je, k čemu je kódování češtiny, ve kterém nelze psát jinými jazyky :) Řekl bych, že k ničemu.

[finn]

V době, kdy vzniklo kódování bratří Kamenických, bylo jasné omezení na straně hardwaru: ve standardním textovém režimu (který se tenkrát používal na většinu rozumné práce) bylo (a je) možné použít jen osmibitové znaky. A pak už si člověk nemůže moc vyskakovat, pokud jde o počet jazyků, které se zahrnou do jedné znakové sady.

[kyknos]

historicky jistě, ale říkad dnes "jediné pořádné kódování češtiny" je jako dnes říci, že pádlo je "jediný pořádný lodní pohon"

[deda.jabko]

:-]] zrovna minuly tyden jsme resili kodovani jednoho hyperstareho textoveho souboru... a nic nesedelo... az pak jsem si uvedomil... ze v te dobe se pouzivaly takove zvlastnosti jako kamenicky... a bylo to ono.... ;-]

[zde]

Nic jiného se na monitoru Hercules v textovém režimu použít nedalo..

[Kyosuke]

Ano, obzvláště Japonci a Číňané musejí být štěstím bez sebe, když jim Unicode slévá varianty znaků…

[Spike]

Případně kdokoli, kdo se zabývá historickými texty ze sféry vlivu čínské vzdělanosti.

Také je zrovna netěší, že oproti třeba Shift-JIS zabere každý znak v UTF-8 více bytů. :)

[petr_p]

Vim, ze jste tu o tom uz psal. Ale neni tak trochu problem v tom, ze Cina a Japonsko zpocatku odmitly spolutvorbu Unicodu a ze i ted tam panuje silna nechut k teto znakove sade?

Neni take pravda, ze problem odliseni cinskeho textu v japonskem je technicky vzato trochu podivny?

[Spike]

Asi takhle -- jsou tu tradiční znaky, moderní čínské znaky, moderní japonské znaky. Mnohdy jsou tyto podoby zásadně odlišné. A v rámci "Han unification" se zavedla jedna společná podoba, což je pro Číňany a Japonce naprosto nepřijatelné, protože jim do toho prostě kecá někdo z venku.

[Sten]

Han unification pouze sjednocuje kódy stejných znaků, nikoliv jejich reprezentaci (vzhled). Problém je v tom, že se nikomu nechtělo dělat software, který by Han uměl dekódovat, a tak sice Han je, ale umí jej jen minimum aplikací. (na druhou stranu je dobré připomenout, že ta unifikace v Unicode je nedokonalá, protože některé znaky neunifikovala)