The problem
While writing my last
answer I noticed that
linking to external resources containing a colon does not work,
since the colon is being escaped as %3a
and thus mangled and the
URLs do not resolve any longer.
Example
Analysis
I tried to link to external resources using the markdown syntax
[description](URL)
. The URL contained unescaped colons. After
having read the RFC - Uniform Resource
Identifier I hold that colons
do not have to be escaped and that this is a bug in the
stackexchange code, rather than a fault on the external resources'
side.
Colons are listed as reserved characters. The relevant section is:
URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component. If a reserved character is found in a URI component and no delimiting role is known for that character, then it must be interpreted as representing the data octet corresponding to that character's encoding in US-ASCII.
Take this URL:
https://gitorious.org/context/context/source/b76759d73e6734cb014fe46da1f8521dcc9a8d71:metapost/context/base/mp-mlib.mpiv#L182-256
According to the RFC the colon belongs to the path part:
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment | _____________________|__ / \ / > urn:example:animal:ferret:nose
Furthermore, the path is of type
path-absolute,
which requires the syntax path-absolute = "/" [ segment-nz *( "/" segment ) ]
with segment-nz = 1*pchar
and segment = *pchar
and
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
.
This means, the path can contain all unreserved characters, encoded characters or colons, if I'm not mistaken.
Workaround
For the time being an URL shortener can be used and the shortened URL can be included. However, this is generally not desirable.
Discussion
I don't know why stackexchange alters the link in the first place. As far as I know, the parentheses enclose an URL, which is only valid if has been properly encoded by the user. No further encoding is required.
EDIT: It was indeed a bug on gitorious side. And Marcin committed a fix today, which has already been released, so the link mentioned above resolves correctly.