If I pass request fields or cookies with a period/dot in their names, PHP auto-replaces them with underscores. For example, if I put this code at https://example.com/test.php?x.y=a.b:
<?php echo $_SERVER['REQUEST_URI']; echo $_GET['x.y']; echo $_GET['x_y']; the output is:
/test.php?x.y=a.b a.b Is there any way I can prevent this behaviour?
Here's PHP.net's explanation of why it does it:
Dots in incoming variable names
Typically, PHP does not alter the names of variables when they are passed into a script. However, it should be noted that the dot (period, full stop) is not a valid character in a PHP variable name. For the reason, look at it:
<?php $varname.ext; /* invalid variable name */ ?>Now, what the parser sees is a variable named $varname, followed by the string concatenation operator, followed by the barestring (i.e. unquoted string which doesn't match any known key or reserved words) 'ext'. Obviously, this doesn't have the intended result.
For this reason, it is important to note that PHP will automatically replace any dots in incoming variable names with underscores.
That's from http://ca.php.net/variables.external.
Also, according to this comment these other characters are converted to underscores:
The full list of field-name characters that PHP converts to _ (underscore) is the following (not just dot):
- chr(32) ( ) (space)
- chr(46) (.) (dot)
- chr(91) ([) (open square bracket)
- chr(128) - chr(159) (various)
So it looks like you're stuck with it, so you'll have to convert the underscores back to dots in your script using dawnerd's suggestion (I'd just use str_replace though.)
Long-since answered question, but there is actually a better answer (or work-around). PHP lets you at the raw input stream, so you can do something like this:
$query_string = file_get_contents('php://input'); which will give you the $_POST array in query string format, periods as they should be.
You can then parse it if you need (as per POSTer's comment)
<?php // Function to fix up PHP's messing up input containing dots, etc. // `$source` can be either 'POST' or 'GET' function getRealInput($source) { $pairs = explode("&", $source == 'POST' ? file_get_contents("php://input") : $_SERVER['QUERY_STRING']); $vars = array(); foreach ($pairs as $pair) { $nv = explode("=", $pair); $name = urldecode($nv[0]); $value = urldecode($nv[1]); $vars[$name] = $value; } return $vars; } // Wrapper functions specifically for GET and POST: function getRealGET() { return getRealInput('GET'); } function getRealPOST() { return getRealInput('POST'); } ?> Hugely useful for OpenID parameters, which contain both '.' and '_', each with a certain meaning!
file_get_contents("php://input") with $_SERVER['QUERY_STRING'].
$_SERVER['COOKIES']
Highlighting an actual answer by Johan in a comment above - I just wrapped my entire post in a top-level array which completely bypasses the problem with no heavy processing required.
In the form you do
<input name="data[database.username]"> <input name="data[database.password]"> <input name="data[something.else.really.deep]"> instead of
<input name="database.username"> <input name="database.password"> <input name="something.else.really.deep"> and in the post handler, just unwrap it:
$posdata = $_POST['data']; For me this was a two-line change, as my views were entirely templated.
FYI. I am using dots in my field names to edit trees of grouped data.
Do you want a solution that is standards compliant, and works with deep arrays (for example: ?param[2][5]=10) ?
To fix all possible sources of this problem, you can apply at the very top of your PHP code:
$_GET = fix( $_SERVER['QUERY_STRING'] ); $_POST = fix( file_get_contents('php://input') ); $_COOKIE = fix( $_SERVER['HTTP_COOKIE'] ); The working of this function is a neat idea that I came up during my summer vacation of 2013. Do not be discouraged by a simple regex, it just grabs all query names, encodes them (so dots are preserved), and then uses a normal parse_str() function.
function fix($source) { $source = preg_replace_callback( '/(^|(?<=&))[^=[&]+/', function($key) { return bin2hex(urldecode($key[0])); }, $source ); parse_str($source, $post); $result = array(); foreach ($post as $key => $val) { $result[hex2bin($key)] = $val; } return $result; } 
a[2][5]=10 produces array(1) { ["a"]=> array(1) { [2]=> array(1) { [5]=> string(2) "10" } } }.This happens because a period is an invalid character in a variable's name, the reason for which lies very deep in the implementation of PHP, so there are no easy fixes (yet).
In the meantime you can work around this issue by:
php://input for POST data or $_SERVER['QUERY_STRING'] for GET dataThe below conversion function (PHP >= 5.4) encodes the names of each key-value pair into a hexadecimal representation and then performs a regular parse_str(); once done, it reverts the hexadecimal names back into their original form:
function parse_qs($data) { $data = preg_replace_callback('/(?:^|(?<=&))[^=[]+/', function($match) { return bin2hex(urldecode($match[0])); }, $data); parse_str($data, $values); return array_combine(array_map('hex2bin', array_keys($values)), $values); } // work with the raw query string $data = parse_qs($_SERVER['QUERY_STRING']); Or:
// handle posted data (this only works with application/x-www-form-urlencoded) $data = parse_qs(file_get_contents('php://input')); 
bin2hex() idea from mine, so can we just drop this pointless feud?This approach is an altered version of Rok Kralj's, but with some tweaking to work, to improve efficiency (avoids unnecessary callbacks, encoding and decoding on unaffected keys) and to correctly handle array keys.
A gist with tests is available and any feedback or suggestions are welcome here or there.
public function fix(&$target, $source, $keep = false) { if (!$source) { return; } $keys = array(); $source = preg_replace_callback( '/ # Match at start of string or & (?:^|(?<=&)) # Exclude cases where the period is in brackets, e.g. foo[bar.blarg] [^=&\[]* # Affected cases: periods and spaces (?:\.|%20) # Keep matching until assignment, next variable, end of string or # start of an array [^=&\[]* /x', function ($key) use (&$keys) { $keys[] = $key = base64_encode(urldecode($key[0])); return urlencode($key); }, $source ); if (!$keep) { $target = array(); } parse_str($source, $data); foreach ($data as $key => $val) { // Only unprocess encoded keys if (!in_array($key, $keys)) { $target[$key] = $val; continue; } $key = base64_decode($key); $target[$key] = $val; if ($keep) { // Keep a copy in the underscore key version $key = preg_replace('/(\.| )/', '_', $key); $target[$key] = $val; } } } 
parse_str call will again urldecode. What are you trying ot parse that's not encoded already?The reason this happens is because of PHP's old register_globals functionality. The . character is not a valid character in a variable name, so PHP coverts it to an underscore in order to make sure there's compatibility.
In short, it's not a good practice to do periods in URL variables.
If looking for any way to literally get PHP to stop replacing '.' characters in $_GET or $_POST arrays, then one such way is to modify PHP's source (and in this case it is relatively straightforward).
WARNING: Modifying PHP C source is an advanced option!
Also see this PHP bug report which suggests the same modification.
To explore you'll need to:
. replacement checkThe source change itself is trivial and involves updating just one half of one line in main/php_variables.c:
.... /* ensure that we don't have spaces or dots in the variable name (not binary safe) */ for (p = var; *p; p++) { if (*p == ' ' /*|| *p == '.'*/) { *p='_'; .... Note: compared to original || *p == '.' has been commented-out
Example Output:
given a QUERY_STRING of a.a[]=bb&a.a[]=BB&c%20c=dd, running <?php print_r($_GET); now produces:
Array ( [a.a] => Array ( [0] => bb [1] => BB ) [c_c] => dd )
Notes:
parse_str() and (if unavailable) fall-back to slower methods. My solution to this problem was quick and dirty, but I still like it. I simply wanted to post a list of filenames that were checked on the form. I used base64_encode to encode the filenames within the markup and then just decoded it with base64_decode prior to using them.
After looking at Rok's solution I have come up with a version which addresses the limitations in my answer below, crb's above and Rok's solution as well. See a my improved version.
@crb's answer above is a good start, but there are a couple of problems.
The solution below addresses both of these problems now (note that it has been updated since originally posted). This is about 50% faster than my answer above in my testing, but will not handle situations where the data has the same key (or a key which gets extracted the same, e.g. foo.bar and foo_bar are both extracted as foo_bar).
<?php public function fix2(&$target, $source, $keep = false) { if (!$source) { return; } preg_match_all( '/ # Match at start of string or & (?:^|(?<=&)) # Exclude cases where the period is in brackets, e.g. foo[bar.blarg] [^=&\[]* # Affected cases: periods and spaces (?:\.|%20) # Keep matching until assignment, next variable, end of string or # start of an array [^=&\[]* /x', $source, $matches ); foreach (current($matches) as $key) { $key = urldecode($key); $badKey = preg_replace('/(\.| )/', '_', $key); if (isset($target[$badKey])) { // Duplicate values may have already unset this $target[$key] = $target[$badKey]; if (!$keep) { unset($target[$badKey]); } } } } 
%20 is also a special character that gets converted to underscore. 2. Your code preproceses all the data, since preg_match_all has to scan everything, even though you say you don't. 3. Your code fails at examples like this: a.b[10]=11.preg_match_all has to "process" one string, not extract and reprocess all the unaffected keys and values, so you're a little off track there as well. That said, your approach with parse_string looks like an interesting approach that, with a bit of tweaking, might be better :)O(n). In fact, you are making the complexity worse, using the in_array() function, as pointed above.in_array anyway. Also, if you care to run some tests, you'll notice that the above is still significantly faster; not O(n) vs O(n^2), but one linear approach can still be faster than another... and this one is ;)Well, the function I include below, "getRealPostArray()", isn't a pretty solution, but it handles arrays and supports both names: "alpha_beta" and "alpha.beta":
<input type='text' value='First-.' name='alpha.beta[a.b][]' /><br> <input type='text' value='Second-.' name='alpha.beta[a.b][]' /><br> <input type='text' value='First-_' name='alpha_beta[a.b][]' /><br> <input type='text' value='Second-_' name='alpha_beta[a.b][]' /><br> whereas var_dump($_POST) produces:
'alpha_beta' => array (size=1) 'a.b' => array (size=4) 0 => string 'First-.' (length=7) 1 => string 'Second-.' (length=8) 2 => string 'First-_' (length=7) 3 => string 'Second-_' (length=8) var_dump( getRealPostArray()) produces:
'alpha.beta' => array (size=1) 'a.b' => array (size=2) 0 => string 'First-.' (length=7) 1 => string 'Second-.' (length=8) 'alpha_beta' => array (size=1) 'a.b' => array (size=2) 0 => string 'First-_' (length=7) 1 => string 'Second-_' (length=8) The function, for what it's worth:
function getRealPostArray() { if ($_SERVER['REQUEST_METHOD'] !== 'POST') {#Nothing to do return null; } $neverANamePart = '~#~'; #Any arbitrary string never expected in a 'name' $postdata = file_get_contents("php://input"); $post = []; $rebuiltpairs = []; $postraws = explode('&', $postdata); foreach ($postraws as $postraw) { #Each is a string like: 'xxxx=yyyy' $keyvalpair = explode('=',$postraw); if (empty($keyvalpair[1])) { $keyvalpair[1] = ''; } $pos = strpos($keyvalpair[0],'%5B'); if ($pos !== false) { $str1 = substr($keyvalpair[0], 0, $pos); $str2 = substr($keyvalpair[0], $pos); $str1 = str_replace('.',$neverANamePart,$str1); $keyvalpair[0] = $str1.$str2; } else { $keyvalpair[0] = str_replace('.',$neverANamePart,$keyvalpair[0]); } $rebuiltpair = implode('=',$keyvalpair); $rebuiltpairs[]=$rebuiltpair; } $rebuiltpostdata = implode('&',$rebuiltpairs); parse_str($rebuiltpostdata, $post); $fixedpost = []; foreach ($post as $key => $val) { $fixedpost[str_replace($neverANamePart,'.',$key)] = $val; } return $fixedpost; } Using crb's I wanted to recreate the $_POST array as a whole though keep in mind you'll still have to ensure you're encoding and decoding correctly both at the client and the server. It's important to understand when a character is truly invalid and it is truly valid. Additionally people should still and always escape client data before using it with any database command without exception.
<?php unset($_POST); $_POST = array(); $p0 = explode('&',file_get_contents('php://input')); foreach ($p0 as $key => $value) { $p1 = explode('=',$value); $_POST[$p1[0]] = $p1[1]; //OR... //$_POST[urldecode($p1[0])] = urldecode($p1[1]); } print_r($_POST); ?> I recommend using this only for individual cases only, offhand I'm not sure about the negative points of putting this at the top of your primary header file.
My current solution (based on prev topic replies):
function parseQueryString($data) { $data = rawurldecode($data); $pattern = '/(?:^|(?<=&))[^=&\[]*[^=&\[]*/'; $data = preg_replace_callback($pattern, function ($match){ return bin2hex(urldecode($match[0])); }, $data); parse_str($data, $values); return array_combine(array_map('hex2bin', array_keys($values)), $values); } $_GET = parseQueryString($_SERVER['QUERY_STRING']); 
