Java によって出力されたプリミティブ型 (int、float、double、float) をエンコードしたデータを解析する必要があります。この機能を既存の一連の Python スクリプトに追加しているので、Java で書き直すことは実際にはオプションではありません。Python ライブラリを再実装および/または使用してデータをデコードしたいと思います (例: float の場合は TH3IFMw)。
このエンコーディングを認識できません。Google Web Toolkit に送信されたリクエストを処理しています。ソースhereおよびhereに基づいています- string.ValueOf だと思っていましたが、これは正しくありません。誰かがそれを認識していますか？
これは float ではなく long int をエンコードしていると思います。特に、それはおそらく0x0000004c7dc814ccですが、そうかもしれません0x00000131f7205330。
私の推理...
リンク先のコードを調べると、float に対してリモートで通常とは異なることが行われているようには見えませvalueOfん。標準の実装では、このようなことはまったくありません。
一方、文字列TH3IFMwは base64 でエンコードされた文字列のように全世界を検索します。上位アルファ、下位アルファ、および数字を使用する一般的なエンコーディングは、他にあまり思いつきません。同じコードを調べると、base64 への参照が 1 つしか見つかりません... StreamWriter の 575 行目で、エンコーディングlongインスタンスを処理します。これは、リンクされたコードの唯一の部分であり、観察した出力をリモートでも生成できるようです。
文字列のサイズを見ると...それがbase64であると仮定すると、末尾の=パディング/アライメント文字が欠落していますが、base64の一部の実装では簡潔にするためにこれらを省略しています. それを追加して ( TH3IFMw=)、base64 としてデコードすると、16 進値になります0x4c7dc814cc。これはわずか 5 バイトのサイズで、少し奇妙です。ただし、これはおそらく float (4 バイト) または double (8 バイト) ではないことを意味します。
しかし、これは行 575 の long のエンコーディングに適合する可能性があります... Base64Utils.toBase64 のドキュメントを見ると、 「すべてのゼロビットの先頭グループが省略されている」という事実に言及しています。元の long が0x0000004c7dc814cc.
しかし、ドキュメンテーションの文言はイライラするほどあいまいです (そして、私は現在、テストするための java+gwt を持っていません)。「すべてゼロビットの先頭グループ」は、すべてゼロであるソースバイトを省略していることを意味する可能性がありますが、エンコードされたbase64文字Aから先頭文字を省略していることを意味する場合もあります( base64で6ビットを表します)。その場合、実際の base64 文字列はであり、長い値にデコードされます。A0ATH3IFMw0x00000131f7205330
あなたが入力として提供しているものにこれらの数字のいずれかが見つかれば、それはおそらく起こっていることです. そうでなければ... 私は困惑しています。