nicht angemeldet
SQL-Server - Problem mit Länge eines NVarChar-Feldes
Guten Tag Forum,
ich muss auf Grund zu implementierender Merhsprachigkeit die Daten
eines Web-Auftritt (Java/Turbine/Velocity/Hibernate) nun in Unicode
verwalten. So weit konnte ich auch alles recht erfolgreich umsetzen -
was das Frontend angeht. Doch bei der Persistence-Schicht allerdings
treten ein paar Probleme auf.
Nach Umwandeln eines Strings in einen Unicodestring besteht dieser
dann ja aus string.length()*6 zeichen. Die Datenbank (SQLServer)
wird mittels BO-Generierung erzeugt, wobei man dort direkt die Länge
eines Feldes anzugeben hat. Nun soll also ein Feld "Bemerkung" mit
der Länge von 250 Zeichen erstellt werden. Doch hier scheitert es
dann, denn 250 Zeichen sind nicht im Sinne von Unicode zu verstehen.
Somit ist die maximale zugelassen Zeichenlänge lediglich string.length()/6.
Ich habe mal gehört, dass mittels eines 'N' vor dem Spaltentyp
(nvarchar) die Spalte zu Unicode geändert werden kann. Doch nach
meinen Versuchen zählt auch hier die Begrenzung jedes einzelne
Zeichen (/u0064 = 6 Zeichen).
--- -
Wie löst ihr solche Probleme ? Oder habe ich einfach etwas übersehen ?
Besten Dank für Bemühungen
Christopher
-
Guten Tag Forum,
ich muss auf Grund zu implementierender Merhsprachigkeit die Daten
eines Web-Auftritt (Java/Turbine/Velocity/Hibernate) nun in Unicode
verwalten. So weit konnte ich auch alles recht erfolgreich umsetzen -
was das Frontend angeht. Doch bei der Persistence-Schicht allerdings
treten ein paar Probleme auf.
Nach Umwandeln eines Strings in einen Unicodestring besteht dieser
dann ja aus string.length()*6 zeichen. Die Datenbank (SQLServer)
wird mittels BO-Generierung erzeugt, wobei man dort direkt die Länge
eines Feldes anzugeben hat. Nun soll also ein Feld "Bemerkung" mit
der Länge von 250 Zeichen erstellt werden. Doch hier scheitert es
dann, denn 250 Zeichen sind nicht im Sinne von Unicode zu verstehen.
Somit ist die maximale zugelassen Zeichenlänge lediglich string.length()/6.
Ich habe mal gehört, dass mittels eines 'N' vor dem Spaltentyp
(nvarchar) die Spalte zu Unicode geändert werden kann. Doch nach
meinen Versuchen zählt auch hier die Begrenzung jedes einzelne
Zeichen (/u0064 = 6 Zeichen).
Wie löst ihr solche Probleme ? Oder habe ich einfach etwas übersehen ?
ihr bastelt dann wohl alle nur einsprachige anwendungen?
aber trotzdem danke ;-(Christopher
-
Hi,
ein NVARCHAR hat einen doppelten Speicherbedarf RDBMS-seitig als VARCHAR. Insgesamt kannst Du 8000 Zeichen in einen Datensatz packen. Nicht viel.
Zu Deinen Problemen: schreib doch mal einfach, was Dein "DB-Problem" ist!
Gruss,
Ludger--
"Die SPD im Aufwind?"-
Hallo Ludger,
danke erstmal für deine Antwort.
Also mir ist mittlerweile aufgefallen, dass ich glaube ich eine wenig
Verständnisprobleme hinsichtlich der Speicherung von Unicode in einer
Datenbank habe.ein NVARCHAR hat einen doppelten Speicherbedarf RDBMS-seitig als VARCHAR.
Gut. Das habe ich mittlerweile auch herausgefunden. Denn Unicode wird
mit 2, statt des gewöhnlichen 1 Bytes, gespeichert. Was logischerweise
zur Konsequenz führt, dass man nur die Hälfte an Daten speichern kann,
bzw. dass genau der doppelte Speicher verbruacht wird.schreib doch mal einfach, was Dein "DB-Problem" ist!
Wenn ich in Java mittels eines UnicodeFormatters einen String codiere,
bekomme ich nacher so etwas heraus wie \u0040\u0065\u0023\u0030 o.ä..
Dieses ist doch jetzt gültiger Unicode oder nicht?
Kann ich den Wert jetzt in die Unicode-DB-Spalte einfügen?
Das verstehe ich nämlich nicht so recht. Denn aus dem Satz "besser wäre
es" ensteht nach der Umstellung zum Unicode: "\u0062\u0065\u0073\u0073\u0065\u0072\u0020\u0077\u00e4\u0072\u0065\u0020\u0065\u0073"
und das sind doch jetzt definitv mehr als die ursprünglichen Zeichen,
und selbst mehr als die UnicodeDarstellung, wenn ich es mittels
INSERT INTO BLA VALUES(N'besser wäre es') machen würde.Ich verstehe nicht so recht, was ich zu sehen bekomme. Ob zB. mein
SQL-Query-Analyzer einen unicode-Wert intern direkt umwandelt, damit
der User es 'richtig' zu sehen bekommt. Bzw. wie so etwas überhaupt
abläuft.Danke
Christopher
-
Hi,
schreib doch mal einfach, was Dein "DB-Problem" ist!
Wenn ich in Java mittels eines UnicodeFormatters einen String codiere,
bekomme ich nacher so etwas heraus wie \u0040\u0065\u0023\u0030 o.ä..
Dieses ist doch jetzt gültiger Unicode oder nicht?nein. Unicode ist entweder 8, 16, 24 oder 32 Bit "breit". "\u0040" z.B. ist nur eine Anweisung an die Umgebung Unicode spaeter zu Erstellen. Das muss die Umgebung aber natuerlich nicht machen sondern sie kann auch mit "\u0040" uninterpretiert weiterarbeiten.
Mal durchlesen: http://de.selfhtml.org/inter/unicode.htm
Ich verstehe nicht so recht, was ich zu sehen bekomme. Ob zB. mein
SQL-Query-Analyzer einen unicode-Wert intern direkt umwandelt, damit
der User es 'richtig' zu sehen bekommt. Bzw. wie so etwas überhaupt
abläuft.Ja, das mit dem was man zu sehen bekommt ist tatsaechlich merkwuerdig. Es kann sein, dass Du "so etwas" zu sehen bekommst und es ist Unicode, der vier Byte pro Zeichen benoetigt. ;-)
Wenn Unicode vorliegt, dann benoetigt die bearbeitende Routine auch (manchmal ;-) die Anweisung, dass es Unicode ist (bei MS SQL Server das 'N'). Wenn Du z.B. UTF-8 (eine spezielle Unicode-Variante) Code liest und die Routine weiss nicht, dass es Unicode ist oder unterstuetzt Unicode erst gar nicht, dann bekommst Du vielleicht "sowas SchA~nes" zu sehen (Umlaute 16Bit codiert).
(Ich habe mich in den letzten Monaten auch an verscheidenen Fronten (PDF-Erstellung, Perl, Perl-DBI, MS SQL Server) mit Unicode-Problemen herumschlagen duerfen). Nichtsdestotrotz "Unicode sit lieb" und "ISO-8859-? ist boese". ;-)
Gruss,
Ludger"Unicode im Aufwind?"
-
danke dir.
"Unicode im Aufwind?"
Unicode im Aufwind!
-
-
-