strona po japońsku
crazy bejbi
Tworzymy stronę firmową w wielu językach, ale klient dodatkowo dodał
opcję że chciałby wersję japońską ...
Mieliście z tym do czynienia ? Jakieś specjalne trudności ?
Wojtek
--
polecam stronę: www.nartyrowery.pl
największy sklep ze sprzętem narciarskim i snowboardowym
Mateusz
> Witam,
>
> Tworzymy stronę firmową w wielu językach, ale klient dodatkowo dodał
> opcję że chciałby wersję japońską ...
>
> Mieliście z tym do czynienia ? Jakieś specjalne trudności ?
Problem ze wstawieniem kontentu we wlasciwie miejsce
i anchorami linków ;)
the_foe
> Witam,
>
> Tworzymy stronę firmową w wielu językach, ale klient dodatkowo dodał
> opcję że chciałby wersję japońską ...
>
> Mieliście z tym do czynienia ? Jakieś specjalne trudności ?
>
> Wojtek
>
jak widac sami Japończycy widzac problemy duzo rzeczy laduje ze swoimi
"krzaczkami" w obrazki
--
the_foe
Jarek
> http://www.sony.jp/
>
> jak widac sami Japończycy widzac problemy duzo rzeczy laduje ze swoimi
> "krzaczkami" w obrazki
Fajny czarset "Shift_JIS", pewnie wszystko piszą z wciśniętym shiftem :D
--
Maly troll
Piotr Siudak
>
> http://www.sony.jp/
>
> jak widac sami Japończycy widzac problemy duzo rzeczy laduje ze swoimi
> "krzaczkami" w obrazki
dla porównania na amerykańskiej stronie jest całkowicie inaczej
--
Piotr Siudak
siu...@xz.pl
Marcin Miczek
> opcję że chciałby wersję japońską ...
> Mieliście z tym do czynienia ? Jakieś specjalne trudności ?
wersji polskiej i japońskiej. Kodowanie UTF-8 w obu wersjach.
Pozdrawiam
--
Marcin Miczek
beherit
>
> Tworzymy stronę firmową w wielu językach, ale klient dodatkowo dodał
> opcję że chciałby wersję japońską ...
>
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?
Pozdr,b
Marcin Miczek
> 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?
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
Pozdrawiam
--
Marcin Miczek
beherit
Właśnie pod tym kątem pytałem. :). W sumie będzie docelowo max. 200 tyś
rekordów średnio po 1000 - 3000 znaków z czego wydaje się min. 30-40% to
angielski, a reszta chiński tradycyjny.
Dzięki i pozdrawiam,
p.
Zbigniew Malec
> Właśnie pod tym kątem pytałem. :). W sumie będzie docelowo max. 200 tyś
> rekordów średnio po 1000 - 3000 znaków z czego wydaje się min. 30-40% to
> angielski, a reszta chiński tradycyjny.
Czyli masz jakieś 2,5GB danych o ile dobrze liczę. Zmieścisz na pendrive w
czymkolwiek byś nie zakodował.
--
Pozdrawiam
Zbyszek Malec
porneL
<mar...@no-spam.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
beherit
> 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.
Andrzej P. Wozniak
<news:op.vvcaq...@aimac.local> pisze:
> On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek
> <mar...@no-spam.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 us...@pochta.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
Marcin Miczek
> Osoba podpisana jako porneL <niu...@pornel.net> w artykule
> <news:op.vvcaq...@aimac.local> pisze:
>> On Wed, 11 May 2011 09:55:57 +0100, Marcin Miczek
>> <mar...@no-spam.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:
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
porneL
<us...@poczta.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/multipage/parsing.html#character-encodings-0
Oczywiście dozwolone nie oznacza, że to dobry pomysł.
--
regards, porneL
Piotr Siudak
>
> Oczywiście dozwolone nie oznacza, że to dobry pomysł.
>
mozesz rozwinąć?
--
Piotr Siudak
siu...@xz.pl
Marcin Miczek
> podwojony.
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
Piotr Siudak
> 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
siu...@xz.pl
Marcin Miczek
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
Piotr Siudak
> 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
siu...@xz.pl
porneL
>> 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
Marcin Miczek
> 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.
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
Piotr Siudak
> 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
siu...@xz.pl