Как java.lang.float может быть закодирован как TH3IFMw? - PullRequest
4 голосов
/ 23 августа 2011

Мне нужно проанализировать некоторые данные, которые имеют закодированные примитивные типы (целые числа, числа с плавающей запятой, числа с плавающей запятой), выведенные с помощью Java.Я добавляю эту функциональность к существующему набору сценариев Python, поэтому переписать ее на Java на самом деле не вариант.Я хотел бы повторно реализовать и / или использовать библиотеку python для декодирования данных (например, TH3IFMw для числа с плавающей запятой).

Я не распознаю эту кодировку.Я работаю с запросами, отправленными в Google Web Toolkit и основанными на источнике здесь и здесь - я думал, что это строка. Значение - но это неверно.Кто-нибудь это признает?

1 Ответ

1 голос
/ 26 августа 2011

Я думаю, что это кодирование long int, а не float.В частности, это, вероятно, 0x0000004c7dc814cc, но может быть 0x00000131f7205330.


Мои рассуждения ...

Просматривая код, на который вы ссылаетесь, не похоже, что что-то отдаленно необычное делается для поплавков, и стандарт *Реализация 1008 * определенно не делает ничего подобного.

С другой стороны, строка TH3IFMw выглядит для всего мира как строка в кодировке base64.Я не могу думать о многих других распространенных кодировках, которые используют верхнюю альфу, нижнюю альфу и цифры.Просматривая тот же код, я могу найти только одну ссылку на base64 ... строку 575 StreamWriter , где он обрабатывает long экземпляры кодирования.Это единственная часть связанного кода, которая, кажется, даже удаленно способна генерировать наблюдаемый вами вывод.

Если посмотреть на размер строки ... предполагая, что равен base64, он отсутствуетзавершающий = символ заполнения / выравнивания, но некоторые реализации base64 для краткости опускают их.Если добавить обратно (TH3IFMw=) и декодировать как base64, то получится шестнадцатеричное значение 0x4c7dc814cc.Это всего 5 байт, что немного странно.Но это означает, что это, вероятно, не float (4 байта) или double (8 байтов).

Но это может соответствовать кодированию строки 575 для long ... Если посмотреть документацию для Base64Utils.toBase64 , он ссылается на тот факт, что "Ведущие группы всех нулевых битовопущено «.Это объяснило бы 5-байтовое значение, если исходный длинный был 0x0000004c7dc814cc.

Однако формулировка документации крайне неоднозначна (и сейчас у меня нет java + gwt для тестирования).«ведущие группы всех нулевых битов» могут означать, что они пропускают исходных байтов , которые являются всеми нулями, но это также может означать, что они пропускают ведущие A символы из кодированных символов base64 (A представляет 6 0 битов в base64).Если это так, то фактическая строка base64 равна ATH3IFMw, которая декодируется в длинное значение 0x00000131f7205330.

Если вы можете найти любое из этих чисел в том, что вы предоставляете в качестве ввода, то этовероятно, что происходит.Если нет ... боюсь, я в тупике.

...