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