- From: <Irene.Vatton@inrialpes.fr>
- Date: Fri, 09 Jul 1999 09:15:25 +0200
- To: Bertrand.Ibrahim@cui.unige.ch
- cc: www-amaya@w3.org
In-reply-to: Your message of Thu, 08 Jul 1999 18:35:52 +0200."
<0FEK00DCZ8RTLB@cuimail.unige.ch>
> jose.kahan@w3.org said:
> > If we're making a local file access, we'll then first convert the %26
> > into '&' then do search the file
>
> I guess you're assuming that, in this case, the '&' will be part of a file
> or directory name, not a field separator in the <searchpart>. Indeed, if you
> look at RFC 1738, section 5 (BNF for specific URL schemes), you find:
Obviously yes.
> fileurl = "file://" [ host | "localhost" ] "/" fpath
>
> and
>
> fpath = fsegment *[ "/" fsegment ]
> fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
>
> In addition, section 3.10, describing the file URL scheme, says:
>
> "A file URL takes the form:
>
> file://<host>/<path>
>
> ... <path> is a hierarchical
> directory path of the form <directory>/<directory>/.../<name>."
>
> I interpret this as meaning that a file URL can contain unreserved characters
> or escaped characters or any of '?', ':', '@', '&' and '='. All these
> characters will be considered as part of a directory name or a file name.
When a URL which contains a '&' is stored within a HREF attribute it has to be
encoded either by & or by %26.
Irene.
Received on Friday, 9 July 1999 03:15:30 UTC