array ( 0 => 'index.php', 1 => 'PHP Manual', ), 'head' => array ( 0 => 'UTF-8', 1 => 'ja', ), 'this' => array ( 0 => 'migration71.windows-support.php', 1 => 'Windows のサポート', 2 => 'Windows のサポート', ), 'up' => array ( 0 => 'migration71.php', 1 => 'PHP 7.0.x から PHP 7.1.x への移行', ), 'prev' => array ( 0 => 'migration71.other-changes.php', 1 => 'その他の変更', ), 'next' => array ( 0 => 'migration70.php', 1 => 'PHP 5.6.x から PHP 7.0.x への移行', ), 'alternatives' => array ( ), 'source' => array ( 'lang' => 'ja', 'path' => 'appendices/migration71/windows-support.xml', ), 'history' => array ( ), ); $setup["toc"] = $TOC; $setup["toc_deprecated"] = $TOC_DEPRECATED; $setup["parents"] = $PARENTS; manual_setup($setup); contributors($setup); ?>

Windows のサポート

長いpath と UTF-8のpath のサポート

Webアプリケーションが UTF-8 に対応しているなら、追加の作業は必要ありません。 UTF-8 でないpathへの I/O に依存したアプリケーションについては、 明示的に INIディレクティブを設定する必要があります。 エンコーディングのINI設定のチェックは、コアの順番に依存します:

コードページを扱う関数がいくつか追加されました:

これらの関数はスレッドセーフです。

コンソール出力のコードページは、 PHP の内部で使用されるエンコーディングに基づいて調整されます。 具体的な システム OEM のコードページによっては、 目に見える出力は正しいかもしれませんし、正しくないかもしれません。 たとえば、OEM コードページ 437 のシステム上での デフォルトの cmd.exe は、1251, 1252, 1253 や、 他のいくつかのコードページを出力しますが、 これらは UTF-8 で表示すれば正しく表示できます。 同じシステム上で、20932 のようなコードページ上の文字は、 正しく表示できません。 これは、コードページにまつわる特定のシステムのルールや、 フォントの互換性、そして特定のコンソールプログラムが関係しています。 PHP は、php.ini から読み取ったエンコーディングのルールに沿って、 コンソールのコードページを自動的に設定します。 cmd.exe 以外のコンソールを使う場合、 ケースによってはより良い体験が得られるかもしれません。

それでもなお知っておくべきなのは、 リクエストの処理が始まったあとの実行時にコードページを変更すると、 CLI 上では予測できない副作用をもたらす可能性があることです。 好ましいやり方は、Unicode をサポートしていない PHP CLI がコンソールのエミュレータとして使われている場合、必須ではないものの、 php.ini を使うことでコンソールのコードページを変更することを避けることです。 これを達成する最良のやり方は、デフォルト、 または内部エンコーディングの設定を ANSI コードページにすることです。 別のやり方として、INI ディレクティブの output_encoding と input_encoding を必要なコードページに設定することがあります。しかしこの場合、 内部のコードページと I/O のコードページが異なることが原因で、 文字化けを引き起こしがちです。レアケースではありますが、 PHP が偶然綺麗にクラッシュしたとしても、 オリジナルのコンソールのコードページがリストアされない可能性もあります。 この場合、手動でリストアする方法として、chcp コマンドが使えます。

DBCS システムについては、特別に知っておくべきことがあります。 実行時に ini_set() を使ってコードページを変更すると、 表示上の問題を引き起こす可能性があることです。 DBCS でないシステムとの違いは、 コンソールのセルふたつ分を表示に要求する拡張文字を表示する場合です。 場合によっては、フォントのグリフセットへの文字のマッピングが発生するのに、 実際のフォントは変わらないといったことが起こります。 これは DBCS システムの性質によって起こります。 この手の表示の問題を避けるもっとも簡単な方法は、 コードページの変更に ini_set() を使わないことです。

ストリームで UTF-8 がサポートされたことによって、 PHP スクリプトは ASCII や ANSI のファイル名にもはや縛られなくなりました。 これは CLI の枠を越えたサポートです。他の SAPI については、 対応するサーバーのドキュメントを見ると有益でしょう。

長いパス名のサポートは透過的です。 260バイトより長いパス名には、 自動的に \\?\ という prefix が付きます。 パス名の最大の長さは、2048バイトに制限されています。 パスセグメントの長さの制限 (basepath の長さ) はまだ続いていることも知っておいてください。

移植性を最大にするために、ファイル名や I/O 、 そして他の関連するトピックを UTF-8 で扱うことを強くお勧めします。 それに加えて、コンソールアプリケーションについては、 TrueType フォントを使うことが好ましいです。 また、コードページの変更に ini_set() を使うことは推奨されません。

readline

readline 拡張モジュール が » WinEditLine ライブラリ を通じてサポートされました。 これにより、インタラクティブな CLI シェルもサポートされました (php.exe -a)。

PHP_FCGI_CHILDREN

環境変数 PHP_FCGI_CHILDREN が尊重されるようになりました。 この環境変数が定義されていた場合、最初の php-cgi.exe プロセスが指定された数の子プロセスを実行します。 これらは同じTCPソケットを共有します。

ftok()

ftok() 関数のサポートが追加されました。