支援長路徑和 UTF-8 路徑

如果網路應用程式符合 UTF-8 標準，則不需要進一步操作。 對於依賴非 UTF-8 編碼路徑進行輸入/輸出的應用程式，必須設定明確的 INI 指示詞。 編碼 INI 設定檢查依賴於核心的順序

• internal_encoding
• default_charset
• zend.multibyte

引進了幾個用於程式碼頁處理的函式

• sapi_windows_cp_set() 用於設定預設程式碼頁
• sapi_windows_cp_get() 用於擷取目前的程式碼頁
• sapi_windows_cp_is_utf8()
• sapi_windows_cp_conv() 用於在程式碼頁之間轉換，使用與 iconv() 相容的簽名

這些函式是執行緒安全的。

主控台輸出的字碼頁會根據 PHP 中使用的編碼進行調整。根據具體系統的 OEM 字碼頁，可見輸出可能正確也可能不正確。例如，在預設的 cmd.exe 中，以及在 OEM 字碼頁為 437 的系統上，使用 UTF-8 時，字碼頁 1251、1252、1253 和其他一些字碼頁的輸出可以正確顯示。在相同的系統上，字碼頁 20932 等字元可能無法正確顯示。這取決於特定系統的字碼頁規則、字型相容性以及所使用的特定主控台程式。PHP 會根據 php.ini 中的編碼規則自動設定主控台字碼頁。在某些情況下，直接使用替代主控台而不是 cmd.exe 可能會帶來更好的體驗。

然而需要注意的是，在請求開始後，運行時字碼頁切換可能會在 CLI 上產生意想不到的副作用。首選方式是透過 php.ini 設定。當在不支援 Unicode 的主控台模擬器中使用 PHP CLI 時，可能需要避免更改主控台字碼頁。實現此目的的最佳方法是將預設或內部編碼設定為與 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 位元組的路徑會自動加上前綴 `\\?\`。最大路徑長度限制為 2048 位元組。請注意，路徑區段限制（基名長度）仍然存在。

為了獲得最佳的可攜性，強烈建議使用 UTF-8 處理檔名、I/O 和其他相關主題。此外，對於主控台應用程式，建議使用 TrueType 字型，並且不建議使用 `ini_set()` 更改字碼頁。

readline

readline 擴充 透過 » WinEditLine 函式庫 支援。因此，也支援互動式 CLI 殼層（php.exe -a）。

PHP_FCGI_CHILDREN

現在已支援 PHP_FCGI_CHILDREN。如果定義了此環境變數，則第一個 php-cgi.exe 程序將執行指定數量的子程序。這些子程序將共享同一個 TCP 通訊端。

ftok()

新增了對 ftok() 的支援。