header content-type utf-8 - proč?

Neas:
Akych vela prikladov? Doteraz som asi ziadne nevydel, a ano je to zbytocne, ak je to uvedene v html.

Reaguji na Nease:
Načítáš-li soubor něčím, co nerozebírá HTML (třeba XMLHttpRequest), informace z <meta> značky se ignoruje. (Zrovna u XHR je UTF-8 výchozí.)
Nastavuješ-li kódování v HTTP hlavičce, můžeš HTML značku vynechat.
Kdybys používal BOM, můžeš vynechat obojí.

Chamurappi má pravdu, ještě je dobré nastavit stené kódování souboru (a myslím, že u souborů UTF-8 nefungují PHP headery)

Colek:
Pokud vím, tak PHP headery nebudou v UTF-8 fungovat pouze v případě, že UTF-8 soubor bude začínat BOMem a PHP při pokusu poslat header zjistí že už se vypsala nějaká data.

Chamurappi:
BOM v žádném případě nepoužívat. Webkitové prohlížeče obsahují bug, který nikdo neřeší.
Ukázka: https://code.google.com/p/chromium/issues/detail?id=71224 (povšimněte si data příspěvku - dodnes to není vyřešeno)

Zabralo mi asi dva dny, než jsem přišel na to, že PsPad mi tam po reinstalaci počítače začal tyto znaky přidávat. Stránku to špatně parsovalo stejně, jak uvádím výše.

Nedávno mi to udělal znova a pak špatně fungovalo jQuery. Opět půl den v ...

actimel:
Ten bug neobsahuje ani funkční testcase a podle popisu se mi ho nepodařilo zopakovat, takže se nedivím, že to nikdo neřeší. Můžeš ukázat stránku, kde se popisovaný problém projevuje?

Reaguji na actimela:
Podle obrázků bych řekl, že stěžovatel posílal několik BOMů, což je pochopitelně chyba na jeho straně, prohlížeč za to nemůže, není, co opravovat.
S jedním BOMem problémy nejsou. Nebojím se ho používat.

Já měl stejný problém. Způsobil mi to PsPad.

Detailům nerozumím. Jen jsem zjistil, že jsem nebyl zdaleka sám, kdo měl nento problém. Nepodařilo se mi zjistit, zda-li za to pokaždé mohl PsPad.

Ale někde je velká chyba. Pravděpodobně na obou stranách - jak u vývojáře pspadu, tak u vývojářů prohlížeče. Proč by prázdný znak na začátku měl způsobit takovéto chování? A pokud PsPad skutečně vkládá tyto řídící znaky špatně nebo vícekrát, tak je to zásadní chyba jeho autora, se kterým jsem neměl příliš produktivní diskuzi. Přecházím stejně dneškem na netbeans, takže mi to už je celkem jedno. Ale, někdo, kdo je na danou problematiku větší odborník, by to měl zkontrolovat a napsat mu, pokud to je skutečně tak, že jsou data vkládána špatně. Mě to stálo dva dny. A stane se to určitě dalším lidem.

actimel:
V PsPadu se dá vkládání BOM vypnout, tím imho odpovědnost jeho autora končí.
Představte si, že máte např. soubor db_connect.php:
a potom soubor index.php:
Výsledkem jsou samozřejmě dva BOMy na začátku výstupu, ale s tím přece nemá nic společného editor; zrovna tak byste mohl obviňovat Apache (že neodstraňuje duplicitní BOMy) nebo PHP (že nevyhazuje BOM z includ.souborů).

Tori:
Ano, toto vskutku bude ta příčina, proč je jich víc. Díky. Minimálně by ale podle mého názoru mělo být výchozím nastavením nevkládat řídíci znak. Určitě nejsem sám, kdo problematice natolik nerozumí, aby ihned věděl, kde hledat příčinu.

Ano, příspěvek na odkazu to pěkně popisuje. Ale všechny takovéto články mají trošku trhlinu. Když se snaží člověk který vůbec neví, že nějaký BOM exituje (já) najít, proč se prohlížeč chová absolutně ztřeštěně, dost těžko se to hledá. Co takový člověk bude vyhledávat? Výslednou chybu vykreslení. Ty tam vesměs chybí. Proto jsem to hledal tak dlouho. (s googlem se bavím jen anglicky)

actimel:
„Co takový člověk bude vyhledávat?“
Trebárs si zobrazí si zdrojový kód stránky a nájde v kóde niečo, čo tam nepatrí.

Ale to je to... chrome to třeba ani neukáže. Až v developer tools v záložce elements je vidět, že je něco špatně. Zase takový vůl nejsem. A asi jsi nepochopil cop jsem myslel tou větou, kterou cituješ: co bude vyhledávat na googlu.

actimel:
„Co takový člověk bude vyhledávat? Výslednou chybu vykreslení. Ty tam vesměs chybí.“
Ano, pak by ale neměl najít informace o BOMu, ale informace o té chybě, kde by bylo i uvedeno, že příčinou může být BOM.
Například by řešil chybovou hlášku headers already sent by a dostal se na odkázaný záznam naší PHP FAQ, kde se dostane k té informaci o BOMu.

Ano, ale i takto jsem pročetl spousty diskuzí a většinou to nebylo ono. Neříkám, že je něco v nepořádku, jen mě zarazilo, jak málo jsem toho k této problematice našel.

A být toho, že jsem tady napsal, tak bych jednak nevěděl, že těch znaků bylo více a hlavně proč. Toto mě nenapadlo. Možná některým z vás připadám jako největší hlupák, mi to pomohlo. A třeba to i pomůže někomu dalšímu? Díky.

actimel:
„Když se snaží člověk který vůbec neví, že nějaký BOM exituje“
To potom není chyba editoru, programovacího jazyka, ani prohlížeče.

„Ano, ale i takto jsem pročetl spousty diskuzí a většinou to nebylo ono.“
Kdybys použil český validátor, tak ten by tě upozornil na bludný BOM.

Tenhle jsem třeba neznal. Proč tady každý předpokládá jednání druhého člověka na základě svých vědomostí?

actimel89:
„Tenhle jsem třeba neznal. Proč tady každý předpokládá jednání druhého člověka na základě svých vědomostí?“

Pretože ak chceš programovať je určité minimum ktoré by si mal vedieť a poznať český validátor patrí k vedomostiam niekde na úrovni HTML a CSS!

Myslíš spíše kódovat, že?

Asi jo... já ale kvůli studiu 5 let nestačil sledovat dění... jen nevím, poč je tak zásadní, aby byl český ;) Vím, že W3C má trhliny...

Vědět o českém validátoru není tak zásadní, ale pro zjištění vícenásobného BOMu může sehrát zásadní roli. Ne každý si všimne prázdného řádku nebo dalších projevů, který může nesprávně umístěný BOM způsobit. On by možná mohl být užitečný nějaký univerzálnější nástroj, kterému by se předhodila webová stránka a on by vypsal všechny potencionální problémy, které tam jsou včetně interpretace chyb PHP s návrhem řešení.

Když se hledá neznámá příčina problému, tak je asi nejrychlejší zeptat se zkušenějších na diskusi.

actimel89:
„Myslíš spíše kódovat, že?“
vyznelo to tak že používaš aj php, preto som na základe obecne známej formulky "PHP is used as the server-side programming language" odvodil výraz programovať.. kľudne ale použival kódovať, skriptovať, tancovať, je to úplne jedno pokiaľ vieš o čom som písal..

actimel89:
„já ale kvůli studiu 5 let nestačil sledovat dění...“
stáva sa, preto sú tu také fóra kde sa môžeš spýtať, ale nemal by si sa čudovať že ľudia čo tu odpovedajú odčakávajú že niektoré vieš, alebo si ich na základe ich nápovedy naštuduješ.

actimel89:
„jen nevím, poč je tak zásadní, aby byl český“
vzhľadom na kvalitu w3c validatora / českého validatora a fakt že píšeš česky mi to príde celkom logické ;)

Reaguji na actimela:
„Ale někde je velká chyba. Pravděpodobně na obou stranách - jak u vývojáře pspadu, tak u vývojářů prohlížeče.“
Já bych spíš řekl, že v tomto případě je chyba především na straně PHP, které neumí soubory s BOMem korektně includovat. Dovedu si představit jen zanedbatelně málo situací, kdy by se opravdu hodil include se zachováním BOMů.

„Proč by prázdný znak na začátku měl způsobit takovéto chování?“
On to ale není prázdný znak, je to neplatný znak (v případě, že není jednou úplně na začátku souboru, tam smysl má). Prohlížeč nemůže předpokládat, že neplatný znak je mezera… to by bylo špatně.

„Asi jo... já ale kvůli studiu 5 let nestačil sledovat dění...“
To tě neomlouvá, český validátor jsem spustil v únoru 2007 :-)
Nacházet BOM v tu chvíli tedy ještě neuměl, hlavní motivací bylo definitivně zbořit mýty o XHTML.

Dávám ti za pravdu, že zjistit příčinu tohoto problému není úplně snadné. Na rozdíl od donnyho bych si netroufal tvrdit, že znalost českého validátoru patří mezi základní vědomosti.


Reaguji na Davexe:
„On by možná mohl být byl užitečný nějaký univerzálnější nástroj, kterému by se předhodila webová stránka a on by vypsal všechny potencionální problémy“
Jo, to by bylo pěkné. Už jsem mnohokrát uvažoval, že bych něco takového vytvořil, ale byl to vždy takový mlhavý nápad, protože jsem si nikdy nedal dohromady, co všechno by se mělo kontrolovat. Kdyby byl ten nástroj příliš zevrubný, hrozilo by, že kolem něj vyroste podobný kult jako kolem validity a SEO blábolátorů.

Já se tady v podstatě na nic neptal. Pro svou práci BOM nepotřebuji. Na to toto téma jsem narazil náhodou a nesouviselo to s mým řešením problému s BOMem. A vzhledem k problémům, které mi to způsobilo jsem to tady napsal, aby Chamurappiho příspěvek někoho nepřivedl do podobných pekel, jako jsem se dostal já. Jsem rád, že to bylo rozebráno a uvedeno na pravou míru. A až na to tady někdo narazí, bude alespoň mít větší přehled.

Jinak se pohybuju spíše na stackOverflow a anglických fórech a stránkách. Když jsem měl tyhle problémy, bylo to poprvé, kdy jsem tam musel položit otázku, vždy jsem si vše potřebné našel, buď tam nebo jinde. A právě proto mě to asi nutí z toho dělat takovou vědu. Možná jsem ten poslední člověk na světě, co to neví ... ale nemyslím si to.

Chamurappi:
„SEO blábolátorů.“
Dávno som sa v práci tak dobre nezasmial :)

Chamurappi:
„Já bych spíš řekl, že v tomto případě je chyba především na straně PHP, které neumí soubory s BOMem korektně includovat.“
Ono PHP už asi devět let umí BOM ignorovat (nebo-li neposílat do výstupu), ale byla to nenápadná volba při kompilaci, takže to nikdo nepoužíval. Od PHP 5.4 už je to standardní součást, která se ale musí zapnout volbou zend.multibyte = On, takže to asi zase nikdo nebude používat.