Auf dieser Website werden Cookies gesetzt, die für den sicheren Betrieb technisch erforderlich sind. Siehe: Datenschutz

A Classic Lotus Domino Web Development Mystery

by Thomas,
assono GmbH, Standort Kiel,

In classic Lotus Domino Web development (without XPages) using non-7 bit-ASCII characters in field names can lead into problems, because Domino encodes such names into cryptic strings inside the HTML page. In some cases, i.e. for client side validation of fields using JavaScript in the browser, it is nearly impossible to get the original fields name off the encoded one. The easiest way would be to pre-calculate the encoded names in the Domino back-end and generate the needed JavaScript code before the HTML is send to the browser.

But there are two problems:
The first problem is, there is no function available to encode data in the same way that Domino uses during generation of the HTML. The only way to decode such a string is using the "@URLDecode" function, which isn't available in JavaScript in the browser.
The other problem is that the encoding algorithm seems not to be documented at all, which makes it quite hard to implement an appropriate encoding function yourself. Well, there is a light at the end of the tunnel and I did a little research on this. The following analysis shows how this encoding works:

When using the field name "Straße" (eng.: street, the "ß" is a sharp "s" in german) the Domino server encodes this into "_gadq74of1ck_". When removing the underscores and trying various examples, the conclusion is that it must be some kind of Base32 encoding, but the results of various Base32 variants don't match the Domino one:
"Straße" -> Domino -> "gadq74of1ck"
"Straße" -> Base32 -> "kn2heyo7mu"
"Straße" -> zBase32 -> "un7rzo75fd"
"Straße" -> Base32hex -> "adq74ogvck"

Looking a little closer at the result, there is a partial match on the Base32hex (RFC 4648 (1)) encoding, but there are some differences:
Notes: gadq74of1ck
Base32hex: adq74ogvck

The Domino encoded value has an extra character and doesn't match the Base32 result in all characters, to look a little closer at the cause of these differences, it is needed to decode the Domino generated string step by step. For now, we skip the first character. It'll be explained later on:
1: encoded field name
2: translation into the decimal values according to the Base32hex table
3: binary values, 5 bit per character
4: regrouping of the bits
5: groups of 8 bit per character
6: converting into characters

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

The difference between "f1" and "gv" is resulting from another character being used instead of the "ß". The conclusion is that Domino uses another character set to encode the field names; a little research on common charsets brings the MS-DOS Codepage 850 (2) to the eye, indeed in this charset and its relatives, the "ß" matches the decimal value of "225". This however doesn't make it not easier, most likely the used code page varies depending on the systems configuration so developing a fully compatible encoding function might be a challenge.

Now the explanation of the above mentioned first character in the Domino encoding, this one is a little tricky, too. First we need to decode it again using Base32hex:

The additional 5 Bits are Parity Bits (Even Parity) and are used to validate the encoding to prevent errors, to make this more clear we use a different display order of the results:
g adq74of1ck
1 0010010001
0 1110011010
0 0101101011
0 1011001000
0 0101001100

Well that's it, one less mystery out there smile.gif


Technical article IBM Notes IBM Notes Traveler Development

You have questions about this article? Contact us:

Sie wollen eine individuelle Beratung oder einen Workshop? Read more

More interesting entries

Any questions? Contact us.

If you want to know more about our offers, you can contact us at any time. There are several ways to contact us for a non-binding first consultation.

assono GmbH

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

Location Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Phone numbers:
Human resources department: +49 4307 900 407
Marketing department: +49 4307 900 402

E-Mail adresses: