PHP problem handling urlencoded '&' (%26) char

Status
Not open for further replies.

FShoppe

Active Member
252
2011
6
0
Hello all,

A script we are working on deals with passing file names in the URL (via $_GET). Some files contain the '&' symbol in the name.

& is the separator in PHP to identify the new $_GET variable.

We typically use urlencode($theString) to encode 'funny' characters to be URL safe. However, PHP seems to treat the encoded '&' value in exactly the same way as if it were not encoded.

Here is an example of the problem.

File name is Q&A.jpg

The script may be like this

<?php
$fileName = $_GET[fileName];
echo $fileName;
?>

If the url in the browser was script.php?fileName=Q&A.jpg, the output would be Q.

If you url encode the file name, the url would appear as script.php?fileName=Q%26A.jpg

However the output is still just Q without the '&A.jpg'.

Similarly, we have tried using rawurlencode, but this does not fix the problem either.

Anyone familiar with this problem and know a fix?
 
16 comments
Not too sure, but I remember a bit vaguely that this used to happen because the browser is itself decoding the urlencoded char before it sends the actual GET request. This obviously has a 'fix', if you will. I just can't seem to remember it at the moment. I'll dig into my archives, see if I have a similar issue I encountered and fixed in the past.
 
urlencoded string fetches '&' character without issues here..

Tested this code snippet:

PHP:
<?php

if(isset($_GET['var'])) {
    echo $_GET['var'];
}

?>

Forks fine on Chrome 21.0.1180.57 and FF 14.0.1

Regards,
Gaurav
 
after encoding URL with urlencode() , did u decode it by urldecode on output?
PHP:
<?php
//$_GET[fileName]  == Q%26A.jpg
$fileName = $_GET[fileName];
echo urldecode($fileName);
?>

Edit : My bad urdecode is bad thing :/ thanks for reminding me out
 
Last edited:
Hi mRAza,

No I did not. This is not required as the superglobal $_GET is already url decoded. Decoding a second time may result in unexpected and unwanted problems.

Guarav, it doesnt work for me :S

---------- Post added at 06:03 PM ---------- Previous post was at 05:57 PM ----------

Okay, the code I wrote above actually DOES work. Something is wrong somewhere else, but I'm not sure where or why.

---------- Post added at 06:12 PM ---------- Previous post was at 06:03 PM ----------

Okay found the problem! But not the solution.

In fact the urlencoding DOES work, however, aparantly not in conjunction with apache's mod_rewrite.

Instead of somedomain.com/script.php?fileName=Q%26A.jpg (which works), I have been using somedomain.com/file/Q%26A.jpg (which doesnt work). Evidently, the mod_rewrite is breaking it.

Any ideas?
 
Why not strip out the & char. from the filename when its orignally uploaded?

Isn't it normal to use a function to strip out chars for filenames?




or something like this?

PHP:
 <?php
	$fileName = explode("fileName=", $_SERVER["REQUEST_URI"]);
	echo $fileName[1];
?>
 
Last edited:
Hi Gavo,

We could, and have in the past done this. But later we found a number of problems with things like Chinese characters and so on. Now, we support all file names, even those including quotes and tildes. But the & seems to be the only thing left.

We rather not make the system impose these kinds of restrictions and just make our system better instead.

We have a new system in production that would be well suited for extremely large number of files (100s of thousands). It is not feasible to rename all files, and also not desirable.
 
The code above will work with any encoding i think

Code:
index1.php?fileName='Q%$£"%$"£>&A.jpg

echo'd filename  'Q%$£"%$"£>&A.jpg
 
This does what you ask in the 1st post

PHP:
 <?php
	$fileName = explode("fileName=", $_SERVER["REQUEST_URI"]);
	echo $fileName[1];
?>


Post script.php?fileName=Q&A.jpg and the filename will be Q&A.jpg
 
mRAza, The B flag does indeed seem to be exactly what I need. But it produces a 500 server error for some reason. Not sure why at the moment. Still researching.

Gavo, I'm afraid I'm lost. Does this help with the mod_rewrite problem?

---------- Post added at 08:15 PM ---------- Previous post was at 08:04 PM ----------

Looks like an apache version issue.

---------- Post added at 08:43 PM ---------- Previous post was at 08:15 PM ----------

mRAza, I can confirm the problem with the B flag is the apache version. Apparantly it was only made available from 2.2.7 and has since been known to have bugs till at least 2.2.9. The version we currently use is 2.2.3 and though we could just update, it needs to be tested first, which annoyingly means we need to come up with a work around for the time being.

We have opted to double encode ONLY the & char, and not everything else. So instead of "%26" it will be "%2526" and this seems to work.

Thanks for the help everyone. And thanks for finding that B flag. I'm sure that will be most useful when we take the plunge to upgrade.
 
Status
Not open for further replies.
Back
Top