Answered C# to ABL

Hi everybody,

I have the following code that I should translate to ABL. The first 2 lines are easy, but i'm stuggeling with the last 2 lines.

int length = base64String.Length;
while (length > 0 && base64String[length - 1] == '=')

char[] chArray = new char[length + 1];
chArray[length] = (char)(48 + base64String.Length - length);

I came up with this solution, but i'm not sure if it is ok:

DEF VAR chArray as CHAR.
SUBSTR(chArray, length, 1) = CHR(48 + LENGTH(base64String) - length).

and if this is ok, then I don't understand what they are doing.
TIA, Wolf


Well-Known Member
Haha, so you're translating something from something that seems to work just fine and then wondering what it seems to be doing...

If as the title states, you need to encode rather than decode, then here's the Encode version of the method which I've tested and seems to work just fine.

Using the OpenEdge.Net.URI class may make more sense.
Hi Stefan,
thanks for your answer, but there are 2 things to mention:

1. IT WORKS, the solution I came up with works !
2. I'm dealing with DocuWare, and they care a shit of "standards" or if one understands what they are doing. I have to encrypt part of an URL-string to view a document in a web-browser. There is a whole thread about this encryption here in ProgressTalk ("AES CBC encryption" from Dec,2019). If I do the encryption with ABL, it is absolutely correct (I tested it with some Web-Tools), but Docuware can't recognize the encryption.
So I got a working C-Code from a friend and this one - after I have "translated" it to ABL - finally works. I think its not only the way they manipulate a Base64encoded string, but it also has to do with the Microsoft-encryption-library they use.
Just one more thing: after the Base64encoded a string, they manilpuate this string by replacing all "+" to "-" and all "/" to "_". And the last curious thing they do: they add this funny "CHR(48 + LENGTH(base64String) - length) " to the end of this string. Why "48" ??? Not even the guy who sent me the C#-code knows.
But anyway, now it works and i'm happy !


Well-Known Member
Formatting the original source that I referred to:

while (length > 0 && (int)str[length - 1] == 61)
char[] chArray = new char[length + 1];
chArray[length] = (char)(48 + str.Length - length);

61 is the ascii code for '=' - so the above is trimming all trailing '=' characters off the end of the base64 encoded string.
48 is the ascii code for '0', so by adding the difference in length, it is adding the ascii representation of the number of '=' characters that were trimmed.

Does it makes sense? Nah, sounds like madness.


It sounds like someone at DocuWare was unable to understand what the padding at the end of the standard is all about and unilaterally decided to fork the standard without documenting his departure from the standard.


Well-Known Member
Exactly - I think that the problem being solved is that the base64 encoded data is part of the url. The url contains key / value pairs separated by equals (=). The possible trailing equals (=) throw salt (pun intended) into the mechanism.

3.1.3 Base64 URL Encoding
Values must be encoded for the "lc" and "q" URL parameters, since complex data must be encoded before it can be used in a valid URL. DocuWare uses base64 URL encoding. Since the characters "+" and "/" may not be used in a URL, they must be converted to "-" and "_". You can find detailed specifications for this in the RFC 4648 document, section 5 (RFC 4648 - The Base16, Base32, and Base64 Data Encodings (DocuWare Knowledge Center)).

By way of example, the code in PHP looks like this:

function base64url_encode($plainText) { 
    $base64 = base64_encode($plainText);
    $base64url = strtr($base64, '+/', '-_'); 
    return ($base64url); 

Please note with strings containing inverted commas (see section Examples, e.g. [COMPANY]="Peters Engineering") that the inverted commas can vary depending on which editor you are using and can therefore also have different Base64 encoding. This will not affect the functioning of the URL.

In addition DocuWare removes the trailing ‘=’ characters and adds 0, 1 or 2 depending on characters removed. Implementation uses the .NET function "HttpServerUtility.UrlTokenEncode", find more information on the Microsoft website HttpServerUtility.UrlTokenEncode(Byte[]) Method (System.Web).
interesting that you found this documentation in the Docuware-Knowledgebase. I searched on it too for "base64". The first 2 hits are almost identical, apart from that the first one has an english "Topic-Title"and the second one a german header. As my language is german, I opened the second hit, and there the last sentence about the trailing "=" is missing !!

My fault, I should - as i usually do - have read the english documentations.
Thanks für your help and explanations !


Well-Known Member
I actually found my quote in a pdf of the manual floating around the internet since was refusing to show my google hit (possibly due to me not selecting the language first).

Maybe the documentation has since been updated, DocuWare Knowledge Center currently contains:

Außerdem entfernt DocuWare die Trailing ‘=’ Zeichen und fügt je nachdem, wie viele Zeichen entfernt worden sind, eine 0, 1 oder 2 hinzu.