Subject | character set OCTETS |
---|---|
Author | peter_jacobi.rm |
Post date | 2003-08-12T14:32:25Z |
Dear All,
As so often playing arounf with character sets.
Using FB 1.5rc4 and plain ISQL on W2K.
Look at this session log:
(the first insert puts german umlauts and sharp-s
in the table, in case the characters got lost in
your email client or at yahoo)
SQL> create table temp (col char(8) character set DOS437);
SQL> insert into temp values (_DOS437'ÄÖÜäöüß');
SQL> insert into temp values (_DOS437'ABCDEF');
SQL> select col, cast (col as char(8) character set OCTETS) from temp;
COL CAST
======== ================
ÄÖÜäöüß FFFFFFFFFFFFFF20
ABCDEF 4142434445462020
Questions:
1) The useful magic of displaying character set OCTETS
in hexadecimal, is this done by ISQL or in the server?
2) All bytes > 0x7F are displayed as 0xFF - is there a hidden
reason? Otherwise I'd tempted to file a bug report on this as
it is somewhat unpractical.
Regards,
Peter Jacobi
As so often playing arounf with character sets.
Using FB 1.5rc4 and plain ISQL on W2K.
Look at this session log:
(the first insert puts german umlauts and sharp-s
in the table, in case the characters got lost in
your email client or at yahoo)
SQL> create table temp (col char(8) character set DOS437);
SQL> insert into temp values (_DOS437'ÄÖÜäöüß');
SQL> insert into temp values (_DOS437'ABCDEF');
SQL> select col, cast (col as char(8) character set OCTETS) from temp;
COL CAST
======== ================
ÄÖÜäöüß FFFFFFFFFFFFFF20
ABCDEF 4142434445462020
Questions:
1) The useful magic of displaying character set OCTETS
in hexadecimal, is this done by ISQL or in the server?
2) All bytes > 0x7F are displayed as 0xFF - is there a hidden
reason? Otherwise I'd tempted to file a bug report on this as
it is somewhat unpractical.
Regards,
Peter Jacobi