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

do góry

W dniu 2011-05-14 17:03, Piotr Siudak pisze:
> W dniu 14.05.2011 12:52, Marcin Miczek pisze:
>> Jeśli chodzi o CSS (bez japońskich znaków),
> Moze zacznij od objaśnienia sensu kodowania w utf16 dokumentu skoro
> mozna go zakodowac w ASCII. Tak, wiem że napisałeś że to dlatego ze
> chcesz "bez problemów". Objaśnij.
Domyślnie jeśli plik HTML jest kodowany w UTF-16, pliki CSS, JavaScript
itp. dołączane z niego będą uznane za kodowane również w UTF-16. Jeśli
plik CSS będzie naprawdę zakodowany w UTF-8, to wyjdzie z tego
(dosłownie) chińszczyzna i style nie zostaną poprawnie zastosowane,
podobnie skrypty.

Można to obejść definiując jawnie charset w znacznikach
<link>, <script> itp., ale moim zdaniem kodowanie plików w jednym
serwisie w UTF-8 i UTF-16 to proszenie się o problemy. Programista lub
redaktor zapomni, wstawi się jakąś nową bibliotekę JS i serwis się wysypie.

>> plik kodowany w UTF-16 (2 bajty na znak) jest dwukrotnie większy
>> niż w UTF-8 (1 bajt na znak), więc nie 30% a 100%.
> Dla kogoś, kto serwuje wyłącznie CSS to rzeczywiście moze byc
> róznica. W zaproponowanym *przez_Ciebie* przykladzie byla to
> jednakowoż strona z arkuszem CSS wydzielonym do osobnego pliku.
> Zakodowana w UTF-8 zajeła 16079 bajtów a w UTF-16 w 21422 bajtów co
> stanowi wzrost o 33,22%. Kup se kalkulator czy coś.
Kalkulator mam dobry, więc nie muszę kupować, natomiast nie widzę sensu
Twoich obliczeń z dokładnością do 4 cyfr znaczących, gdyż tabelka, którą
zamieściłem na stronie, nie obejmuje wszystkich plików (ani nawet
wszystkich plików tekstowych). Obliczony tak zysk/strata nie ma zatem
wiele wspólnego ani z zajętością dysku ani z transferem.

>> Oczywiście wszystko zależy od rozmiaru serwisu, liczby
>> odwiedzających, buforowania, kompresji itd.
> Skoro zależy od czynników które wymienileś to żeby odpowiedzieć jak
> jest lepiej trzeba prze analizowac te czynniki.
Jeśli ma się czas lub ludzi do tego, to można analizować, ale przy tak
wielu zmiennych jest to gra niewarta świeczki, skoro zyski na UTF-16
będą minimalne albo nie będzie ich wcale, a po drodze pojawi się sporo
problemów.

Lepiej i bardziej technicznie opisał to już porneL.


Pozdrawiam
--
Marcin Miczek

do góry

W dniu 16.05.2011 09:54, Marcin Miczek pisze:
> nie widzę sensu
> Twoich obliczeń z dokładnością do 4 cyfr znaczących, gdyż tabelka, którą
> zamieściłem na stronie, nie obejmuje wszystkich plików (ani nawet
> wszystkich plików tekstowych).

No to moze pretensje o to ze tabelka jest do dupy skieruj tego gościa
który zamiescił ta tabelkę na stronie i uzył jako argumentu w dyskusji.
Gosć nazywa sie Marcin Miczek.


> Obliczony tak zysk/strata nie ma zatem
> wiele wspólnego ani z zajętością dysku ani z transferem.

Bo w rzeczywistosci róznica jest jeszcze mniejsza? Ojej, pozwól ze
wyjaśnie: to moja teza, nie musisz mnie do niej przekonywać.

> Lepiej i bardziej technicznie opisał to już porneL.

Różnica w tym żę porneL napisał co wie na temat, a ty co ci się wydaje.



--
Piotr Siudak
s...@x...pl

do góry