Re: oh, i don't know did it is a bug or not.

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: oh, i don't know did it is a bug or not.
Дата
Msg-id 20020416100846Y.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на oh, i don't know did it is a bug or not.  (Terry Lou <terry@aitc.com.tw>)
Список pgsql-bugs
> the problem is
> my postgresql compile with enable multi bytes = unicode and my default
> language is BIG5 encoding, in previous version of postgresql 7.1
> i can use unicode encoding to do my back-end encoding and client
> encoding set to BIG5, with this setting i can insert a chinese word code
> (0xf9d6) in to db (ps: it is not standard of BIG5, it is MS950), another
> word (0xea4d) work.
> but now
> in 7.2 when i insert that word into db, i got a "local_to_utf: could not convert (0xf9d6) BIG5 to UTF-8. Ignored"
> it seems very bad for me.
> but i have try another back-end encoding, the mule_internal and client
> big5 is work with that word.
> i remember that word is ok for oracle 8i with unicode encoding.
> so that is a standard of unicode,why in 7.2 is fail?

Hard to belive. Neither 7.1 and 7.2 has a mapping from 0xf9d6(BIG5) to
0xea4d(UTF-8). Take a look at
src/backend/utils/mb/Unicode/big5_to_utf8.map.

BTW, if you really want to the conversion between 0xf9d6 and 0xea4d,
you could add it to big5_to_utf8.map and utf8_to_big5.map.
Hope this helps,
--
Tatsuo Ishii

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: 7.2 crash...
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Bug #633: CASE statement evaluation does not short-circut