But there are two problems:
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:
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
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:
Well that's it, one less mystery out there