Clob to Blob

[Fuerchau]

Die Begrifflichkeit ist hier unglücklich gewählt.
N(ational) Character heißt nichts weiter, dass nun multinationale Zeichen verwendet werden dürfen. Man hätte ja auch MNCHAR verwenden können.
Historie auf der AS/400:
GRAPHIC(nn) CCSID 13488 => UCS2 => RPG-Typ "C".
NCHAR(nn) => CCSID 1200 => UTF-16 => RPG-Typ "C"

(nn) ist hier die Anzahl Zeichen und nicht Bytes, also für den Platz mal 2 zu nehmen!

Die Unterscheidung ist im Wesentlichen, dass UCS2 auf 2-Byte-Zeichen beschränkt ist.
UTF-16 ist ein variabler 2/4-Byte-Zeichensatz und kann somit alle gültigen und zukünftigen Zeichen aufnehmen. UTF-16 ist allerdings in der CLientwelt weniger verbreitet. Da findet UTF-8 eher Anwendung, das ist eine 1-4-Byte-Zeichensatz, also variabel von 1 bis 4 möglichen Zeichen.

Die Oracle-DB arbeitet bei NCHAR z.B. mit UTF-8, was bei der Anlage von Tabellen allerdings zu beachten ist. Wählt man z.B. NCHAR(1) so sind damit nicht 1 Zeichen sondern 1 Byte gemeint. Spätestens bei deutschen Umlauten und sonstigen europäischen Sonderzeichen kann man da nichts mehr unterbringen.
Ich hatte da mal ein kleines Übertragungsproblem in eine Oracle-DB mit NCHAR(2). Hier sollte der Wert "ÜA" untergebracht werden. in UTF-8 sind das aber 3 Bytes und die Oracle-DB hat das abgelehnt.
Aber das ist hier "Off-Topic".

[dschroeder]

Vielen Dank für deine Erklärung!

[dschroeder]

So, wir haben das ganze jetzt im Einsatz. Mit der Idee, die clob-Funktion nochmal auf ein Clob-Feld anzuwenden, um den gewünschten Zeichensatz zu bekommen, klappt wunderbar. Unsere per TinyMCE editierten Texte landen wunderschön formatiert im Microsoft Word.

Nochmals vielen Dank!