perl - 如何测试/分类 CPAN 模块的 utf8 正确性

Question

这是一个优秀的question和精彩的tchrist的answer有 7+24+52 条建议和评论如何使 perl 程序 utf8 安全。

但这里是 19k CPAN 模块。可以做些什么来区分“好”和“坏”？ (从 utf8 的角度来看)

例如:File::Slurp如果您将阅读该文件

#use strict encoding warnings utf8 autodie... etc....
my $str = read_file($file, binmode => ':utf8');

您将根据命令行开关得到不同的结果， perl -CSDA不管用。伤心。 (是的，我知道 Encode::decode("utf8", read_file($file, binmode => ':raw')); 会有所帮助，但无论如何 SAD。

我的问题:

这里有任何首选方式，如何测试/分类哪些 CPAN 模块是 utf8 安全/准备好/正确的？

这里有一些 Test::something 已经为 utf8 测试完成了吗？

这里是 Perl::Critic for utf8 之类的东西 - 什么会检查模块源中可能存在的 utf8 错误？ (因为手动检查 7+24+52 事物的来源，我无法将其归类为“简单的编程方式”)

或任何其他方式？ :)

我明白，很多 CPAN 模块根本不需要了解 utf8。但是这里有很多其他人应该做什么。

请不要误会我的意思。 我喜欢 Perl 语言 .我知道 perl 具有极其强大的 utf8 功能。 (尤其是 5.14)。以上并不是 perl 批评的意思——但我(可能还有其他一些人)需要知道哪些 CPAN 模块是可以的，以及如何对它们进行分类......)

使用多个 CPAN 模块进行开发时，最初一切顺利，但在最终测试中，您发现某些模块不支持 utf8，因此您的部分工作是无用的 - 这确实会导致一些幻想破灭。 :(

编辑:

我明白，围绕 unicode 的所有复杂事物都有两个根源:

unicode 本身 - 正如 tchrist 出色地分析了一些问题点

perl - 简单不能破坏所有工作模块、实时服务器等 - 所以需要保持向后兼容性。

我唯一的希望:perl6。是一种全新的、不同的语言。不需要维护任何向后兼容性。所以我希望，在 perl6 中将是 默认 有些事情在 perl5 中是不可能做的，而所有 utf8 的事情都会更加直观。

但是，回到模块:@daxim 告诉:“作者甚至不会透露他们的模块是否是 taint-safe，而且这个功能已经存在了几十年!” - 这是一场灾难。也许(也许很大，老实说不知道该怎么做)，但也许我们到了那个时候，需要对 CPAN 提交施加更严格的限制。

一方面，我对 CPAN 作者的志愿者作品非常满意。另一方面，发布源代码不仅是言论自由的“权利”——还应该遵守一些规则。

我明白，几乎不可能进行任何“革命”，但我们可能需要一些“进化”。也许标记任何不是 utf8 安全的 CPAN 模块。标记所有不安全的东西。标记(如 SO 中的此处)哪些模块不符合最低编码标准并将其删除。也许我是一个理想主义者和/或天真。 :)

Answer 1

冷静点，情况没有你想象的那么可怕。除了 tchrist 没有人在这个级别的 Unicode 正确性上运行，另见 Aristotle's recent commentary .与所有事情一样，您只需付出 20% 的努力就能完成 80% 的工作。这个基础努力，即getting the topic of character encoding right ，有据可查；和 jrockway repeats it in his answer在那个线程中。

回复您的具体问题:

不，没有。没有齐心协力在中心位置收集这些信息。 Perl 5 wiki 可以用来记录有问题的模块，Juerd 已经在 uniadvice 中讨论了一些。 .我真的很想在他们的文档中看到每个模块作者的声明“这个模块 DTRT w.r.t. 编码”，但我没有看到它发生。作者甚至不会透露他们的模块是否是 taint-safe，而且这个功能已经存在了几十年!

encoding::warnings可用于抽出意外升级。我在 Checklist for going the Unicode way with Perl 的工作流程中提到了它

你不能用 Perl::Critic 或静态分析来做到这一点。除了知识渊博的人用尖尖的字符戳模块直到它分崩离析(或不分崩离析)之外，我没有其他办法，就像 mirod 刚刚评论的那样。