Re: JDBC to load UTF8@psql to latin1@mysql
От | Emi Lu |
---|---|
Тема | Re: JDBC to load UTF8@psql to latin1@mysql |
Дата | |
Msg-id | 50CB87C7.5070600@encs.concordia.ca обсуждение исходный текст |
Ответ на | Re: JDBC to load UTF8@psql to latin1@mysql (Emi Lu <emilu@encs.concordia.ca>) |
Список | pgsql-general |
On 12/14/2012 01:37 PM, Emi Lu wrote: > Hello All, >>> Meh. That character renders as \310 in your mail, which is not an >>> assigned code in ISO 8859-1. The numerically corresponding Unicode >>> value would be U+0090, which is an unspecified control character. >> >> Oh, scratch that, apparently I can't do hex/octal arithmetic in my >> head first thing in the morning. It's really U+00C8 which is perfectly >> valid. I can't see a reason why that character and only that character >> would be problematic --- have you done systematic testing to confirm >> that that's the only should-be-LATIN1 character that fails? > > Finally, the problem is resolved: > > SHOW VARIABLES LIKE "character\_set\_%"; > +--------------------------+--------+ > | Variable_name | Value | > +--------------------------+--------+ > | character_set_client | latin1 | > | character_set_connection | latin1 | > | character_set_database | latin1 | > | character_set_filesystem | binary | > | character_set_results | latin1 | > | character_set_server | latin1 | > | character_set_system | utf8 | -- here mysql uses utf8 for > character_set_system. Another try is that if I change my client tool encoding set, I do not even need my java transition. All right, good to learn from this. Emi
В списке pgsql-general по дате отправления: