为什么现代Perl默认会避免使用UTF-8？

Question

我想知道为什么使用Perl构建的大多数现代解决方案默认情况下都不启用UTF-8。

我知道核心Perl脚本存在许多遗留问题，可能会破坏它们。但是，从我的观点来看，在21世纪，大型新项目（或具有重大视角的项目）应该使他们的软件UTF-8从头开始证明。我仍然没有看到它发生。例如，Moose启用严格和警告，但不启用Unicode。 Modern::Perl也减少了样板，但没有UTF-8处理。

为什么呢？有没有理由在2011年的现代Perl项目中避免使用UTF-8？

---

评论@tchrist太长了，所以我在这里添加它。

似乎我没有说清楚。让我尝试添加一些东西。

tchrist 我看到情况非常相似，但我们的结论完全是相反的。我同意，Unicode的情况很复杂，但这就是为什么我们（Perl用户和编码人员）需要一些层（或编译指示），这使得UTF-8处理变得像现在一样容易。

tchrist 指出要涵盖的许多方面，我会阅读并思考它们几天甚至几周。不过，这不是我的观点。 tchrist 试图证明没有一种方法“启用UTF-8”。我没有太多的知识可以与之争辩。所以，我坚持实例。

我和Rakudo一起玩，UTF-8就在那里，因为我需要。我没有任何问题，它只是奏效了。也许在某些地方存在一些限制，但一开始，我测试的所有工作都按照我的预期进行。

这不应该是现代Perl 5的目标吗？我更强调一点：我不是建议将UTF-8作为核心Perl的默认字符集，我建议有可能为那些开发 new 并快速 >项目。

另一个例子，但有更负面的基调。框架应该使开发更容易。几年前，我尝试过Web框架，但只是把它们扔掉了，因为“启用UTF-8”是如此模糊。我没有找到如何以及在何处挂钩Unicode支持。这是非常耗时的，我发现它更容易走老路。现在，我在这里看到了Mason 2： How to make Mason2 UTF-8 clean? 处理相同问题的赏金。因此，它是一个非常新的框架，但使用UTF-8需要深入了解其内部。这就像一个大红色标志：停止，不要使用我！

我真的很喜欢Perl。但处理Unicode是痛苦的。我仍然发现自己在墙上奔跑。某种方式 tchrist 是正确的并回答了我的问题：新项目不会吸引UTF-8，因为它在Perl 5中过于复杂。

Answer 1

Answer 2

Answer 3

我们都同意这是一个很难解决的问题，原因很多， 但这正是试图让每个人都更轻松的原因。

CPAN上有一个最近的模块，utf8::all，它试图“打开Unicode。所有这些”。

正如已经指出的那样，你不能神奇地使整个系统（外部程序，外部Web请求等）也使用Unicode，但我们可以合作制作合理的工具，使常见问题更容易。这就是我们是程序员的原因。

如果utf8 :: all没有做你认为应该做的事情，让我们改进它以使其变得更好。或者让我们一起制作其他工具，以便尽可能满足人们的各种需求。

`

Answer 4

我认为你误解了Unicode及其与Perl的关系。无论您以何种方式存储数据，Unicode，ISO-8859-1或许多其他内容，您的程序都必须知道如何解释它作为输入（解码）获取的字节以及如何表示它想要输出的信息（编码） ）。得到错误的解释，你搞砸了数据。你的程序中没有一些神奇的默认设置可以告诉你程序之外的东西如何行动。

你认为很难，很可能，因为你习惯了所有的ASCII。您应该考虑的所有内容都被编程语言和它必须与之交互的所有内容所忽略。如果一切都只使用UTF-8而你别无选择，那么UTF-8也会如此简单。但并非所有东西都使用UTF-8。例如，你不希望你的输入句柄认为它正在获得UTF-8八位字节，除非它实际上是，并且如果从它们读取的东西可以处理UTF-8你不希望你的输出句柄是UTF-8 。 Perl无法知道这些事情。这就是你是程序员的原因。

我不认为Perl 5中的Unicode太复杂了。我认为这很可怕，人们会避免它。有区别。为此，我将Unicode放在 Learning Perl，第6版中，并且 Effective Perl Programming 中有很多Unicode内容。您必须花时间学习和理解Unicode及其工作原理。否则你无法有效地使用它。

Answer 5

在阅读此主题时，我经常会觉得人们使用“UTF-8”作为“Unicode”的同义词。请区分Unicode的“代码点”，它是ASCII代码的放大相对和Unicode的各种“编码”。还有一些，其中UTF-8，UTF-16和UTF-32是当前的，还有一些是过时的。

请UTF-8（以及所有其他编码）存在且仅在输入或输出中有意义。在内部，从Perl 5.8.1开始，所有字符串都保存为Unicode“Code-points”。没错，你必须启用一些前所未有的功能。

Answer 6

在野外存在着一种真正可怕的古代代码，其中大部分都是常见的CPAN模块。我发现如果我使用可能受其影响的外部模块，我必须非常小心地启用Unicode，并且我仍然试图在我经常使用的几个Perl脚本中识别并修复一些与Unicode相关的故障（特别是{{由于转码问题，3}}对于非7位ASCII的任何事情都会严重失败。）

Answer 7

您应该启用unicode字符串功能，如果您使用v5.14;

，这是默认设置

你不应该真的使用unicode标识符esp。对于通过utf8的外国代码，因为它们在perl5中不安全，只有cperl才能做到这一点。参见例如http://perl11.org/blog/unicode-identifiers.html

关于文件句柄/流的utf8：您需要自己决定外部数据的编码。一个库无法知道，因为即使libc不支持utf8，也很少有正确的utf8数据。还有更多的wtf8，utf8的窗户像差。

BTW：Moose并不是真正的“现代Perl”，他们只是劫持了这个名字。 Moose是完美的Larry Wall风格的后现代perl混合了Bjarne Stroustrup风格的一切，伴随着正确的perl6语法的折衷差异，例如使用字符串作为变量名，可怕的字段语法，以及一个非常不成熟的天真实现，比正确的实现慢10倍。 cperl和perl6是真正的现代perls，其中form跟随函数，并且实现被减少和优化。