Wenn eine Webanwendung UTF-8-konform ist, sind keine weiteren Maßnahmen erforderlich. Für Anwendungen, die auf Pfade angewiesen sind, die nicht UTF-8-kodiert sind, muss eine explizite INI-Direktive gesetzt werden. Die Prüfung der INI-Einstellungen für die Kodierung hängt von der Reihenfolge im Kern ab:
Es wurden mehrere Funktionen zur Handhabung von Codepages eingeführt:
Diese Funktionen sind threadsicher.
Die Codepage für die Konsolenausgabe wird abhängig von der intern in PHP verwendeten Kodierung festgelegt. Je nach konkreter OEM-Codepage des Systems kann die sichtbare Ausgabe korrekt sein oder nicht. Zum Beispiel wird die Ausgabe in der standardmäßigen cmd.exe und auf einem System mit der OEM-Codepage 437 in den Codepages 1251, 1252, 1253 und einigen anderen korrekt angezeigt, wenn UTF-8 verwendet wird. Auf dem gleichen System werden Zeichen in Codepages wie 20932 wahrscheinlich nicht korrekt angezeigt. Dies hängt ab von den jeweiligen Systemregel für die Codepage, der Kompatibilität der Schriftart und dem verwendeten Konsolenprogramm. PHP konfiguriert die Codepage der Konsole automatisch gemäß den Kodierungsregeln der php.ini. In manchen Fällen kann es das Ergebnis verbessern, wenn eine andere Konsole verwendet wird als cmd.exe selbst.
Es ist jedoch zu beachten, dass ein Wechsel der Codepage zur Laufzeit nach dem Start der Anfrage unerwartete Nebeneffekte auf die CLI haben kann. Die bevorzugte Methode führt über die php.ini. Wenn PHP-CLI in einem Konsolen-Emulator verwendet wird, der kein Unicode unterstützt, kann dieser Weg notwendig sein, um eine Änderung der Konsolenkodierung zu vermeiden. Um dies zu erreichen, wird empfohlen, die Standard- oder interne Kodierung entsprechend der ANSI-Codepage einzustellen. Eine Alternative ist, die INI-Direktiven output_encoding und input_encoding auf die gewünschte Codepage zu setzen, wobei in diesem Fall der Unterschied zwischen interner und E/A-Codepage jedoch wahrscheinlich zu Zeichensalat führt. In seltenen Fällen kann es vorkommen, dass bei einem Absturz von PHP die ursprüngliche Konsolen-Codepage möglicherweise nicht wiederhergestellt wird. In diesem Fall kann der Befehl chcp verwendet werden, um sie manuell wiederherzustellen.
Besondere Vorsicht ist bei DBCS-Systemen (Systeme mit Doublebyte-Characterset) geboten - die Codepage zur Laufzeit mittels ini_set() zu ändern, kann zu Darstellungsproblemen führen. Der Unterschied zu Nicht-DBCS-Systemen ist, dass die erweiterten Zeichen zwei Konsolenzellen für die Anzeige benötigen. In bestimmten Fällen kann es vorkommen, dass Zeichen in den Glyphensatz der Schriftart abgebildet werden, ohne die Schriftart zu ändern. Dies liegt in der Natur der DBCS-Systeme und die einfachste Methode, Darstellungsprobleme zu vermeiden, besteht darin, die Codepage nicht per ini_set() zu ändern.
Infolge der Unterstützung von UTF-8 in den Streams sind PHP-Skripte nicht mehr auf ASCII- oder ANSI-Dateinamen beschränkt. Dies wird standardmäßig von CLI unterstützt. Für andere SAPIs ist die Dokumentation für den entsprechenden Server hilfreich.
Die Unterstützung langer Pfade ist transparent. Pfaden, die mehr als 260
Bytes haben, wird automatisch ein \?\ vorangestellt. Die
maximale Pfadlänge ist auf 2048 Bytes begrenzt. Es ist zu beachten, dass
die Begrenzung der Pfadsegmente (Länge des Basisnamens) weiterhin gilt.
Um die beste Portabilität zu erreichen, wird dringend empfohlen, für Dateinamen, I/O und andere verwandte Themen UTF-8 zu verwenden. Außerdem ist für Konsolenanwendungen eine TrueType-Schriftart zu bevorzugen. Darüber hinaus wird davon abgeraten, ini_set() für für die Änderung der Codepage zu verwenden.
Die Erweiterung readline wird nun von
der » WinEditLine-Bibliothek
unterstützt, wodurch die interaktive CLI-Shell nun
ebenfalls unterstützt wird (php.exe -a).
Die Umgebungsvariable PHP_FCGI_CHILDREN wird nun berücksichtigt. Wenn sie definiert ist, führt der erste php-cgi.exe-Prozess die angegebene Anzahl von Unterprozessen aus. Diese teilen sich denselben TCP-Socket.
Die Unterstützung für ftok() wurde hinzugefügt