如何测试/分类CPAN模块以确保utf8的正确性

Question

这里有一个优秀的问题和精彩的克里斯特's 回答，提供了7+24+52的建议&如何使perl程序utf8安全。

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

例如：File::Slurp，如果您将使用

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

您将根据命令行开关获得不同的结果，而perl -CSDA将无法工作。悲伤的。(是的，我知道比编码：：解码(“utf8”，read_file($file，binmode =>‘：raw’))更有帮助，但还是有帮助的。

我的问题：

• 这里有什么首选的方法，如何测试/分类哪些utf8模块是安全的/就绪的/正确的？
• 这里有一些测试：：已经为utf8测试做了什么吗？
• 这里是否类似于Perl：：utf8的批评者--什么将检查模块源代码中是否存在可能的utf8错误？(因为手动检查7+24+52的源代码，我不能将其归类为“易于编程的方法”)
• 或其他方式？)

我明白，比许多CPAN模块更不需要了解utf8。但这里还有其他人该做的。

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

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

编辑：

我理解与unicode有关的所有复杂事物有两个根源：

1. unicode本身-作为tchrist出色地分析了一些问题点。
2. perl - simple不能破坏所有工作模块、活动服务器等，因此需要保持向后兼容性。

我唯一的希望是: perl6。是一种全新的不同的语言。不需要保持任何向后兼容性。因此，我希望，在perl6中，默认的中有些东西在perl5中是不可能的，并且所有的utf8事物都会更加直观。

但是，回到模块：@daxim告诉我们：“作者甚至不愿透露他们的模块是否被污染--安全，而且这个特性存在了几十年！”--这是一场灾难。也许(可能很大，而且诚实地说我们不知道该如何做)，但也许我们到了那个时候，需要在CPAN提交中施加更多的限制。

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

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

Answer 1

冷静点，情况不像你想象的那么可怕。除了tchrist之外，没有人对此级别的Unicode正确性进行操作，也请参阅亚里士多德最近的评论。和所有的事情一样，你用20%的努力就可以得到80%的成功。这个基本的工作，即正确处理字符编码主题，在这个线程中有很好的文档；以及jrockway在他的回答中重复了这句话。。

对你的具体问题的答复：

1. 不，没有。没有一致的努力在一个中心的地方收集这些信息。Perl 5 wiki可以用来记录有问题的模块，Juerd已经在优胜劣汰中讨论了一些。我真的很想看到每个模块作者在他们的文档中声明“这个模块的DTRT w.r.r.t.编码”，但我不认为它会发生。作者甚至不愿透露他们的模块是否是污染安全的，而且这个特性存在了几十年！
2. 编码：：警告可以用来排除意外的升级。我在使用Perl使用Unicode方式的检查表的工作流程中提到了这一点。
3. 您不能用Perl：：批评家或静态分析来实现这一点。我没有别的办法，只有知识渊博的人用尖尖的字符戳这个模块，直到它分崩离析(或者没有)，就像米罗德刚才评论的那样。