记住在 PHP 中完成所有与 Unicode 相关的工作以使其正常工作实在太棘手、繁琐且容易出错,因此我正在寻找一种方法,通过使用一个简单的声明,让 PHP 魔法般地将绝对可能的一切从古老的ASCII字节模式升级到现代Unicode字符模式。
这个想法是为了使 PHP 脚本现代化,以便与 Unicode 一起使用,而不必在源代码中添加一堆令人困惑的替代函数调用和特殊的正则表达式。一切都应该只是“做正确的事情”,不需要问任何问题。
鉴于目标是最大程度地使用Unicode,最小限度地烦扰,这个声明必须至少执行以下操作(以及我忘记的任何其他有助于实现总体目标的操作):
PHP脚本源代码本身被认为是UTF-8编码的(例如,字符串和正则表达式)。
所有输入和输出都会根据需要自动转换为/从UTF-8,并提供规范化选项(例如,将所有输入规范化为NFD并将所有输出规范化为NFC)。
所有具有Unicode版本的函数都使用这些版本(例如,
sort
的Collator::sort
)。所有字节函数(例如,
strlen
、strstr
、strpos
和substr
)的工作方式都像相应的字符函数(例如,mb_strlen
、mb_strstr
、mb_strpos
和mb_substr
)。所有正则表达式和正则表达式函数都透明地处理Unicode(即,像所有preggers隐含地附加了
/u
,以及像\w
、\b
和\s
等东西都按照Unicode标准所要求的方式工作,等等)。
额外加分:),我希望有一种方法可以将此声明“升级”到完整的字形模式。这样,字节或字符函数就变成了字形函数(例如,grapheme_strlen
、grapheme_strstr
、grapheme_strpos
和grapheme_substr
),正则表达式也可以在正确的字形上工作(即,.
——甚至[^abc]
——匹配一个Unicode字形簇,无论它包含多少个代码点,等等)。
mbstring.func_overload
,我觉得应该有一种方法使其适用于其他函数,包括grapheme_*
。同样地,被弃用的mb_regex_set_options
似乎正是所需的——只是它不包括/u
用于preg_*
。为什么这么麻烦呢?问题是PHP的模块/扩展机制不够丰富,无法使这些扩展自然而易于编写吗?你不能在某个表中添加一些东西吗,尤其是在第一个情况下?谢谢,Pascal。 - tchristunicode_semantics = On
。我猜那从未发生过。他们真的最终在内部使用了令人讨厌的 UTF-16 吗?我希望不是:由于 ASCII 标记的密度,UTF-8 使得即使对于 CJK 来说,HTML 或 XML 更小。 - tchrist