1 - DBLIB   Der Standardwert für die Zeichensätze DBLIB CHAR und NCHAR ist der Zeichensatz des Client-Betriebssystems. Der CHAR-Zeichensatz wird für alle Zeichenfolgendaten mit Ausnahme von BINARY und NCHAR verwendet. Der NCHAR-Zeichensatz wird für Hostvariablen mit dem Datentyp NCHAR und Host-Parameter verwendet (diese stehen in den DBTools- oder DBCAPI-Schnittstellen nicht zur Verfügung). Der Datenbankserver führt alle Zeichensatzkonvertierungen durch.

Sie legen die Zeichensätze CHAR und NCHAR mithilfe des Verbindungsparameters CharSet bzw. der Funktion db_change_nchar_charset fest. Siehe Verbindungsparameter CharSet (CS) und db_change_nchar_charset-Funktion.

2 - Unicode-APIs   Bei Unicode-APIs konvertiert ein Treiber die Unicode UTF-16-Zeichendaten in den und aus dem Zeichensatz der Datenbank. Der Treiber konvertiert Unicode-Host-Parameter in den NCHAR-Zeichensatz (UTF-8), bevor er sie an den Datenbankserver sendet. Die als NCHAR beschriebenen Spalten einer Ergebnismenge werden im NCHAR-Zeichensatz (UTF-8) abgerufen und, nachdem sie empfangen wurden, in Unicode konvertiert. Es wird nicht empfohlen, den Verbindungsparameter CharSet zu setzen, da dies zu einer verlustreichen Konvertierung führen kann. Siehe Verlustreiche Konvertierung und Ersetzungszeichen.

3 - HTTP/HTTPS   HTTP-Dienste (SQL Anywhere als Server): Bei HTTP-Diensten gibt es zwei Anforderungstypen: URL-kodierte und Multipart/Formdaten-Anforderungen.

URL-kodiert: Die Anforderungen haben das Format "application/x-www-form-urlencoded". Hierbei werden die Variablen als Schlüssel/Wert-Paare übergeben. Der Datenbankserver dekodiert %-kodierte Daten (UTF-8 oder Zeichensatz der Datenbank) automatisch und konvertiert die Schlüssel/Wert-Paare in den Zeichensatz der Datenbank. Die verarbeiteten Werte können mithilfe der HTTP_VARIABLE-Funktion extrahiert werden. Dabei kann mithilfe der @BINARY- oder @TRANSPORT-Attribute ein Wert zurückgegeben werden, der zwar %-dekodiert wird, dessen Zeichensatz aber nicht konvertiert wird. Alternativ kann der unformatierte HTTP-(Transport-)Wert zurückgegeben werden.

Multipart/Formdaten: Die Anforderungen werden als binär betrachtet, d.h.die Attribute @BINARY und @TRANSPORT geben identische Werte zurück.

Die Zeichensatzkonvertierung einer HTTP-Dienstantwort hängt von den HTTP-Optionen CharsetConversion und AcceptCharset ab. Sie können diese mit der Systemprozedur sa_set_http_option einstellen. Siehe sa_set_http_option-Systemprozedur.

Des Weiteren können sich die folgenden Einstellungen auf die Zeichensatzkonvertierung für Anforderungen und Antworten auswirken: der Accept-Charset-Header, der für die Festlegung der bevorzugten Zeichensätze benutzt wird, und der Content-Type-Header, mit dessen Hilfe der Zeichensatz des Inhalts gekennzeichnet wird.

HTTP-gespeicherte Prozeduren (SQL Anywhere als Client): Bei HTTP-gespeicherten Prozeduren werden CHAR-Daten im Zeichensatz der Datenbank gesendet. Wenn ein Parameter ein NCHAR-Typ ist, werden alle Daten als UTF-8 gesendet (alle CHAR-Parameter werden in UTF-8 konvertiert). Die Anforderung sendet einen Accept-Charset-HTTP-Header, der den Zeichensatz der Datenbank als bevorzugten Zeichensatz kennzeichnet. UTF-8 ist immer in der Liste der bevorzugten Zeichensätze enthalten. Wenn die Antwort im Content-Type-Header einen anderen Zeichensatz angibt als den Zeichensatz der Datenbank, dann konvertiert der Client die Antwort in den Zeichensatz der Datenbank.

4a - ODBC mit Unicode-Eintrittspunkten   Wenn eine ODBC-Anwendung Unicode-Eintrittspunkte benutzt, wird sie als Unicode-Client-API betrachtet. WCHAR-Daten werden auf die gleiche Weise verarbeitet wie für Unicode-APIs. Wenn eine ODBC-Anwendung die Unicode-Eintrittspunkte und CHAR-(ANSI)-Daten benutzt, wird angenommen, dass die Daten im Zeichensatz der Datenbank vorliegen. Es wird nicht empfohlen, CHAR- und WCHAR-Daten in einer Anwendung zu mischen.

4b - ODBC mit ANSI-Eintrittspunkten   Wenn eine ODBC-Anwendung ANSI-Eintrittspunkte benutzt, wird sie als Unicode-Client-API betrachtet. Der CHAR-Zeichensatz hat standardmäßig den Wert des Zeichensatzes des Client-Betriebssystems. Der CHAR-Zeichensatz kann mithilfe des Verbindungsparameters CharSet geändert werden. Siehe Verbindungsparameter CharSet (CS).

Jede Konvertierung von ANSI-Daten erfolgt durch den Datenbankserver. Das Abrufen von WCHAR-Hostvariablen kann zu einer verlustreichen Konvertierung von CHAR-Daten auf dem Datenbankserver führen. Es wird nicht empfohlen, CHAR- und WCHAR-Daten in einer Anwendung zu mischen.

4c - ODBC-Treibermanager   Einige ODBC-Treibermanager konvertieren alle CHAR-Daten in WCHAR-Daten und rufen dann die Unicode-Eintrittspunkte auf.

5 - SQL Anywhere JDBC-Treiber   Der SQL Anywhere JDBC-Treiber führt keine Zeichensatzkonvertierung durch und verwendet die Unicode-Eintrittspunkte und WCHAR-Typen des ODBC-Treibers. Es handelt sich um den gleichen Fall wie unter ODBC mit Unicode-Eintrittspunkten beschrieben.

6 - Borland DBExpress   Der Borland DBExpress-Treiber verwendet ODBC als ANSI-Client-API. Der CHAR-Zeichensatz hat standardmäßig den Wert des Zeichensatzes des Client-Betriebssystems. Sie können ihn zwar mithilfe des Verbindungsparameters CharSet ändern, jedoch ist dies nicht empfehlenswert, da es zu fehlerhaften Daten führen kann.

7 - TDS-Clients   TDS-Clients wie etwa Sybase Open Client und jConnect verhandeln zur Verbindungszeit mit dem Datenbankserver und ziehen es vor, dass die Zeichensatzkonvertierung auf dem Client stattfindet. Während der Aushandlung wird der Datenbankserver angewiesen, den Zeichensatz nicht zu konvertieren.