Verwendet ihr TDS 7.0?

FreeTDS verwendet doch UCS2. Das bedeutet doch dass es en/decoded vom Clientcharset in UCS2.
Also wenn der Client UTF8 liefert, dann bekommt der Server das richtige Endcoding.
Der Server sollte aber UCS2 zurück liefern. Weil das TDSProtokoll über UCS2 läuft.
Wenn er das nicht tut, decodiert natürlich FreeTDS falsch.

Und wenn ihr das Charset in der DB umstellt?
Also von UTF8 auf UCS2?

Microsoft: http://support.microsoft.com/kb/232580/EN-US/\n\n

<!--EDIT|GwenDragon|1156867088-->

[quote=waterdeep,29.08.2006, 16:02]Ein MS-SQL Server kann UTF-8 Daten aufnehmen in n(text|varchar|date etc) Feldern. Er speichert die Daten intern aber nicht UTF-8 sonder UCS2 ab. FreeTDS gibt UTF-8 Daten beim Schreiben in die DB richtig weiter. Beim Auslesen veranlasst der Parameter CLIENT CHARSET = UTF-8 FreeTDS dazu die Daten aus der SQL Server DB nach UTF-8 zu encodieren obwohl sie bereits UTF-8 in der DB stehen.[/quote]
Versteh' ich das richtig? Anstatt die Daten in UCS2 in die Datenfeldern einzutragen, habt ihr UTF8 genommen? Wie habt ihr das fertig gebracht, wo es soch gar keine UTF8-Collation gibt, oder täusche ich mich?


Übrigens MS schreibt:

Quote

Note that if you store UTF-8 data in SQL Server you should not use character columns (CHAR/NCHAR/VARCHAR and so forth)

http://support.microsoft.com/kb/232580/EN-US/





Dann stellt euch der Treiber ein Bein, weil er ja annimmt, dass alle Daten in UCS2 sind.

Dann hilft nur: alle diese "UTF8"-Daten in UCS2 zu konvertieren.\n\n

<!--EDIT|GwenDragon|1156867817-->

Nee nee das passt schon. Ja e stimmt schon das der SQL Server nicht ohne weiteres eine UTF-8 Collation unterstützt (mit etwas C# Code wäre aber auch das machbar als user defined datatype ab SQL Server 2005).
Also im Gegensatz zu MySQL kennt der MS-SQL Server keine feld spezifischen Zeichensätze. Um UTF-8 oder sonstige UNICODE Strings abzuspeichern nimmt man "n"-Datentypen. In der Regel ist das dann das "ntext" Feld da es die meisten Bytes für Strings halten kann. Das UCS2 Format benutzt der SQL Server rein intern zur Speicherung jeglicher Daten (ausser Binary Datentypen). Es läuft so: Ich speichere einen UTF-8 String in ein ntext Feld im SQL Server. Der wandelt das intern für sich nach UCS2 ab, vermerkt aber dass das Original Encoding UTF-8 war. Wenn ich jetzt auf genau diesen Datensatz einen SELECT ausführe wandelt der SQL-Server meinen zuvor eingetragenen String wieder in das Eingabeformat - in diesem Fall UTF-8 - zurück.
Und obwohl der daraus resultierende String wieder so encodiert ist, wie ich ihn haben will, wandelt z.B. eben FreeTDS den String dann nochmal um, auch wenn kein Client Charset angegeben wird. - Kann natürlich auch sein, dass ich hier einfach einen massiven Denkfehler habe.

@GwenDragon, der Link ist gut:
http://support.microsoft.com/kb/232580/EN-US/

Microsoft Windows NT, SQL Server, Java, COM, and the SQL Server ODBC driver and OLEDB provider all internally represent Unicode data as UCS-2.
Heißt soviel wie - wir können nur das.

1. Mit codepage "<%@ CodePage=65001 %>"
kann man in der Windows-Umgebung UCS-2 schreiben und ASP macht automatisch utf-8. - Schöne heile Windows Welt.

2. ist das, was bei uns mit FreeTDS nicht funktioniert.

Bei 3. steht dann die Lösung:
Modify the application to use UCS-2 instead of UTF-8 encoding.

4. Store the actual UTF-8 data on the server using the BINARY/VARBINARY/IMAGE columns.
Dann verlierst Du jede SQL-Kontrolle über die Daten, kannst nur noch lesen und schreiben.

***

Wenn wir eine Datenbank mit ISO-8859-1 haben, dann kommen wir auch mit utf-8 an mit unserem Statement und den Hosteingabeparametern und müssen diese nach ISO-8859-1 umcodieren, zur Datenbank schicken und beim fetchen, das ISO-Zeugs wieder zurück in utf-8 codieren.

Wahrscheinlich müssen wir den gleichen Weg bei UNICODE gehen. Statement und Hosteingabeparameter werden von utf-8 nach UCS-2 codiert, wir arbeiten dann in Windows-Manier. Und beim fetchen codieren wir von UCS-2 wieder nach utf-8 zurück.

habt ihr mal verifiziert, dass das was der MsSQL Server speichert auch echtes UCS-2 ist? Oder nimmt er nur den UTF-8 String und doppelt dann die Bytes ohne wirklich zu konvertieren? heißt sind z.B. die ü's echte ü's oder tauchen sie als utf-8 kodierte zeichen im Enterprise Manger auf?

Die Zeichen tauchen als UTF-8 kodierte Zeichen auf.

[quote=waterdeep,30.08.2006, 08:02]Die Zeichen tauchen als UTF-8 kodierte Zeichen auf.[/quote]
okay; das hab ich mir nämlich gedacht.
also wurde nicht convertiert.
ihr müsst also erst utf-8 nach ucs-2 kodieren, bevor ihr die daten in mssql schiebt.

[quote=waterdeep,29.08.2006, 21:44]wandelt z.B. eben FreeTDS den String dann nochmal um, auch wenn kein Client Charset angegeben wird[/quote]
kein ClinetCharset bedeutet bei FreeTDS ISO-8859-1!

In jedem Fall ist aber wohl die Autokonvertierung von UCS2 -> "gemerktes Charset" im Datenfeld das Problem. Da wird das MSSQL-Feature zur Falle.

[quote=GwenDragon,30.08.2006, 12:19]In jedem Fall ist aber wohl die Autokonvertierung von UCS2 -> "gemerktes Charset" im Datenfeld das Problem. Da wird das MSSQL-Feature zur Falle.[/quote]
Naja das ist so nicht ganz richtig. Viel mehr ist FreeTDS die Falle. Der SQL Server gibt die Daten wieder passend zurück, so wie sie eingegeben wurden.
Aber aufgrund der Tatsache, dass:
"kein ClientCharset bedeutet bei FreeTDS ISO-8859-1!"
also die Daten vom SQL Server nicht einfach AS IS weitergereicht werden können, wird FreeTDS zur Falle da es immer ein Zeichenencoding macht.