From: Sebastian Rose <sebastian_rose@gmx.de>
To: David Maus <dmaus@ictsoc.de>
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>, emacs-orgmode@gnu.org
Subject: Re: [bug] org-link-escape and (wrong-type-argument stringp nil)
Date: Wed, 22 Sep 2010 16:25:46 +0200 [thread overview]
Message-ID: <87fwx1yhw5.fsf@gmx.de> (raw)
In-Reply-To: <87sk128cuk.wl%dmaus@ictsoc.de> (David Maus's message of "Wed, 22 Sep 2010 09:19:15 +0200")
David Maus <dmaus@ictsoc.de> writes:
> Sebastian Rose wrote:
>>Is there a reason for this distinction between multibyte and unibyte?
>>I favour the "shotgun-approach" if not. It's bullet-proof.
>
>>The JavaScript function `encodeURIComponent()' encodes the German Umlaut
>>`ü' as `%C3%B6' regardless of the sources encoding actually. That's why
>>I wrote the two functions `org-protocol-unhex-string' and
>>`org-protocol-unhex-compound' (s. org-protocol.el).
>
> Ah, yes. From my understandig of the RFC %C3%BC is a valid
> representation of the "ü" character.
>
> I do not yet fully understand
> how to unescape such a representation. E.g. Is %C3%BC a hexencoded
> multibyte char or a succession of two singlebyte chars?
It's a hexencoded multibyte char.
JavaScript implementations seem to turn non-ascii singlebyte chars into
multibyte chars first, then encode the result.
This means if a page is iso-8859-1 encoded (singlebyte `ü'), JavaScript
will recode the `ü'. It's funny, but that's what I found when writing
org-protocol.el
`org-protocol-unhex-string' and `org-protocol-unhex-compound' decode
such a representation.
The trick is in the utf-8 encoding itself. If a byte starts with a 1,
another byte will follow. The number of leading `1's denotes the amount
of bytes used for one character. On a GNU/Linux system try
sh$ man utf-8
Sebastian
next prev parent reply other threads:[~2010-09-22 14:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 12:42 [bug] org-link-escape and (wrong-type-argument stringp nil) Sébastien Vauban
2010-09-20 18:57 ` David Maus
2010-09-20 19:31 ` Sebastian Rose
2010-09-22 7:19 ` David Maus
2010-09-22 14:25 ` Sebastian Rose [this message]
2010-09-23 18:40 ` David Maus
2010-09-23 19:57 ` Sebastian Rose
2010-09-26 18:22 ` David Maus
2010-09-26 21:23 ` Sebastian Rose
2010-09-26 22:43 ` Sebastian Rose
2010-09-26 22:47 ` Sebastian Rose
2010-09-26 22:51 ` Sebastian Rose
2010-09-27 5:36 ` [PATCH] " David Maus
2010-09-27 12:43 ` Sebastian Rose
2010-09-29 15:48 ` Carsten Dominik
2010-09-27 5:36 ` [PATCH] Decode single byte sequence if decoding unicode failed David Maus
2010-11-04 20:35 ` [bug] org-link-escape and (wrong-type-argument stringp nil) David Maus
2010-09-20 19:49 ` Sébastien Vauban
2010-09-22 7:20 ` David Maus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fwx1yhw5.fsf@gmx.de \
--to=sebastian_rose@gmx.de \
--cc=dmaus@ictsoc.de \
--cc=emacs-orgmode@gnu.org \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).