|
|
Posted by M. Trausch on 11/18/05 01:23
Oli Filth wrote:
>
> My point was that the browse *never* treats %23 in a URL as #, it treats
> it as %23.
>
%23 is the encoding for #.
There is no meaningful separation save for the representation of it.
The character is the same. Just as %20 is a space. All that "escaped"
form is, is the ASCII character number written in hexadecimal after a
percent symbol to let the URL-aware application know that it's about to
encounter a hex character code -- internally, they are pretty well
represented the same -- the character number 0x23 or 0x20, respectively.
Also, because the standard doesn't explicitly declare or define it as
anything except for "unsafe," you cannot make a blanket assumption as to
how any URL-aware application will treat the differentiation between an
escaped hexadecimal value and the actual character itself. That's
(partly) why it's unsafe. There are too many browsers and too many
interpretations of the standard, by too many different people, for
*anyone* able to issue such a blanket statement. The safest option for
anything which is undefined or unsafe, is to work around it in a fashion
that is safe, and defined. So, probably in this instance, substituting
it for another, or something along those lines.
It's akin to certain HTML tags or JavaScript methods or code; it's not
defined as safe, and it's not cross-platform, so it's not guaranteed to
work. Hence, you can't say that a particular method or code segment
will always work without testing it -- and who tests their code in every
known browser on every platform? Surely, nobody that I've ever met;
it's next to impossible. Though I have met some people that have tested
code in a far lot more places then most.
Regards,
Mike
--
Strip the obvious trash from the header to send e-mail.
Navigation:
[Reply to this message]
|