[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Module name mangling

From: Martin Grabmueller
Subject: Re: Module name mangling
Date: Tue, 30 Jan 2001 16:27:03 +0100 (MET)

> From: Marius Vollmer <address@hidden>
> Date: 30 Jan 2001 15:49:57 +0100
> Martin Grabmueller <address@hidden> writes:
> > The RFC for URL-encoding specifies so-called `safe' characters, which
> > do not need encoding.  These are alphanumeric characters an a few
> > others, like `-', `_' etc.  Unfortunaly I don't have the RFC number
> > handy, but I will try to figure that out while at university today.
> > Then I'll post the result of my search.
> > 
> > When we have a list of safe characters, the only thing we need to
> > agree upon is how we encode the unsafe ones. Am I right?
> Yes, exactly.
> Since the list is a list of safe characters, we don't have a list of
> the unsafe ones.  This means that we can't make a mapping from these
> unsafe characters to pretty encodings.  Thus, we would be back to
> hexadecimal encoding.  Hmm.

I've done some `research' and want to present the results.  Maybe it
will be useful for the discussion.

RFC1738 specifies how URLs have to look like, and also specifies which
characters are `unsafe' and `safe'.  For the full explanation, see for

In short:

Safe characters are:

alphanumerics and $-_.+!*'(),

Unsafe are all others, except when reserved characters are used for
their specific purpose (e.g. / as a path separator).

So if we want to be on the safe side and stick to URL encoding, there
is only the possibility of hex-encoding the unsafe characters.  That
would be my original patch with the safe characters (defined above)

Summary of the possibilities (please add more if you want):

1. Strict URL encoding: not beatiful but safe for the future

2. More readable encoding: will probably have to change in the future.

Martin Grabmueller              address@hidden  address@hidden on EFnet

reply via email to

[Prev in Thread] Current Thread [Next in Thread]