如果您创建了一篇文章，其标题中包含重音符号和其他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开发人员首先从后段代码中删除重音字符？
最合适的回答,由SO网友:David Sword 整理而成
这个sanitize_title() 函数使用remove_accents() 马上这两个函数都可以追溯到<；=v1.2.1。这个remove_accents() 函数是一个硬编码的重音字符列表，用于显式替换几种特定语言中的少数字符。内联注释和function reference 简单地说：
将所有重音字符转换为ASCII字符。
According to RFC 3986, valid URLs 仅为ASCII。
因此（虽然我找不到任何证据），我假设这里发生的事情是，替换重音字符，为只有少量ascii字符的语言创建ascii有效URL。这源于很久以前。
无效的URL/à-b-c/ 变为有效/a-b-c/ （而不是有效的编码/%wtv-b-c/ 标题）。
至于为什么WordPress不替换、删除或编码/转义中文字符（非ASCII），似乎是有意为之。同样，我找不到任何关于这方面的文档，但字符甚至不像前面提到的重音字符那样接近ascii有效，因此没有任何东西可以替代它们。转义URL将是荒谬的，几乎无法使用。和this entire thread, 尤其是this post, 了解URL中的这些字符：
[带有非ASCII字符的地址]不是URI（因此也不是URL，因为URLare a type of URIs). 如果我们认为自己受制于现有IETF标准的术语，那么我们应该正确地将其称为IRIs（国际化资源标识符），如中所定义RFC 3987, 技术上不是URI，但只需对IRI中的所有非ASCII字符进行百分比编码即可转换为URI。
因此，我假设WordPress没有这些字符的处理程序，在这些情况下，它将由用户和浏览器决定，但它从早期起就一直在清除重音。
（我意识到这个答案不能满足这个问题，但希望它能提供更多的信息，让你更接近你的答案）
SO网友:Mark Kaplun
既然我们已经有了一个“答案”，我将添加一个我自己的“答案”，尽管这也只是一个猜测。
重要的方面是10多年前i18n的状态，这不仅适用于与web相关的软件，也适用于OSs本身。当时，IDN还不是一个标准，web是面向ASCII的，如果在i18n方面做得更好，对web也没有多大好处，因为几乎没有主流操作系统支持它，例如，如果你想要支持希伯来语的windows，你必须购买一个特殊版本，或者安装一个语言包。但是，即使安装了所有适当的语言包，浏览器也有bug，在chrome之前的时代，浏览器要有新版本还需要几年时间，web服务器在正确处理URL并将其正确传递到PHP层方面也有bug。
拉丁语脚本的解决方案很简单，只需将任何非ascii的内容转换为语音正确的ascii等效。很明显，代码不处理希伯来语，尽管它有类似的口音问题。我对希伯来语的猜测是，这两种口音在正常阅读的文本中都不太重要（孩子们在很小的时候学习“想象”口音是基于对单词上下文的理解，而你真正需要它们的地方是当外语文本使用希伯来文字时，例如yiddish), 当以色列的网络真正上线时，这些bug基本上已经修复（尽管有一段时间人们倾向于避免这个问题，不使用仅在4.4中默认的永久链接，或者在英语中使用slug）。
现在，我不认为这个函数有任何作用，就像wordpress代码的其他部分一样，它是作为惯性的一部分进行维护的，而不是基于实际需要。
