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