Datenbankfrage zu Tabellenfeldern mit Name, Vorname, ... Umgang mit Sonderzeichen ... UTF8 / UTF16

[T-Hagel-SK]

Hallo zusammen,

wir hatten gerade in unserer SchildZentral2-Datenbank ein bisschen Aufregung, weil in ein paar wenigen Fällen das Eintragen von Zusatznamen nicht möglich war, weil das Programm z.B. vietnamesische Zeichen nicht annahm. Ursache war, dass das betroffene Datenfeld (aber auch ein paar andere) nur mit varchar statt mit nvarchar angelegt wurden.

Im Zuge dessen habe ich mal in SchILD3 in der Datenbank nachgeschaut. Hier ist z.B. in der Tabelle "Schueler" bei Name, Vorname, Zusatz, Geburtsname die Definiztion varchar und die Collation uft8mb4_bin eingetragen.

Wenn ich mir so die Zeichentabelle zu UTF8 anschaue, sind dort schon recht viele Sonderzeichen enthalten, aber eben nicht die, mit denen wir jetzt gerade zu kämpfen hatten. D.h. meiner Meinung nach müssten bei den Namensfeldern und ggf. auch bei den Geburtsorten die Collation auf UTF16 hochgeschraubt werden. Oder ?

Schöne Grüße Thomas Hagel

Stadt Köln Fachanwendungsbetreuung

[ThomasBachran]

@T-Hagel-SK : Die Definition von nvarchar und varchar mit UTF8 (mb4) ist hier äquivalent, wie in https://mariadb.com/kb/en/varchar/ nachzulesen ist.

• An welcher Stelle ist denn die fehlerhafte Darstellung?
• Liegt es daran, dass die Datenbank selbst das Zeichen nicht enthält? Oder liegt es daran, dass der Client es nicht darstellen kann?
• Um welche Unicodes handelt es sich denn konkret? Eventuell kann ich das Szenario dann nachstellen...

[T-Hagel-SK]

Das mit UTF8 und nvarchar/varchar hatte ich mir vor dem Eintrag auch schon mal angeschaut. Deswegen kam ich ja auf UTF16.

Die Zeichen werden in Schild zwar eingetragen, beim Speichern aber kommt es zur Fehlermeldung: "Ein Datensatz der Tabelle "Schueler" kann nicht abgespeichert werden. Fehlermeldung: Fehler bei einem aus mehreren Schritten bestehenden Vorgang. "

Nachdem wir die Namens-Felder auf dem SchildZentral2-MSSQL-Server von varchar auf nvarchar umgestellt hatten, ließen sich Namen mit diesem Zeichen problemlos speichern..

In unserem Fall ging es um vietnamesische Zeichen, wie etwa "ả". Das aber ist in SchILD3 mit UTF8 abgedeckt.

https://www.utf8-zeichentabelle.de/unicode-utf8-table.pl?unicodeinhtml=dec https://www.fileformat.info/info/charset/UTF-16/list.htm

UTF8 deckt die Sonderbuchstaben A, C, E, I, D, N, O, U, Y in groß und klein ab. UTF16 hingegen auch G, H, J, K, L, R, S, T, W, Z.

[ThomasBachran]

@T-Hagel-SK: Das Zeichen "ả" lässt sich im SVWS-Client problemlos eingeben und wird auch in der SVWS-DB korrekt mit utf8mb4 gespeichert. Eine Eingabe in Schild 3 ist z.B. bei einem Lehrernachnamen bei mir auch möglich. Ich kann daher kein allgemeines Problem mit dem Charset bzw. der Collation feststellen. Das Zeichen hat den Codepoint U+1EA3 und ist in der Darstellung von utf8 in hex E1 BA A3. Da sie oben geschrieben haben, dass sie damit Schweirigkeiten in Ihrer SchildZentral2-DB hatten, scheint dies nicht den SVWS-Server zu betreffen. Ich schließe daher das Issue hier.

[T-Hagel-SK]

Das besagte a-Zeichen "mit Ring" ist nicht das Problem. Das wird ja wie beschrieben in der UTF8 abgebildet.

Wie oben beschrieben deckt UTF8 aber nicht die Sonderzeichen ab, die es unter den Varianten der Buchstaben "G, H, J, K, L, R, S, T, W, Z." abdeckt...

[ThomasBachran]

@T-Hagel-SK : Ich bräuchte da konkrete Beispiel, um das nachvollziehen zu können.

[kroerig]

Möglicherweise macht es auch einen Unterschied, ob die Daten über den SVWS oder den Full-Clients erfasst werden. Der SVWS nutzt auf jeden Fall die API und UTF-8 als Zeichensatz bei der Übertragung.

SchILD 3 nutzt vermutlich auch die API aber nicht zwinged UTF-8 als Zeichensatz. Manches läuft bei dem Full-Client aber auch per direktem DB Zugriff.

[JuergenRichter]

Ich habe mal in SchILD3 alle Varianten des Buchstabens "G" eingegeben (GgĜĝĞğĠġĢģ), die das Windows-Programm "Zeichentabelle" hergibt. Funktioniert einwandfrei:

[T-Hagel-SK]

SchILD 3 nutzt vermutlich auch die API aber nicht zwinged UTF-8 als Zeichensatz. Manches läuft bei dem Full-Client aber auch per direktem DB Zugriff.

Da aber über den SVWS-Server die Datenbanken migriert werden und von dort die Vorgabedaten für den DB-Aufbau kommen, frag ich hier und nicht beim Client nach. :-)

[T-Hagel-SK]

Ich habe mal in SchILD3 alle Varianten des Buchstabens "G" eingegeben (GgĜĝĞğĠġĢģ), die das Windows-Programm "Zeichentabelle" hergibt. Funktioniert einwandfrei:

Erstaunlich ... Werden diese Zeichen denn auch so in der Datenbank gespeichert ?

[JuergenRichter]

Ja, werden gespeichert:

[T-Hagel-SK]

Ja, werden gespeichert:

noch erstaunlicher ... aber erfreulich, wenn es klappt, obwohl UTF8 diese Zeichen gar nicht vorsieht ...

[JuergenRichter]

Ich zitiere mal (https://askanydifference.com/de/difference-between-unicode-and-utf-8/?utm_content=cmp-true) "Unicode ist ein universeller Zeichencodierungsstandard, der jedem Zeichen in jeder Sprache und Schrift, einschließlich Emojis und Sonderzeichen, eine eindeutige Nummer oder einen Codepunkt zuweist. UTF-8 ist ein Codierungsschema mit variabler Länge, das jeden Unicode-Codepunkt auf eine Folge von 8-Bit-Bytes abbildet."

[T-Hagel-SK]

Ok, also Unicode ist geklärt. UTF ist ein Schema.

_1. UTF-8 ist eine Zeichenkodierung mit variabler Länge, während UTF-16 eine Zeichenkodierung mit fester Länge ist.

2. UTF-8 verwendet ein bis vier Bytes zur Darstellung von Zeichen, während UTF-16 zwei oder vier Bytes verwendet.
3. UTF-8 wird häufig für Webseiten und E-Mails verwendet, während UTF-16 für Sprachen verwendet wird, die mehr als zwei Bytes zur Darstellung von Zeichen benötigen._ (https://askanydifference.com/de/difference-between-utf-8-and-utf-16/)

Also bräuchten wir ein Namensbeispiel, bei denen die Darstellung eines Zeichens mehr als 2 Byte benötigen.

Wir können diesen Issue auch gerne erst mal geschlossen lassen und nochmal ausbuddeln, falls es dann mal zu Problemen mit Zeichen im Namen kommt, die auf Zeugnissen oder sonst wo nicht dargestellt werden können. Oder die von Programmmodulen nicht gefunden werden können.