Default Character Set

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
Groffy
Beiträge: 24
Registriert: Do 12. Apr 2018, 23:14

Mo 13. Jul 2020, 09:42

Hallo Zusammen,

wenn ich in einer Datenbank für jedes CHAR, VARCHAR und (Text) Blob Feld explizit einen Zeichensatz angegeben habe, welchen Bedeutung hat dann noch der für die Datenbank vorgegebene Default Character Set?

Welcher Zeichensatz wird für die DDL Metadaten (Kommentare) angenommen?

Beste Grüße Ulrich Groffy
bfuerchau
Beiträge: 185
Registriert: Mo 7. Mai 2018, 18:09

Mo 13. Jul 2020, 09:57

Der Default Charset gilt für alle Felder, bei denen der Charset nicht explizit angegeben wird.
Metadaten (also RDB$-Tabellen) werden in UNICODE_FSS, einer speziellen Unicodecodierung der Firebird gespeichert.
Entscheidend für die Kommunikation bzgl. Zeichenfeldern ist der CHARSET der Connection. Wird dies weggelassen, gilt der Default-CHARSET der DB.
Groffy
Beiträge: 24
Registriert: Do 12. Apr 2018, 23:14

Mo 13. Jul 2020, 10:14

Hallo, vielen Dank für die Antwort
Der Default Charset gilt für alle Felder, bei denen der Charset nicht explizit angegeben wird.
Das hatte ich aus der verfügbaren Doku auch so verstanden
Entscheidend für die Kommunikation bzgl. Zeichenfeldern ist der CHARSET der Connection
Was passiert wenn Verbindungszeichensatz und Zeichensatz für ein Tabellenfeld unterschiedlich sind? Wird dann versucht beim lesen/schreiben zu konvertieren? Wenn ja - wo wird diese durchgeführt? Im Datenbanktreiber?
Benutzeravatar
martin.koeditz
Beiträge: 217
Registriert: Sa 31. Mär 2018, 14:35

Mo 13. Jul 2020, 17:14

Was passiert wenn Verbindungszeichensatz und Zeichensatz für ein Tabellenfeld unterschiedlich sind? Wird dann versucht beim lesen/schreiben zu konvertieren? Wenn ja - wo wird diese durchgeführt? Im Datenbanktreiber?
Wenn der Zeichensatz der Verbindung sowie der Standardzeichensatz der DB identisch sind, ist alles OK. Abweichende Feld-Kodierungen werden durch die DB-Instanz intern konvertiert und korrekt an die Verbindung übergeben.

Obacht ist beim Einfügen geboten. Es dürfen nur vorhandene Zeichen verwendet werden. Hast du beispielsweise ein Feld mit ISO 8859_1, kannst du z.B. kein €-Zeichen einfügen, da dieses Zeichen dem Zeichensatz nicht bekannt ist.

Gruß
Martin
Martin Köditz
it & synergy GmbH
Groffy
Beiträge: 24
Registriert: Do 12. Apr 2018, 23:14

Di 14. Jul 2020, 15:44

Hallo Martin,

Konvertierungsprobleme traten bei uns auf, nachdem wir irgendwann bemerkt haben, daß wir mit dem Zeichensatz Latin 1 (ISO8859_1) in Osteuropa (Ungarisch & Tschechisch) nicht weiterkamen und den Zeichensatz der Textfelder auf UTF8 geändert haben. Bei einigen Installationen wurde vergessen den Verbindungszeichensatz anzupassen und dann gab es Konvertierungsfehler beim lesen von UTF8 Strings, die nicht in ISO8859_1 konvertiert werden konnten.

Vielen Dank und beste Grüße - Ulrich Groffy
bfuerchau
Beiträge: 185
Registriert: Mo 7. Mai 2018, 18:09

Di 14. Jul 2020, 16:47

Willkommen in der Welt der vielen Zeichensätze.
Das schöne daran ist auch noch, dass außer native C++ alle Sprachen bzgl. Strings sowieso in Unicode (UCS2) arbeiten.
Wenn also der Treiber ISO_8859_1 oder WIN1252 nimmt, convertiert dieser erst mal UCS2 in ISO_8859_1 und im 2. Schritt dann die DB in den Zielcode.
Nun kommt auch noch UTF8 daher.
Also konvertiert der Treiber beim Senden von UCS2 in UTF8 und die DB schreibt das dann, ggf. mit Konvertierung, weg.
Beim Lesen aus der DB in UTF8 und im Treiber dann wieder in UCS2.
Hat man dann noch eine alte IDE (VB6, VBA), die kein Unicode kann, wird der UCS2-String in z.B. WIN1252 kodiert und ungültige Zeichen durch "?" ersetzt.

Derzeit gibt es noch keine Umgebung in der Strings nicht permanent konvertiert werden müssen.
Groffy
Beiträge: 24
Registriert: Do 12. Apr 2018, 23:14

Mi 15. Jul 2020, 11:07

Hallo bfuerchau
Hat man dann noch eine alte IDE (VB6, VBA), die kein Unicode kann, wird der UCS2-String in z.B. WIN1252 kodiert und ungültige Zeichen durch "?" ersetzt.
VB6 Code haben wir seit einigen Jahren glücklicherweise nicht mehr im Einsatz.


Eine Frage habe ich allerdings noch :

Wenn die Kombination von Verbindungszeichensatz und Zeichensatz der Text/Blob Felder zueinander passen, welche Auswirkung hat es noch wenn in der Datenbank ein anderer default CharacterSet definiert ist?

Besteht die Notwendigkeit mittels ALTER CHARACTER SET den default CharacterSet zu ändern? Wobei ich in der Doku gerade gesehen habe, daß ich den default CharacterSet mittels DDL nicht ändern kann...


Vielen Dank und beste Grüße
bfuerchau
Beiträge: 185
Registriert: Mo 7. Mai 2018, 18:09

Mi 15. Jul 2020, 13:38

Dies ergibt sich eigentlich von selber.
Der Default wird angewendet beim Create Table/Domain. Danach gilt nur noch das, was in der Domain steht (jedes Feld verweist auf eine Domain), da der Charset kopiert wird.
Du kannst natürlich den Default auf NONE setzen. Dies hat keine Auswirkungen solange du immer Charset beim Erstellen angibst.

VB6 war nur ein Beispiel. Die Office VBA-IDE ist immer noch nicht unicodefähig und der Excel-Querywizard ebenso wenig, auch wenn das Ergebnis nach dem Laden trotzdem korrekt ist.
Auch C++ wird noch gerne ohne den Unicodeschalter für wChar verwendet.

Ich bekomme auch ab und an Mails, wo mein Nachname als nativer UTF8-Code ausgegeben wird. Sowas passiert dabei eben.
Antworten