Si une application web est conforme à l'UTF-8, aucune action supplémentaire n'est requise. Pour des applications qui dépendent de chemins dans un encodage différent que UTF-8 pour l'I/O, une directive INI doit être explicitement définie. La vérification des paramètres d'encodage INI se fie à l'ordre dans le cœur (core) :
Plusieurs fonctions pour la gestion des codepage ont été introduites :
Ces fonctions sont thread safe.
La sortie de la console codepage est ajustée en fonction de l'encodage utilisé en PHP. En fonction du codepage OEM du système concret, la sortie visible pourrait ou pourrait ne pas être correcte. Par exemple, avec le cmd.exe par défaut et sur un système avec le codepage OEM 437, les sorties en codepage 1251, 1252, 1253 et d'autres peuvent être affichées correctement en utilisant UTF-8. Sur les mêmes systèmes, les caractères dans codepage tel que 20932 ne seront probablement pas affichées correctement. Ceci fait référence aux règles système particulières pour codepage, la compabilité de la police et le choix du programme de console utilisé. PHP définit automatiquement la codepage console en accord avec les règles d'encodages depuis php.ini. Utiliser des consoles alternatives à la place de cmd.exe directement pourrait apporter une meilleure expérience dans certains cas.
Toutefois soyez conscient, changer de codepage après que la requête a commencé peut causer des effets secondaires inattendus en CLI. La façon préférable est php.ini. Quand PHP CLI est utilisée dans un émulateur de console, qui ne supporte pas Unicode, il est possiblement nécessaire, d'éviter de changer la codepage de la console. La meilleure façon pour achever ceci est de définir l'encodage interne ou par défaut pour correspondre à la codepage ANSI. Une autre méthode est de définir la directive INI output_encoding et input_encoding à la codepage requise, cependant dans ce cas la différence entre les codepages internes et I/O risque de causer du mojibake. Dans de rares cas, si PHP arrive à planter gracieusement, la codepage originale de la console peut ne pas être restaurée. Dans ce cas, la commande chcp peut être utilisée, pour la restaurer manuellement.
Attention particulière pour les systèmes DBCS - le changement de codepage lors de l'exécution en utilisant ini_set() risque de causer des problèmes d'affichage. À la différence des systèmes non DBCS, c'est que les caractères étendus nécessitent deux consoles pour être affichés. Dans certains cas, seule la mise en correspondance des caractères dans le jeu de glyphes de la police pourrait se produire, aucun changement de police ne se produit. Ceci est la nature des systèmes DBCS, la manière la plus simple de prévenir des problèmes d'affichages est d'éviter l'usage de ini_set() pour le changement de codepage.
En conséquence du support d'UTF-8 dans les flux, les scripts PHP ne sont plus limités à des noms de fichiers ASCII ou ANSI. Ceci est prêt à l'emploi en CLI. Pour d'autres SAPI, la documentation pour le serveur correspondant est utile.
Le support des chemins longs est transparent. Les chemins plus longs que 260 octets sont
automatiquement préfixés par \\?\. La longueur maximale du chemin est
limitée à 2018 octets. Soyez conscient, que la limite des segments de chemin (longueur du
basename) persiste.
Pour une meilleure portabilité, il est fortement recommandé de gérer les noms de fichiers, I/O et autres sujets connexes UTF-8. En outre, pour les applications console, l'usage d'une police TrueType est préférable et l'usage de ini_set() pour le le changement de codepage est déconseillé.
L'extension readline est supportée
à travers la » bibliothèque
WinEditLine. Ainsi l'interface système interactive CLI est
aussi supportée (php.exe -a).
PHP_FCGI_CHILDREN est désormais respecté. Si cette variable d'environnement est définie, le premier processus php-cgi.exe exécutera le nombre spécifié d'enfants. Ceux-ci partageront le même socket TCP.
Ajout du support pour ftok()