此内容已被标记为最终。 显示 5 条回复
Do you have the same problem when using "sqlplusw" ?
Forget sqlplusw if you want to display characters not contained in your Windows-ANSI-Codepage, e.g. cyrillic characters. AFAIK sqlplusw is a non unicode capable application, character set is restricted by ANSI codepage, default is 1252 for Western Europe. sqlplusw requires that the NLS_LANG encoding is set according to the ANSI codepage, that is WE8MSWIN1252 for codepage 1252.
Ah I think now I understand what you are referring to.
SQL*PLUS is able to show the correct sign/codepages. However windows is not able to render the output from sqlplus correctly.
So far I didn't feel this is restricting much, because users usually don't use SQL*PLUS. But it is annoying/confusing somtimes for the developer.
works for characters covered by Lucida Console font if the first character in a line is ASCII (code < 128, e.g. blank)
SQL> select ' ', unistr('Josef \0419\043E\0437\0435\0444') from dual;
SQL> select ' ',unistr('Euro \20AC') from dual;
Sven, windows is able to render the output (as covered by Lucida Console), but there is a quirk in MSVCRTxx (C Runtime-Lib), function fwrite(). The first byte in a line is passed separately to an isolated single write() call, which causes conversion of an utf8 sequence to fail.
For non-ascii characters (code >= 128), ReadConsoleW must be called, e.g. through a simple filter converting UTF-16 stdin to UTF-8 stdout.
Nice. (from a fellow CLI freak)
Never had to worry or deal with Unicode using SQL*Plus thus far though... touch wood. Also, using Linux almost exclusively these days. :-)