I am trying to render text from a user with a url like this in it: https://example.com/%20%23654
I pass the url to urlize and I get this:
tracks
I understand that 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>'
escapes to a space and %20
to a hash, but why is it only escaping the hash in the href? Is this a bug? If it were intended, why is it not escaping the %23
to blank space?
答案 0 :(得分:2)
我不认为这是一个错误。
我看到这个问题的两个部分:
为什么它只是取消哈希而不是空间? 为什么它只在href中进行unescaping而不是在可见的链接文本中?
以下是我对第一个问题的看法:
哈希是一个完全合法的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
。
问题的第二部分是为什么它只是在链接中没有出现而在可见的描述中没有出现。这也是有道理的。在href中,无论您是传递https://example.com/%66
还是https://example.com/f
都无关紧要。效果是一样的,描述是在引擎盖下。&#34;所以urlize
使用最简单的形式,没有不必要的编码。另一方面,可见部分呈现给用户。因此,urlize
试图保留最初传递的确切描述,因为这是最不令人惊讶的事情。