I'm using the following script in my website in order to create pagination "next-previous" functionality. It's a actually a Dreamweaver's code. The script uses the url to get some values and then it re-creates it. The result url in IE7 and IE8 contains non-readable characters and at the end the page does not work properly.
$queryString_met = "";
if (!empty($_SERVER['QUERY_STRING'])) {
$params = explode("&", $_SERVER['QUERY_STRING']);
$newParams = array();
foreach ($params as $param) {
if (
stristr($param, "pageNum_met") == false
&& stristr($param, "totalRows_met") == false
) {
array_push($newParams, $param);
}
}
if (count($newParams) != 0) {
$queryString_met = "&" . htmlentities(implode("&", $newParams));
}
}
$queryString_met = sprintf("&totalRows_met=%d%s", $totalRows_met, $queryString_met);
Then when I display the data, I use:
<a href="<?php printf("%s?pageNum_met=%d%s", $currentPage, max(0, $pageNum_met - 1), $queryString_met); ?>"> << </a>
I don't understand which part of the code is responsible for this issue.
htmlentities(implode("&", $newParams));
htmlentities
encodes all non-ASCII bytes in your string, usually needlessly, and, if you don't specify a charset
argument, guessing your strings are in ISO-8859-1, which for Greek they definitely won't be. (Hopefully, you're using UTF-8 for everything in your site.)
Use htmlspecialchars
instead, which will leave the non-ASCII characters alone and only encode what really does have to be encoded.
However, for this to be an issue at all, you would have to be using non-ASCII characters directly in your URL. This is really unreliable; don't. Unencoded non-ASCII characters are not valid in a URI at all; they must be %
-encoded (eg. using urlencode
). IRIs allow non-ASCII characters, which browsers can automatically UTF-8-encode and %-encode to turn them into URIs, but IE doesn't (always) do that.
[Also the script to process query string will fail for any value containing the targeted names, not just those beginning with them.]