On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek
<m...@n...miczek.pl> wrote:

>> A to się podepnę z pytaniem, może ktoś ma pewność: do chińskiego
>> tradycyjnego UTF-8 też starczy czy jakieś inne wymysły? Albo może inne
>> kodowanie bardziej optymalne jest?
> Znaki chińskie i japońskie to prawie to samo. Dla stron mieszanych UTF-8
> wydaje się dobry, ale jeśli będzie przewaga chińskiego, to
> oszczędniejszy będzie UTF-16 - Zobacz http://pl.wikipedia.org/wiki/UTF-8

W HTML UTF-16 nie będzie oszczędniejszy, bo koszt kodu i URLi jest
podwojony.

--
regards, porneL

do góry

W dniu 2011-05-12 01:12, porneL pisze:
> On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek

> W HTML UTF-16 nie będzie oszczędniejszy, bo koszt kodu i URLi jest
> podwojony.
>

O słuszna uwaga. Szzczególnie, że ilość kodu HTML będzie podobna do
ilości treści.

Dzięki za słuszną uwagę, p.

do góry

Osoba podpisana jako porneL <n...@p...net> w artykule
<news:op.vvcaqqegvq69rq@aimac.local> pisze:

> On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek
> <m...@n...miczek.pl> wrote:
>
>>> A to się podepnę z pytaniem, może ktoś ma pewność: do chińskiego
>>> tradycyjnego UTF-8 też starczy czy jakieś inne wymysły? Albo może inne
>>> kodowanie bardziej optymalne jest?
>> Znaki chińskie i japońskie to prawie to samo. Dla stron mieszanych UTF-8
>> wydaje się dobry, ale jeśli będzie przewaga chińskiego, to
>> oszczędniejszy będzie UTF-16 - Zobacz http://pl.wikipedia.org/wiki/UTF-8

Tu nie ma mowy o UTF-16, sami zobaczcie:
/----
Znaki CJK zajmują po 3 bajty zamiast 2 w kodowaniach narodowych.
\----

> W HTML UTF-16 nie będzie oszczędniejszy, bo koszt kodu i URLi jest
> podwojony.

UFT-16 jako text/html to w ogóle nie będzie, bo nie znam standardu, który by
na to zezwalał. Jeśli sądzicie inaczej, wskażcie RFC, które dopuszcza w
Internecie niezakodowany tekst zawierający bajty 0x00.

--
Andrzej P. Woźniak u...@p...onet.pl (zamień miejscami z<->h w adresie)
Słuchaj, ty zacznij czytać też, a nie tylko pisać ...
-- RamOl na pl.comp.os.ms-windows.win9x

do góry

W dniu 2011-05-13 13:30, Andrzej P. Wozniak pisze:
> Osoba podpisana jako porneL <n...@p...net> w artykule
> <news:op.vvcaqqegvq69rq@aimac.local> pisze:
>> On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek
>> <m...@n...miczek.pl> wrote:
>>>> A to się podepnę z pytaniem, może ktoś ma pewność: do
>>>> chińskiego tradycyjnego UTF-8 też starczy czy jakieś inne
>>>> wymysły? Albo może inne kodowanie bardziej optymalne jest?
>>> Znaki chińskie i japońskie to prawie to samo. Dla stron
>>> mieszanych UTF-8 wydaje się dobry, ale jeśli będzie przewaga
>>> chińskiego, to oszczędniejszy będzie UTF-16 - Zobacz
>>> http://pl.wikipedia.org/wiki/UTF-8
> Tu nie ma mowy o UTF-16, sami zobaczcie:
Link odnosi się do całego zdania - również do UTF-8, a w szczególności
do znaków CJK, o których jest mowa.

> UFT-16 jako text/html to w ogóle nie będzie, bo nie znam standardu,
> który by na to zezwalał. Jeśli sądzicie inaczej, wskażcie RFC, które
> dopuszcza w Internecie niezakodowany tekst zawierający bajty 0x00.
Nie wiem, czy jest na to RFC, ale W3C wspomina o UTF-16 [
http://www.w3.org/TR/html4/charset.html#encodings ], a Firefox i Chrome
mają UTF-16 w swoich menu.

Pozdrawiam
--
Marcin Miczek

do góry

On Fri, 13 May 2011 12:30:34 +0100, Andrzej P. Wozniak
<u...@p...onet.pl.invalid> wrote:

> UFT-16 jako text/html to w ogóle nie będzie, bo nie znam standardu,
> który by
> na to zezwalał. Jeśli sądzicie inaczej, wskażcie RFC, które dopuszcza w
> Internecie niezakodowany tekst zawierający bajty 0x00.

HTML4 http://www.w3.org/TR/html4/charset.html#h-5.2
zezwala na wszystko z tej listy:
http://www.iana.org/assignments/character-sets
i tam jest pełno kodowań z \0.

XML wręcz wymaga obsługi UTF-16: http://www.w3.org/TR/xml/#charsets
(to dla mnie jeden z powodów, dla których "parsery XML są łatwe do
napisania" jest bujdą).

HTML5 zezwala na UTF-16:
http://www.whatwg.org/specs/web-apps/current-work/mu
ltipage/parsing.html#character-encodings-0

Oczywiście dozwolone nie oznacza, że to dobry pomysł.

--
regards, porneL

do góry

W dniu 14.05.2011 00:17, porneL pisze:

>
> Oczywiście dozwolone nie oznacza, że to dobry pomysł.
>

mozesz rozwinąć?

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

do góry

W dniu 2011-05-12 01:12, porneL pisze:
> W HTML UTF-16 nie będzie oszczędniejszy, bo koszt kodu i URLi jest
> podwojony.
Masz rację. Dla testów spróbowałem zakodować w UTF-16 jedną stronę,
gdzie tekstu japońskiego jest dość dużo w stosunku do kodu HTML. Mimo to
UTF-8 jest oszczędniejszy.

Można zobaczyć zestawienie na stronie http://test.miczek.pl/utf/

Ponadto, jeśli chce się bez problemów wczytać style, a HTML jest w
UTF-16, to plik CSS też powinien być w UTF-16 (może jest obejście - nie
szukałem). A to już jest wyraźna strata miejsca.

Pozdrawiam
--
Marcin Miczek

do góry

W dniu 14.05.2011 10:52, Marcin Miczek pisze:

> Ponadto, jeśli chce się bez problemów wczytać style, a HTML jest w
> UTF-16, to plik CSS też powinien być w UTF-16 (może jest obejście - nie
> szukałem). A to już jest wyraźna strata miejsca.

30%? "wyraźna strata" to jest zmiana o rząd wielkości róznica miedzy 15k
a 20k fachowo klasyfikuje sie jako "zasadniczo pomijalna"



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

do góry

W dniu 2011-05-14 11:01, Piotr Siudak pisze:
> W dniu 14.05.2011 10:52, Marcin Miczek pisze:
>> Ponadto, jeśli chce się bez problemów wczytać style, a HTML jest w
>> UTF-16, to plik CSS też powinien być w UTF-16 (może jest obejście - nie
>> szukałem). A to już jest wyraźna strata miejsca.
> 30%? "wyraźna strata" to jest zmiana o rząd wielkości róznica miedzy 15k
> a 20k fachowo klasyfikuje sie jako "zasadniczo pomijalna"
Jeśli chodzi o CSS (bez japońskich znaków), 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%.

Nie wiem, czy to jest "zasadniczo pomijalne". Na dysku być może, jeśli
chodzi o transfer - już mniej. Oczywiście wszystko zależy od rozmiaru
serwisu, liczby odwiedzających, buforowania, kompresji itd. Wydaje mi
się jednak, że obecnie lepiej użyć UTF-8 niż UTF-16.

Pozdrawiam
--
Marcin Miczek

do góry

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.


> 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ś.

Pomijając juz zupełnie fakt że żeby odnieść to choć troche do
rzeczywistości trzeba by sprawdzic jaką część pasma stanowi serwowanie
szablonów CSS. I jak bardzo jest to pomijalna wartość.



> 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.


> Wydaje mi się jednak, że obecnie lepiej użyć UTF-8 niż UTF-16.


Mozna też pojechać z "wydaje mi sie". Fakt.


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

do góry