Azure search indexer base64encode function

Viewed 115

I have a question regarding azure64encode function in the indexer. When I try to encode via Java I got different encoding rather than in azure indexer:

In azure

        {
            sourceString= "00cbc05fc051e634d7d485c7879fe7bdb4f6509a"  
            base64EncodedString= "MDBjYmMwNWZjMDUxZTYzNGQ3ZDQ4NWM3ODc5ZmU3YmRiNGY2NTA5YQ2",
        }

In Java

       {
            sourceString= "00cbc05fc051e634d7d485c7879fe7bdb4f6509a"  
            base64EncodedString= "MDBjYmMwNWZjMDUxZTYzNGQ3ZDQ4NWM3ODc5ZmU3YmRiNGY2NTA5YQ==",
        }

Why in azure at the end "2" in java "=="???

Both are decoded to the same string.

1 Answers

The "2" at the end from indexer field mappings represents there are 2 equal signs in "==".

Standard base64 encoding uses equal signs as padding characters at the end of a string to make the length a multiple of 4, but they're not necessary to decode the original string.

Since standard encoding uses characters that are meaningful in URL query strings and sometimes the encoded strings will be passed through the URL, so there are versions that swap out/omit characters to make the encoding URL-safe.

The indexer has 2 implementations of base64Encode and defaults to using HttpServerUtility.UrlTokenEncode, which replaces all equal signs at the end of encoded strings with the count of those equal signs. The other implementation simply omits the equal signs, and you can choose between the two behaviors by setting useHttpServerUtilityUrlTokenEncode (defaults to true but you probably want false).

You can encode the string 00>00?00 in the indexer/Java to see exactly which behavior you're getting, and check this table to see how to convert between them.

N.B. - using standard base64 decoding with HttpServerUtility.UrlTokenEncode is very misleading and should be avoided. Try encoding and decoding a, aa, aaa, sometimes you get the original string back and sometimes you don't.

Related