2

私は理解できない問題に遭遇しました。問題の定義は次のとおりです。Db2/Linux環境のBlob列にいくつかのデータがあります。byte []がJDK圧縮を使用して圧縮された後にBlobがDB2に書き込まれました（これを行うコードはLinux環境で実行されています）。このデータの一部を読み取り（JDKを使用して）、Windows環境（開発環境）で解凍されたバイト配列から文字列を作成する簡単なプログラムを作成しようとしています。問題は、Blob（byte []）を解凍した後、解凍されたバイト配列の長さが通常、予想より1〜3バイト長くなることです。私が期待しているのは、オフセットフィールドと長さフィールドもデータベースに保存されているということです。したがって、この場合、解凍されたバイト配列の長さは通常、データベースに格納されている長さよりも長く、ほんの数バイトです。

例：データベースレコードにblobが含まれている、オフセット：0、長さ：260,409blobを解凍した後-

 compressedByte[].length  - 71,212
 decompressedByte[].length   - 260,412
 new String(decompressByte[]).length()  - 260,412
 new String(decompressByte[]).subString(0, 260,409).length() - 260409

他のいくつかの入力レコードの場合、私が見ている違いは、長さが1〜3バイトの間のどこかにあります。

私はこの問題に少し戸惑っていて、この問題を理解するためにさらにデバッグを行うことができるように、誰かがヒントを提案できるかどうか疑問に思っています。これは、Linux環境でのバイトの保存/書き込み方法とWindowsでのバイトの読み取り方法に何らかの形で関係しているのではないかと思います。ご協力いただきありがとうございます。

4

2 に答える 2

3

デフォルトのエンコーディングは2つのシステムで異なると思います。

// on the linux box   
byte [] blob = str.getBytes("UTF-8");

// in your code 
String str = new String(blob, "UTF-8");

または、少なくともLinuxボックスのデフォルトのエンコーディング（通常のUTF-8）を確認し、手順1をスキップします。

ここで何が起こっているのかについての本当に良い例は、ソフトウェアのJoelにあります

于 2011-01-06T15:27:44.727 に答える
2

AStringはバイトの一般的なホルダーではありません。間違いなく、db2 / Linux環境とWindows環境の間でデフォルトの文字エンコードが異なるため、バイトと文字の間の変換が異なります。

于 2011-01-06T15:26:13.433 に答える