Vlákno názorů k článku Jak budou vypadat pravidla přístupného webu pro veřejnou správu? od Michal Kubeček - Že by měl web obsahovat korektní specifikaci kódování,...

Že by měl web obsahovat korektní specifikaci kódování, pod to se klidně podepíšu. Ale vynucovat, že to musí být provedeno meta elementem, s tím souhlasit nemohu. Meta element http-equiv slouží jen jako berlička pro případ, že příslušnou hodnotu nelze specifikovat přímo v HTTP hlavičce. Je-li možné nastavit HTTP hlavičky, měla by tomu řešení být dána přednost. Specifikace v meta elementu přináší spíš problémy, protože dokument může být v různých situacích překódován (např. v závislosti na Accept-Charset a meta element takové překódování značně komplikuje (je ho nutné najít, přeparsovat a opravit).

Charset v meta má ale i jednu velkou výhodu - umožňuje určit kódování i u stránky, která je uložena na disk.

Který ze současných browserů nepodporuje utf-8?

V jakých praktických situacích by bylo třeba řešit accept-charset?

Historicky skutečně nebylo moc moudré vkládat informaci o kódování do , protože první moduly pro překódování češtiny měnily pouze HTTP hlavičky, ne obsah HTML stránky. Podle mé zkušenosti se tyto moduly teď už moc nepoužívají, a novější alternativy přepisují i kódování v , aby identifikace kódování souhlasila.

Kvůli ukládání stránek na disk, CD-ROM apod. je skutečně potřeba mít kódování identifikované přímo uvnitř dokumentu. Ostatně tímto směrem se vydalo i XML, které si také nese informaci o použitém kódování.

Kromě pragmatických důvodů se můžeme nechat inspirovat W3C, které se rovněž přiklání k názoru, že by kódování mělo být součástí dokumentu:

http://www.w3.org/TR/2004/WD-i18n-html-tech-char-20040509/#IDAK1FO

Tento požadavek má hlavní důvod v tom, aby byla stránka čitelná po uložení na jiné médium, než je web. Tedy např. po uložení lokální disk, kdy se všechny informace z http hlavičky ztratí.

V tom případě by ho tam měl doplnit ten, kdo stránku na disk ukládá. Jen on totiž ví, v jakém kódování ji tam ukládá. Navíc si představte modelový příklad: mějme dvě stránky řekněme ve windows-1250. Stránka A má toto kódování uvedeno v HTTP hlavičce a nemá http-equiv. Stránka B má v HTTP hlavičce uvedeno iso-8859-2 a v http-equiv má windows-1250. Asi se shodneme, že stránka A je v pořádku a stránka B ne; jenže podle pravidel z článku je to přesně naopak. Ten příklad se stránkou B není tak umělý, jak by se zdálo, s takovými stránkami se setkávám poměrně často; právě proto, že je autorům neustále vtloukáno do hlavy používání http-equiv, aniž by se dozvěděli, co to vlastně je a jak to funguje (nebo nefunguje).

Ze současných prohlížečů podporují UTF-8 asi všechny. Ale u těch starších by stránka v UTF-8 byla natolik nepoužitelná, že bych si ani dnes nedovolil poslat stránku v UTF-8 nikomu, kdo podporu tohoto kódování nedeklaruje v hlavičce dotazu.

Myslím, že k tomuto problému je potřeba přistoupit pragmaticky. Kódování v meta tagu je užitečné pro ukládání na disk, proto je vhodné ho ve stránce mít. Kódování určené v HTTP hlavičce má přednost před kódováním z meta tagu (viz specifikace HTML 4.01). Aby nedocházelo k špatné interpretaci kódování stránky je proto vhodné, aby kódování zasílané v HTTP hlavičce bylo stejné jako v meta tagu. Pokud kódování nesouhlasí, je to způsobeno špatnou konfigurací WWW serveru nebo jeho modulu pro překódování, a to je to místo, které by se mělo opravit.

Souhlasím s tebou Michale, že by aplikace při ukládání stránky měla doplnit informaci o kódování. Ale kolik prohlížečů to dělá? Překonfigurovat WWW server mi přijde nepoměrně jednodušší, než si doprogramovávat chybějící funkci prohlížeče :-D

Přece v Lynxu se tam přidá kromě kodu i BASE. Mám pocit, že i správci WWW-stránek znají jenom MSIE.
Ale co opravdu chybí v doporučeních a je potřebné říci, jsou západoevropské znaky na české stránce - zvláště když jsme už v Evropské Unii. (Třeba přeškrtnuté o )
Může se připsat třeba do kodování Windows-1250 znak ø resp. ø anebo k tomu musí být vše v UTF-8 ?
Je vůbec znám způsob transkripce přeškrtnutého o do češtiny? Kdysi o tom něco psali v oběžníku UVISu, ale to brali všichni tak vážně, jako když USIS psal, že stránky mají být v ISO-8859-2. Hlavně aby tak také neskončila současná doporučení. To, že zcela ignorují předchozí výstupy - produkované dokonce pořád ve stejném baráku - to samo už je k tomu asi opět předurčuje.
P.S.
Jinak jsem se chtěl ještě zeptat ohledně terminologického problému se znakovou sadou, zda někdo umí na WWW-server umístit znak, který by nebyl někde definován v Unicodu?

Taky uvedu jeden odkaz. Na WaSP v článku Webby Awards Validation Woes je doporučení přesně opačné:

If you have the appropriate encoding on the server, please do not add it to your document via the meta element.

Ta citace je trochu vytržená z kontextu:

Encoding mismatches. This problem is popping up more and more now that the W3C's validator has been upgraded. What this means is that the encoding on the server is conflicting with the encoding in the document. If you have the appropriate encoding on the server, please do not add it to your document via the meta element.

Doporučení podle mne vychází z předpokladu, že HTTP hlavičky a dokument identifikují rozdílná kódování (jedno z nich je pak logicky chybné). Pokud se však oba údaje shodují, nevidím v čem by měl být problém. Jen se zkrátka uplatnila mezi sexuology oblíbená metoda "pásek a kšandy".

Problém je v tom, co označuje pojem znak. :-) Samozřejmě, že lze v datech uložit znak, který není v žádné standardní znakové sadě.

Ukladat informaci o kodovani do dokumentu samotneho je IMHO naprosto nekonsistentni, jelikoz na to, abyste META tag objevili, uz musite vedet (alespon priblizne), v jakem kodovani dokument je.

"Slepice, nebo vejce?", rekl by na to klasik.

Kodovani tedy musi uvedeno externe. Pravda, do META tagu ho take muzeme pripsat, ale pokud spravne rozumim specifikaci HTTP, pak ma proxy pravo text prekodovavat a onu externi informaci aktualizovat, aniz by ovsem mela povinnost rozumet vnitrku dokumentu.

Neřekl bych, že je to vytržené z kontextu. I v tom kontextu vyznívá IMHO takto: než riskovat, že v HTTP hlavičce bude něco jiného než v meta elementu, je lepší používat jen jedno. Svým způsobem tu hraje roli i argument o uložení do souboru: pokud v HTTP hlavičce bude kódování správné a v meta elementu chybné, v prohlížeči to nepoznám. A je určitě lepší, pokud v dokumentu nebude nic, než pokud tam bude kódování, které neodpovídá skutečnosti. Proto autor doporučuje používat jen jednu variantu: buď HTTP hlavičku (přednostně) nebo meta element (pokud to nejde).

Na druhou stranu je nutno vzít v úvahu, že jak toto doporučení, tak to od W3C, psali lidé, kteří se nemuseli vyrovnávat se schizmatem ISO 8859-2 vs. Windows 1250.

Myslím, že weby státní správy se také nemusejí zabývat problémem osmibitového kódování, protože stále platí ČSN ISO/IEC 8859-2. :-)

Uvedena norma se jmenuje "Informační technologie - Jedním 8-bitovým bytem kódované soubory grafických znaků - Část 2: Latinská abeceda č. 2".

Já myslel, že u nás je ještě pořád za oficiální považována KOI8CS... :-)

No, tak to sesumirujme.

1. "Do dokumentu" je dobre kvuli ukladani na disk, zo by mohl delat i ten, kdo stranku uklada, ale aktualne to nikdo moc nedela
2. "Do hlavicky" je dobre protoze v tele to komplikuje prekodovavani, kdy se musi sahat "do dokumentu" coz samo o sobe pusobi komplikace a navic muze az vyustit ve zmenu jeho delky coz vyrazne komplikuje situaci (zejmena zadost o ne celou stranku, ale jen cast); krome toho, parsing dokumentu a tedy i teto informace uz podleha informaci o pouzitem kodovani

A ted rozbor. Mozna reseni -

1. ukladace zacnou informaci z hlavicky ukladat (nepravdepodobne)
2. stranky budou jen v UTF, ISO-8859-* nebo ASCII, ktere uz vetsina modernich prohlizecu zvlada cimz zmizi potreba prekodovavani cimz prestane vadit TAG v hlavicce
3. stranky budou jen v UTF cimz zmizi jak potreba prekodovavat tak charset oznacovat, cimz problem jestli tam nebo onam zcela mizi

Osobne bych byl nejradeji pro [3], ale zda se, ze [2] je prijatelna kompromisni volba - pokud budou stranky jen ve vyjmenovanych kodovanich lze jakekoliv prekodovavani "on-demand" hodit pres palubu ...

Takze, pokud uzname realitu sveta (ze kodovani se pri ukladani na disk typicky ztraci) pak za dodrzeni podminky, ze stranky budou v kodovani, ktere je "rozumne" zvolene reseni patrne dobrym kompromisem ...