How can java.lang.float be encoded as TH3IFMw?

Question

I need to analyze some data that encoded primitive types (ints, float, doubleles, floats) output by java. I am adding this functionality to an existing python scripting suite, so rewriting it in Java is not really an option. I would like to reimplement and / or use the python library to decode the data (e.g. TH3IFMw for float).

I do not understand this encoding. I work with requests sent to the Google Web Toolkit, and based on the source here and here - I thought it was a string. ValueOf - but this is not true. Does anyone know this?

Answer 1

I think this is encoding a long int, not a float. In particular, it is probably 0x0000004c7dc814cc , but could be 0x00000131f7205330 .

---

My reasoning ...

Looking through the code you are attached to, it doesn't look like everything removed from the usual is done for swimming, and the standard implementation of valueOf definitely does nothing of the sort.

The TH3IFMw string, on the other hand, searches the whole world as a base64 encoded string. I can’t come up with many other common encodings that use upper alpha, lower alpha and numbers. Looking through the same code, I can find only one reference to base64 ... line 575 of StreamWriter , where it processes instances of the encoding long is the only part of the linked code that seems even remotely able to generate the result that you observed.

Looking at the size of the string ... assuming it's base64, there is no numbered character = padding / alignment, but some base64 implementations omit them for brevity. Adding this back ( TH3IFMw= ) and decoding as base64 will result in the hexadecimal value 0x4c7dc814cc . It is only 5 bytes, which is a bit strange. But this means that it is probably not a float (4 bytes) or double (8 bytes).

But it can fit with an encoding length of 575 long ... looking at the documentation for Base64Utils.toBase64 , it refers to the fact that "Leading groups of all zero bits are omitted." This explains the value of 5 bytes if the original long was 0x0000004c7dc814cc .

However, the wording of the documentation is disappointing ambiguous (and I don't have java + gwt available to me now to test). “leading groups of all zero bits” may mean that they skip the original bytes, which are all zeros, but it can also mean that they skip the leading characters of A from the encoded base64 characters ( A represents 6 0 bits in base64). If so, then the actual base64 string is ATH3IFMw , which decodes the long value 0x00000131f7205330 .

If you can find any of these numbers in what you provide as input, then this is probably what happens. If not ... I'm afraid I'm at a standstill.