mvSQL-Zeichenfolgenliterale im Jitterbit App Builder

Der SQL-Standard definiert zwei Zeichenfolgentypen, jeder mit seiner eigenen Literalsyntax.

• ANSI
• National

ANSI-Zeichenfolgen repräsentieren ASCII und andere einbyte-Zeichencodierungen, wie EBCDIC auf DB2/i.

National-Zeichenfolgen repräsentieren mehrbyte-Zeichencodierungen wie Unicode.

Der SQL-Standard definiert eine separate Literalsyntax für jeden Zeichenfolgentyp. Die Syntax für ein ANSI-Zeichenfolgenliteral lautet:

'Aristoteles'' Zitate'

Beachten Sie, dass einfache Anführungszeichen, die innerhalb des Zeichenfolgenliterals eingebettet sind, durch Verdopplung des einfachen Anführungszeichens escaped werden.

Die Syntax für ein National-Zeichenfolgenliteral lautet:

N'Aristoteles'' Zitate'

mvSQL unterstützt die SQL-Standardsyntax für ANSI- und National-Zeichenfolgenliterale.

Anbietersupport

Sofern nicht anders dokumentiert, werden ANSI- und National-Zeichenfolgenliterale direkt dem nativen Anbieteräquivalent zugeordnet.

MySQL

MySQL definiert keine separate Syntax für ANSI- und National-Zeichenfolgenliterale. In MySQL wird angenommen, dass das Zeichenfolgenliteral mit dem Zeichensatz der Verbindung codiert ist. Das bedeutet, dass die Codierung je nach Verbindungseinstellungen variieren kann. Wenn die Verbindung eine ANSI-Codierung verwendet (wie die Standard-latin1-Codierung), wird angenommen, dass alle Zeichenfolgen ANSI sind.

MySQL unterstützt Zeichensatz-Einführungen. Die "Einführung" ist ein Präfix, das zu Beginn des Zeichenfolgenliteralwerts hinzugefügt wird. Das Präfix gibt den Zeichensatz der Zeichenfolge an. Der App Builder verwendet Zeichensatz-Einführungen, um sicherzustellen, dass Unicode-Daten in Zeichenfolgenliteralen kodiert werden können, unabhängig von den Verbindungseinstellungen. Umgekehrt stellt die Verwendung des UTF-8-Zeichensatzes in der Verbindung sicher, dass ASCII-Daten als ASCII an den Server übergeben werden, wodurch problematische Konvertierungen vermieden werden.

In der Praxis bedeutet dies, dass ein mvSQL ANSI-Zeichenfolgenliteral übersetzt wird in:

_latin1'Aristoteles' Zitate'

Ein mvSQL National-Zeichenfolgenliteral wird in die MySQL-Syntax übersetzt als:

_utf8'Aristoteles' Zitate'

MySQL definiert keine separaten Speicherdatentypen für ANSI- und National-Zeichentypen. Stattdessen werden alle Zeichentypen in einem gemeinsamen Datentyp gespeichert. Der Zeichensatz bestimmt, wie die Daten gespeichert werden. Der App Builder ordnet MySQL-Zeichenspalten mit einem Unicode-Zeichensatz (utf8) dem entsprechenden, herstellerneutralen National-Zeichenfolgen-Typ (z. B. NCHAR oder NVARCHAR) zu.

DB2/i

Wie MySQL hat DB2/i keine separaten Datentypen für ANSI- und National-Zeichenfolgen. Stattdessen bestimmt der CCSID die Kodierung. Der CCSID ist eine unsigned, 16-Bit-Ganzzahl. Er ist in seiner Natur ähnlich dem Windows LCID.

Wie bei MySQL untersucht der App Builder den CCSID, um korrekt von einem DB2/i-Zeichentyp (z. B. VARCHAR) zu einem App Builder, herstellerneutralen Datentyp (z. B. NVARCHAR) zuzuordnen. Die folgenden CCSIDs werden dem NVARCHAR-Datentyp zugeordnet:

• 1200 - UTF-16
• 1208 - UTF-8
• 13488 - UCS-2

Umgekehrt setzt der App Builder beim Erstellen von Spalten mit einem National-Zeichendatentyp explizit den CCSID. Konkret setzt der App Builder den CCSID auf 1208 (UTF-8).

Schließlich muss DB2/i keine separate Syntax für ANSI- und National-Zeichenfolgen haben. Daher wird dieselbe Syntax für beide verwendet.

Non-RDBMS-Datenquellen

mvSQL National-Zeichenliterale werden für Nicht-RDBMS-Datenquellen wie REST und Salesforce usw. nicht unterstützt.

Weiterführende Literatur

https://learn.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support

https://docs.microsoft.com/en-us/sql/t-sql/data-types/constants-transact-sql

https://dev.mysql.com/doc/refman/8.0/en/charset-introducer.html