Re: PHP + PostgreSQL: invalid byte sequence for encoding "UTF8"
| From: | aldnin | Date: | Sun, 22 Jul 2007 00:51:34 +0000 |
| Subject: | Re: PHP + PostgreSQL: invalid byte sequence for encoding "UTF8" | ||
| References: | 1 2 3 | Groups: | php.db |
| Request: | Send a blank email to php-db+get-43840@lists.php.net to get a copy of this message | ||
> output_handler=mb_output_handler
This helped me to fix any output to the browser properly, so I don't need to do any
utf8_decode() any more, thanks.
> Setting it to "7" won't let me even echo something else.
Right, it's strange, but true... :-(
> mbstring.detect_order = UTF-8,eucjp-win,sjis-win
That solved the problem that mb_detect_encoding() was resulting with ASCII, now its saying
"UTF-8", BUT only when running the script on console, with browser it tells me still
ASCII, well not important.
But still the comparison test is "not equal", so the ut8_decode() is still needed when
data comes from database, it's the same result in browser and on console (even it shows UTF-8
as detected).
> The other thing to be wary of, is output to the console. Some OSes do
> not support unicode in the console. So unless you're certain yours does,
> I wouldn't use it as a test.
I know, that's why I use the comparison test ;-)
Niel wrote:
> Hi
>
> You still haven't answered whether you're using any output handler, and
> if so which one. I use
>
> output_handler=mb_output_handler
>
>> I overloaded the mbstring variables with:
>> mbstring.func_overload = 6
>> Setting it to "7" won't let me even echo something else.
>
> Very strange, the only additional function overloaded is mail() and that
> shouldn't stop you using echo.
>
> As well as setting the internal encoding and enabling it with
> mbstring.encoding_translation = On
> mbstring.internal_encoding = UTF-8
>
> I would also use:
> mbstring.language = English
> ; or German in your case
> mbstring.detect_order = UTF-8,eucjp-win,sjis-win
> mbstring.http_input = UTF-8,SJIS,EUC-JP
> mbstring.http_output = UTF-8
>
>> Is it possible for mbstring to overload the pg-functions I need?
> No, and it shouldn't be needed. Those functions should be UTF-8 enabled
> in order to communicate with the database and supply the correct data
>
> You're still referring to 'UTF8' which as I pointed out isn't the
> official name of the encoding system. I have no idea if PHP will
> recognise it, but to be safe I suggest you use the official 'UTF-8'
> (hyphen between letters and number) in case it's causing problems.
> The other thing to be wary of, is output to the console. Some OSes do
> not support unicode in the console. So unless you're certain yours does,
> I wouldn't use it as a test.
>
> --
> Niel Archer