Browse Source

Fix link encoding bug:

Geert Kloosterman writes:

> When an org link is created from an URL containing a hex escape
> `org-make-link-string' creates a link that ends up corrupted the moment
> it is followed (e.g. using `org-open-at-point').
>
> I've traced this back to `org-link-escape' and `org-link-unescape'.  The
> following shows how the hex code "%2B" is converted to a "+" after an
> escaping round trip:
>
>    (org-link-unescape (org-link-escape
>                        "http://some.host.com/form?&id=blah%2Bblah"))
>    ==>
>    "http://some.host.com/form?&id=blah+blah"
>
> In my case this small change ended up in a broken URL.
>
> Additionally, when the URL-escape happens to be in lower case (or
> otherwise not present in `org-link-escape-chars') we end up with an
> error:
>
>    (org-link-unescape (org-link-escape
>                        "http://some.host.com/form?&id=blah%2bblah"))
>    ==>
>    Debugger entered--Lisp error: (wrong-type-argument characterp nil)
>      char-to-string(nil)
>      ...
>
> When `org-url-encoding-use-url-hexify' is set to `t' we do get a proper
> round trip of the URL containing hex-escapes:
>
>    (setq org-url-encoding-use-url-hexify t)
>    (org-link-unescape (org-link-escape
>                        "http://some.host.com/form?&id=blah%2bblah"))
>    ==>
>    "http://some.host.com/form?&id=blah%2bblah"
>
>
> Setting `org-url-encoding-use-url-hexify' does not fix the complete
> problem however: `org-open-at-point' still did not end up with the
> proper URL.   Within `org-open-at-point' there is another call to
> `org-link-escape':
>
>    (org-link-escape path org-link-escape-chars-browser)
>
> This time a mapping table is passed in explicitly (the second argument).
> However, when `org-url-encoding-use-url-hexify' is set,a this mapping
> table isn't used, resulting (again) in a broken URL.
>
> I have attached a patch that fixes the problem: do not use url-hexify in
> `org-link-escape' and `org-link-unescape' when an explicit mapping table
> has been specified.
>
> In summary:
> - the default behaviour of `org-link-escape', with
>   `org-url-encoding-use-url-hexify' set to nil, has some issues with
>   handling URLS which contain url-encoded hex escapes
> - when a mapping table is passed to `org-link-escape' and
>   `org-link-unescape', they should probably not use url-hexify.
>   Patch attached.
Carsten Dominik 15 years ago
parent
commit
dcf34971f6
2 changed files with 7 additions and 2 deletions
  1. 5 0
      lisp/ChangeLog
  2. 2 2
      lisp/org.el

+ 5 - 0
lisp/ChangeLog

@@ -1,3 +1,8 @@
+2010-01-16  Carsten Dominik  <carsten.dominik@gmail.com>
+
+	* org.el (org-link-unescape, org-link-escape): Only use hexlify if
+	the table is not explicitly given.
+
 2010-01-15  Carsten Dominik  <carsten.dominik@gmail.com>
 
 	* org-clock.el (org-clock-out-when-done): Allow a list of keywords

+ 2 - 2
lisp/org.el

@@ -7893,7 +7893,7 @@ This is the list that is used before handing over to the browser.")
 
 (defun org-link-escape (text &optional table)
   "Escape characters in TEXT that are problematic for links."
-  (if org-url-encoding-use-url-hexify
+  (if (and org-url-encoding-use-url-hexify (not table))
       (url-hexify-string text)
     (setq table (or table org-link-escape-chars))
     (when text
@@ -7910,7 +7910,7 @@ This is the list that is used before handing over to the browser.")
 
 (defun org-link-unescape (text &optional table)
   "Reverse the action of `org-link-escape'."
-  (if org-url-encoding-use-url-hexify
+  (if (and org-url-encoding-use-url-hexify (not table))
       (url-unhex-string text)
     (setq table (or table org-link-escape-chars))
     (when text