3

I'm trying to set the href of an a element using jQuery. When I set an IDN in Firefox 6, the href is url encoded. One example is the IDN http://räksmörgås.se, which is mangled to http://r%C3%A4ksm%C3%B6rg%C3%A5s.se. When I do the same in other browsers (IE8, Chrome 13, Safari 5.1), the IDN isn't encoded.

The reason I am trying to do this is that i am letting the user change hrefs and then upload a subset of the page content by ajax to a web server. I then have problems since the link is buried deep in a html string; and I'd prefer not to dig up all a elements in the html string.

Is there any way to disable the encoding of hrefs when setting it in Firefox? Or do you have any other ways I might solve the problem?

(I've noticed that if the href is a valid punycode IDN, i.e. http://www.xn--rksmrgs-5wao1o.se, the browsers are fine and dandy. But I then have to do the punycode encoding in js, something which I prefer not to; there might be one or several bugs, and there doesn't seem to be a official release of an encoder/decoder.)

The following html page displays my problem. If you input an international domain name (copy-paste "http://www.räksmörgås.se"), #linkHtml will get the entire a element, including the mangled href if using Firefox, and the correct href if using any other browser.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script>
$(document).ready(function(){
$("#linkText").focus();
$("#linkText").keyup(function() {
    var href = $(this).val();
    $("#link").attr('href', href);
    $("#linkHtml").text($("#link").parent().html());
});
});
</script>
</head>
<body>
<div><input id="linkText" type=text /></div>
<div><a id="link" href="#">link</a></div>
<span id="linkHtml"></span>
</body>
</html>
Thomas Lundström
  • 1,589
  • 1
  • 13
  • 18
  • I've seen this with TLDs that are not whitelisted by Mozilla (although .se should be ok: http://www.mozilla.org/projects/security/tld-idn-policy-list.html) so maybe there is something bug-like involved? Also see: http://idn.icann.org/Firefox_Information and http://www.slideshare.net/playingwithsid/universal-acceptability – m90 Sep 01 '11 at 10:25
  • Hmm, it looks ok to me (Firefox 6 @ ubuntu) - the updated href isnt't endoded. – WTK Sep 01 '11 at 11:25
  • @WTK, are you checking the output in the span, or in Firebug? It seems as if Firebug decodes the url, so it's not possible to only check in firebug. – Thomas Lundström Sep 01 '11 at 11:34
  • Btw, is this the same problem as http://stackoverflow.com/questions/6069187/jquery-linkify-firefox-displaying-21-instead-of-in-href-attr ? (However, the answer in that question isn't possible for this problem; I can't foresee which strange IDN:s my users are going to input.) – Thomas Lundström Sep 01 '11 at 11:37
  • These IDNs were always going to be an absolute nightmare \*sigh\* – Lightness Races in Orbit Sep 01 '11 at 11:49

1 Answers1

0

Use decodeURI (native function) if you're concerned with how this href value is displayed. Following displays ok in Firefox.

$("#linkHtml").text(decodeURI($("#link").parent().html()));

Techincally, as far as I know, even while Firefox shows encoded value you should be ok with that data after submission to some server.

WTK
  • 16,583
  • 6
  • 35
  • 45
  • It's true that decodeURI in my example shows correctly. However, I'm submitting a subset of the DOM to the server (i.e. submitting $("#someDistantParentToTheLink").html()), and I'm a bit afraid that this would decode stuff that shouldn't be decoded. – Thomas Lundström Sep 01 '11 at 11:52
  • So there you go, you shouldn't decode it - anything I know on a server side can handle that kind of decoding. You mentioned "and I'd prefer not to dig up all a elements in the html string." - what do you mean by that - dig up all a elements in the html - would the encoding/decoding change something in that matter? – WTK Sep 01 '11 at 12:12
  • Well, I am submitting a boatload of html to the server, and when the user uses Firefox, the href of all IDN links are encoded, but not when using any other browser. This means I have to hack around this by digging up all A tags on the server side and html decode them (yay, regex) iff the user uses Firefox. – Thomas Lundström Sep 01 '11 at 12:48
  • So before you save the "boatload of html" to the database (I asssume), decode it on the server side to get rid of the problem. What kind of server-side technology are you using? – WTK Sep 01 '11 at 12:54
  • Yup, that's exactly what I had to do, since it seems that there's no way to make Firefox to do what I want. – Thomas Lundström Sep 02 '11 at 14:21