我需要解析一些由 java 输出的编码原始类型（整数、浮点数、双精度数、浮点数）的数据。我正在将此功能添加到现有的一组 python 脚本中，因此用 Java 重写它并不是一个真正的选择。我想重新实现和/或使用 python 库来解码数据（例如 TH3IFMw 用于浮点数）。
我不认识这种编码。我正在处理发送到 Google Web Toolkit 的请求，并且基于此处和此处的源- 我认为它是 string.ValueOf - 但这是不正确的。有人认得吗？
问问题
244 次
1 回答
1
我认为这是编码一个长整数，而不是浮点数。特别是，它可能是0x0000004c7dc814cc，但可能是0x00000131f7205330。
我的推理...
查看您链接到的代码，看起来并没有对浮点数进行任何不寻常的操作，标准valueOf实现肯定不会这样做。
另一方面，该字符串TH3IFMw会像 base64 编码的字符串一样查找整个世界。我想不出许多其他使用大写字母、小写字母和数字的常见编码。查看相同的代码，我只能找到一个对 base64 的引用... StreamWriter 的第 575 行，它处理编码long实例。这是链接代码的唯一部分，它似乎甚至能够远程生成您观察到的输出。
查看字符串的大小......假设它是base64，它缺少一个尾随=填充/对齐字符，但是base64的一些实现为了简洁而省略了这些。将其加回 ( TH3IFMw=) 并解码为 base64，这将产生十六进制值0x4c7dc814cc。这只有 5 个字节大小，有点奇怪。但这确实意味着它可能不是浮点数（4 个字节）或双精度数（8 个字节）。
但这可能适合第 575 行的长编码...查看Base64Utils.toBase64的文档，它提到了“省略了所有零位的前导组”这一事实。如果原始 long 是 ，这将解释 5 字节值0x0000004c7dc814cc。
但是，文档的措辞令人沮丧地模棱两可（而且我现在没有可用的 java+gwt 来测试）。“全零位的前导组”可能意味着它们省略了全为零的源字节，但也可能意味着它们A从编码的 base64 字符中省略了前导字符（A表示 base64 中的 60位）。如果是这种情况，那么实际的 base64 字符串是ATH3IFMw，它会解码为 long 值0x00000131f7205330。
如果您可以在作为输入提供的内容中找到这些数字中的任何一个，那么这可能就是正在发生的事情。如果不是……恐怕我很难过。
于 2011-08-26T17:19:15.003 回答