ugrás a tartalomhoz

htmlentites-el mi a gond?

breakline · 2007. Júl. 23. (H), 12.20
Sziasztok!

Szóval egy adott oldalon, a szokásos problémákat elkerülendő, a tinyMCE szerkesztőből érkező adatokban levő éáőúű stb.., tehát magyar karaktereket átkonvertálom html entitásokra, és így is tárolom az egyébként UTF-8 alapú adatbázisban. Ezenfelül UTF-8 minden más is, as far as i know. Eddig működött is minden, de a nyilvános résznél is át kellett konvertálni a keresőből érkező adatokat, mert kölönben pl. é-t keres ott, ahol é van, és így nincs találat. Az alábbi kód pl. a 'lehetséges' szóra az alábbi megfelelőt adja:

$search['value'] = htmlentities($search['value'], ENT_QUOTES, 'UTF-8');
echo htmlspecialchars($search['value']);
//Kiírja lehetséges
Amit én szerettem volna (mellesleg fogalmam sincs miért kell két különböző entitás ugyanarra), az a numerikus verzió, amit ez nem ad vissza, viszont a php manuálban valaki volt kedves egy konvertáló függvényt beírni:

function convert($s){
	$table1 = get_html_translation_table(HTML_ENTITIES, ENT_QUOTES);
	foreach ($table1 as $k=>$v){
		$table1[$k] = "/$v/";
		$c = htmlentities($k,ENT_QUOTES,"UTF-8");
		$table2[$c] = "&#".ord($k).";";
	}
	$s = preg_replace($table1,$table2,$s);
	return $s;
}
$search['value'] = convert(['value']);
echo htmlspecialchars($search['value']);
//Kiírja hogy lehetséges, és így működik is
Akkor a numerikus-t, vagy a karakteres-t kéne használni? És hogyan kerül képbe az UTF-8? ISO-nál ez eddig nem tűnt fel, az én hibám, hogy nem régóta használok teljes egészében UTF-8-at.

üdvözlettel
BL
‹ MYSQL INSERT SQL probléma tárhelyem még felhasználható mérete ›
 ■
1

UTF-8

vbence · 2007. Júl. 23. (H), 12.33
Az UTF-8-nak az lenne a lényege, hogy nem kéne bohóckodni html kódolással. Minek UTF8 adatbázis, ha 8bites karaktereket tárolsz benne? A másik pedig: a böngésző általában a lap kódolásával küldi a postot. Tehát ha ISO-8859-2 lenne a lapod kódolása (ahol a tinymce van), akkor nem lennének &#... -val küldve, sőt, ha UTF8 lenne, akkor normálisan UTF-8 karakterek jönnének.

Ha biztonsági okokból szeretnéd bevitelkor konvertálni a karaktereket, akkor az nem a legjobb megoldás. Igazából nincs is jó megoldás rá, csak framework szinten, ami nincs igazából a PHP-hez.

Egyébbként abban nem bíthatsz, hogy &# lesz az aktuális kódlappal nem megjeleníthető kerakterek kódolása, mert ezt a böngésző csinálja, és ahány böngésző annyi képpen (a Safari pl. nem küld olyan karaktereket, amik nem férnek bele a lap kódolásába, az IE pedig váltogatja a Ӓ és ö stb. formát).
2

félmegoldás

breakline · 2007. Júl. 23. (H), 13.46
Igen, sajnos volt egy ilyen félmegoldás, mivel php alapú _cache lesz használatban (tehát nem html oldalakat cache-el, hanem php tömböket, mivel rekurzív menü- és tartalom kezelés van, tettszőleges szintű ráadásul), ami tömböket tárol, és a _cache file-ok eddig nem voltak képesek utf-8-ra konvertálódni... Most megnéztem a manuált, végülis van megoldás (utf8-encode fileba írás előtt), sajnos kénytelen leszek átírni a szükséges részeket úgy néz ki.... Végülis jobb az UTF-8, mert csak feleannyit szívok, bár szép lassan azért kiegyenlítődik.:)

üdv
BL
3

Megoldás: entity_encoding:"raw"

Csiszár Attila · 2007. Júl. 24. (K), 13.14
Tehát ha ISO-8859-2 lenne a lapod kódolása (ahol a tinymce van), akkor nem lennének &#... -val küldve, sőt, ha UTF8 lenne, akkor normálisan UTF-8 karakterek jönnének.


Ez nem teljesen igaz. Épp ma futottam én is bele a fenti problémába, és hiába használok az oldalon UTF-8-at az istenért sem úgy küldte a mysql-nek az adatokat, átírta html-entitásokra a tinyMCE az ékezetes karaktereket.

Viszont szerencsére van egy egyszerű megoldás a fenti nyűgre, a tiniMCE beállításainál a következőt kell megadni:

tinyMCE.init({
	entity_encoding:"raw"
)};
És láss csodát, működik!