PHP charset not supported

7-es PHP-t fordítok, ami szépen működik, de pl a htmlentities() parancs esetén, ha a paraméter egy ISO-8859-2 kódolású string, a következő hibaüzenetet adja:


PHP Warning:  htmlentities(): charset `ISO-8859-2' not supported, assuming utf-8

Ilyenkor egy üres stringet ad eredményül, ami elég kellemetlen, ha például e-mail fejléceket akarok dekódolni, ahol sokféle karakterkészlettel is érkezhetnek levelek.
Nem segít a "default_charset" ini állítása sem.
Több általam fordított PHP verzióval is teszteltem, a jelenség ugyanaz, de a Debian gyári 7.0-ás PHP-ja is ugyanezt az eredményt adja.
Hogyan tudom úgy lefordítani a PHP-t, hogy kezelje az ISO-8859-2, windows-1250 és egyéb gyakori karakterkészleteket is? Vagy milyen csomag telepítésére lehet szükség, hogy jól működjenek ezek a karakterek PHP alól?

Hozzászólások

./configure --with-iconv=/usr/local|grep iconv

???

-------------------------
Hivatásos pitiáner
neut @

Elsokent iconvval atalakitod utf-8-ba, utana mar fut rajta a htmlentities.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ez nagyon szép, de mi a fészkes fenét csináljak, ha az adatbázisban iso8859-2 karakterek tömkelege van? Az azért elég ezoterikus megoldás lenne, hogy befelé convert, kifelé convert... Bár, ha nincs más...

(merthogy a htmlentities nem ismeri a ...-2-t, csak az ...-1-et)

----------
Registered Linux user #46079

Az adatbázist teljesen te kontrollálod? Ha igen, akkor két lépés kell neked:

  1. Az adatbázis tartalmát ISO 8859-2-ről átalakítod Unicode-dá, UTF-8 kódolással.
  2. Az adatbáziskapcsolatot átparaméterezed, hogy UTF-8 kódolást használjon.

Ha ezt nem teheted meg, és az adatbázisnak kötelezően ISO 8859-2-ben kell lennie, akkor nincs más, mint az ide-oda konverzió, bizony.

Ja, és ezért nem használunk PHP-t. :)

Mitől ezoterikus egy iconv? Ráadásul a htmlentities helyett, ha jól értem, mivel arra már nem lesz szükség.

A "befelé convert, kifelé convert" részt sem egészen értem; mármint, az iconv tudja mindkét irányt, de a htmlentities csak az egyiket, szóval ha befelé is kell tolni az adatbázisba, ismételten az iconv-ot keresed, és nem a htmlentities-t.

Ezzel azert vigyazva!

En mondjuk nem szeretnem, ha a < megmaradna, es a htmlentities nelkul bennmaradna.. &lt;, aztan ennyi..

Es a tobbi foglalt html/xml karakterrel ugyanigy.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A probléma nem PHP függő. Magát az adatbázist egy olyan őskori alkalmazás használja, ami nem ismeri az UTF8-at. Hiába jelent meg újabb változat, ezzel nem foglalkoztak. Így aztán marad az oda-vissza. Még az lehet egy megoldás, ha java applet-twel kísérletezünk...

----------
Registered Linux user #46079

A htmlentititiesnek igen.

 

A legjobban azt teszed, ha szöveggel akarsz dolgozni, hogy minden bejövő információt Unicode-ra kódolsz, mondjuk UTF-8-cal (Unicode-ban mindegyik ISO 8859-* karaktert reprezentálni lehet, az UTF-8 meg át tudja alakítani neked bytesorozattá), azon dolgozol, majd ha szükséges, az outputra küldöd azzal a kódolással, amivel kell.
Például ha ez egy szűrő, akkor az eredeti bejövő kódolással.

Az más kérdés, hogy fel tudod-e mindig jól ismerni, hogy mi a karakterkészlete és kódolása a bejövő adatnak. Főleg úgy, ha nincs metaadatod róla.

Az e-mail fejlécek világa kicsit érdekes, ugyanis:

  1. Alapesetben az e-mail 7-bites ASCII karakterkészletet és kódolást használ.
  2. A MIME (pontosabban annak az RFC 2047-ben definiált része) megengedi, hogy olyan olyan karakterkészletet használj, ami identikus leképezéssel 8 bitre kódol minden karaktert. Ilyenből persze sok van, az ISO 8859-es szabványsorozat ilyen, a Windows 1250-1258-as sorozat stb. Szóval itt létezik egy metaadat, hogy milyen karakterkészlet és milyen kódolás van (mivel identikus a leképezés, sokan keverik ezt a két fogalmat).
  3. Az RFC 6532 óta használható az Unicode karakterkészlet UTF-8 kódolása e-mail fejlécben. Ekkor viszont RFC 6531 szerinti SMTPUTF8 kiterjesztést kell támogatnia a mail szervernek. A fejlécek nevei továbbra is csak az ASCII karakterkészletből kerülhetnek ki, de a fejlécek tartalma lehet UTF-8 kódolt Unicode karaktersorozat. Viszont ezt akkor tudod csak felismerni, ha tudod valahogy az üzenet MIME típusát, ennek message/globalnak kell lennie. Magában az üzenetben sehol nincs metaadat arról, hogy UTF-8-at tartalmazna, azt a kliens a MAIL parancs elküldésekor jelzi a szervernek, hogy SMPTUTF8 extensiont használ.

Persze. A befelé-kifelé azt takarja, hogy az adatbázisban latin-2 karakteres szavak vannak, a képernyőn viszont már utf-8-nak kell megjelennie.

Ettől ezoterikus :-)

----------
Registered Linux user #46079

Szerkesztve: 2019. 10. 30., sze - 10:11

A PHP semmilyen verziója sem támogatja az ISO-8859-2 -et [ebben a kontextusban]; `htmlentities` helyett a `htmlspecialchars` ajánlatos, ISO-8859-1 paraméterrel. (Ami valójában csak annyit jelent, hogy 'a senki által sem kért, bosszantásképpen belerakott utf8-validság-ellenőrzést ne csináld'.)

Szerk.: ezt pedig érdemes lenne nemcsak elovasni, hanem szóról szóra meg is tanulni: http://lzsiga.users.sourceforge.net/ekezet.html