469,923 Members | 1,350 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,923 developers. It's quick & easy.

urlencode and $_GET

urlencode turns # into %23
When I sent it thru $_GET, it dissapears, along with anything that comes
after it.

for example:
urlencode turns
HOYDM_EXC_#4_NAT
into HOYDM_EXC_%234_NAT

When I use it in an url
index.php?id=HOYDM_EXC_%234_NAT

$_GET[id]=HOYDM_EXC_

Am I doing something wrong ?
Nov 22 '05 #1
27 5039
meltedown wrote:

Hi,
urlencode turns # into %23
Yes.
When I sent it thru $_GET, it dissapears, along with anything that comes
after it.
What does that mean?
"sending through $_GET" ???
Do you mean you use some URL?

You do not send anything through $_GET, you use $_GET to retrieve values
encoded in GET.

for example:
urlencode turns
HOYDM_EXC_#4_NAT
into HOYDM_EXC_%234_NAT

yes.
When I use it in an url
index.php?id=HOYDM_EXC_%234_NAT

$_GET[id]=HOYDM_EXC_

Am I doing something wrong ?


Yes.

If you want the value of 'id' from the URL (GET) use:

$bla = $_GET["id"];

Regards,
Erwin Moller

Nov 22 '05 #2
try NOT encoding the original url (it's the browser's job), but DO
decode the "incoming" url.

Nov 22 '05 #3
Erwin Moller wrote:
meltedown wrote:

Hi,

urlencode turns # into %23

Yes.

When I sent it thru $_GET, it dissapears, along with anything that comes
after it.

What does that mean?
"sending through $_GET" ???
Do you mean you use some URL?

You do not send anything through $_GET, you use $_GET to retrieve values
encoded in GET.


And how does it get there- you send it there. So you are sending it
throught $_GET
for example:
urlencode turns
HOYDM_EXC_#4_NAT
into HOYDM_EXC_%234_NAT
yes.

When I use it in an url
index.php?id=HOYDM_EXC_%234_NAT

$_GET[id]=HOYDM_EXC_

Am I doing something wrong ?

Yes.

If you want the value of 'id' from the URL (GET) use:

$bla = $_GET["id"];


Yes of course I know that- I'm not talking about getting the value from
$_GET. I am saying that the value of $_GET is equal to "HOYDM_EXC_". Its
obvious what I meant. The point is, the end of the string is missing.
Do you now whether this is a common problem ?
Regards,
Erwin Moller

Nov 22 '05 #4
black francis wrote:
try NOT encoding the original url (it's the browser's job), but DO
decode the "incoming" url.

I tried this even though it doesn't make any sense.
Browsers don't do anything to #. As far as I can see, it is not the
browsers job to encode anything in the url. #'s are not allowed in URLs.
Thats what urlencode() is for, and it works fine. The question is: why
doesn't %23 and everything after it make it to $_GET ?
Nov 22 '05 #5
meltedown wrote:
black francis wrote:
try NOT encoding the original url (it's the browser's job), but DO
decode the "incoming" url.
I tried this even though it doesn't make any sense.
Browsers don't do anything to #. As far as I can see, it is not the
browsers job to encode anything in the url. #'s are not allowed in URLs.


clarificatin: # are allowed in urls, but only as part of an anchor
identifyer.
Thats what urlencode() is for, and it works fine. The question is: why
doesn't %23 and everything after it make it to $_GET ?

Nov 22 '05 #6
meltedown wrote:
Erwin Moller wrote:
meltedown wrote:

Hi,

urlencode turns # into %23


Yes.

When I sent it thru $_GET, it dissapears, along with anything that comes
after it.


What does that mean?
"sending through $_GET" ???
Do you mean you use some URL?

You do not send anything through $_GET, you use $_GET to retrieve
values encoded in GET.

And how does it get there- you send it there. So you are sending it
throught $_GET

for example:
urlencode turns
HOYDM_EXC_#4_NAT
into HOYDM_EXC_%234_NAT

yes.

When I use it in an url
index.php?id=HOYDM_EXC_%234_NAT

$_GET[id]=HOYDM_EXC_

Am I doing something wrong ?


Yes.

If you want the value of 'id' from the URL (GET) use:

$bla = $_GET["id"];

Yes of course I know that- I'm not talking about getting the value from
$_GET. I am saying that the value of $_GET is equal to "HOYDM_EXC_". Its
obvious what I meant. The point is, the end of the string is missing.
Do you now whether this is a common problem ?

Regards,
Erwin Moller


Can you post your code?

I've encoded a '#' before with no problems at all.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 22 '05 #7
meltedown wrote:

clarificatin: # are allowed in urls, but only as part of an anchor
identifyer.
Thats what urlencode() is for, and it works fine. The question is: why
doesn't %23 and everything after it make it to $_GET ?


That's because the browser treats %23 as #... e.g., you cannot use that
character, as it's local to the browser as a named-anchor. Use a
different character. The browser treats all URL escaped characters *as
the character it is*, so you can encode spaces and ~ and all sorts of
other things into the URL.

- Mike

--
Strip the obvious trash from the header to send e-mail.
Nov 22 '05 #8
Jerry Stuckle wrote:
Can you post your code?

I've encoded a '#' before with no problems at all.

Thanks for telling me that. Apparently, this not a common problem but
something wrong with my code. After you told me that, I did this simple
example.

http://reenie.org/test/test16.php?value=start%23end
After you hit the link, it says
$_GET is:Array ( [value] => start#end )
#end is not missing, so it works fine

Here's the code for the example
echo "\$_GET is:";
print_r($_GET);
echo "<br>\n";
$value="start#end";
echo "value is:$value<br>\n";
$value=urlencode($value);
echo "value after urlencode is:$value<br>\n";
echo "<a href='?value=".$value."'>test link</a>";

I'm still trying to figure out how to make an example of the original
problem.
Nov 22 '05 #9
meltedown wrote:

<snip>

And how does it get there- you send it there. So you are sending it
throught $_GET


Well, I had the impression you didn't understand that part.
But appearantly you do.

for example:
urlencode turns
HOYDM_EXC_#4_NAT
into HOYDM_EXC_%234_NAT

yes.

When I use it in an url
index.php?id=HOYDM_EXC_%234_NAT

$_GET[id]=HOYDM_EXC_
This part is where you confused me.
It looks like you want to ADD stuff to the $_GET-array, which doesn't make
much sense.


Am I doing something wrong ?

Yes.

If you want the value of 'id' from the URL (GET) use:

$bla = $_GET["id"];


Yes of course I know that- I'm not talking about getting the value from
$_GET. I am saying that the value of $_GET is equal to "HOYDM_EXC_". Its
obvious what I meant. The point is, the end of the string is missing.
Do you now whether this is a common problem ?


I do not see the problem to be honest.
I just tested on my own machine (PHP5) the follwing:

http://bla.bla.bla/test.php?id=HJUYH_%234_NAT

from php.test:

$id = $_GET["id"];
// ID now contains HJUYH_#4_NAT

Which is excactly what is expected.

So show us some more code.

Regards,
Erwin Moller
Nov 22 '05 #10
M. Trausch wrote:
meltedown wrote:
clarificatin: # are allowed in urls, but only as part of an anchor
identifyer.

Thats what urlencode() is for, and it works fine. The question is: why
doesn't %23 and everything after it make it to $_GET ?


That's because the browser treats %23 as #...

Right. but its a # which is not an anchor.
e.g., you cannot use that character, as it's local to the browser as a named-anchor. Use a
different character. The browser treats all URL escaped characters *as
the character it is*, Yes that's what I want it to do.
You can use that charactar as something besided an anchor, as long as it
is encoded. See the example I just posted in this thread.

so you can encode spaces and ~ and all sorts of other things into the URL.

- Mike

Nov 22 '05 #11
M. Trausch said the following on 17/11/2005 14:22:
meltedown wrote:
clarificatin: # are allowed in urls, but only as part of an anchor
identifyer.

Thats what urlencode() is for, and it works fine. The question is: why
doesn't %23 and everything after it make it to $_GET ?


That's because the browser treats %23 as #... e.g., you cannot use that
character, as it's local to the browser as a named-anchor.


What? No it doesn't.

--
Oli
Nov 22 '05 #12
Erwin Moller wrote:

I do not see the problem to be honest.
I just tested on my own machine (PHP5) the follwing:

http://bla.bla.bla/test.php?id=HJUYH_%234_NAT

from php.test:

$id = $_GET["id"];
// ID now contains HJUYH_#4_NAT

Which is excactly what is expected.

So show us some more code.

Regards,
Erwin Moller

Right, I believe you. I know what it is now. Its not a PHP problem, its
a mod rewrite problem. Sorry, I left it out because I was trying not to
complicate my explaination.

if I use
http://thecigar-auction.com/item.php...NROSA_%234_NAT
it works fine.

but if I use:
http://thecigar-auction.com/santa-ro..._%234_NAT.html
The last part gets tuncated into SANROSA_

Here's the rewrite rule :
RewriteRule ([^/]+)/([^/]+)\.html$ /item.php?id=$2&cname=$1

The second ([^/])+ is the culprit, but I'm not sure how to fix it.
Presumably, it doesn't recognize %

Right now I have fixed the problem with a hack
$id=preg_replace("|#|",'_PDSGN_',$id);
So this example now looks like:
http://thecigar-auction.com/santa-ro...SGN_4_NAT.html

Nov 22 '05 #13
meltedown wrote:
Jerry Stuckle wrote:
Can you post your code?

I've encoded a '#' before with no problems at all.

Thanks for telling me that. Apparently, this not a common problem but
something wrong with my code. After you told me that, I did this simple
example.

http://reenie.org/test/test16.php?value=start%23end
After you hit the link, it says
$_GET is:Array ( [value] => start#end )
#end is not missing, so it works fine

Here's the code for the example
echo "\$_GET is:";
print_r($_GET);
echo "<br>\n";
$value="start#end";
echo "value is:$value<br>\n";
$value=urlencode($value);
echo "value after urlencode is:$value<br>\n";
echo "<a href='?value=".$value."'>test link</a>";

I'm still trying to figure out how to make an example of the original
problem.


Yes, it looks like it's doing exactly what it's supposed to do.

I suspect a logic problem in your code. Look at the URL in your browser
bar in your original code. It should have something like:

http://www.example.com?value=start%23end

If instead of the "%23" you have a "#", the problem is you didn't get it
encoded properly. OTOH, if it you have something like "?value=" or
"?value=start" you probably didn't get the string concatenated properly.

You can also look at the HTML source for the page you're linking from.
There you should see:

<a href="http://www.example.com/testpage?value=start%23end">test link</a>

These things can be difficult to find sometimes!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 22 '05 #14
again, it's the browser the one who 'encodes' the url, not you.

try-n-see:
<a href="example.php?var=one word"> turns into
"example.php?var=one+word" in the address bar.

what you should never use un a url is an ampersand (use &amp; instead
of &), any other character is encoded by the browser.

Nov 22 '05 #15
Oli Filth wrote:

That's because the browser treats %23 as #... e.g., you cannot use that
character, as it's local to the browser as a named-anchor.


What? No it doesn't.


According to RFC 1738, the characters that should be escaped in a URL
are {\$&+,:/=?@}. It defines the following characters to be unsafe, and
hence undefined as to how the application can/will handle it and remain
compliant with the RFC: { "`'<>#%\{\}|\\\^~[]}

So... you're partially right. It doesn't *have* to. The point is that
the intended use of the hash mark is as a named-anchor reference. It
doesn't have to be passed. It depends on the application's
implementation of RFC 1738.

Regards,
Mike

--
Strip the obvious trash from the header to send e-mail.
Nov 22 '05 #16
black francis wrote:
again, it's the browser the one who 'encodes' the url, not you.

try-n-see:
<a href="example.php?var=one word"> turns into
"example.php?var=one+word" in the address bar.

what you should never use un a url is an ampersand (use &amp; instead
of &), any other character is encoded by the browser.


Wrong.

The browser will convert a space to a + sign. The other characters need
to be encoded before being sent to the browser so they don't get
interpreted incorrectly.

Hence the urlencode() function. Read up on it in the PHP doc.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 22 '05 #17
M. Trausch said the following on 17/11/2005 19:17:
Oli Filth wrote:
That's because the browser treats %23 as #... e.g., you cannot use that
character, as it's local to the browser as a named-anchor.


What? No it doesn't.

According to RFC 1738, the characters that should be escaped in a URL
are {\$&+,:/=?@}. It defines the following characters to be unsafe, and
hence undefined as to how the application can/will handle it and remain
compliant with the RFC: { "`'<>#%\{\}|\\\^~[]}

So... you're partially right. It doesn't *have* to. The point is that
the intended use of the hash mark is as a named-anchor reference. It
doesn't have to be passed. It depends on the application's
implementation of RFC 1738.


My point was that the browse *never* treats %23 in a URL as #, it treats
it as %23.
--
Oli
Nov 22 '05 #18
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.
Nov 22 '05 #19
On 17 Nov 2005 11:16:24 -0800, "black francis" <cr***************@gmail.com>
wrote:
again, it's the browser the one who 'encodes' the url, not you.

try-n-see:
<a href="example.php?var=one word"> turns into
"example.php?var=one+word" in the address bar.


That's the browser (whichever one you're using) attempting to compensate for
your badly encoded URL. This is not behaviour you should rely on.

In fact I don't know what browser you're using, because IE, Firefox and Opera
attempt to correct the invalid URL by converting the space to %20, not +.

Putting that source through an HTML validator (HTML Tidy) produces:

line 1 column 1 - Warning: <a> escaping malformed URI reference

error: <...> escaping malformed URI reference
Cause:

An URI contains non-authorized characters. Or the quotes around the URI are not
closed.
Solution:

Correct the URI.
Samples:

error: <a> escaping malformed URI reference

BAD <a href="http://www.mozilla.org/one space.html">space</a>
GOOD <a href="http://www.mozilla.org/one%20space.html">space</a>
GOOD <a href="http://www.mozilla.org/one+space.html">space</a>

BAD <a href="http://www.w3c.org>w3c</a>
GOOD <a href="http://www.w3c.org">w3c</a>

For the first example, a space should not be contained in URL. (Even if it
works in all browsers...). This is described in detail in the RFC1738 (Look for
Unsafe)
References:

RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax"
RFC1738 - Uniform Resource Locators
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Nov 22 '05 #20
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
Nov 22 '05 #21
Oli Filth wrote:

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:

That's very much like saying the character # on the right side of a hex
dump and the '23' on the left side of a hex dump aren't represented
internally at all. It's just a character reference, either way. Just
because one may receive a flag that the other doesn't in one instance or
several instances does not mean that it will in *all* instances.

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...


The fact is that the published standard which addresses the issue states
that it's unsafe. It is wise to be cautious and write defensively
towards something you can refer, then away from it, even if it does work
on 98% of the browsers. My point was that you cannot make a blanket
assumption about something when it's already known that it's unsafe and
the behavior of an action is undefined. There are many examples of
things going wrong with code in the past, related only to the fact that
something didn't follow the rules or the standards because at one time
it was safe to do so, and any one of a million particular vendors made a
change that altered the application behavior, yet maintaining the
standard, and guess what breaks? The application.

If you work defensively to start with, you'll never be bit like that in
the future.

The standards that are out there that deal with escaping of characters
also denotes that the application, in many cases, has the right to make
a difference or not, depending on context, and that the safe behavior is
action x and that people (read: programmers) shouldn't rely on the
behavior of something at one time just because something is permitted in
a set of applications.

Bluntly, that's like saying, "Well, I speed through area X every day,
and the X police department never pulls me over," when area X has a
speed limit of 55 MPH. Common sense tells you that it's unsafe (read:
introducing a risk) if you drive faster then that. Just because you
haven't been bitten yet by it, doesn't mean you won't ever be.

- Mike

--
Strip the obvious trash from the header to send e-mail.
Nov 22 '05 #22
M. Trausch said the following on 18/11/2005 01:49:
Oli Filth wrote:
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:

That's very much like saying the character # on the right side of a hex
dump and the '23' on the left side of a hex dump aren't represented
internally at all. It's just a character reference, either way. Just
because one may receive a flag that the other doesn't in one instance or
several instances does not mean that it will in *all* instances.


%23 is a character reference, yes, but not an *HTML* character
reference/entity, it's merely a way of representing # in an HTTP GET
string, and means nothing in the context of HTML.

The browser treats %23 as exactly that, the literal characters %, 2, 3.
In the context of a clicked hyperlink, these exact characters are
transmitted in the corresponding HTTP GET request string. e.g. the
following link:

<A href="http://example.com/file.php?%23xyz">...</A>

will result in the following HTTP request:

GET /file.php?%23xyz HTTP/1.1
Host: example.com

At no point between the server delivering the original HTML to the
browser and the server receiving the GET request has %23 been decoded.

On the other hand, the browser treats the literal # as a delimiter (as
defined by HTML specs), and strips that (and everything after it) from
the URL before the HTTP request is made. e.g. the following link:

<A href="http://example.com/file.php?#xyz">...</A>

will result in the following HTTP request:

GET /file.php? HTTP/1.1
Host: example.com

Entirely different behaviour, working at a different layer (HTML vs.
HTTP), completely defined by the specs (W3C HTML specs, and RFC 1738).

If you had tried the demo code I posted earlier, you would see this in
action.

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...


The fact is that the published standard which addresses the issue states
that it's unsafe.


No, it states that it's unsafe to use # in cases other than where you
mean it to be a delimiter for an HTML anchor identifier.

In cases where you do not intend it as a delimiter, you should encode it
with the alternative, %23, because this *is* safe (defined as such in
RFC 1738), and when received by the agent processing the HTTP GET
request (i.e. the server), it is translated into the originally intended
character, i.e. #.

It is wise to be cautious and write defensively
towards something you can refer, then away from it, even if it does work
on 98% of the browsers. My point was that you cannot make a blanket
assumption about something when it's already known that it's unsafe and
the behavior of an action is undefined.


However, the behaviour *is* *completely* defined, so any agent (browser,
server, or otherwise) that behaves differently is in explicit breach of
the specs, i.e. a bug.

--
Oli
Nov 22 '05 #23
sorry, it`s 'one space.html' -> 'one%20space.html' not '+'.

as u said, it's 'unsafe' to use spaces according to the rcf, therefore
the browser encodes them (isn`t that rfc compliant?)

btw: the w3 validator isn't yelling anything by using a space in the
url (html 4.01 strict, xhtml 1.0 strict & transitional).
btw2: %23 gets treated as %23, not #.

Nov 22 '05 #24
black francis wrote:
sorry, it`s 'one space.html' -> 'one%20space.html' not '+'.

as u said, it's 'unsafe' to use spaces according to the rcf, therefore
the browser encodes them (isn`t that rfc compliant?)

btw: the w3 validator isn't yelling anything by using a space in the
url (html 4.01 strict, xhtml 1.0 strict & transitional).
btw2: %23 gets treated as %23, not #.

http://reenie.org/test/test16.php?value=start%23end
click on this url and the first line tells you the value of $_GET
It says: $_GET is:Array ( [value] => start#end )

So it looks to me like the %23 is treated as #.

Nov 22 '05 #25
meltedown said the following on 18/11/2005 17:17:
black francis wrote:
sorry, it`s 'one space.html' -> 'one%20space.html' not '+'.

as u said, it's 'unsafe' to use spaces according to the rcf, therefore
the browser encodes them (isn`t that rfc compliant?)

btw: the w3 validator isn't yelling anything by using a space in the
url (html 4.01 strict, xhtml 1.0 strict & transitional).
btw2: %23 gets treated as %23, not #.

http://reenie.org/test/test16.php?value=start%23end
click on this url and the first line tells you the value of $_GET
It says: $_GET is:Array ( [value] => start#end )

So it looks to me like the %23 is treated as #.


Yes, but now try echoing $_SERVER["REQUEST_URI"].

It is PHP that translates the octet, not the browser.

--
Oli
Nov 22 '05 #26
i mean it's treated like '%23' to the browser, not php.
php by default decodes the incoming string (as u realize in the above
example)

Nov 22 '05 #27
Oli Filth wrote:
meltedown said the following on 18/11/2005 17:17:
black francis wrote:
sorry, it`s 'one space.html' -> 'one%20space.html' not '+'.

as u said, it's 'unsafe' to use spaces according to the rcf, therefore
the browser encodes them (isn`t that rfc compliant?)

btw: the w3 validator isn't yelling anything by using a space in the
url (html 4.01 strict, xhtml 1.0 strict & transitional).
btw2: %23 gets treated as %23, not #.

http://reenie.org/test/test16.php?value=start%23end
click on this url and the first line tells you the value of $_GET
It says: $_GET is:Array ( [value] => start#end )

So it looks to me like the %23 is treated as #.


Yes, but now try echoing $_SERVER["REQUEST_URI"].

It is PHP that translates the octet, not the browser.

OKIE DOKIE.
I added the output from $_SERVER["REQUEST_URI"]
to http://reenie.org/test/test16.php?value=start%23end
Just for the hell of it.
I guess the browser didn't change it after all.
Nov 22 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Joshua Beall | last post: by
32 posts views Thread by Nuno Paquete | last post: by
3 posts views Thread by JP SIngh | last post: by
1 post views Thread by yawnmoth | last post: by
1 post views Thread by Jim | last post: by
12 posts views Thread by sleytr | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.