Trash spec: wrapping up

[David Faure]

On Tuesday 02 November 2004 10:48, you wrote:
> On Tue, 2004-11-02 at 10:04 +0300, Mikhail Ramendik wrote:
> > Alexander Larsson wrote:
> > 
> > > Thus, i propose that we store the byte string in escaped form in the
> > > trash info file. The normal desktop file escaping method doesn't allow
> > > encoding of any byte value, so we can't use that. To avoid multiple
> > > escape/unescape problems when using existing desktop parsers we
> > > shouldn't extend that method. Instead i propose that we use url-style
> > > escaping. 
> > 
> > What's the name of the standard that describes URL-style escaping and is 
> > supported in Gnome and KDE? We need to redference that in the text.
> 
> Its described in RFC 2396, section 2.4.1. We still have to decide
> exactly what characters to escape though. I think a good set of
> characters to not escape is the "unreserved characters" class in the
> RFC, plus "/".
> 
> That would mean everything is escaped except:
> 'a' - 'z', 'A'- 'Z', '0' - '9', 
> '-', '_', '.' '!', '~', '*', ''', '(', ')'
> '/'
 
The shared code for this in KDE (i.e. KURL) refers to
 RFC 1738, 2.2. URL Character Encoding Issues (pp. 3-4)
and encodes everything <=32, >=127, or among
@<>#"&%?={}|^~[]'`\:+

This conflicts on ~ and ' ... but does it matter? If one implementation
encodes '~' and the other doesn't, this is no problem, they can both 
read each other anyway.

Given the Key=Value / Key[fr]=Value format, I think the most important is to 
make sure that '=', '[', ']', control characters (<32) and non-ascii (>=127) 
are escaped, the rest doesn't matter.

If an implementation wants to escape 'a'..'z' it will look ugly, but it will still
be interoperable :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).