[python] unicode

[Petr Prikryl]

ViNiL napsal
> [...]Je to otazka jednoho kazdeho autora, kolik je do sveho dila
> ochoten/schopen investovat prace "navic" a neomezovat okruh
> (potencialnich) uzivatelu.
> 
> > Implementační problém s "čínštinou" nastane tedy jen v případě,
> > kdy fyzicky spoléháme na to, že jeden znak zabírá v souboru
> > přesně dva bajty. Bude to problém chybného předpokladu o počtu
> > bajtů na znak v souboru, nikoliv problém samotného kódování
> > Unicode.
> 
> Coz je u dotazu na zaruceni pevne sirky znaku vada dosti podstatna.
> Taky bych opatrneji zachazel s terminem "kodovani Unicode."
> Uf, tak si nejsem jist, jestli to melo byt zaverecne shrnuti nebo
> zmateni ;-)))

Omlouvám se, jestli moje dřívější poznámka byla málo
srozumitelná. Jako autor programu nemůžu ovlivnit,
jaký si uživatel nainstaluje Python. Můžu to jen 
otestovat a případně varovat.

Pokud potřebuju pevnou šířku na znak, musím
použít UTF-32. Nejsem si vědom, že bych nějak
mátl pojmy kolem "kódování Unicode". Myslel jsem
tím skutečně přiřazení čísla znaku v abstraktním
smyslu, které je vždy jednoznačné. Při ukládání
do souboru jsem použil "způsob kódování Unicode",
což byl možná neobratný překlad anglického
"encoding form".

Souhlasím s tím, že aplikaci by měla být věnována
náležitá péče, aby nebyla omezující. Odhaduji ale,
že většina uživatelů software vytvořeného zde 
nebude sedět na židli v teoretické zemi, kde
se používají znaky s kódem větším, než 64k. 
Pro většinu uživatelů může být naopak vynucené 
použití UTF-32 chápáno jako omezující, protože 
UTF-8 i UTF-16 poskytují z abstraktního hlediska 
naprosto stejnou funkčnost a UTF-8 je navíc 
kompatibilní s ASCII.

Ještě jednou chci zdůraznit, že samotné použití
"formy kódování Unicode" UTF-16 není nijak omezující
(narozdíl od ASCII vs. 8bitové kódování). Omezení
do toho všeho -- co může ovlivnit programátor -- vnáší
zase jen programátor.

Můžu se rozhodnout. Buď budu šetřit kódem programu,
nebo datovým prostorem. V tomto případě bych se 
přimlouval za to, aby aplikace nevyžadovala
konkrétní způsob ukládání do souborů. Od programátora
se pak vyžaduje, aby více přemýšlel nad tím, zda 
je opravdu nutné soubory ukládat ve formě UTF-32.
Otázkou taky zůstává, do jaké míry mi skutečnost,
že jeden znak je uložen vždy na pevný počet bajtů,
vlastně může pomoci.

Původní dotaz Martina Blažíka se netýkal zaručení 
pevného počtu bajtů na znak v souboru. Teprve v druhém
dotazu upřesnil, že potřebuje dva bajty na znak.
V třetím dotazu upřesňuje, že se jedná o malá data.
V tom případě bych dal přednost načtení souboru
do paměti a jednoduché práci přes unicode řetězce.

Další zmatek může vyplývat z mírné odlišnosti
UTF-16 a Martinem zmiňovaného kódování UCS-2. 
UCS-2 je méně obecný, protože neumožňuje vůbec 
uložit znaky s kódem větším, než 64k. Znak 
v UCS-2 tedy vždy zabírá 2 bajty.

V tomto smyslu pokládám použití UTF-16 za mocnější,
perspektivnější, i když mírně komplikovanější. 
UTF-32 a UCS-4 se nyní pokládají za prakticky 
identické, ale velmi zřídka používané. Na druhou 
stranu UTF-16 se pokládá za přirozenou interní 
reprezentaci textu v různých operačních systémech 
a programátorských prostředcích.

A taky bych se nejdříve zajímal o to, jaké lidské
jazyky vůbec potřebují znaky mimo BMP (tj. kód na více,
než dva bajty). Tu "čínštinu" jsem minule střelil
jen od boku. Tipnul bych si, že pro ni BMP stačí 
A taky bych se zajímal, jestli si vůbec můžu 
dovolit spoléhat na to, že jedno písmeno na papíře
znamená jeden unicode znak (zda není nutné slepovat
více částí písmene z několika unicode znaků). 
Tím pádem nemusí být poskakování v souboru pomocí
seek na n-tý znak od začátku principiálně vůbec 
použitelné.

> A vetsine lidi staci heterosexualni manzelstvi.

Z mého pohledu si můžeš založit klidně bisexuální
manželství. Já s tím problém mít nebudu. ;)

pepr