ARCHIV

A nebylo by lepší opatchovat interpret PHP, aby si poradil s BOM?

Určitě nebylo. Protože PHP může zasahovat pouze do oddílů určených počáteční a koncovou značkou.

Opatchováním byste musel začít zasahovat do souboru v oblasti, který PHP nepřísluší.

Mimochodem, PHP nemá s BOM sebemenší problém, zpracovává jej naprosto korektně. Jako každou sekvenci bajtů, která není mezi počáteční a koncovou značkou pustí nezměněně na výstup.

Můžete to dokonce záměrně využít a v některých případech může být zaslání BOM znaku záměrem.

Dokonce nemusí nastat ani warning s již odeslanými hlavičkami. Stačí mít nastavený v PHP konfiguraci output_buffer na hodnotu vyšší nebo rovno třem bajtům a pak žádný warning nenastane ani s BOM znakem a hlavičky budou korektně odeslány. Stejně tak nenastane žádný warning, pokud nenastavujete v PHP žádné hlavičky, tedy nepoužíváte funkci header() nebo setcookie().

Důvodem, proč nastává warning je HTTP protokol. HTTP protokol, který přenáší data mezi web browserem (obecně user agentem) a webovým serverem vyžaduje aby byly nejdříve odeslány hlavičky a pak data. Odešlete-li přes PHP jakákoli data, pak již nejdou hlavičky odeslat. Data jsou v PHP odeslána prvním výstupem (tedy i znakem BOM, je-li), pokud tento výstup není bufferovaný – pak data jsou odeslána až po naplnění bufferu.

Na úvod len toľko, že pred rokmi som mal ten istý problém a vyriešil som ho používaním vhodne nastaveného editora a teraz k veci:

Ak tomu správne chápem, BOM je na to, aby aplikácia alebo skôr spracovateľ vstupu vedel, že sa jedná o UTF kódovanie bez toho, aby ho musel nejako detekovať. Je pravda, že PHP s tým vlastne problém nemá. Lenže ak to prekáža, tak to nejaký článok reťazca nevie správne spracovať. Ak je to protokol HTTP, tak je chyba v ňom a treba opraviť ten. Ideálny prípad je tieto znaky vôbec na výstup neposielať alebo ich normou úplne zrušiť. Každý rozuný editor vie, že tieto BOM robia len problémy a preto ich nepoužíva a radšej kódovanie detekuje. Ďalšia vec je, keďže sú to "skryté" znaky, nie každého napadne o čo sa jedná, ak má problém s presmerovaním. K týmto znakom by sa teda malo správať inak. Buď oznámiť BOM na vstupe a teda používateľ bude vedieť čo je za problém alebo ho rovno ignorovať. Samozrejme, prikláňam sa k druhej možnosti.

No a k zdrojáku na odstraňovanie BOM:
Zdroják je síce fajn, ale zbytočnosť. Každý, kto sa programovaniu venuje aspoň v takej miere, že počíta s tým, že programovať bude aj naďalej sa na zdroják vykašle a stiahne si poriadny editor, prípadne si správne nastaví ten svoj. Ak sa jeho editor nastaviť nedá, tak ten editor na programovanie nie je vhodný.

Ako som už napísal, s týmto problémom som sa už pred rokmi stretol, nejako som to vyriešil (asi som si nastavil editor) a odvtedy neviem čo je to problém s BOM. A to som už skúšal nejeden editor, ktorý som ani nenastavoval (prešiel som tuším z Dreamweaver, ktorý bolo treba nastaviť, na PSPad a neskôr k NetBeans).

Teraz ma napadlo na čo je ten zdroják dobrý. Ono je to vlastne na to, že práca je rozrobená a nie je to ako opraviť do funkčného stavu. Ale to skutočne neexistuje na to nástroj? Priznám sa, že ako som odstránil BOMy sa už nepamätám.

HTTP nemá žádný problém s BOM znakem. Všechny články řetězce jsou v pohodě vůči BOM znaku.

Jediný problém má programátor, který v některých případech je zaskočen tím, že je BOM znak zpracován a podle všech korektních pravidel poslán všemi řetězci jako výstup se všemi důsledky. Programátorovi se to občas nehodí, protože zahájením výstupu přes PHP skript -> PHPinterpretr -> HTTP protokol -> webový browser (nebo obecně user agent) má za následek také zaslání všech hlaviček HTTP protokolu a ukončení možnosti jejich změny.

Všechny články řetězce fungují korektně a všechny umějí bez problémů zpracovat BOM znak jasně určeným způsobem, viz potřebné normy, RFC, atd. atd. V žádném článku řetězce není problém, nic není potřeba měnit.

Řeknu to analogií: Když si programátor nejdříve smaže soubor a pak si vzpomene, že by z toho souboru chtěl přečíst nějaká data – všechny řetězce, tedy API -> operační systém -> filesystém driver -> diskový driver pracují v pohodě, perfektně, bez chyby a nic na nich není potřeba měnit. Pouze programátor je idiot, že udělal nesprávné pořadí operací a těžko může čekat, že ze souboru, který neexistuje, bude číst.

A tak je to i se znakem BOM. PHP se (při vypnutém bufferu) chová tak, že zasláním výstupu – kterým je i neviditelný znak BOM – se odešlou i HTTP hlavičky a zablokují se proti změně. Tedy je to pouze problém programátora. Pokud nepotřebujete měnit HTTP hlavičky, můžete klidně psát PHP skripty s BOM znaky a žádného problému se nenadějete.

Miloslav Ponkrác

Možná pro vysvětlení problému. Vlastní BOM znak není problém. Úplně stejná situace nastane, když bude na začátku jakýkoli znak či řetězec. Například řetězec s názvem naší zlodějské strany "ODS" způsobí přesně stejné důsledky jako BOM znak – nemlich a do puntíku ty samé, protože to co způsobuje problém jsou jakékoli znaky a řetězce před začátkem PHP skriptu. Nikoli BOM znak.