Ein Mysterium in klassischen Domino-Web-Anwendungen

von Arnd Koch,
assono GmbH, Standort Kiel,

Bei der klassischen Web-Entwicklung unter Lotus Domino (ohne XPages) stößt man bei der Verwendung von Umlauten in Feldnamen auf ein "großes" Problem: Die Feldnamen werden bei der Generierung der Web-Seite durch Domino in einen kryptischen String umgewandelt. Will man jetzt z.B. clientseitig, also im Browser, eine Validierung vornehmen, so ist es nicht möglich, nur anhand der Feldnamen im HTML auf die Namen im eigentlichen Dokument zu schließen. Am besten wäre es, die Feldnamen für die JavaScript-Validierung zu berechnen, bevor das HTML generiert und an den Browser geschickt wird.

Dabei stößt man jedoch auf zweierlei Probleme:

Einerseits ist es nicht möglich, diese Umkodierung der Feldnamen manuell durchzuführen, Feldnamen werden ausschließlich durch den Server umkodiert, aber es gibt keine Funktion die man hier verwenden könnte. Das einzige, was man mit einem so kodierten Feldnamen tun kann, ist ihn mit "@URLDecode" wieder in das Original umzuwandeln, was im Browser nicht ohne Weiteres geht und gewisse Risiken birgt.

Andererseits ist die Art der Kodierung nicht dokumentiert, was das Implementieren einer eigenen Funktion erschwert. Um dies doch zu ermöglichen, folgt hier eine Analyse des Kodierungsverfahrens, das bei Notes/Domino verwendet wird.

Verwendet man den Feldnamen "Straße" so kodiert der Server den Namen als "_gadq74of1ck_", analysiert man verschiedene Beispiele und lässt hierbei die Unterstriche einmal weg so kann man anhand der  verwendeten Zeichen darauf schließen, dass es es sich um eine Base32-Kodierung handelt, jedoch entspricht das Ergebnis bei verschiedenen Varianten von Base32 nicht der Domino-Kodierung:
"Straße" -> Domino    -> "gadq74of1ck"
"Straße" -> Base32    -> "kn2heyo7mu"
"Straße" -> zBase32   -> "un7rzo75fd"
"Straße" -> Base32hex -> "adq74ogvck"

Eine Ähnlichkeit besteht offensichtlich mit Base32hex (RFC 4648 (1)), allerdings ist die Übereinstimmung nicht perfekt:
Notes:     gadq74of1ck
Base32hex:  adq74ogvck

Die Domino-Kodierung enthält also ein zusätzliches Zeichen und weicht teilweise von dem Base32hex-Ergebnis ab.

Um dieses Muster nun näher zu untersuchen, ist es erforderlich, einmal den von Domino berechneten String zu dekodieren; dabei wird an dieser Stelle zunächst auf das erste Zeichen verzichtet:
1: kodierter Feldname
2: Umwandlung in Dezimalzahlen laut Base32hex-Tabelle
3: Binäre Darstellung, je 5 Bit pro Zeichen
4: Neugruppierung der Bits
5: Gruppen mit je 8 Bit pro Zeichen
6: Umwandlung in Zeichen

1:    a     d     q     7     4     o     f     1     c     k
2:   10    13    26     7     4    24    15     1    12    20
3: 01010 01101 11010 00111 00100 11000 01111 00001 01100 10100
4: 01010011011101000111001001100001111000010110010100
5: 01010011 01110100 01110010 01100001 11100001 01100101
6:        S        t        r        a        á        e

Die Abweichung "f1" zu "gv" resultiert also aus einem anderen Zeichen als dem angenommenen "ß", folglich kodiert Domino die Zeichen intern nach einer anderen Zeichentabelle, eine Recherche hierzu fördert die MS-DOS-Codepage 850 (2) zu Tage, bei der das Zeichen "ß" tatsächlich dem dezimalen Wert "225" entspricht. Damit wird es allerdings keinesfalls leichter, da vermutlich abhängig von den Systemvorgaben auch andere Codepages verwendet werden.

Was noch fehlt ist das zusätzliche erste Zeichen der Domino-Kodierung, dekodiert man auch dieses Zeichen nach Base32hex so erhält man folgende Ergebnis:
     g
    16
 10000

Diese zusätzlichen 5 Bit dienen als Paritätsbits (gerade Parität) und somit zur Prüfung der Kodierung, dies wird in etwas anderer Darstellung deutlicher:
g adq74of1ck
1 0010010001
0 1110011010
0 0101101011
0 1011001000
0 0101001100
 
Das war es dann auch schon - ein Mysterium weniger da draußen smile.gif

(1) http://www.rfc-editor.org/rfc/rfc4648.txt
(2) ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP850.TXT

Fachbeitrag IBM Notes IBM Notes Traveler Entwicklung

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

IBM Cognos Analytics 11.0.9 (R9)

IBM Cognos Analytics 11.0.9 (R9)

Erst Mitte November hatten wir über Neuerung in der Version 11.0.8 gebloggt. Knapp ein Monat später veröffentlicht IBM die Version 11.0.9 … Mehr

von
Filip Meyer
,

Sie haben Fragen? Wir sind für Sie da.

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Sie können uns auf verschiedene Weisen für eine unverbindliche Erstberatung erreichen:

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Techn. Hotline: +49 4307 900 403
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de