Neplatné znaky ve formuláři

Školení, která pořádám

Pokud uživatel zadá do formuláře znak, který není obsažen v kódové stránce dokumentu, pošle ho Firefox a Opera jako Unicodovou entitu (Internet Explorer pošle u znaků s jednobajtovou reprezentací jejich binární hodnotu, u vícebajtových nedovolí formulář odeslat). Týká se to např. dlouhé pomlčky (–) nebo „typografických uvozovek“, které nejsou v ISO-8859-2. Protože úplně stejný řetězec prohlížeče pošlou i v případě, že uživatel skutečně zadá entitu, tak se s tím nedá nic moc dělat. Podle mě by spíš takový znak vůbec neměly dovolit zadat, ale s tím asi nic nezmůžu.

Zobrazit uživateli místo zadaného znaku jakýsi podivný řetězec je neprofesionální, vyhodit nebo interpretovat všechny entity je neslušné. Nezbývá tedy nic jiného, než používat kódování, které obsahuje všechny běžně dostupné znaky, např. UTF-8.

Jakub Vrána, Výuka, 10.4.2006, diskuse: 12 (nové: 0)

Diskuse

ikona dgx:

Také lze převést entity (ať už jmenné pomocí tabulky nebo unicodové třeba pomocí preg_replace_callback) do ISO-8859-2 pomocí iconv('UTF-8', 'ISO-8859-2//TRANSLIT', $text);

Z té dlouhé pomlčky &ndash nebo &mdash to udělá pomlčku klasickou.

dusoft:

az na to, ze iconv nie je standardom a nie je na vsetkych hostingoch.

skuste radsej nezavislu:
http://sourceforge.net/projects/phputf8

ikona dgx:

This module (iconv) is part of PHP as of PHP 5 thus iconv.dll and php_iconv.dll is not needed anymore

Hever:

nj, ale až v PHP5 ... ve 4řce je nestandartní

tark:

Psát pro PHP4 už nemá smysl...

Mordae:

Na jakemkoli linuxu je primo (pardon) uchylka admina nedat iconv z libc k dispozici v PHP :]

salko:

Hosting, ktorý nemá podporu ICONV nie je hosting, ale iba nejaký Web server s pokusom o PHP.

JPAS:

A proč taky ne? Já používám UTF-8 všude a jsem spokojený.

ikona Jakub Hejda:

Na tento problém jsem také narazil.
A bohužel se nedá vyřešit tím, že budete používat výhradně UTF-8 a na ostatní jazykové sady zapomenete.

Jedná se o odeslání těchto problematických znaků dat emailem.
Typicky - zákazník eshopu napíše do objednávky poznámku, resp. zkopíruje nějaký text do formuláře a problém je tu.

České emaily je myslím nejsprávnější posílat v ISO-8859-2 a né v UTF-8, abychom měli jistotu že se zobrazí všude správná čeština. Takže to budu řešit převodem těchto znaků na jejich alternativy.

Zatím jsem vypozoroval že jde pouze o znaky s ASCII hodnotou
150, 148, 146 a 133
Zapomněl jsem na nějaké?

ikona Jakub Vrána OpenID:

Myslím, že ani u e-mailů by UTF-8 už nemělo dělat žádné problémy.

ikona Jakub Hejda:

No nemělo, ale dělá.
Používám na posílání http://phpmailer.sourceforge.net

A pokud to pošlu v UTF-8, tak lidi s MS Outlook mají problém.
Nechápu proč, ale je to tak..

pojízdná kočka:

I v roce 2010 s tím mají problémy největší české servery, které mají tisíce až desetitisíce komentářů denně, jako Aktuálně, iHned a spol - přestože (bych tipoval, že) používají UTF-8, tak při speciální znaky při uložení převedou na entity a při zobrazování (buď v těle příspěvku nebo jeho názvu) je pak ukazují včetně ampersandu, # a čísla.
'chjo.

Vložit komentář

Používejte diakritiku. Vstup se chápe jako čistý text, ale URL budou převedeny na odkazy a PHP kód uzavřený do <?php ?> bude zvýrazněn. Pokud máte dotaz, který nesouvisí s článkem, zkuste raději diskusi o PHP, zde se odpovědi pravděpodobně nedočkáte.

Jméno: URL:

avatar © 2005-2018 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.