If a URL has unusual characters in the fragment part (i.e. after #) how should they be (percent) escaped? I can't find a consistent answer in how browsers handle this, which is probably a good reason not to have them, but I'd like to know what the 'right' answer is.
My testing seems to suggest not to escape at all, but that this is only reliable when following links, not when pasting into a browser's address bar.
I wrote a little web page as appended. I then pasted the following link into various browsers. The 'go' link in the page is there to see what happens when you click a link as opposed to pasting it (which seems to differ in some browsers)
.html/?new=1#{# &}%7B%23%20%26%7D
(I notice stackoverlow's pattern match for URLs doesn't like that - I intend the whole line; again there may be a clue for me there!)
Chrome appears to do no unescaping of any kind, and produces consistently:
#{# &}%7B%23%20%26%7D
Firefox substitutes some, but not all, of the escaped characters pasted with their non escaped equivalents, and then produces
#{# &}{# &}
and this is the same if you follow the link
Safari (on PC) does the opposite: it encodes non-encoded unusual characters on paste, and then produces
#%7B%23%20&%7D%7B%23%20%26%7D
but following the link is different, producing
#{# &}%7B%23%20%26%7D
IE9, amazingly, behaves just like Chrome
IE7 replaces the real space with %20 on paste but otherwise leaves the URL alone, and produces
#{#%20&}%7B%23%20%26%7D
and if you click the link, it gives
#{# &}%7B%23%20%26%7D
<html>
<head>
<title>test</title>
<script type="text/javascript">
function wibble() {
document.getElementById("wobble").innerHTML =
location.hash.replace(/&/g,"&").replace(/</g,"<").replace(/>/g,">");
}
</script>
</head>
<body onload='wibble()'>
<div id='wobble'></div>
<a href='/test.html?new=1#{# &}%7B%23%20%26%7D'>go</a>
</body>
</html>
If a URL has unusual characters in the fragment part (i.e. after #) how should they be (percent) escaped? I can't find a consistent answer in how browsers handle this, which is probably a good reason not to have them, but I'd like to know what the 'right' answer is.
My testing seems to suggest not to escape at all, but that this is only reliable when following links, not when pasting into a browser's address bar.
I wrote a little web page as appended. I then pasted the following link into various browsers. The 'go' link in the page is there to see what happens when you click a link as opposed to pasting it (which seems to differ in some browsers)
http://www.frankieandshadow./test.html/?new=1#{# &}%7B%23%20%26%7D
(I notice stackoverlow's pattern match for URLs doesn't like that - I intend the whole line; again there may be a clue for me there!)
Chrome appears to do no unescaping of any kind, and produces consistently:
#{# &}%7B%23%20%26%7D
Firefox substitutes some, but not all, of the escaped characters pasted with their non escaped equivalents, and then produces
#{# &}{# &}
and this is the same if you follow the link
Safari (on PC) does the opposite: it encodes non-encoded unusual characters on paste, and then produces
#%7B%23%20&%7D%7B%23%20%26%7D
but following the link is different, producing
#{# &}%7B%23%20%26%7D
IE9, amazingly, behaves just like Chrome
IE7 replaces the real space with %20 on paste but otherwise leaves the URL alone, and produces
#{#%20&}%7B%23%20%26%7D
and if you click the link, it gives
#{# &}%7B%23%20%26%7D
<html>
<head>
<title>test</title>
<script type="text/javascript">
function wibble() {
document.getElementById("wobble").innerHTML =
location.hash.replace(/&/g,"&").replace(/</g,"<").replace(/>/g,">");
}
</script>
</head>
<body onload='wibble()'>
<div id='wobble'></div>
<a href='/test.html?new=1#{# &}%7B%23%20%26%7D'>go</a>
</body>
</html>
-
Remember that entity references in an inline snippet of JavaScript like that will be expanded by the HTML parser, so the code actually says
location.hash.replace(/&/g,"&").replace(/</g,"<").replace(/>/g,">");- you probably want to use<script><![CDATA[...]]></script>– Ian Roberts Commented Dec 13, 2012 at 13:57 - That was only a little script to test with, doesn't affect the conclusions. If you don't have JS it rather misses the point. – frankieandshadow Commented Dec 17, 2012 at 18:20
1 Answer
Reset to default 7The ABNF in RFC3986 says that fragments are made up of pchars - i.e. they are percent encoded.
Which is to say that characters in fragment identifiers may be any alphanumeric or one of
-._~!$&'()*+,;=:@
All other characters should be percent encoded.