Freigeben über


Verwalten der Datenkonvertierung zwischen Unicode-Codierungsschemas

Dieses Thema beschreibt, wie die Integrität von Zeichendaten gewahrt werden kann, wenn die serverseitige Datenspeicherung und die clientseitige Anwendung, die mit den Daten interagiert, zwar für Unicode aktiviert sind, jedoch unterschiedliche Unicode-Codierungsschemas verwenden. SQL Server speichert Unicode im UCS-2-Codierungsschema. Viele Clients verarbeiten Unicode jedoch in einem anderen Codierungsschema; dabei handelt es sich in der Regel um UTF-8. Dieses Szenario tritt häufig bei webbasierten Anwendungen auf.

Da die Konvertierung im Wesentlichen auch hier aus einem Codierungsschema in ein anderes erfolgt, sind zahlreiche der in den Themen Verwalten der Datenkonvertierung zwischen einem Unicode-Server und einem Nicht-Unicode-Client und Verwalten von Datenkonvertierungen mit unterschiedlichen Client/Server-Codepages beschriebenen Lösungen ebenfalls anwendbar.Unicode-Zeichenfolgekonstanten, die an den Server gesendet werden, muss der Großbuchstabe N vorangestellt werden. Für webbasierte Anwendungen geben Sie den CHARSET-Code unter dem META-Attribut der clientseitigen HTML-Seite an. Geben Sie z. B. CHARSET = utf-8 an, wenn das Unicode-Codierungsschema UTF-8 ist. Geben Sie auf der Serverseite das Codierungsschema des Clients mithilfe der Session.CodePage-Eigenschaft oder der @Codepage-Direktive an. Beispielsweise gibt codepage=65001 ein UTF-8-Codierungsschema an. Wenn Sie diese Anweisungen befolgen, ist die nahtlose Verarbeitung der Konvertierung aus UTF-8 in UCS-2 und umgekehrt durch Internetinformationsdienste (IIS), Version 5.0 oder höher, gewährleistet, ohne dass Sie zusätzliche Aktionen ausführen müssen.

In Visual Basic-Anwendungen werden Zeichenfolgen im UCS-2-Codierungsschema verarbeitet. Daher müssen Sie die Codierungsschemakonvertierung zwischen diesen Anwendungen und einer Instanz von SQL Server nicht explizit angeben.