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

Question

这里是一个很好的问题及精彩tchrist的答案 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测试做了些什么？
在这里是类似于Perl ::批判性的utf8 - 什么会检查模块源可能的utf8错误？(因为手动检查7 + 24 + 52件事物的来源我无法归类为"简单的编程方式")
或任何其他方式？:)

据我所知,CPAN模块很多都不需要了解utf8.但这里有zilion其他应该是什么.

拜托,不要误解我.我喜欢Perl语言.我知道perl具有非常强大的utf8功能.(特别是5.14).以上并不意味着perl批判 - 但我(也可能是其他一些人)需要知道什么是CPAN模块,以及如何对它们进行分类......)

在使用多个CPAN模块进行开发时,最初一切顺利,但在最终测试中,您发现某些模块不支持utf8,因此您的部分工作无用 - 这实际上可能会导致一点幻灭.:(

编辑:

据我所知,unicode周围的所有复杂事物都有两个根源:

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

但是,回到模块:@daxim告诉:"作者甚至不会透露他们的模块是否是污点安全的,这个功能存在了几十年!" - 这是一场灾难.也许(很可能,老实说也不知道怎么做),但也许我们到了那个时候,需要对CPAN提交提出更多更严格的限制.

在一方面,我对CPAN作者的志愿者作品非常满意.另一方面,发布源代码不仅仅是一个"正确"的言论自由 - 而且应该遵守一些规则.

我理解,几乎不可能做出任何"革命",但我们可能需要一些"进化".也许标记任何CPAN模块什么不是utf8安全.标记所有不安全的东西.标记(如此处于SO中)哪个模块不符合最小编码标准并将其删除.也许我是一个理想主义者和/或天真的人.:)

Answer 1

寒冷,情况不像你想的那么可怕.除了tchrist之外,没有人能够在这种级别的Unicode正确性上运行,也可以参见亚里士多德最近的评论.与所有事情一样,你可以通过20%的努力获得80%的收益.这种基本努力,即正确地编写字符编码主题,已有详细记录; 并且jrockway在那个帖子中回答了它.

回答您的具体问题:

不,没有.没有一致的努力在中心地方收集这些信息.Perl 5 wiki可以用来记录有问题的模块,Juerd已经在uniadvice中讨论了一些.我真的希望在他们的文档中看到每个模块作者的声明"这个模块DTRT wrt编码",但我不认为它发生了.作者甚至不会透露他们的模块是否是污点安全的,这个功能存在了几十年!
encoding :: warnings可用于冒烟意外升级.我在Checklist的工作流程中提到它与Perl一起使用Unicode方式
你不能用Perl :: Critic或静态分析来做到这一点.我认为除了知识渊博的人用尖尖的角色戳它之前没有别的办法,直到它崩溃(或没有),就像mirod刚评论一样.