我正在尝试使用这样的 url 呈现来自用户的文本：https ://example.com/%20%23654
我将 url 传递给 urlize，我得到了这个：
In[1]: outp = urlize('https://example.com/%20%23654'); print outp
Out[1]: u'<a href="https://example.com/%20#654">https://example.com/%20%23654</a>'
我知道会%20转义到空格和%23散列，但为什么它只转义href中的散列？这是一个错误吗？如果它是有意的，为什么它不逃逸%20到空白空间？
我不认为这是一个错误。
我看到这个问题的两个部分：
为什么它只对散列而不是空间进行转义？为什么它只在 href 中而不是在可见链接文本中进行取消转义？
以下是我对第一个的想法：
哈希是完全合法的 URL 路径字符。它最常用于 HTML 中的锚点（示例和文档链接合二为一！）：
http://www.w3.org/TR/html4/struct/links.html#h-12.2
urlize意识到这一点。它对href中的哈希进行转义。它适用于任何合法 URL 字符的字母。这是一个带有字母的示例f：
>>> urlize('https://example.com/%66')
u'<a href="https://example.com/f">https://example.com/%66</a>'
另一方面，空格不是合法的 URL 字符（尽管通常可以容忍）。%20因此，它在链接和可见链接描述中都保持编码。
问题的第二部分是为什么它只在链接中取消转义而不在可见描述中。这也是有道理的。https://example.com/%66在href中，传入或传入都没有关系https://example.com/f。效果是一样的，描绘的是“引擎盖下”。所以urlize使用最简单的形式，没有不必要的编码。另一方面，可视部分呈现给用户。因此，urlize尝试保留它最初传入的确切描述，因为这是最不令人惊讶的事情。