php中的UTF-8问题：var_export()返回\0空字符，ucfirst()、strtoupper()等行为异常答案

【问题标题】：UTF-8 problems in php: var_export() returns \0 null characters, and ucfirst(), strtoupper(), etc. behave strangelyphp中的UTF-8问题：var_export()返回\0空字符，ucfirst()、strtoupper()等行为异常
【发布时间】：2012-04-02 05:32:12
【问题描述】：

我们正在处理以前从未发生过的 Joyent Solaris 服务器中的一个奇怪错误（不会发生在 localhost 或其他两个具有相同 php 配置的 Solaris 服务器中）。其实我也不确定要不要看php还是solaris，是软件还是硬件的问题……

我只是想发布这个，以防有人能指出我们正确的方向。

所以，问题似乎出在var_export()处理奇怪字符时。在 CLI 中执行此操作，我们在 localhost 机器和其中两台服务器中获得了预期的结果，但在第三台服务器中却没有。它们都配置为使用utf-8。

$ php -r "echo var_export('ñu', true);"

在较旧的服务器和本地主机中提供此功能（预期）：

'ñu'

但是在服务器中我们遇到了问题（PHP 版本 => 5.3.6），它会在遇到“不常见”字符时添加 \0 空字符：è、á、ç , ...你的名字。

'' . "\0" . '' . "\0" . 'u'

知道应该在哪里看吗？提前致谢。

更多信息：

PHP version 5.3.6。
setlocale() 没有解决任何问题。
default_charset 在 php.ini 中是 UTF-8。
mbstring.internal_encoding 在php.ini 中设置为UTF-8。
mbstring.func_overload = 0。
这发生在 CLI（示例）和 Web 应用程序（php-fpm + nginx）中。
iconv 编码也是UTF-8
所有文件utf-8 编码。

system('locale') 返回：

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

目前完成的一些测试（CLI）：

正常行为：

$ php -r "echo bin2hex('ñu');" => 'c3b175'
$ php -r "echo mb_strtoupper('ñu');" => 'ÑU'
$ php -r "echo serialize(\"\\xC3\\xB1\");" => 's:2:"ñ";'
$ php -r "echo bin2hex(addcslashes(b\"\\xC3\\xB1\", \"'\\\\\"));" => 'c3b1'
$ php -r "echo ucfirst('iñu');" => 'Iñu'

不正常：

$ php -r "echo strtoupper('ñu');" => 'U' 
$ php -r "echo ucfirst('ñu');" => '?u' 
$ php -r "echo ucfirst(b\"\\xC3\\xB1u\");" => '?u' 
$ php -r "echo bin2hex(ucfirst('ñu'));" => '00b175'
$ php -r "echo bin2hex(var_export('ñ', 1));" => '2727202e20225c3022202e202727202e20225c3022202e202727'
$ php -r "echo bin2hex(var_export(b\"\\xC3\\xB1\", 1));" => '2727202e20225c3022202e202727202e20225c3022202e202727'

所以问题似乎出在var_export() 和"string functions that use the current locale but operate byte-by-byte" ^Docs（查看@hakre 的答案）。

【问题讨论】：

我首先检查每台服务器上运行的软件版本。特别是 php。一个版本中的函数采用 UTF-8，而不同版本中的相同函数采用 ISO-8859-1。
还可以尝试比较locale(1) 的输出和/或检查以LC 开头的环境变量。
这只发生在 CLI 上吗？这可能是 Solaris 终端如何处理 Unicode 的一些特殊情况。或者从保证不包含NUL字节的源代码文件运行时也会发生这种情况吗？
检查两件事，一是在 CLI 上执行的 php.ini（可能与 web 服务器上的不同），将 default_charset 设置为“utf-8”。其次，检查 /etc/locale.gen 是否在那台服务器上有 en_US.UTF-8。
我确信这与 Solaris 和 PHP 使用的系统 C 库有关。我会说编译的包已经被宿主搞砸了，否则strtoupper 必须工作。获取正确的二进制文件。

标签： php utf-8 localization joyent

【解决方案1】：

尝试在 php 中强制使用 utf-8：

<? ini_set( 'default_charset', 'UTF-8' ); ?>

在任何页面/模板的最顶部（第一行代码）。它主要帮助我处理我的特殊角色。不确定它是否也能帮助你，试试吧。

【讨论】：

default_charset 在php.ini 中为UTF-8。还是谢谢。

【解决方案2】：

可能您所有的服务器都处于良好状态。在您所说的一个 cmets 中，您只有 ucfirst() 和 var_export() 的问题。根据这些回复，您可能正在查看此SOQ。大多数 php 字符串函数在处理多字节字符串时将无法正常工作。这就是为什么 php 有separate set of functions 来处理它们。

This 可能会有所帮助

【讨论】：

【解决方案3】：

我建议您验证遇到问题的 PHP 二进制文件。检查编译器标志和它使用的库。

通常 PHP 在内部使用二进制字符串，这意味着像 ucfirst 这样的函数逐字节工作，并且只支持您的语言环境支持的内容（如果和类似配置）。见Details of the String Type^Docs。

$ php -r "echo ucfirst('ñu');"

返回

?u

这是有道理的，ñ 是

LATIN SMALL LETTER N WITH TILDE (U+00F1)    UTF8: \xC3\xB1

您配置了一些语言环境，使 PHP 将 \xC3 更改为其他内容，破坏了 UTF-8 字节序列并使您的 shell 显示 � replacement character^Wikipedia。

如果你真的想分析问题，我建议你应该从hexdumps 开始，旁边是事物如何在 shell 和其他地方显示。知道您可以显式定义二进制字符串b"string"（这是向前兼容性，也许您已经启用了一些编译标志并且您正在使用 unicode 实验性？），您也可以按字面意思编写字符串，这里是 UTF- 的十六进制方式8：

 $ php -r "echo ucfirst(b\"\\xC3\\xB1u\");"

而且还有很多设置可以发挥作用，我开始在an answer to Preparing PHP application to use with UTF-8列出一些点。

多字节ucfirst 变体示例：

/**
 * multibyte ucfirst
 *
 * @param string $str
 * @param string|null $encoding (optional)
 * @return string
 */
function mb_ucfirst($str, $encoding = NULL)
{
    $first = mb_substr($str, 0, 1, $encoding);
    $rest = mb_substr($str, 1, strlen($str), $encoding);
    return mb_strtoupper($first, $encoding) . $rest;
}

参见mb_strtoupper^Docs 和mb_convert_case^Docs。

【讨论】：

我已经进行了“十六进制测试”：所有服务器，包括“坏人”，在执行 $ php -r "echo bin2hex('ñu');" 时都会返回 c3b175。不知道我应该如何解释这个......
而$ php -r "echo ucfirst(b\"\\xC3\\xB1u\");" 返回?u。
bin2hex(ucfirst('ñu')); 提供了什么？（您的报告显示，对于这两种情况，PHP 在字符串中使用 UTF-8 序列，因此在这些系统中是相同的）。
bin2hex(ucfirst('ñu')); 返回00b175。
好吧，因为这甚至与strtoupper 有关，我怀疑它与编译PHP 时的底层c 库有关。您应该检查 Joynet 支持并要求他们提供正确配置/编译的二进制文件。另外，我建议您获得一个更新的 PHP 5.3 版本的 PHP 版本，例如 PHP 5.3.10。

【解决方案4】：

我通常对所有法语字符使用utf8_encode('ñu')

【讨论】：

感谢 Vinay，但这似乎是一个底层 C 问题，可能是一个编译问题。仍在尝试找出它，但 PHP 似乎不是问题的根源。

【解决方案5】：

为此的 phpunit 测试被添加到 https://gist.github.com/68f5781a83a8986b9d30 - 我们可以建立一个更好的单元测试套件，以便我们可以确定预期的输出应该是什么？

【讨论】：