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 
(1) http://www.rfc-editor.org/rfc/rfc4648.txt
(2) ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP850.TXT
