Re: pgAdmin2 Japanese display
От | Hiroshi Inoue |
---|---|
Тема | Re: pgAdmin2 Japanese display |
Дата | |
Msg-id | 3C7B1C07.EB2DF8B6@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: pgAdmin2 Japanese display (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Список | pgadmin-hackers |
Jean-Michel POURE wrote: > > Le Lundi 25 F騅rier 2002 17:19, Hiroshi Inoue a 馗rit : > > SET CLIENT_ENCODING to 'SJIS' > > Strictly speaking, you need a multibyte psqlodbc driver > > to handle SJIS(Shift Jis) properly. > > Dear Hiroshi, > > Thank you for your answer. Could you tell us more about SJIS: > 1) Is it Microsoft encoding standard for Japanese? Yes. You can see SJIS Japanese strings if you set the locale *Japanese*. > 2) Is the multibyte psqlodbc driver a separate driver? Yes and no. You could build the multibyte driver with the same source but the different compile option. > What are the > settings to switch odbc to SJIS? Please set the connect_settings DSN option as set client_encoding to 'SJIS'. The commands are issued immediately after the connection was established and you can see SJIS(converted from EUC_JP, UTF-8 etc) Japanese strings. Note that you can see the strings properly in most cases even though you don't use the multibyte driver. However SJIS could have ASCII(e.g. \, { ) byte as the second byte of some multibyte characters and they sometimes confuses non-multibyte psqlodbc driver. It occurs with neither EUC_XX nor UTF-8 because every byte of their multibyte characters is non-ASCII. > Do you think it would be usefull to convert UTF-8 into UCS-2 using: > SET CLIENT_ENCODING to 'UCS-2'. The *SET CLIENT_ENCODING .. * command is to request the server to convert every server side text string(server encoding) to the specified client_encoding when retrieving the text strings at the client side. However currently(maybe in the future also) PostgreSQL doesn't support any UCS-2 <-> .. conversion. The main reason is that all currently supported encodings contain ASCII as a part of themselves and they are always teminated by NULL('\0') but UCS-2 satisfies neither. To support Unicode(UCS-2) in our ODBC driver we would have to implement the APIs for Unicode like SQLColAttributesW, SQLColumnPrivilegesW, SQLColumnsW, SQLConnectW, SQLDataSourcesW, SQLDescribeColW, SQLDriverConnectW, SQLErrorW, SQLExecDirectW, SQLForeignKeysW, SQLGetConnectOptionW, SQLGetCursorNameW, SQLGetInfoW, SQLNativeSqlW, SQLPrepareW, SQLPrimaryKeysW, SQLProcedureColumnsW, SQLProceduresW, SQLSetConnectOptionW, SQLSetCursorNameW, SQLSpecialColumnsW, SQLStatisticsW, SQLTablesW, SQLTablePrivilegesW and handle SQL_WCHAR and SQL_C_WCHAR at various(not clear now) places using UCS-2 <-> UTF-8 conversion. regards, Hiroshi Inoue
В списке pgadmin-hackers по дате отправления: