hironobu wrote:
> nkeric wrote:
>>> I guess it should be something reated to mysql's internal encoding?
>>> AFAIK, you will need to specified mysql's encoding to utf-8 before
>>> using it :)
>> - since mysql version >= 5.0 :)
>
> Thank you.
>
> MySQL version is 4.1, so it may differ a little fro
Malcolm writes:
>I think you forgot to attach the patch. :-)
Yes, indeed. Thank you.
I posted the patch.
And now I'm checking MySQL settings and 5.0's handling.
This problem may disappear on another environment,
then I'll report details later.
--~--~-~--~~~---~--~--
nkeric wrote:
>> I guess it should be something reated to mysql's internal encoding?
>> AFAIK, you will need to specified mysql's encoding to utf-8 before
>> using it :)
>- since mysql version >= 5.0 :)
Thank you.
MySQL version is 4.1, so it may differ a little from your guess,
but this is reall
nkeric wrote:
> I guess it should be something reated to mysql's internal encoding?
> AFAIK, you will need to specified mysql's encoding to utf-8 before
> using it :)
- since mysql version >= 5.0 :)
--~--~-~--~~~---~--~~
You received this message because you are
FYI, we're using django's 0.95 trunk version to handle Chinese
contents, django works properly whether with sqlite3 or postgresql as
its db backend. pre-magic-removal django worked properly too.
I guess it should be something reated to mysql's internal encoding?
AFAIK, you will need to specified
On Tue, 2006-05-23 at 21:47 -0700, hironobu wrote:
> Hello, Django users and developers.
>
> I'd been trying to handle non-ascii string (such as Japanese text) from
> MySQL database for recent several days, on version 0.95
> "post-magic-removal". Django loads onto memory as raw byte strings and
Hello, Django users and developers.
I'd been trying to handle non-ascii string (such as Japanese text) from
MySQL database for recent several days, on version 0.95
"post-magic-removal". Django loads onto memory as raw byte strings and
saves similarly too, so string data I can see directly on dat
7 matches
Mail list logo
