PHP源文件应保存为UTF-8无BOM，运行时需统一设置mb_internal_encoding、default_charset和Content-Type响应头为UTF-8，并确保header()调用前无任何输出，否则易触发headers already sent错误。
PHP 文件本身的编码（即源码文件保存时的字符集）和 PHP 运行时输出的编码（如 Content-Type 响应头、mb_internal_encoding() 等）是两回事；Windows 和 Linux 下 PHP 解析器对源文件编码没有本质区别，但编辑器行为、默认终端环境、以及常见错误场景差异显著。
PHP 源文件编码怎么设才不会乱码
PHP 解析器本身不强制要求源码编码，但它会原样读取文件字节。只要没用到非 ASCII 字符（比如中文变量名、中文字符串），UTF-8、GBK、ISO-8859-1 都能跑通。一旦出现中文：echo "你好";，就必须确保：
- 文件保存为 UTF-8 无 BOM（BOM 是 Windows 记事本常加的 3 字节头部，PHP 会把它当输出内容，导致 headers already sent 错误）
- 如果用了 GBK 编码保存，而 PHP 输出时又没声明
header('Content-Type: text/html; charset=gbk');，浏览器大概率显示乱码 - Linux 终端默认 UTF-8，Windows CMD 默认 GBK（旧版），这会影响
var_dump()或echo的终端显示效果，但不影响脚本逻辑
PHP 运行时编码设置的关键函数与位置
真正影响输出是否乱码的是运行时编码配置，不是文件保存格式。重点看三处：
-
mb_internal_encoding('UTF-8')：设置多字节函数（如mb_strlen）的默认编码，应在脚本最开头调用，否则可能失效 -
default_charset = "UTF-8"（php.ini）：控制header('Content-Type')默认值，也影响htmlspecialchars()等函数的行为 -
header('Content-Type: text/html; charset=UTF-8');：必须在任何输出前调用，且 charset 值要和 HTML 中<meta charset="UTF-8">一致
Windows 与 Linux 下的实际差异点
差异不在 PHP 引擎本身，而在配套环境：
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- Windows 上用记事本保存 PHP 文件，默认是 ANSI（即当前系统 locale，中文 Win 就是 GBK），极易踩 BOM 和编码不匹配坑；Linux 下 vim / nano 默认按 UTF-8 处理，更“省心”
- Web 服务器方面：Apache 在 Windows 下默认不读取 .htaccess 的
AddDefaultCharset UTF-8，而 Linux + Apache 常启用；Nginx 则需显式配charset utf-8;，否则响应头无 charset -
iconv()函数在 Windows 下对某些编码（如 GB18030）支持较弱，Linux 下 glibc 支持更全；遇到转码失败时，mb_convert_encoding()更可靠
最容易被忽略的是：即使所有配置都设成 UTF-8，只要有一个 echo 或空格/换行写在 session_start() 或 header() 前，就可能触发 headers already sent，进而让 charset 设置失效——这种问题在 Windows 开发环境里尤其隐蔽，因为编辑器自动加的末尾空行或 BOM 往往看不见。
立即学习“PHP免费学习笔记（深入）”；
