Hallo,
Das 0-Byte dahinter ist erklärlich, weil PHPs explode() am Punkt schneidet.
ja, richtig, aber ...
Der Punkt ist eingerahmt von 0-Bytes. Eins davon gehört zu ihm, das andere gehört entweder zum vorhergehenden oder nachfolgenden Zeichen, je nach Bytereihenfolge. Doch das ist PHP egal. Es sieht den Punkt und das 0-Byte davor kommt zum ersten Teilstring, das danach kommt zum zweiten Teilstring.
Eben. Der Original-String müsste in ISO-Latin gelesen "1_1_._1_1_._2_0_1_1_" gewesen sein[*], wobei ich mit den Unterstrichen hier die Nullbytes repräsentieren möchte. Trenne ich das nun mit explode() an den Punkten, erhalte ich
[0] "1_1_"
[1] "_1_1_"
[2] "_2_0_1_1_"
Das erste Fragment wird durch intval zu 1 ausgewertet, die anderen beiden zu 0, weil sie nicht mit einer Ziffer beginnen. Man beachte den Hinweis im Handbuch zum Ergebnis:
Strings will most likely return 0 although this depends on the leftmost characters of the string. The common rules of integer casting apply.
There you go. Auch meinen Tests zufolge wird gewöhnlicher Whitespace (Leerzeichen, Tab, Zeilenumbruch) am Stringanfang von intval() ignoriert, ein Null-Zeichen beendet aber das Parsing sofort und das Ergebnis ist 0.
Ciao,
Martin
[*] Wir wissen nicht, wie T-Rex den String ursprünglich gewinnt, vermutlich schneidet er alles vor der ersten Ziffer weg. Sonst stünde vor der ersten '1' ja auch noch ein Nullbyte.
--
Niemand lebt allein von seinen Träumen.
Aber wer träumt, lebt noch.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(