On 5/28/09 3:21 PM, "Nitsan Bin-Nun" <nitsan@xxxxxxxxxxxx> wrote:
> That's the thing, I do NOT know the encoding of the GET parameters.
in which case that preg_replace is _extremely_ risky.
> They are not submitting any form, the request is made through a link (<a>
> tag).
if you have control over the pages that include these links then i would
think the right thing to do is encode the pages as uft8 and encode the urls
percent-encoded utf8.
(pay attention to the issues with the php functions urlencode and
rawurlencode, neither of which, i have read, conform to RFC 3986. i have
taken to using str_replace("%7E", "~", rawurlencode($s)), which i believe
does, though i have not carefully checked myself.)
otherwise i think you have no choice but to figure out how those uris are
encoded by manual trial and error. if you are potentially dealing with more
than one single-byte encoding (e.g. iso 8859-1, win-1250, 1251, 1252, 1255)
then there's no simple way to automatically detect which is which.
>> I'm afraid that I don't have access to the php.ini, since it's a shared
>> hosting, do you know if hostgator gives access to php.ini or let you changes
>> it's values?
>
> i have no idea. but i imagine it is sufficient to use ini_set().
>
>
>
> I have used the ini_set() you submitted but no luck yet.
>
> Any further ideas or suggestions will be appreciated :)
the value default_charset is probably not related to the problem. it's
probably related to the issues above.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
