MS SQL Server 2012, nvarchar-Spalte mit Unicode dez. funktioniert nicht
Hi
Ich habe eine Tabelle in MS SQL Server 2012 Express Edition auf einem Windows 7 PRO PC in einem isolierten Netzwerk ohne Internetzugang. Die Tabelle funktioniert auch tadellos, solange in den Spalten der Text auf Deutsch oder Englisch eingetragen wird. Die meisten Felder sind vom Datentyp nvarchar(256), so auch jene, die mir Probleme machen.
Neu sollen einige Spalten auch östliche Schriftzeichen enthalten: kyrillische, hebräische und arabische. Die Einträge habe ich anhand von dezimal Unicode-Tabellen im Format ✏ gemacht, wobei ich für das Kyrillische Zahlen von 1024 bis 1279 anstelle der 9999 eingesetzt habe, für das Hebräische Zahlen von 1425 - 1524 und für das Arabische solche zwischen 1536 und 1791.
Ein Eintrag lautet somit z.B. БеЛьІй und sollte so aussehen: Белый, tut es aber nicht.
Die Tabellen-Einträge werden von einer Drucksoftware abgerufen. Ein Layout besteht aus festen Feldern und variablen Feldern. In den festen Feldern kann ich Einträge ganz unproblematisch direkt mit einer dieser drei Schriftzeichenarten machen. Die Inhalte der festen Felder sind im Layout selbst abgespeichert. Variable Felder beziehen sich aber auf die SQL Tabelle. Der Anwender trifft eine Auswahl und der Inhalt wird von dort bezogen.
1.) Das Layout und der Druck der festen Felder erfolgt korrekt. In den variablen Felder steht aber Б etc.
2.) Wenn ich den Datensatz mit like%% abrufe, stehen im Feld die Unicodes
Was mache ich falsch?
Danke für Euer Input.
Berner
Ich habe eine Tabelle in MS SQL Server 2012 Express Edition auf einem Windows 7 PRO PC in einem isolierten Netzwerk ohne Internetzugang. Die Tabelle funktioniert auch tadellos, solange in den Spalten der Text auf Deutsch oder Englisch eingetragen wird. Die meisten Felder sind vom Datentyp nvarchar(256), so auch jene, die mir Probleme machen.
Neu sollen einige Spalten auch östliche Schriftzeichen enthalten: kyrillische, hebräische und arabische. Die Einträge habe ich anhand von dezimal Unicode-Tabellen im Format ✏ gemacht, wobei ich für das Kyrillische Zahlen von 1024 bis 1279 anstelle der 9999 eingesetzt habe, für das Hebräische Zahlen von 1425 - 1524 und für das Arabische solche zwischen 1536 und 1791.
Ein Eintrag lautet somit z.B. БеЛьІй und sollte so aussehen: Белый, tut es aber nicht.
Die Tabellen-Einträge werden von einer Drucksoftware abgerufen. Ein Layout besteht aus festen Feldern und variablen Feldern. In den festen Feldern kann ich Einträge ganz unproblematisch direkt mit einer dieser drei Schriftzeichenarten machen. Die Inhalte der festen Felder sind im Layout selbst abgespeichert. Variable Felder beziehen sich aber auf die SQL Tabelle. Der Anwender trifft eine Auswahl und der Inhalt wird von dort bezogen.
1.) Das Layout und der Druck der festen Felder erfolgt korrekt. In den variablen Felder steht aber Б etc.
2.) Wenn ich den Datensatz mit like%% abrufe, stehen im Feld die Unicodes
Was mache ich falsch?
Danke für Euer Input.
Berner
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665353
Url: https://administrator.de/contentid/665353
Ausgedruckt am: 23.11.2024 um 17:11 Uhr
11 Kommentare
Neuester Kommentar
Ein leidiges Thema, treibt mich regelmäßig in den Wahnsinn.
Du hast zwar eine Spalte die Unicode speichern kann, deine Unicode-Zeichen sind aber tatsächlich in HTML codiert. Für SQL ist das kein Unicode sondern eine Zeichenkette a la ASCII. Wie genau schreibst du die Zeichen in die Tabelle?
Hier mal ein bischen Code zur Veranschaulichung:
https://stackoverflow.com/questions/49817637/how-to-decode-html-encoded- ...
Du hast zwar eine Spalte die Unicode speichern kann, deine Unicode-Zeichen sind aber tatsächlich in HTML codiert. Für SQL ist das kein Unicode sondern eine Zeichenkette a la ASCII. Wie genau schreibst du die Zeichen in die Tabelle?
Hier mal ein bischen Code zur Veranschaulichung:
DECLARE @string NVARCHAR(10);
SET @string = N'Б';
SELECT @string,unicode(@string);
--Б 1041
SET @string = N'Б'
SELECT @string,cast(cast(@string AS XML) AS NVARCHAR(10));
--Б Б
Hallo Berner,
Dein Code ist fehlerfrei, im SSMS funktioniert er. Das einzige, was ich mir jetzt vorstellen kann ist, daß Adminer jede Zeile einzeln abschickt und nicht das Skript als ganzes verarbeitet. Das kannst Du ausprobieren, indem Du die Zeilenumbrüche entfernst, also:
Du mußt die Zeichen auch nicht einzeln umwandeln, Du kannst alle Zeichen in einen String packen.
Aber Du willst das ja sowieso in eine Tabelle schreiben, dann geht das auch direkt über einen insert- oder update-Befehl:
Danke übrigens ukulele, das mit dem Umwandeln der HTML-Codes kannte ich noch nicht (hab ich aber bis jetzt auch noch nicht gebraucht).
Gruß, Mad Max
Dein Code ist fehlerfrei, im SSMS funktioniert er. Das einzige, was ich mir jetzt vorstellen kann ist, daß Adminer jede Zeile einzeln abschickt und nicht das Skript als ganzes verarbeitet. Das kannst Du ausprobieren, indem Du die Zeilenumbrüche entfernst, also:
DECLARE @string NVARCHAR(50); SET @string = N'БеЛьІй'; SELECT @string,cast(cast(@string AS XML) AS NVARCHAR(10));
Du mußt die Zeichen auch nicht einzeln umwandeln, Du kannst alle Zeichen in einen String packen.
Aber Du willst das ja sowieso in eine Tabelle schreiben, dann geht das auch direkt über einen insert- oder update-Befehl:
insert into Tabelle (Wert nvarchar (256)) values (cast (cast ('БеЛьІй' as xml) as nvarchar (256)))
update Tabelle set Wert = cast (cast ('БеЛьІй' as xml) as nvarchar (256)) where ...
Danke übrigens ukulele, das mit dem Umwandeln der HTML-Codes kannte ich noch nicht (hab ich aber bis jetzt auch noch nicht gebraucht).
Gruß, Mad Max
Ja sry bin auch schwer beschäftigt und schreibe grade weniger.
Der Code war nur zur Veranschaulichung in SSMS und schreibt oder ließt erstmal nicht in der Tabelle, das müsste dann per UPDATE oder INSERT gemacht werden. Ich ging davon aus das du ein Front-End / Anwendung hast die die Tabelle mit Daten füttert und dort Probleme mit dem Zeichensatz entstehen. Natürlich kann prinzipiell jeder Client solche Probleme mit sich bringen aber auch ein Webclient müsste theoretisch in der Lage sein damit umzugehen.
Aber du hast es ja hin bekommen Sollte es eine Randerscheinung bleiben kannst du dir mit cast() AS XML behelfen. Wenn du das öfters brauchst würde sich eventuell ein anderer SQL-Editor besser schlagen.
Der Code war nur zur Veranschaulichung in SSMS und schreibt oder ließt erstmal nicht in der Tabelle, das müsste dann per UPDATE oder INSERT gemacht werden. Ich ging davon aus das du ein Front-End / Anwendung hast die die Tabelle mit Daten füttert und dort Probleme mit dem Zeichensatz entstehen. Natürlich kann prinzipiell jeder Client solche Probleme mit sich bringen aber auch ein Webclient müsste theoretisch in der Lage sein damit umzugehen.
Aber du hast es ja hin bekommen Sollte es eine Randerscheinung bleiben kannst du dir mit cast() AS XML behelfen. Wenn du das öfters brauchst würde sich eventuell ein anderer SQL-Editor besser schlagen.