Dummes DB-Design trifft dämlichen ASCII-rulez!-Ansatz.
In der DB der vorhergehender Version der Groupware-„Lösung“ gibt es 1. keine eindeutige ID für Benutzer, 2. nicht-eindeutige Display-Names und 3. etliche durchaus relevante Felder (created by, midofied by u.ä.) in denen wild gemischt mal der Benutzername und mal der Display-Name drin stehen. Da war ich dann erst mal am kotzen.
Im in Python geschriebenen Export-Tool muss es nun – natürlich – die Funktion geben, diese bunte Sammelsurium an Benutzer-Identifikatoren halbwegs sauber in die XML-Files reinzupacken. So weit so schlecht.
Nun kann so ein Display-Name (i.d.R. Vorname Nachname) nun Non-ASCII-Zeichen enthalten, was wohl nicht bedacht wurde, auf jeden Fall wurde dies in dem Tool nur in einem Viertel der Fälle umgesetzt (ob es nun Absicht oder Inkompetenz war *shrug*). Aber wie dem auch sei, das Zeug habe ich jetzt gefixt – kann mir nun jemand erklären, warum es in Python den ASCII-only-Ansatz gibt? UTF-8 ist recht straight forward und auch schon einige Jährchen standardisiert, selbst in Java hat ein char eine Breite von 16 Bit und spackt nicht rum, nur weil man aus einer DB UTF-8-Strings ausliest, in eine Variable packt und diese in ein XML-Konstrukt wirft.