Sebastian Rose wrote: >David Maus writes: >>> sh$ man utf-8 >> >> Thanks! I finally get a grip on one of my personal nightmares. >It's not that bad, is it? :D Even better: It makes sense ;) >> The attached patch is the first step in this direction: It modifies >> the algorithm of `org-link-escape', now iterating over the input >> string with `mapconcat' and escaping all characters in the escape >> table or are between 127 and 255. >Between 128 (1000 0000) and 255 ?? >The binary representation of 127 is 0111 1111 and valid ascii char. DEL >actually (sh$ man ascii) Right, and that's why it is encoded: No control characters in a URI. The final algorithm for the shiny new unicode aware percent encoding function would be: - percent encode all characters in TABLE - percent encode all characters below 32 and above 126 - encode the char in utf-8 - percent escape all bytes of the encoded char The remaining problem is keeping backward compatibility. There are Org files out there where "รก" is encoded as "%E1" and not "%C3A1". The percent decoding function should be able to recognize these old escapes and return the right value. I looks like this could be done by changing the behavior of `org-protocol-unhex-string'. Currently it returns the empty string for "%E1" because it does not represent a valid utf-8 encoded unicode char. Maybe we could say: If the percent encoded sequence does not form a valid char, use the old method (extended ASCII?) to decode the sequences. Sadly (or luckily?) chances are good that I will be somewhat offline for the next two weeks -- I think implementing this unicode aware escaping function should be the way to go but requires some careful checking for it's consequences for old Org files. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmjena@jabber.org Email..... dmaus@ictsoc.de