|
|
Posted by Oli Filth on 11/18/05 02:33
M. Trausch said the following on 17/11/2005 23: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.
They aren't represented the same interally at all. A literal hash in a
URL delimits an HTML reference to a named anchor, whereas %23 does not,
it's treated as part of the query string in the HTTP GET request; try
this simple test to demonstrate this:
=== test.php ====
<HTML>
<BODY>
<A href="test.php?%23blah">Test 1 (%23blah)</A>
<BR>
<A href="test.php?#blah">Test 2 (#blah)</A>
<XMP>
<?php
echo $_SERVER["REQUEST_URI"];
?>
</XMP>
</BODY>
</HTML>
> 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.
Where is it defined as "unsafe", except in RFC 1738 where it states that
it's unsafe to use # unless to delimit a named anchor reference?
Show me an example where it doesn't work...
--
Oli
Navigation:
[Reply to this message]
|