Technik vor Einführung von CSharp (Cobol-Denkweise)
1 Zeichen = 1 Byte (max. 255 Zeichen, real: max. 223 Zeichen)
Die Interpretation des Zeichencodes erfolgt dabei über die unter Windows aktuell eingestellt Codepage (Systemsteuerung - Sprache)
Bei der SOG in Hamburg: Windows-1252
Siehe auch: https://de.wikipedia.org/wiki/ISO_8859-1#Windows-1252
Problem: Jeder Benutzer, jeder Arbeitsplatz und jeder Server kann mit einer anderen Codepage arbeiten!
Unterschiede Windows-1254 (Türkisch) zu Windows-1252 (Westeuropäisch)
Tabelle Windows-1251 Kyrillisch
Technik nach Einführung von CSharp
1 Zeichen = 2 Byte (Maximal 65535 Zeichen)
Interpretation = Unicode
Siehe auch: https://de.wikipedia.org/wiki/Unicode
#Unicode ist ein internationaler Standard <https://de.wikipedia.org/wiki/Standard>, in dem langfristig für jedes Sinn tragende Schriftzeichen <https://de.wikipedia.org/wiki/Schriftzeichen> oder Textelement aller bekannten Schriftkulturen <https://de.wikipedia.org/wiki/Schriften_der_Welt> und Zeichensysteme <https://de.wikipedia.org/wiki/Semiotik> ein digitaler Code <https://de.wikipedia.org/wiki/Code> festgelegt wird. Ziel ist es, die Verwendung unterschiedlicher und inkompatibler <https://de.wikipedia.org/wiki/Kompatibilit%C3%A4t_(Technik)> Kodierungen <https://de.wikipedia.org/wiki/Zeichenkodierung> in verschiedenen Ländern oder Kulturkreisen zu beseitigen. Unicode wird ständig um Zeichen weiterer Schriftsysteme ergänzt.
Mit der CSharp-Umsetzung ist SOG ERP in der Lage, die ersten 65535 Zeichen des Unicode-Zeichensatzes zu verarbeiten. Dies entspricht der Unicode „Basic Multilingual Plane“.
Die Basic Multilingual Plane (BMP; deutsch <https://de.wikipedia.org/wiki/Deutsche_Sprache> Mehrsprachige Basis-Ebene, auch als Plane 0 bezeichnet) enthält hauptsächlich Schriftsysteme, die aktuell in Gebrauch sind, Satzzeichen und Symbole, Kontrollzeichen und Surrogate-Paare <https://de.wikipedia.org/wiki/UTF-16>, und einen privat nutzbaren Bereich (PUA).[30] <https://de.wikipedia.org/wiki/Unicode> Der Block ist stark fragmentiert und weitgehend belegt, sodass neu zu codierende Schriftsysteme hier keinen Platz mehr finden. Der Zugriff auf andere Ebenen als der BMP ist in manchen Programmen noch nicht oder nur eingeschränkt möglich.
An Stelle eines Datentyps „char(30)“ wird nun „nchar(30)“ verwendet.
Diese Datenfelder belegen in der Datenbank n*2 Byte. Also hier: 60 Byte.
Überall, wo Textkonstanten verwendet werden müssen diese als N“TEXT“ geschrieben werden, wenn sie Unicode-Zeichen enthalten.
Diese Text-Umsetzung erfolgt automatisch durch unser Generic-SQL.
Der Grenzwert zur Entscheidung, ob ein Datenfeld als nchar(x) oder als nvarchar(x) erzeugt wird, beträgt nicht mehr 100 Zeichen, sondern 30.
Key-Datenfelder werden, sofern sie keine alphanumerischen Inhalte haben, weiter als char(x) erzeugt.
Das Konvertieren einer bestehenden Datenbank ist aufwendig, da sie einmal per sogdbunload entladen werden, neu angelegt, und per sogdbunload wieder neu geladen werden muss.
Geschwindigkeitsmessungen haben ergeben, dass Zugriff zum Teil schneller funktionieren als vorher. Dies liegt wahrscheinlich an den kleineren nvarchar-Feldern, ist damit aber natürlich vom effektiven Datenbestand abhängig.
Die Ausgabe von Dateien erfolgt ohne weitere Änderung wie vorher auch als Datei 1 Byte pro Zeichen mit der unter Windows eingestellten Codepage.
Beispiel: abcÄÖÜ<CR><NL>
00000000 616263C4 D6DC0D0A [abcÄ ÖÜ.. ]
Erfolgt eine Ausgabe in eine UTF-8 Datei, werden Unicode-Zeichen über eine definierte Codierung so umgesetzt, dass sie möglichst wenig Bytes belegen.
Zeichencodes Codierung (Binär) Datenbits (x)
00000000 - 0000007f 0xxxxxxx 7
00000080 - 000007ff 110xxxxx 10xxxxxx 11
00000800 - 0000ffff 1110xxxx 10xxxxxx 10xxxxxx 16
00010000 - 0010ffff 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 21
Der Algorithmus lässt theoretisch bis zu acht Bytes lange Byteketten und dadurch über vier Billionen Zeichen zu. Die letzte Stufe enthielte als erstes Byte 11111111 und danach sieben Folge-Bytes mit jeweils sechs Nutz-Bits. Die gesamte Codefolge wäre dann 2(7*6) = 242 = 4.398.046.511.104 Zeichen. Real definiert wurde ursprünglich eine Folge aus einem ersten Byte mit bis zu 1111110x und somit fünf Folge-Bytes der Form 10xxxxxx, also zusammen sechs Byte mit insgesamt 31 Bit für den enthaltenen Unicode-Wert. In seiner Verwendung als UTF-Kodierung <https://de.wikipedia.org/wiki/Unicode_Transformation_Format> ist er aber auf den gemeinsamen Coderaum aller Unicode-Kodierungen beschränkt, also von 0 bis 0010 FFFF (1.114.112 Möglichkeiten) und weist maximal vier Bytes lange Byteketten auf. Der damit verfügbare Wertebereich für den Zeichencode wird letztlich nicht vollständig benutzt. Entsprechend lange Bytefolgen und große Werte gelten heute als unzulässige Codes und sind entsprechend zu behandeln.
Damit ein lesendes Programm erkennen kann, dass es sich bei der Eingabedatei um eine UTF-8 Datei handelt, werden zu Anfang der Datei 3 „Magic Bytes“ geschrieben: 0xEF 0xBB 0xBF
Beispiel: abcÄÖÜ<CR><NL>
00000000 EFBBBF61 6263C384 C396C39C 0D0A [a bcÄ Ã-Ãœ .. ]
Darstellung mit „sogdump -utf8“
00000000 EFBBBF61 6263C384 C396C39C 0D0A
U8 a b c Ä Ö Ü 0D0A
Ausgabe im Format 2 Byte Unicode (z.B. Notepad)
Erfolgt eine Ausgabe in eine 2 Byte Unicode Datei, werden alle Zeichen mit 2 Byte codiert.
Damit ein lesendes Programm erkennen kann, dass es sich bei der Eingabedatei um eine 2 Byte Unicode Datei handelt, werden zu Anfang der Datei 2 „Magic Bytes“ geschrieben: 0xFF 0xFE
Beispiel: abcÄÖÜ<CR><NL>
00000000 FFFE6100 62006300 C400D600 DC000D00 [ÿþa. b.c. Ä.Ö. Ü...]
00000010 0A00 [.. ]
Darstellung mit „sogdump -unicode“
00000000 FFFE6100 62006300 C400D600 DC000D00 0A00
UC a b c Ä Ö Ü0D00 0A00
Der Vollständigkeit halber sei erwähnt, dass es auch das Format „Unicode-Big-Endian“ gibt, bei dem die Byte-Reihenfolge umgekehrt wird.
Magic Bytes: 0xFE 0xFF
Vorteile des Datenformates UTF-8
Gegenüber 1-Byte Dateien hat das UTF-8 Format den Vorteil, dass jedes Zeichen klar definiert ist. Ein Zeichencode hat immer eine definierte Bedeutung, und muss nicht über eine zugehörige Codepage interpretiert werden. UTF-8 Dateien können problemlos multinational ausgetauscht werden, sofern alle beteiligten die UTF-8 Codierung beherrschen.
Gegenüber dem 2 Byte Unicode-Format hat UTF-8 den Vorteil, dass alle Standardzeichen a-z, A-Z, 0-9 usw. nur ein Byte in der Datei belegen. Dadurch sind UTF-8 Dateien im Allgemeinen kleiner als Unicode-Dateien.
Generell hat UTF-8 gegenüber 2 Byte Unicode den Vorteil, dass alle Zeichen des Unicode Standards codiert werden können.
Ausgabe von sequentiellen Dateien (LGEN, .txt, CSV) aus SOG ERP
Bei der Ausgabe von LGEN-Listen kann die gewünschte Zeichencodierung mit Hilfe von „(utf8)“ oder „(unicode)“ als Präfix vor dem Ausgabepfadnamen vorgegeben werden.
Das Programm „sogutf8print“, das das Drucken solcher Dateien inzwischen realisiert, erkennt das Format automatisch.
Diese Form der Festlegung der Codierung ist auch an vielen anderen Stellen realisiert, an denen die Ausgabe von Schnittstellendateien erfolgt.
Bei Export von Daten in CSV (z.B. ObjectList Export) kann ggf. eingestellt werden, dass der Export im UTF-8 Format codiert werden soll.
Es muss mit der Partner-Software abgestimmt sein, dass diese die Codierung in UTF-8 (oder Unicode) lesen kann.
Außerdem muss abgestimmt werden, ob die Partnersoftware mit Zeichen zurechtkommt, die nicht der aktuellen Windows-Codepage entsprechen.
Ansonsten würden beim Lesen von UTF-8 Dateien alle Zeichen, die nicht in der aktuellen Windows-Codepage vorkommen, automatisch in ein Zeichen umgesetzt werden, das so ähnlich aussieht.
Also z.B.
Polnische Zeichen: ą ć ę ł ń ś ź ż Ą Ć Ę Ł Ń Ó Ś Ż Ź
Werden umgesetzt in: a c e l n s z z A C E L N Ó S Z Z
Wenn die Partnersoftware auf Daten der Datenbank z.B. über Views zugreift, muss geklärt werden, ob sie mit dem Datentyp „nchar“ oder „nvarchar“ zurechtkommen.
Außerdem muss auch hier abgestimmt werden, ob die Partnersoftware mit Zeichen zurechtkommt, die nicht der aktuellen Windows-Codepage entsprechen.