java - 如何将 java.lang.float 编码为 TH3IFMw？

Question

我需要解析一些由 java 输出的编码原始类型(整数、 float 、 double 、 float )的数据。我正在将此功能添加到现有的一组 python 脚本中，因此用 Java 重写它并不是一个真正的选择。我想重新实现和/或使用 python 库来解码数据(例如 TH3IFMw 用于 float )。

我不认识这种编码。我正在处理发送到 Google Web Toolkit 的请求，并基于来源 here和 here - 我认为它是 string.ValueOf - 但这是不正确的。有人认识吗？

Answer 1

我认为这是对 long int 进行编码，而不是 float。特别是，它可能是 0x0000004c7dc814cc，但也可能是 0x00000131f7205330。

---

我的推理......

查看您链接到的代码，看起来并没有对 float 做任何异常的事情，标准的 valueOf 实现肯定不会像这样。

另一方面，字符串 TH3IFMw 像 base64 编码的字符串一样在整个世界中查找。我想不出许多其他使用大写字母、小写字母和数字的常见编码。查看相同的代码，我只能找到一个对 base64 的引用... line 575 of StreamWriter ，它处理编码 long 实例。这是链接代码中唯一似乎能够生成您观察到的输出的部分。

查看字符串的大小...假设它是 base64，它缺少尾随 = 填充/对齐字符，但 base64 的某些实现确实省略了这些为简洁起见。将其加回去 (TH3IFMw=)，并解码为 base64，这会产生十六进制值 0x4c7dc814cc。这只有 5 个字节，有点奇怪。但这确实意味着它可能不是 float (4 字节)或 double (8 字节)。

但这可能符合第 575 行的长编码...查看 Base64Utils.toBase64 的文档，它提到了“省略所有零位的前导组”这一事实。如果原始 long 为 0x0000004c7dc814cc，这将解释 5 字节值。

但是，该文档的措辞令人沮丧地模棱两可(而且我现在没有 java+gwt 可供我测试)。 “全零位的前导组”可能意味着他们省略了全为零的源字节，但也可能意味着他们省略了中的前导A字符>编码的 base64 字符(A 表示 base64 中的 6 个 0 位)。如果是这种情况，那么实际的 base64 字符串是 ATH3IFMw，它解码为长值 0x00000131f7205330。

如果您可以在作为输入提供的内容中找到这些数字中的任何一个，那么这可能就是正在发生的事情。如果不是...恐怕我很难过。