Freigeben über


Eingabezeichensatz (Entity SQL)

Entity SQL akzeptiert UNICODE-Zeichen, die in UTF-16 codiert sind.

Zeichenfolgenliterale können ein beliebiges UTF-16-Zeichen enthalten, das in einfache Anführungszeichen eingeschlossen ist. Beispielsweise N'中字列リテラル'. Wenn Zeichenfolgenliterale verglichen werden, werden die ursprünglichen UTF-16-Werte verwendet. Beispielsweise unterscheidet sich N'ABC' in japanischen und lateinischen Codeseiten.

Kommentare können ein beliebiges UTF-16-Zeichen enthalten.

Escaped identifiers can contain any UTF-16 character enclosed in square brackets. Beispiel: [エスケープされた識別子]. Der Vergleich von UTF-16 escaped-IDs ist bei der Groß-/Kleinschreibung nicht zu beachten. Entity SQL behandelt Versionen von Buchstaben, die identisch angezeigt werden, aber von verschiedenen Codeseiten als unterschiedliche Zeichen stammen. [ABC] entspricht z. B. [abc], wenn die entsprechenden Zeichen von derselben Codeseite stammen. Wenn jedoch die gleichen beiden Bezeichner von unterschiedlichen Codeseiten stammen, sind sie nicht gleichwertig.

Leerzeichen sind alle UTF-16 Leerzeichen.

Eine Neue zeile ist ein beliebiges normalisiertes UTF-16-Neuzeilenzeichen. Beispielsweise werden "\n" und "\r\n" als Neuzeilenzeichen betrachtet, aber "\r" ist kein Neuzeilenzeichen.

Schlüsselwörter, Ausdrücke und Interpunktion können ein beliebiges UTF-16-Zeichen sein, das in Latein normalisiert wird. Select in einer japanischen Codepage ist beispielsweise ein gültiges Schlüsselwort.

Schlüsselwörter, Ausdrücke und Interpunktionszeichen können nur lateinische Zeichen sein. SELECT in einer japanischen Codepage ist kein Schlüsselwort. +, -, *, /, =, (, ), ', [, ] und alle anderen Sprachkonstrukte, die hier nicht zitiert werden, können nur lateinische Zeichen sein.

Einfache Bezeichner können nur lateinische Zeichen sein. Dies vermeidet Mehrdeutigkeit während des Vergleichs, da originale Werte verglichen werden. ABC würde sich beispielsweise in japanischen und lateinischen Codeseiten unterscheiden.

Siehe auch