最直接且推荐的方法是修改php.ini中的default_charset和mbstring.internal_encoding为UTF-8，或使用php -d参数临时设置，确保PHP解释器、脚本文件与输出环境编码一致，避免乱码、数据损坏及文件解析错误；可通过php -i命令或ini_get()函数验证当前设置，并注意不同操作系统终端编码差异，尤其Windows需调整代码页以支持UTF-8输出。
PHP命令执行脚本时，要设置默认字符集，最直接且推荐的方法是通过修改
php.ini配置文件中的
default_charset指令，或者在执行命令时使用
-d参数临时覆盖该设置。确保
mbstring扩展的
mbstring.internal_encoding也与此保持一致，通常都设为
UTF-8。
解决方案
处理PHP CLI脚本的字符集问题，核心在于确保PHP解释器、脚本文件本身以及最终输出环境（如终端或重定向的文件）三者之间的编码一致性。这远不止是简单设一个值那么简单，它关乎到PHP如何理解你的代码中的字符串字面量，如何处理文件I/O，以及如何与外部系统（比如数据库或API）交互。
首先，最基础也是最推荐的做法，是调整你的
php.ini文件。找到并设置以下指令：
; 确保PHP内部处理字符串时默认使用的编码 default_charset = "UTF-8" ; 如果你启用了mbstring扩展，这个设置也至关重要 ; 它定义了mbstring函数处理字符串的内部编码 mbstring.internal_encoding = "UTF-8"
修改后，记得重启你的Web服务器（如果是FPM/Apache/Nginx）或者对于CLI，每次执行都会读取最新的
php.ini。这个方法的好处是全局生效，避免了每个脚本都去单独设置的麻烦。
立即学习“PHP免费学习笔记（深入）”；
然而，在某些场景下，你可能需要为特定脚本或者一次性执行临时更改字符集。这时，PHP命令行工具的
-d参数就派上用场了。它允许你在执行时覆盖
php.ini中的任何配置项。
php -d default_charset=UTF-8 -d mbstring.internal_encoding=UTF-8 your_script.php
这种方式非常灵活，特别适合测试不同编码环境下的脚本行为，或者在共享服务器上你没有权限修改全局
php.ini时。
最后，如果你需要在脚本内部动态地控制字符集，可以使用
ini_set()函数。但这通常不推荐作为首选，因为它意味着你的脚本逻辑与环境配置耦合，且只在脚本执行期间生效。
这种方式在处理某些遗留系统或特定库的兼容性问题时可能有用，但从架构角度看，应尽量通过配置而非代码来管理这类全局设置。
PHP CLI脚本中字符集配置不当会引发哪些常见问题？
字符集配置不当，在PHP CLI脚本里简直是噩梦的开始。最直观的，就是我们常说的“乱码”——那些奇奇怪怪的符号，比如“â„¢”或者“���”。这通常发生在你的脚本输出是UTF-8，但终端却期望GBK，或者反过来。它不仅影响输出的可读性，更深层次的问题在于数据完整性和逻辑正确性。
想象一下，你从数据库读取一个包含中文的字符串，如果PHP内部处理时用的编码和数据库返回的不一致，或者你在处理过程中没有正确转换，那么字符串的长度计算、子串截取、甚至正则表达式匹配都会出错。一个UTF-8的汉字通常占3个字节，而GBK可能占2个。如果你按字节数来操作，结果就完全不对了。这就导致了数据损坏或者逻辑错误，比如用户注册时名字被截断，或者搜索功能无法正确匹配。
文件I/O也是个大坑。你用
file_put_contents写入一个文件，如果PHP的
default_charset和文件实际需要的编码不匹配，或者你没有显式指定，那么文件内容就可能变成乱码，其他程序读取时就会出问题。特别是当你处理CSV、JSON或XML文件时，错误的编码会导致解析失败，因为这些格式对字符编码通常有严格要求。
还有，与外部命令交互时，比如通过
exec()或
shell_exec()执行系统命令，如果PHP的输出编码和系统命令的输入编码不一致，或者系统命令的输出编码和PHP期望的编码不一致，也会出现乱码或解析错误。这就像两个人用不同的语言对话，虽然能听到声音，但根本无法理解对方的意思。解决这些问题，往往需要耗费大量时间去排查，因为它们通常不报错，只是结果不对。
如何验证PHP CLI当前使用的字符集设置？
要验证PHP CLI当前到底在用什么字符集，有几种方法，每种都有其适用场景。最直接的，也是我个人最常用的，是利用PHP的
phpinfo()输出结合命令行工具。
你可以在终端运行：
php -i | grep -E 'default_charset|mbstring.internal_encoding'
这会过滤出
phpinfo()输出中关于
default_charset和
mbstring.internal_encoding这两项的关键信息。通过这种方式，你可以快速确认当前PHP CLI环境读取到的
php.ini配置是怎样的。
如果你想在脚本运行时动态检查，可以在你的PHP脚本中加入：
运行这个脚本，你不仅能看到配置值，还能通过
strlen和
mb_strlen的对比来初步判断PHP是否正确识别了多字节字符。如果
strlen是
mb_strlen的三倍（对于UTF-8中文），那说明编码是正确的。如果两者相等，或者
mb_strlen返回不正确的值，那很可能
mbstring没有正确配置或者编码有问题。
当然，最彻底的验证方式是结合终端的编码设置。在Linux/macOS下，你可以用
locale命令查看终端的
LANG和
LC_ALL环境变量。它们决定了终端显示字符的编码。如果你的PHP CLI输出是UTF-8，而终端期望的是其他编码，那就会乱码。你可以尝试将PHP的输出重定向到文件，然后用文本编辑器（如VS Code、Sublime Text）打开文件，查看其编码格式。这能帮你确定PHP实际输出了什么编码。
在不同操作系统环境下，PHP CLI字符集设置有何差异与考量？
PHP CLI的字符集设置在不同操作系统下确实会有一些微妙但重要的差异，这往往是新手容易踩坑的地方。理解这些差异，能帮你少走很多弯路。
在Linux/Unix这类系统上，情况相对简单，因为它们普遍对UTF-8支持良好。核心在于系统的locale设置，这通常通过
LANG、
LC_ALL等环境变量来定义。例如，
en_US.UTF-8或
zh_CN.UTF-8。PHP CLI在执行时，很多内部函数（比如文件路径处理、与C库的交互）会受到这些locale设置的影响。如果你的
php.ini设置了
default_charset = "UTF-8"，并且系统locale也是UTF-8，那么通常不会有太大问题。但如果你的脚本需要处理其他编码的文件（比如一个遗留的GBK编码日志），你就需要显式地进行编码转换，例如使用
iconv或
mb_convert_encoding。这里需要注意的是，即使PHP内部是UTF-8，如果终端的locale不是UTF-8，输出到终端依然会乱码。
而Windows环境则复杂得多。Windows命令行（cmd.exe）默认使用的是OEM代码页（如简体中文系统的GBK/CP936），而不是ANSI代码页（如UTF-8或系统默认的Windows代码页）。这就意味着，即使你的PHP脚本内部处理的是UTF-8，输出到cmd窗口时，很可能就会乱码。你可以在cmd窗口中使用
chcp 65001命令来临时将代码页改为UTF-8，但这个设置只对当前会话有效，而且并非所有字体都支持所有字符。PowerShell在这方面表现要好一些，它对UTF-8的支持更原生。在Windows上部署PHP CLI脚本时，你可能需要特别注意终端的编码设置，或者将输出重定向到文件，然后用一个支持UTF-8的编辑器查看。
跨平台开发时，为了避免这些平台特有的编码陷阱，最佳实践是：始终将PHP脚本内部的字符串处理编码设置为UTF-8。这样，无论是在Linux还是Windows上，PHP自身对字符串的理解都是一致的。然后，对于外部交互（如文件I/O、数据库连接、终端输出），根据具体情况进行必要的编码转换。例如，连接MySQL数据库时，确保连接字符集设置为UTF-8；写入文件时，显式指定编码；输出到Windows命令行时，考虑先进行编码转换，或者建议用户将命令行编码设置为UTF-8。这种“内部统一，外部按需转换”的策略，能大大减少编码问题带来的困扰。
