Unicode Unterstützung

Bis und mit Vertec 6.4 war die Datenhaltung von Texten in Vertec (z.B. Adressen, Leistungstexte, Bemerkungen) auf ein 1 Byte Encoding beschränkt, nämlich Windows-1252 oder ANSI (die beiden Begriffe meinen das gleiche, wir verwenden im folgenden ANSI als Begriff). Vertec konnte also genau die in ANSI definierten Zeichen verarbeiten, siehe z.B. Wikipedia . Andere Zeichen wurden durch ? ersetzt.

Mit diesem 250 Zeichen umfassenden ANSI-Zeichensatz können Englisch und alle westeuropäischen Sprachen abgebildet werden, was in den meisten Fällen für die Anwendung von Vertec genügt. Immer mehr Kunden mit Geschäftsbeziehungen nach beispielsweise Osteuropa wünschten sich jedoch die Möglichkeit, auch diese Adressen korrekt in Vertec abbilden zu können. Aus diesem Grund erfolgte mit Vertec 6.5 die Umstellung auf Unicode.

Ab Vertec 6.5 werden Texte in Vertec in Unicode abgespeichert. Dementsprechend unterstützt Vertec alle rund 65'000 Zeichen der BMP ("Basic Multilingual Plane") und damit die Zeichen aller relevanten Sprachen, einschliesslich sämtlicher asiatischer Sprachen. Zeichen, die ausserhalb der BMP liegen und in Vertec eingetragen werden, werden (wie bereits bisher bei nicht unterstützten Zeichen) durch ein ? ersetzt, was nur bei einigen wenigen Emojis der Fall sein dürfte.

Bei einem Datenbank Konvert von 6.4 auf 6.5 werden alle Texte in Vertec von ANSI auf Unicode konvertiert. Auf der Oberfläche bleibt diese Änderung unsichtbar. Die Vertec Datenbank wird dadurch in der Regel beim Update 20%-30% grösser, was jedoch kaum negativ auffallen dürfte.

Rückwärtskompatibilität

Die Erweiterung auf Unicode ist vollständig abwärtskompatibel, hingegen nicht unbedingt vorwärtskompatibel. Dies bedeutet, dass sich eine bestehende Vertec Installation bei gleicher Nutzung auch gleich verhält, sobald jedoch Unicode Zeichen in Vertec verarbeitet werden (bewusst oder unbewusst, z.B. über das Reinkopieren eines Textes), dies nicht unbedingt der Fall sein wird.

Im Folgenden werden einige Punkte aufgeführt, die bei Kundeninstallationen allenfalls Aufmerksamkeit benötigen. Die Risiken konzentrieren sich dabei auf kundenspezifische Scripts (vor allem Python) und Schnittstellen.

Python und Unicode

Ein Vertec String-Member (wie z.B. der Text einer Leistung) war bis zur Version Vertec.6.4 vom Typ str, in 6.5 vom Typ unicode. Das stellt sicher, dass Python Code der Strings kopiert, zusammensetzt, ergänzt etc. immer noch gleich funktioniert. Das str-Modul wurde von uns zusätzlich auf Unicode «umgebogen», weil eine Analyse von bestehendem Python Code bei Kunden gezeigt hat, dass es viele Verwendungen von str() gibt für eine Umwandlung von z.B. auch Strings selber zu einem String existieren, die ohne diese Korrektur dann Fehler generieren würde.

Das Default Encoding in Python ist ANSI. Das sichert eine grösstmögliche Rückwärtskompatibilität bei bestehendem Code von Versionen vor 6.5. Allerdings können nicht-ANSI Zeichen nicht direkt als Stringliterals angegeben werden (in Python gibt es jedoch Alternativen).

Der Übergang von einem Unicode String in das Default Encoding, also von Unicode nach ANSI, ist fehlertolerant gestaltet: Zeichen, die nicht umgewandelt werden können, führen zu keinem Error, sondern werden durch ? ersetzt.

Encodings

Das Default Encoding in ANSI bringt es mit sich, dass bestehender Python Code von Versionen vor 6.5 nach dem Update allenfalls angepasst werden muss, wenn er z.B. Strings verarbeitet und in einem File speichert oder an einen Webservice sendet. Damit Nicht-ANSI Zeichen, die ab Version 6.5 in Vertec vorkommen können, korrekt ankommen, muss ein Unicode Encoding (wie z.B. UTF-8) gewählt werden – die Gegenseite muss dieses aber auch lesen können. Ohne ein explizites Encoding wie zum Beispiel

string.encode("UTF-8")

kommt die implizite Umwandlung auf ANSI mit dem allfälligen, oben erwähnten, Datenverlust von nicht-ANSI Zeichen zum Tragen.

Auch beim Einlesen von Daten nach Vertec, sei es über das Öffnen einer Textdatei, über den Vertec XML Server oder einem vtcapp.requestfilefromclient() sollte man sich ums Encoding kümmern, weil Datenverluste von nicht-ANSI Zeichen durch die Unicode Unterstützung unnötig sind. Liest man also z.B. ein Textfile ein, welches in UTF-8 encodiert ist, muss dieses korrekt dekodiert werden:

unicodestring = filecontent.decode("UTF-8")

Als Faustregel kann man sich merken, dass in Python

• encode immer von einem Unicode String zu einem Bytestream konvertiert (ä belegt z.B. 2 Bytes in UTF-8)
• decode immer von einem Bytestream (z.B. in UTF-8 encodiert) zu Unicode konvertiert.

Kundenspezifische Extensions

Das «Umbiegen» des str-Moduls auf Unicode wird nicht bei kundenspezifische Extensions gemacht, die als Python Files im Ordner Extensions im Vertec Verzeichnis liegen. Dies betrifft auch abgeänderter Extension-Code, der ursprünglich von Vertec geliefert wurde. Bei diesen Extensions führt ein str() dazu, dass ein Unicode String mit dem erwarteten Datenverlust bei nicht-ANSI Zeichen nach ANSI umgewandelt wird. Kunden mit solchen Schnittstellen sollten den Python Code beim Update auf Version 6.5 auf mögliche Probleme untersuchen.

Unicode Unterstützung bei Zusatzfeldern

Die Zusatzfeldtypen Zeichenund Textkonnten in Vertec 6.4 Text darstellen. Dabei ist Zeichen ein Feld, welches auf maximal 255 Zeichen beschränkt ist, während das Feld Text unbeschränkt ist. Die Zusatzfelder vom Typ Zeichen werden mit 6.5 automatisch auf Unicode umgestellt, diejenigen vom Typ Text nicht.

Die Zusatzfelder vom Typ Textwerden in der Datenbank als BLOB-Felder (Binary Large Object) abgespeichert. Dies bedeutet, dass die Daten als reine Binärdaten in der Datenbank abgespeichert und erst in der Vertec Businesslogik als Texte interpretiert werden. Da die Zusatzfelder vom Typ Bildim gleichen Datenbankfeld gespeichert werden, bleiben Zusatzfelder vom Typ Text aus Gründen der Abwärtskompatibilität in Vertec 6.5 unveränderte 8-Byte Texte im ANSI Format.

Mit Vertec 6.5 gibt es stattdessen den neuen Zusatzfeldtyp Unicode Text:

Falls Sie Zusatzfelder vom Typ Text verwenden, empfehlen wir dringend, diese unmittelbar nach dem Konvert auf Unicode Text umzustellen. Der DB Konvert auf 6.5 kopiert die Texte aus dem Feld Text automatisch im richtigen Format in das Feld Unicode Text.

Achtung: Alle Zugriffe auf das Zusatzfeld (OCL, SQL) müssen ebenfalls umgestellt werden:

• bei SQL von WERTBLOBauf WERTTEXT
• in OCL von zusatzfeldblob('zusatzfeldname')auf zusatzfeld('zusatzfeldname').