unicode转换html实体,将unicode转换为HTML实体功能

你要求的是能够安全地加倍字符编码。一些编码允许这样做。 HTML字符编码并不是因为它使用某些字符如&来进行编码，而且它不能区分用于编码的特殊字符和需要编码的特殊字符之间的区别。

例如...

use HTML::Entities;

use v5.10;

say encode_entities("&foo");

产生&foo。如果我们再次编码它会产生&foo，因为&是一个特殊的字符，它忠实地编码。 它不知道&是一个已经编码的&所以它把它当作文字&并对它进行编码。

您可能编写您自己的自定义HTML编码函数，假设&xxx;(及其变体)已被编码，但这只是一个猜测。除了文字&foo;和编码&foo;之外，你实际上不能说出。例如，它将与例如旧学校的Perl代码(如&function;)打破。也许你可以超级聪明并使用一个对象数组来指示哪些部分被编码，并让整个事物超负荷化，所以它看起来像一个字符串，只要所有的东西都小心地保留那个看起来像一个字符串的对象，我会努力...

现在我们进入lava flow anti-pattern而不是修复坏的设计，更复杂和糟糕的设计是分层的。试图“修复”这只会造成更多的问题。真正的问题在于更深层次。

真正的问题是你要多次编码。这可能意味着你已经将你的格式和功能一起使用。例如...

sub get_user_name {

my $uid = shift;

my $name = ...do a bunch of work to get the user name...

return encode_entities($name);

}

通过对数据进行HTML编码，像这样的函数就会假设数据将如何被使用。它将它的使用限制在HTML中。如果你所有的功能都这样做，你就会遇到双重编码问题。

，那么也许你有这样的事情：

sub do_something {

my $uid = shift;

# $name is already HTML encoded.

my $name = get_user_name($uid);

my $stuff = ...something incorporating $name...

# Whoops, the user name is double encoded.

return encode_entities($stuff);

}

答案是离开HTML格式和编码，直到最后一分钟。理想情况下，根本不要这样做，只需处理数据并让HTML模板系统处理它。例如，Template Toolkit。

这也提供了格式化和代码之间的清晰分离，所以现在非程序员可以使用文档化的模板系统来处理格式化。