共计 3145 个字符,预计需要花费 8 分钟才能阅读完成。
封面图片源自 Pixabay
前言
前段时间在应用 str_getcsv
和 fgetcsv
解决 CSV 文件的时候遇到的一个问题:
测试中, 文,foo,bar,123
预期状况下,应该返回一个数组。["测试中", "文", "foo", "bar", "123"]
,而理论却失去了 ["测试中, 文,foo", "bar", "123"]
,是的,测试中, 文
竟然没有被离开,通过一番测试和查证,最初发现,这个问题默认状况下只会在 Windows 上的 PHP 7 版本(5 测试的时候没有问题,然而会乱码)中呈现(还跟字符长度无关),Linux 下默认没问题。
问题起源
因为是间接从文件进行获取解决,共事一开始间接应用的 explode(',', $row)
进行解决,一开始是好的,然而当 CSV 列中呈现了 ,
号的时候,就会被意外离开了,至于源数据,不便做批改。为了解决这个问题,我将其改为 str_getcsv
进行解决,却引发了这个问题。
简略说一下 CSV 格局,个别状况下,应用逗号 (,
) 宰割列,用换行来示意新行,而共事一开始就是以 explode
的形式来解析单行的数据,而这种状况下,如果有一列的数据中呈现了 逗号(,
) 就会导致被意外宰割,多处一列数据来,显然这是不合理的,为此就须要引入本义解决。
为了在单列数据中应用逗号(,
),那就须要应用英文的双引号("
)把这一列数据包起来(对于须要换行的数据也须要这样解决),而当咱们须要示意一个双引号时,就须要双写这一个双引号,就像这样子。
"php,composer",foo,bar"","
say"
下面的例子该当被解析为:
array(4) {[0]=>
string(12) "php,composer"
[1]=>
string(3) "foo"
[2]=>
string(5) "bar"""
[3]=>
string(4) "say"
}
解决问题
通过多个环境验证,发现在 Linux 下没有问题,在 PHP 8 也没问题,就只有 PHP 7 上有这个问题。
当搜寻过一番时,发现遇到过最多的问题,都是乱码,偶有人提到过这个问题。
因为这里编码解析失常,天然不认为是编码的问题,所以持续找材料,顺带还问了问 ChatGPT,一开始他也文不对题的说,是分隔符的问题,最初再疏导下,他提到,能够增加 UTF-8 BOM
(字节程序标记(英语:byte-order mark,BOM))来解决。
于是便调整代码,大抵如下:
$str = '';
$str .= "\xEF\xBB\xBF";
$str .= '测试中, 文,foo,bar,123';
var_dump(str_getcsv($str));
当尝试增加 BOM 之后,后果从原先的 ["测试中, 文,foo", "bar", "123"]
变成了 ["测试中", "文,foo", "bar", "123"]
🤔。
然而有些状况下就会正确了,假如去掉第二列的 文
字,就能够合乎预期,然而这显然不行,因为这样(增加 BOM)不能解决所有状况,所以还是不合时宜的。
通过在 PHP 的 Change Log 外面一番搜寻 csv
,找到了一条。
- Fixed bug #72330 (CSV fields incorrectly split if escape char followed by UTF chars).
在这个 bug 中,有人遇到了同样的问题,并且提供了残缺的复现步骤给出了。
其中有人给出了一个解决方案,就是通过设置 setlocale(LC_ALL, ‘C’) 办法设置本机运行的 locale 信息,从而解决。
既然要设置,无妨先看看,以后的 locale 是什么,在我的 Windows 平台上,执行 setlocale(LC_ALL, 0)
,其返回为:
LC_COLLATE=C;LC_CTYPE=Chinese (Simplified)_China.936;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C
而当在 Linux 上执行时,这里返回 C
。
留神这里,在咱们 Windows 平台上 PHP 7.x 这里的 LC_CTYPE
是 Chinese (Simplified)_China.936
,而自 PHP 8 开始,在 Windows 平台上 LC_CTYPE
,将默认为 C
,所以在 PHP 8 上没有了这个问题。
- PHP: Other Changes – Manual
setlocale(LC_ALL, 'C');
$str = '测试中,foo,bar,123';
var_dump(str_getcsv($str));
当初这个后果将合乎预期,输入:["测试中", "文", "foo", "bar", "123"]
。
看起来所有都很好,问题被实打实的解决,然而,在后续的探讨中,PHP 官网回复指出,因为 str_getcsv 思考了 locale,所以是能够通过设置 locale 来解决这个问题。
然而这并不是一个好的解决方案,正如 setlocale 在文档中所写的。
区域信息是按过程保护的,而不是线程。如果在多线程服务器 API 上运行 PHP,区域设置可能在脚本运行时忽然变动,只管脚本自身并没有调用 setlocale()。这是因为其它脚本在同一时刻的同一过程的不同线程中运行,应用 setlocale() 扭转了过程级别的区域。在 Windows 上,自 PHP 7.0.5 起,每个线程都保护本人的区域信息。
而给出的另一个计划是,将源字符串转为 CSV 能够辨认并解决的编码,解决当前,再转回去。🤔
在 中文环境下的 Windows 平台上,将会是这样,后果合乎预期。
$str = '测试中, 文,foo,bar,123';
$str = mb_convert_encoding($str, 'gb2312', 'UTF-8');
$arr = str_getcsv($str);
$arr = array_map(function ($v) {return mb_convert_encoding($v, 'UTF-8', 'gb2312');
}, $arr);
var_dump($arr);
总之,就是最好的实现形式就是提供一个不依赖用户 locale 设置的办法来解决。
问了问 ChatGPT,TA 给出了一份答案:
function user_str_getcsv($input, $delimiter = ',', $enclosure = '"', $escape ='\\')
{$output = array();
$string = '';
$quote = false;
$strlen = mb_strlen($input);
for ($i = 0; $i < $strlen; $i++) {$char = mb_substr($input, $i, 1);
if ($char === $enclosure) {$quote = !$quote;} elseif (!$quote && (($char === $delimiter) || ($char === "\n"))) {$output[] = $string;
$string = '';
if ($char === "\n") {break;}
} elseif ($char === $escape) {
$i++;
$string .= ($i < $strlen) ? mb_substr($input, $i, 1) : '';
} else {$string .= $char;}
}
$output[] = $string;
return $output;
}
然而这样的性能或者不肯定高。
这份回复后,PHP 文档中,将本来在上面的“此函数思考区域设置。如果 LC_CTYPE 是相似 en_US.UTF-8 的值,此函数将谬误的读取单字节编码的字符串。”
总结
解决这个问题的计划有几个:
- 1、应用 setlocale 办法设置 locale 为 C。能够仅设置 LC_CTYPE。
- 2、手动对传入的数据进行编码转换解决
- 3、实现自行实现一个 CSV 办法[1]
- 4、应用 PHP8
locale 的设置影响内置函数的行为比拟多的,所以请审慎处理 LC_ALL
。