Rejtvényfejtőknek: Hol a hiba a képen?

Kódrészlet következik (pontosabban gdb backtrace), a kérdés: látunk-e valami furcsaságot: 


#53166 0x0900000007c389c4 in determine_charset () from /usr/local/libexec64/apache2/libphp7.so
#53167 0x0900000007c3ad18 in php_escape_html_entities_ex () from /usr/local/libexec64/apache2/libphp7.so
#53168 0x0900000007c3a920 in php_escape_html_entities () from /usr/local/libexec64/apache2/libphp7.so
#53169 0x0900000007c402e4 in php_verror () from /usr/local/libexec64/apache2/libphp7.so
#53170 0x0900000007c411e4 in php_error_docref0 () from /usr/local/libexec64/apache2/libphp7.so
#53171 0x0900000007c389c4 in determine_charset () from /usr/local/libexec64/apache2/libphp7.so

Annyit segítek, hogy ez PHP7.1.9, AIX6.1 platform (szerk: vagy Debian GNU/Linux 8), és épp egy hibát igyekszik kezelni a derék szoftver.

Szerk: úgy látom, valami xdebug is van a történetben, és igyekszik jó kiscserkész módjára segíteni...

Szerk: a következő kóddal is ki lehet provokálni hibát, Apache segítsége nélkül (vigyázat, csak erős idegzetűeknek): 


#!/usr/local/bin/php
<?php
    ini_set('html_errors', true);
    ini_set('default_charset', 'ISO-8859-2');

    printf ("before getfilecontent\n");
    file_get_contents ('no/suchfile');
    printf ("after getfilecontent\n");
?>

Szerk:
https://bugs.php.net/bug.php?id=75236

Szerk:
állítólag fixed in 7.1.11
Mindjárt kipróbálom.

( persicsb | 2017. 09. 20., sze – 15:01 )

Szép dolog a kölcsönös rekurzió.

( Mcsiv v | 2017. 09. 21., cs – 04:34 )

és már fixed is. Tempósak a srácok ;)

// Happy debugging, suckers
#define true (rand() > 10)

( NevemTeve | 2017. 09. 21., cs – 10:52 )

Kezdem lehetségesnek hinni, hogy szegény jó PHP történelmileg támogat olyan multibájtos kódolásokat, amik nem ASCII-kompatibilisek (vagyis előfordulhat olyan 00..07f karakter, ami nem ASCII-kód, hanem egy szekvencia része).

Ha ez igaz, akkor az egész dolog menthetetlen. Ha nem igaz, akkor szvsz egy nemlétező probléma megoldásán dolgoznak gőzerővel.

Kieg: Az egyik hozzászóló arra emlékeztet, hogy az UTF-16 sem ASCII-kompatibilis. Ez mondjuk igaz, de ha eddig ellen tudtak állni az UTF-16-nak, szerintem most már nem is érdemes belemenni.

https://bugs.php.net/bug.php?id=75236
https://bugs.php.net/bug.php?id=47494
http://web.axelero.hu/lzsiga/ekezet.html#Q0061

Akkor jó, megnyugtattál.

Kivéve, ha mondjuk jön egy üzenet az Oracle szervertől, ami a derék PHP szeretne beleszúrkálni a standard outputba. Ekkor a következő problémák adódnak.

1. fax se tudja, milyen kódolásban jön az üzenet az Ora-tól. Ha elég pancser az üzemeltetés, valami magyarra félrefordított szöveg jön NLS_LANG-függő encodingban (pl EE8ISO8859P2, AL32UTF8, etc)

2. fax se tudja, milyen kódolásban kellene kimenjen az üzenet az outputba.

3. az üzenetben bőven lehet < > & ' "

4. vagy akár olyasmi, ami a küldő szerint normál karakter, a fogadó szerint viszont értelmetlen (vagy káros) bináris szekvencia

5. a PHP nem ismer olyat, hogy 'ISO-8859-2': ismeretlen vad exotikum, százmillió embert ha érint...

Namostan az első kérdésen úgy emelkedik felül a PHP, hogy a default_charset-et alapértelmezi, ez eléggé megkérdőjelezhető, szvsz; a 2-4 pontokon úgy, hogy a htmlentities-t hívja, ami ugyebár az 5. pont miatt problémás

Az én javaslatom az, hogy ha csak ASCII-kompatibilis kódolásokkal akarunk dologzni, akkor csak a htmlspecialchars-t használjuk (annak is csak a konvertáló funkcionalitását, az UTF8-ellenőrzés nélkül); ha viszont nem ASCII-kompatibilis kódolásokra is fel akarunk készülni, akkor a legjobb, ha simán kiírjuk, hogy 'SOMETHING IS WRONG WITH SOMETHING, GO AWAY'

1. Olyan kódolásban, ahogy azt beállítod a kapcsolódáskor. http://php.net/manual/en/function.oci-connect.php.
2. Ez a specifikációtól függ.
3. Igen, és?
4. Nana, ha a küldőről tudod, milyen kódolásban küld (és tudod, mert beállíthatod a fogadó oldalán), akkor nincs olyan, hogy a fogadó szerint értelmetlen.
5. Az ilyen szarok miatt nem használunk PHP-t. Egy aluldefiniált, fos platform. De szophatsz vele nyugodtan.

"Az én javaslatom az, hogy ha csak ASCII-kompatibilis kódolásokkal akarunk dologzni, akkor csak a htmlspecialchars-t használjuk (annak is csak a konvertáló funkcionalitását, az UTF8-ellenőrzés nélkül); ha viszont nem ASCII-kompatibilis kódolásokra is fel akarunk készülni, akkor a legjobb, ha simán kiírjuk, hogy 'SOMETHING IS WRONG WITH SOMETHING, GO AWAY'"

A legjobb meg nem úgy tekinteni karakterekre, mint byte-ok sorozata, amikor dolgozol velük. Vannak bytesorozatok, amelyekből karakterkódolások karakterek sorozatát készítik, illetve karakterek sorozatából bytesorozatokat készítenek.
Amint az ember meg tudja lépni ezt az absztrakciót, hogy különítsük el a karaktereket és a karakterkódolásokat, akkor az élete könnyű lesz.
A legelterjedtebb karakterkészlet az Unicode. Ha egy programozási platform nem támogatja az Unicode karaktereket, amikor karakterláncokat használ, az eleve felejtős.
Ha a PHP nem ilyen, akkor a PHP egy fos platform és ne használd. Ha meg használod, akkor ne csodálkozz. Szívatod magad, majd csodálkozol, hogy szívsz.

> Az ilyen szarok miatt nem használunk PHP-t.

Ha ezzel kezdted volna, gyorsabban lezárhattuk volna a beszélgetést! Már megyek is a főnökhöz, mondom neki, hogy lecsaphatjuk a rendszert, megállhat a ****gyártás, random troll az interneten megmondta a tutiságot.

Szerk: de valóban, lehetett volna még konkrétabb az előző hozzászólásom, pl:

... mondjuk jön egy üzenet az Oracle szervertől, ami a derék PHP szeretne beleszúrkálni a standard outputba. Amikor a PHP illetékes hibakiíró függvénye fut, akkor a következő problémái adódnak:

1. nem tudja, hogy milyen kódolásban jön az üzenet az Ora-tól. Igazából azt sem tudja, hogy az üzenet az Oracle-tól jött. Azt tudja, hogy itt egy byte-sorozat, ami valamiféle hibaüzenet valamilyen kódolásban.
...

A hibaüzenet előállítójának kell gondoskodnia arról, hogy amikor a kiíró felé kerül a hibaüzenet, akkor UTF-8 kódolásban legyen.

Amikor Oracle műveletet hajtasz végre, tudod, hogy milyen kódolásban jön az üzenet az Oracle-től, hiszen ez a kapcsolat paramétereinek a része.
Amikor az Oracle hibaüzenetét elkapod, akkor fogod, és az ismert kódolásról UTF-8 kódolásra alakítod át, ls ezzel már tud mit kezdeni az output előállítója.

Itt valahogy azt sejtem, hogy nagyon fel vannak keverve a felelősségi körök.

Az output előállítójának legyen az a contractja, hogy mindenféle kiírandó üzenetet ő UTF-8 kódolásban vár. Neki a kapott bytesorozatról az a feltételezése kell legyen, hogy UTF-8 kódolásban van a kapott bytesorozat. Az, hogy a kimeneten mi lesz, az más kérdés.

Aki pedig a hibaüzenet-kiírónak szeretne hibaüzenetet küldeni, kötelessége azt UTF-8 kódolással elküldenie a hibaüzenet-kiíró felé.
Így aki az Oracle-lel kommunikál, és onnan hibaüzenetet kap, kötelessége azt UTF-8-ra alakítania. Az a fél, aki az Oracle-lel kommunikál, nem tudja, hogy milyen kódolásban kap az Oracle-től hibaüzenetet? Az régen rossz, hiszen az Oracle-lel kommunikáló kódnak felelőssége (és csak neki felelőssége) tudnia azt, hogy éppen milyen kódolással kap választ az Oracle-től.

Nem nagyon haladunk előre, igaz?
https://hup.hu/node/148889#comment-2010410
Nem fogunk 'Adj Uramisten, de rögtön!' alapon UTF8-ra váltani. (Persze Fecó hobbiprogramjában lehetne ilyesmiket csinálni, hiszen ott az sem gond, ha működik, de az sem, ha nem működik. Viszont Fecó hobbiprogramjáért nem is fizetnek. Szóval valamit valamiért.)

Nyugodtan szopasd magad, és a workaroundokra workaroundokkal, és ne normális rendberakással válaszolj, úgy biztos kevésbé lesz törékeny a kódbázis az évek folyamán. Ez az igazán előremutató megoldás.
Ahelyett, hogy azokat a komponenseket, amelyek bajosak, leválasztanád, és egy wrapperrel megoldanád, hogy UTF-8-at köpjön ki magából, csak szenvedsz.

Miért akarnád ezt így használni? Ja, önszopatásból. Értelek.

htmlspecialchars($str, ENT_QUOTES, 'UTF-8') és előtte biztosítanod kell, hogy $str UTF-8 kódolású és kész.

A htmlspecialchars nem ismeri ezt a kódolást. ÉS AKKOR MI VAN?
Olyan bemenettel kell használni, amit ismer.