strtolwer merkwürdiges Verhalten in verschiedenen Umgebungen mit Multibyte-Zeichen

Question

Es gibt 5 Maschinen.

Mine ist ein win10 64bit, php 5.6, production server ist neueste debian 64bit mit php 5.6.

Beide Maschinen führen dasselbe Skript mit den gleichen Ergebnissen aus. Das Seltsame ist der Unterschied zwischen dem Ausführen des Skripts aus dem Web und der Befehlszeile.

Der Code:

$string = chr(194) . chr(160); 
var_dump($string); 
var_dump(bin2hex($string)); 
var_dump(bin2hex(strtolower($string))); 
var_dump(bin2hex(mb_strtolower($string))); 

Die Ausgabe von web:

string(2) " " 
string(4) "c2a0" 
string(4) "c2a0" 
string(4) "c2a0" 

Seltsam ist, dass beide Maschinen in der Befehlszeile das gleiche tun:

string(2) " " 
string(4) "c2a0" 
string(4) "e2a0" <-- Listen this! 
string(4) "c2a0" 

aus irgendeinem Grunde , strtolower hat das erste Byte des UTF8-Zeichens geändert.

Mein Kollege hat eine Himbeer 32 Bit, mit PHP7, ein weiterer Server mit 64bit CentOs mit PHP7, und es gibt noch eine Maschine CentOs 64bit PHP 5.3.3.

Aber diese Maschinen Dumps überall c2a0. Natürlich verwenden wir überall UTF8-Zeichen für alles.

Was kann das verursachen?

EDIT:

Auf Produktion: setlocale(LC_ALL,0);

Befehlszeile:

LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C 

Von web:

string(1) "C" 

Auf meinem localhost Maschine:

Von web:

string(1) "C" 

Befehlszeile:

LC_COLLATE=C;LC_CTYPE=Hungarian_Hungary.1250;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C 

Answer 1

Sie setlocale Funktion vor der Verwendung String-Funktionen auf Multibyte Strings verwenden sollten.