Subject | Re: [firebird-support] character set OCTETS |
---|---|
Author | Olivier Mascia |
Post date | 2003-08-12T14:42:25Z |
Hello peter_jacobi.rm,
Tuesday, August 12, 2003, 4:32:25 PM, you wrote:
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;
pr> COL CAST
pr> ======== ================
pr> ÄÖÜäöüß FFFFFFFFFFFFFF20
pr> ABCDEF 4142434445462020
pr> Questions:
pr> 1) The useful magic of displaying character set OCTETS
pr> in hexadecimal, is this done by ISQL or in the server?
ISQL. Plain C-API returns bytes as is.
pr> 2) All bytes >> 0x7F are displayed as 0xFF - is there a hidden
pr> reason? Otherwise I'd tempted to file a bug report on this as
pr> it is somewhat unpractical.
Probably a signed/unsigned char issue in ISQL treating each
value > 127 as a negative and then defaulting to -1 (FF).
Should check the source code of isql to verify this before bug report.
--
Best regards,
Olivier Mascia
Tuesday, August 12, 2003, 4:32:25 PM, you wrote:
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;
pr> COL CAST
pr> ======== ================
pr> ÄÖÜäöüß FFFFFFFFFFFFFF20
pr> ABCDEF 4142434445462020
pr> Questions:
pr> 1) The useful magic of displaying character set OCTETS
pr> in hexadecimal, is this done by ISQL or in the server?
ISQL. Plain C-API returns bytes as is.
pr> 2) All bytes >> 0x7F are displayed as 0xFF - is there a hidden
pr> reason? Otherwise I'd tempted to file a bug report on this as
pr> it is somewhat unpractical.
Probably a signed/unsigned char issue in ISQL treating each
value > 127 as a negative and then defaulting to -1 (FF).
Should check the source code of isql to verify this before bug report.
--
Best regards,
Olivier Mascia