Zunächst sollte ich sagen, dass ich MySQL nicht verwende, aber ich kenne mich mit ODBC-Treibern aus. In ODBC gibt es verschiedene APIs für Unicode und Ansi. Die Ansi-APIs enden auf A und die Unicode-APIs auf W (z. B. SQLPrepareA und SQLPrepareW). Die Ansi-APIs akzeptieren Bytes/Oktette für Zeichenfolgen und können daher nur Chrs 0-255 verarbeiten. Die Unicode-APIs akzeptieren SQLWCHARs, die 2-Byte-UCS-2-codierte Unicode-Codepunkte sind (neuere MS SQL Server-Versionen können UTF16-codierte Zeichenfolgen verarbeiten) und können daher ungefähr die ersten 65000 Codepunkte in Unicode verarbeiten.
Wenn Sie also Unicode-Daten speichern müssen, haben Sie keine Wahl, welchen Treiber Sie verwenden sollen.
Ich würde mich von den Kommentaren zur Geschwindigkeit von Carnangel nicht abschrecken lassen, den Unicode-Treiber zu verwenden, und auf jeden Fall enthalten seine Kommentare keine Fakten. Er bezieht sich möglicherweise auf:
Wenn Sie Unicode-Daten in MySQL speichern, werden diese UTF-8-codiert und als UTF-8 über Ihr Netzwerk übertragen. Auf der Clientseite muss der ODBC-Treiber die UTF-8-codierten Daten in UCS-2 konvertieren, da ODBC dies benötigt. Offensichtlich gilt das Gegenteil.
Wenn Sie eine ANSI-ODBC-Anwendung (d. h. eine, die die Ansi-ODBC-APIs verwendet) mit einem Unicode-ODBC-Treiber schreiben, muss der ODBC-Treibermanager den UCS-2-Treiber konvertieren, der Treiber kehrt zu 8 Bit (verlustbehaftet) zurück und konvertiert die 8 Bit Daten, die Sie dem Treiber an UCS-2 übergeben. Also tu das nicht.
Heutzutage wäre ich überrascht, wenn noch jemand ANSI-ODBC-Treiber verwendet.
