Re: Encoding Problem in export?

[Nicolas Goaziou <n.goaziou@gmail.com>]

David Maus <dmaus@ictsoc.de> writes:

Thanks for your answer. It seems I got confused with the current state
of URI-encoding. Please scratch my previous suggestion and let's start
over.

> The assumption underlying the current implementation is
> to delegate dealing with forbidden characters to the consuming
> application.

I agree with this assumption, even though I think some URI-fixing (à la
`url-encode-url') would be nice too. But that's not the topic here.
Also, the current implementation doesn't totally follow this assumption
(e.g. `org-link-escape-chars-browser').

Alas, there is a serious flaw in the current implementation. As you
said:

> There is, of course, the nasty thing that we don't know if the link in
> a buffer went through org-link-escape or not. E.g. if you paste
>
>  ,----
> | [[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]]
>  `----
>
> into the buffer you'll get a broken link because org-link-open assumes
> the link to be escaped by org.

There is, indeed, no easy way to know if a link went through
`org-link-escape', so we cannot unescape it properly in every situation.
We could use text properties on escaped links, but that seems awkward.

I think there is a simpler solution: we never "unescape" links, which
means that escaping must be at its minimum. For example, we could only
replace "[" and "]" with, respectively, "%5B" and "%5D" and newlines
with spaces. It doesn't cripple link's readability very mucĥ, and is
safe as "[", "]" and "\n" are always forbidden in URI anyway.

Replacing non-ascii characters would make the link unreadable to
a human. Also, we don't prevent encoding mismatch (e.g., from UTF-8 to
ISO-8859-1) when yanking regular text in an Org buffer, so there's no
particular reason to do it for links.

This operation is clearly idempotent.

When sending the URL to the consuming, there will be problems, according
to the assumption at the beginning of this message. But that is to be
expected.


Regards,

-- 
Nicolas Goaziou