I was trying to comment to Marc Gravel, but the URL I pasted kept getting corrupted.

The URL is http://eval.ironscheme.net/?id=(number->string+(char->integer+%23%5C)+16)

Interestingly, Twitter explodes when given the above URL, thinking it is longer than 140 chars.

As you can see it already goes ape shit...

Another try with encoded URL: http://eval.ironscheme.net/?id=(number-%3Estring+(char-%3Einteger+%23%5C%EE%93%BB)+16)

In comments, the trailing ) gets truncated. (See 3rd comment)



As Nick Craver noted, the Unicode char is in the PAU, but the bug happens regardless of that.



  • eval.ironscheme.net/…)+16)
    – leppie
    Oct 27, 2011 at 9:50
  • Hmmm, the behavior here seems different from StackOverlow. eval.ironscheme.net/…)+16) Another test
    – leppie
    Oct 27, 2011 at 9:51
  • Encoded URL test: eval.ironscheme.net/…
    – leppie
    Oct 27, 2011 at 9:53
  • Stack Exchange websites do not support invalid URL's - I also reported something related to links becoming "corrupted" and was told something along those words. Oct 27, 2011 at 10:15
  • Just an aside...don't just twitter's URL shortening, well, anything...their "shortener" is completely incompetent at recognizing and shortening (or lengthening, now) a very large number of URLs, or things that aren't URLs (different, but also ridiculous behavior topic). Oct 27, 2011 at 10:36
  • @ShadowWizard: Those URL's are perfectly valid. Why do you say they are invalid?
    – leppie
    Oct 27, 2011 at 10:36
  • @leppie - The unicode in your URL is in the private use area, which isn't necessarily in agreement on both sides and is discouraged when sharing links for just that reason. You can refer to rule C073 here: w3.org/TR/charmod/#sec-PrivateUse There's a reason this is discouraged... Oct 27, 2011 at 10:48
  • @NickCraver: Did not realize this was a PUA Unicode char. But I am sure the bug will happen without it.
    – leppie
    Oct 27, 2011 at 10:54
  • @leppie - don't assume, try and see! Oct 27, 2011 at 10:54
  • Testing without PAU: eval.ironscheme.net/…
    – leppie
    Oct 27, 2011 at 10:55
  • @NickCraver: Same issue...
    – leppie
    Oct 27, 2011 at 10:55
  • Testing: eval.ironscheme.net/… Oct 27, 2011 at 10:56
  • @NickCraver: Updated the question with non-PAU chars.
    – leppie
    Oct 27, 2011 at 10:57
  • @NickCraver: How did you get that right? The link is correct for your comment.
    – leppie
    Oct 27, 2011 at 10:58
  • 2
    @leppie - I escaped the ) at the end, as \) Oct 27, 2011 at 11:00

2 Answers 2


Assuming the only part left here is the part with the parenthesis:

A closing parenthesis at the end is never considered to be part of the link when auto-hyperlinking URLs, because this pattern is way too common:

@Joe Turtles should be allowed to move freely (see http://freedom-of-MOVETO.com).

There may be ways to make that a little smarter, and I'm considering some, but the bottom line is:

Auto-detection of links in free text can only ever work in the 99% case.*

And since it's way more common for a link to be in parentheses than for a link to end with a parenthesis, that's what happens.

By the way, when creating manual links, we allow one level of nested parens to work with the standard case, e.g. Wikipedia or MSDN:

Check [Wikipedia](http://en.wikipedia.org/wiki/Turtle_(disambiguation)) for the different meanings.

Since your example has two levels of parentheses, this wouldn't have worked either, so you'd actually have to URL-encode. Links to URLs containing parentheses has some more on that (note though that that's in the context of full Markdown, not comments).

*We could do worse, though.

  • +1: Thanks for the explanation. Probably why links are normally shown in angle brackets, eg: < http://foo.com >
    – leppie
    Oct 27, 2011 at 12:02
  • 3
    Any chance an exemption could be made for wikipedia.org URLs? They rely on foo (category) links extensively and are the most common source of broken URLs I see on SO.
    – sarnold
    Nov 7, 2011 at 2:16

For posterity, one way that you can fix this by changing the closing paren to be %29. For example, the following URL will not be detected correctly and will drop the closing paren:


Versus this one with %29 instead of the closing paren does work and finds the correct anchor



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .