为什么WordPress后鼻涕虫不允许口音？

Question

如果您创建一个标题中带有重音的帖子，并在其中添加其他unicode字符(如à 漢語 title thing )，则其段塞(permalink)将成为a-漢語-title-thing.即，à被转换成一个普通的a，但是那些unicode汉字没有受到影响。为什么WordPress不让重音字符单独出现呢？我创建了一个代码片段，告诉WordPress不要对它们进行任何处理

function mn_sanitize_title($modified_title, $original_title, $context)
{
    // the $modified_title may have had accents removed, but not the $original_title
    return $original_title;
}
// set this filter to run BEFORE WP already ran the title through `sanitize_title_with_dashes`
add_filter('sanitize_title', 'mn_sanitize_title', 5, 3);

而且它似乎工作得很好(重音字符在后弹格中保持不变)，所以我想知道为什么WordPress开发人员一开始就从后置段塞中删除了重音字符？

Answer 1

sanitize_title()函数立即使用remove_accents()。这两个函数都可以追溯到<= v1.2.1。remove_accents()函数是一个硬编码的重音字符列表，用于显式替换少数几种特定语言中的字符。内联评论和功能参考简单地说：

将所有重音字符转换为ASCII字符。

根据RFC 3986，有效的URL只是ASCII。

所以(虽然我找不到这方面的任何证据)，我认为这里发生的事情是，重音字符被替换成一个ascii有效的URL，对于只有几个几乎-ascii字符的语言。这起源于很久以前。

无效的URL /à-b-c/变成有效的/a-b-c/ (而不是有效的编码/%wtv-b-c/标题)。

至于为什么中文字符(不是ASCII)不被WordPress替换、条纹化或编码/转义似乎是有意的。再说一遍，我找不到任何关于这方面的文档，但是这些字符甚至不接近ascii--就像前面提到的重音字符一样有效，所以没有什么可以替换它们的。转义URL将是荒谬的，几乎无法使用。整个线程，特别是这个职位，在URL中对这些字符做了一些说明：

不是URI(因此也不是URL，因为URL是是URI的一种类型)。如果我们认为自己遵守现有IETF标准的术语，那么我们应该正确地将它们称为IRIs (国际化资源标识符)，正如RFC 3987中定义的那样，它们在技术上不是IRI，但可以通过对IRI中的所有非ASCII字符进行百分比编码来转换为IRI。

因此，我假设WordPress没有这些字符的处理程序，在这些情况下，它将由用户和浏览器来处理，但从早期开始就一直在清除重音。

(我意识到这个答案不能满足这个问题，但希望它能提供更多的信息，让你更接近你的答案)。

Answer 2

既然我们已经有了一个“答案”，我会添加一个我自己的“答案”，尽管这也不过是猜测而已。

重要的方面是多年前i18n 10+的状态，这不仅适用于web相关软件，也适用于开放源码软件本身。那时IDN还不是一个标准，而且网络是面向ASCII的，如果在i18n上做得更好也不会有什么好处，因为几乎没有主流操作系统支持它，例如，如果你想要支持希伯来语的窗口，你必须购买一个特别的版本，或者安装一个语言包。但是，即使安装了所有适当的语言包，浏览器也有错误，而在chrome之前的年代，浏览器需要数年才能获得新版本，web服务器在正确处理URL并将它们正确传递给PHP层时也有错误。

拉丁文的解决方案很简单，只需将任何不是ascii的内容转换为语音上正确的ASCII等价。很明显，该代码不处理希伯来语，尽管它有类似的口音问题。我对希伯来语的猜测是，在通常阅读的文本中，这两种口音都不那么重要(孩子们在很小的时候就开始根据单词的上下文来学习“想象”口音，而你真正需要它们的地方是外语文本使用希伯来语脚本(例如伊迪什) )，而当网络真正进入以色列时，这些bug大多是固定的(尽管有一段时间，人们更愿意通过不使用仅在4.4中默认的漂亮的permalinks来避免问题，或者在英语中使用段塞)。

现在，我不认为这个函数能提供任何服务，就像wordpress代码的其他部分一样，它是作为惯性的一部分来维护的，而不是基于实际需要。