After encoding the non-padded data, if two octets of the 24-bit buffer are padded-zeros, two “=” characters are appended to the output; if one octet of the 24-bit buffer is filled with padded-zeros, one “=” character is appended. This signals the decoder that the zero bits added due to padding should be excluded from the reconstructed data. This also guarantees that the encoded output length is a multiple of 4 bytes.
As the code exists, the encoder returns an error and stops encoding if the first symbol is = and it is also the first character, which is correct, as this should not happen. However, if the an = or symbol appears at the end of a base 64 string, it just means that the data that was encoded had to be 0 padded, but the encoder treats this as an end-of-string event and halts the decoding algorithm.
It is possible to append multiple base64 strings together. For example, I have unit data that I want to save in a class:
If I have a vector of n units each with a UnitDataToSave class, it is possible to:
1.) loop through the vector and encode each element into base64
2.) just append the strings together into one long base64 string.
3.) Upon decoding, prepare a buffer for UnitDataToSave which is n elements long (new UnitDataToSave[n]).
4.) The base64 encoder will, the the edits above, properly decode the appended string and put the data properly back in the buffer, so each element can be accessed
The problem with the original code was that one of the UnitDataToSave might have been encoded with an = or an in step 1 which would halt the decoder in step 4. The solution is to treat the = and == as a valid character, preform the bit shifting and padding, but simply reset the char_count to 0 so that the decoder can continue along.
Could the base64 decoder also be exported from the Cocos2-x library? This technique is incredibly useful for writing binary data to disk on ANY platform in XML format.
Thanks for taking the time to work with me on this issue,