Speichern von UTF-16/Unicode-Daten in SQL Server

Gemäß this verwendet SQL Server 2K5 intern UCS-2. Es kann UTF-16-Daten in UCS-2 (mit entsprechenden Datentypen, Nchar usw.) speichern, wenn jedoch ein Zusatzzeichen vorhanden ist, wird dies als 2 UCS-2-Zeichen gespeichert.Speichern von UTF-16/Unicode-Daten in SQL Server

Dies bringt die offensichtlichen Probleme mit den String-Funktionen, nämlich, dass was ein Zeichen ist wie 2 von SQL Server behandelt wird.

Ich bin etwas überrascht, dass SQL Server grundsätzlich nur mit UCS-2 umgehen kann, und noch mehr, dass dies in SQL 2K8 nicht behoben ist. Ich weiß es zu schätzen, dass einige dieser Charaktere nicht so häufig sind.

Abgesehen von den im Artikel vorgeschlagenen Funktionen, Vorschläge für den besten Ansatz für den Umgang mit den (gebrochenen) String-Funktionen und UTF-16-Daten in SQL Server 2K5.

Quelle

2009-04-30 Anonymous

Welche Zeichenfolge Funktionen sind bitte gebrochen? – gbn

LEN gibt die Anzahl der UCS-2-Zeichen in der Zeichenfolge zurück, nicht die Anzahl der UTF-16-Zeichen. SUBSTRING teilt UTF-16-Zeichen in zwei Hälften. Gleiches gilt für LINKS und RECHTS. UPPER und LOWER würden wahrscheinlich auch brechen. REVERSE würde definitiv brechen. CHARINDEX und PATINDEX auch. Ich bin mir nicht sicher über Unterschied und Material. So viele von ihnen .... –

Vielen Dank für das Aufzeigen. Die Tatsache, dass ALL Unicode-Zeichen nicht unterstützt wird, bedeutet, dass einige UTF-16-Zeichenfolgenwerte (z. B. von Windows oder .NET) nicht ohne Verifizierung in SQL Server übertragen werden können. Damit jede Anwendung fehlerfrei und technisch korrekt ist (wie RARE-Fehler verursachende Zeichen keinen Unterschied machen, wenn es um Korrektheit geht), müssen ALLE Zeichenketten zuvor auf UCS-2-kompatible Zeichen geprüft werden in SQL Server gespeichert werden. Wunderbar! Way, um meine Arbeit so viel schwieriger zu machen Microsoft. – Triynko

Die String-Funktionen funktionieren gut mit Unicode-Zeichenfolgen; Diejenigen, die sich um die Anzahl der Zeichen kümmern, behandeln ein Zwei-Byte-Zeichen als einzelnes Zeichen, nicht als zwei Zeichen. Die einzigen, auf die geachtet werden muss, sind len() und datalength(), die bei Verwendung von Unicode unterschiedliche Werte zurückgeben. Sie geben natürlich die korrekten Werte zurück - len() gibt die Länge in Zeichen zurück und datalength() gibt die Länge in Byte zurück. Sie sind nur zufällig wegen der Zwei-Byte-Zeichen unterschiedlich.

Also, solange Sie die richtigen Funktionen in Ihrem Code verwenden, sollte alles transparent funktionieren.

EDIT: Wie bereits ausgeführt in den Kommentaren, SQL Server-String-Funktionen nicht unterstützt: Just doppelt geprüft Books Online, Unicode-Daten nahtlos mit String-Funktionen, da SQL Server 2000

EDIT 2 gearbeitet haben der volle Unicode-Zeichensatz aufgrund fehlender Unterstützung für das Parsen von Surrogate außerhalb von Ebene 0 (oder anders ausgedrückt, die String-Funktionen von SQL Server erkennen nur bis zu 2 Byte pro Zeichen). SQL Server speichert und gibt die Daten jedoch korrekt zurück Eine Zeichenfolgenfunktion, die auf Zeichen zählt, gibt die erwarteten Werte nicht zurück. Die gängigste Methode zur Umgehung dieses Problems ist entweder die Verarbeitung der Zeichenfolge außerhalb von SQL Server oder die Verwendung der CLR-Integration zum Hinzufügen von Unicode-fähigen Zeichenfolgenverarbeitungsfunktionen.

Quelle

2009-04-30 03:50:50 Rick

Sie haben die Frage falsch verstanden. UTF-16 ermöglicht zusätzliche Zeichen. Dies funktioniert, indem ein einzelnes Zeichen (aus der Sicht des Benutzers) in 2 Code-Einheiten, dh 4 Bytes, gespeichert wird. UCS-2 behandelt keine zusätzlichen Zeichen. Daher werden die 4 Bytes von SQL Server als zwei Zeichen behandelt, wenn es sich tatsächlich um ein Zeichen handelt. –

Das ist nur für Zeichen außerhalb der definierten Standardsprachen. Das Whitepaper gibt an, dass dies hauptsächlich für historische Sprachen gilt. – Rick

Kommentar zur Bearbeitung: SQL Server funktioniert gut auf UCS-2 Unicode-Daten. UCS-2 ist ein veralteter Standard, Windows verwendet seit Win2K intern UTF-16. –

-2

etwas hinzufügen, dass ich auf die harte Art und Weise gerade gelernt:

, wenn Sie in Oracle ein „n“ Feld verwenden (im 9i ausgeführt wird), und greifen Sie über die .net OracleClient, so scheint es, dass nur parametriert sql wird funktionieren ... das N'string'-Unicode-Präfix scheint nicht den Trick zu machen, wenn Sie ein Inline-SQL haben.

und mit "Arbeit", meine ich: es wird alle Zeichen verlieren, die nicht vom Basiszeichensatz unterstützt werden. In meinen Fällen funktionieren englische Zeichen gut, kyrillisch wird zu Fragezeichen/Müll.

dies ist eine ausführlichere Diskussion über das Thema: http://forums.oracle.com/forums/thread.jspa?threadID=376847

Wonder, wenn die ORA_NCHAR_LITERAL_REPLACE Variable kann in der Verbindungszeichenfolge oder etwas eingestellt werden.

Quelle

2010-02-06 00:44:59

Hi boomhauer, die Frage war über Microsoft SQL Server. Ihre Antwort kann woanders nützlich sein. –

wow ... hier ist etwas passiert. habe ich die falsche Frage gestellt? Ich frage mich fast, ob SO das vermasselt hat, da es seit Februar 2010 ... –

tatsächlich ist, weiß ich, dass diese Antwort auf eine andere Frage war! –

SQL Server 2012 unterstützt nun UTF-16 einschließlich Ersatzpaare. Siehe http://msdn.microsoft.com/en-us/library/ms143726(v=sql.110).aspx, insbesondere der Abschnitt "Zusätzliche Zeichen".

So eine Lösung für das ursprüngliche Problem ist die Annahme von SQL Server 2012.

Quelle

2012-10-11 02:57:05

Wahr, dass SQL Server 2012 die '_SC'-Sortierungen eingeführt hat, die eine ordnungsgemäße Behandlung von Ergänzungszeichen aufweisen, ist die Frage _very_ spezifisch bezüglich SQL Server 2005. Außerdem ist es seit UTF-16 nicht" UTF-16 + Ersatzpaare " = "UCS-2 + Ersatzpaare". –

Speichern von UTF-16/Unicode-Daten in SQL Server

Antwort

Verwandte Themen