On Sat, 14 May 2011 10:44:37 +0200, Piotr Siudak <s...@x...pl> wrote:

>> Oczywiście dozwolone nie oznacza, że to dobry pomysł.
>
> mozesz rozwinąć?

Oszczędność miejsca w UTF-16 jest w najlepszym przypadku minimalna, a
bardzo często -- nawet dla CJK -- UTF-16 jest marnotrawny.

Nawet w idealnym dla UTF-16 przypadku 100% znaków spoza ASCII UTF-8 może
być tylko 1/3 większy i różnica robi się mniejsza po gzip.

W praktyce nie serwujesz 100% text/plain z krzaczkami. Masz HTML, URL-e,
łacińskie nazwy, czasem interpunkcję z ASCII. Wszystkie te rzeczy puchną
dwukrotnie w UTF-16, przez co na typowej stronie, nawet pełnej tekstu,
UTF-16 traci przewagę.

Poza wydajnością na tekście bez ASCII UTF-16 nie ma żadnych zalet. UCS-2
przynajmniej miał gwarantowane 2 bajty na codepoint, a UTF-16 ma 2 i
4-bajtowe sekwencje.

Musisz męczyć się z BOM (jak gdzieś zapomnisz, to masz takie fajne jazdy:
http://en.wikipedia.org/wiki/Bush_hid_the_facts).

Musisz męczyć się z niekompatybilnością z ASCII i binarnością plików.
Oprogramowanie ze skopaną obsługą kodowań (w tym 99% shellowych narzędzi)
zazwyczaj da radę przynajmniej nie zepsuć UTF-8, ale z UTF-16 już nie ma
szans.

UTF-8 daje ci maksymalną kompatybilność, na typowych stronach minimalną
wielkość, a w najgorszym przypadku niezbyt dużą stratę na plikach bez
kompresji.


Jak masz ochotę się męczyć z innym kodowaniem, niż UTF-8, to już lepiej
użyć odpowiedniego nie-Unicode, żeby nie drażnić chińskich i japońskich
tradycjonalistów:
http://en.wikipedia.org/wiki/Han_unification (ale ZTCW, to w praktyce
wystarczy wybrać odpowiedni chiński/japoński font).

--
regards, porneL