Je pro mě obtížené pochopit, proč se tvůrci Unicode nesnažili zastavit na počtu 65 000 znaků, aby se vešli do dvou bajtů. Je teď těch znaků tolik jenom vlivem různých emoji a dalších serepetiček, nebo by se do dvou bajtů nevešly ani běžně používané jazyky (asijské)? Současná situace mi připadá trochu blbá, máme spoustu míst, kde se sedmibitové ASCII ukládá do 4 bajtů na znak. Kolik bajtů na znak naopak má text kódovaný nějakým tím UTF s proměnným počtem b/z, složený jen z těch nejhorších znaků, už si radši ani nepředstavuju.
to je tezke. tohle :), tohle :( nebo tohle jsou uz natolik pouzivane symboly, ze si to snad unicode special zaslouzilo. jenze tim se otviraji vratka zaplave vsech jinych (kdo posuzuje dulezitost smajliku?), a pak to konci symbolem pro lenochochoda a cerveny ctverec. (mimochodem, bude se v budoucnu rozlisovat i lenochod dvouprsty a triprsty?)
svym zpusobem mi vic vadi znaky U+3380 az U+33FF. treba U+3380 je specialni znak pro pikoamper. ale z definice systemu SI je pikoamper slozenina dvou znaku piko a amper, a pise se jako dva znaky za sebou pA. proc z toho ti chytraci udelali jeden znak netusim, a nema to logiku.
tak picoamper, to je zvracenina. Dokazu pochopit kombinaci fi, protoze pri tisku se tahle sekvence tiskne trochu jinak nez f i. Ale picoamper nema nejmensi duvod byt slozenina! Pak nastavaji problemy, ze
1. nemuzes vyhledavat v textu
2. nekdo nebude mit tento symbol ve fontu, tak to neuvidi nebo nevytiskne.
Mam napriklad jeden manual, kde chybi vsechny fi. Nedokazete si predstavit, jak blbe se to cte a jak casto se to v textu vyskytuje.
Oni se o to docela dlouho snažili a máme z toho docela dost pohrobků, např. kódování UCS-2, které znaky větší než 216 neumí kódovat, nebo UTF-16, které je dvoubajtové a znaky nad 216 kóduje pomocí surrogate pairs. Jenže se ukázalo, jak jste správně odhadl, že se tam asijské jazyky nevejdou. V Unicode 1.0 byla nějaká omezená sada společných znaků, se kterými si prý asijské jazyky měly vystačit, ale v příslušných státech na to měli jiný názor.
Kde je těch „spousta míst“, kde se používá UTF-32? Pokud vím, obvykle se používá UTF-8 nebo UTF-16.
Text složený z „těch nejhorších znaků“ bude výjimečný, ony se na konec přeci jen přidávají málo používané znaky. A asijské jazyky většinou používají jiná kódování, než UTF-8. S běžnými texty s vícebajtovými znaky se asi paradoxně ve střední Evropě setkáváme podstatně častěji, než v jiných částech světa. Stále se setkávám s chybami ve zpracování vícebajtových sekvencí v UTF-8. Dříve jsem si říkal, jak je to možné, vždyť se s UTF-8 pracuje na celém světě, jak je možné, že je v tom stále tolik chyb. Jediné vysvětlení, které mne napadá, je to, že tam, kde se používá latinka, se většinou používá „UTF-8“, ale ve skutečnosti jsou všechny znaky jednobajtové. Úplně jiné jazyky, jako ty asijské, používají jiná kódování. Tím pádem UTF-8, kde se vícebajtové znaky občas vyskytují (takže se vyplatí používat UTF-8, ale zase je to tak často, aby si té chyby vůbec někdo všiml), je používané relativně málo, takže i s naší prťavou češtinou na ty chyby občas narazím.
Ono napsat UTF8 aplikaci ve starších programovacích jazycích jako je např. C zas není až tak triviální - v Cčku je podpora wide charů, UTF8 char je vlastně vlastně ukazatel na řetězec. Některé knihovny chtějí wide chary, jiné UTF8 stringy. Docela jednoduchá úloha jako převod písmena z malého na velké již vyžaduje převod na wide char nebo zas speciální knihovnu. Pak, když už se to poladí, tak s tím problém nebývá - i když pořád pak člověk může narazit na špeky typu 1 UTF8 znak může mít šířku 1, 1.5 a 2 znaku - což pro terminál znamená kontrolovat jak šířku v bajtech, tak šířku zobrazení.
Délka jednoho znaku je ještě v pohodě, ale to, že se dá spojit více znaku do jednoho, to je teprve špek:
Jinak většina aplikací s řetězci či znaky nemanipuluje, v drtivé většině maximálně formou spojení řetězců (do jiného řetězce nebo stream). Zobrazení pak řeší obvykle grafický toolkit, bez které stejně není reálné aplikaci napsat... Terminál je zcela transparentní - buď si s tím poradí nebo ne, ale aplikaci to neovlivní.
> Docela jednoduchá úloha jako převod písmena z malého na velké již vyžaduje převod na wide char nebo zas speciální knihovnu.
Převod písmena z velkého na malé není ve vší obecnosti (tedy s přihlédnutí ke všem jazykům používajících nějakou formu rozdělení velkých a malých písmen) vůbec jednoduchá úloha. Podívejme se třeba na turečtinu, která rozlišuje tři formy písmena i: bez tečky (ı/I), s tečkou (i/İ) a se stříškou (î/Î).
Správně implementované toUpper("i") tedy s tureckým locale vrátí "İ", což programátora očekávajícího znak z rozsahu ASCII může překvapit a způsobit pád aplikace.
Mezi velkým a malým písmenem prostě bohužel obecně není rozdíl jednoho bitu…
AFAIK se na webu prave pouziva UTF-8 i pro asijsky jazyky, nebot diky HTML tagum porad velkou cast obsahu tvori ASCII znaky, jedine, kde se nevyplati pouzit UTF-8 by bylo mit nejakej asijskej text, kde neni moc ridicich znaku (ASCII), ti by pravdepodobne pouzili UTF-16. Pak taky mame technologie, ktery zase nic jinyho, nez UTF-8 neznaji