Fuerchau
02-08-24, 14:27
Per Definition gibt es keinen Fehler bei einer Umsetzung von UTF8 oder UTF16 (1200) in eine beliebige andere CCSID, da bei ungültigen Zeichen grundsätzlich das "?" eingesetzt wird.
Dies wurde halt so festgelegt und ist auch im Windows-Umfeld so.
Wenn man per ODBC in die DB2 übertragen will und die Tabelle eine Single-CCSID hat, 273, 1141, 870, usw., gibt es eine Einstellung im Treiber, dass keine ungültigen Zeichen zugelassen werden (Default).
Dies trifft z.B. bei CCSID 273 das "€"-Zeichen, da dort das Zeichen nicht definiert ist.
Hier muss man dazu erwähnen, dass i.d.R. in ODBC-Zugriffe mit "String" umgegangen wird und diese sind seit 1998 grundätzlich UTF16. Einzig in byteorientierten Sprachen wie C/C++ kann man noch mit Singlebyte-char-Arrays arbeiten.
Man spart sich daher das Umwandeln von Strings in byte-Arrays, außer bei der Verwendung von UTF8.
Bei der Erkennung von ungültigen Zeichen wird der Insert/Update dann abgelehnt.
Dies wurde halt so festgelegt und ist auch im Windows-Umfeld so.
Wenn man per ODBC in die DB2 übertragen will und die Tabelle eine Single-CCSID hat, 273, 1141, 870, usw., gibt es eine Einstellung im Treiber, dass keine ungültigen Zeichen zugelassen werden (Default).
Dies trifft z.B. bei CCSID 273 das "€"-Zeichen, da dort das Zeichen nicht definiert ist.
Hier muss man dazu erwähnen, dass i.d.R. in ODBC-Zugriffe mit "String" umgegangen wird und diese sind seit 1998 grundätzlich UTF16. Einzig in byteorientierten Sprachen wie C/C++ kann man noch mit Singlebyte-char-Arrays arbeiten.
Man spart sich daher das Umwandeln von Strings in byte-Arrays, außer bei der Verwendung von UTF8.
Bei der Erkennung von ungültigen Zeichen wird der Insert/Update dann abgelehnt.