0

バイト配列をデータベースに保存する前に、その出力を出力するnew String(data)と「foobar」のような読み取り可能な文字列が返されますが、データベースから引き出した後は、new String(data)「9238929384739427349327...」のようなぎこちない文字列のように読み取られます。ここには非常に多くの部分があり、それらすべてをリストアップしようと思います。eclipselinkを使用していて、データ列が定義されています。

@Lob
@Column(name = "data")
private byte[] data;

このコードを実行すると：

public static void main(String[] args) {
    System.out.println(Charset.defaultCharset());
}

を出力しますwindows-1250。

私のデータベースは次のように定義されています：

CREATE DATABASE project_trunk
  WITH OWNER = project
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'English_United States.1252'
       LC_CTYPE = 'English_United States.1252'
       CONNECTION LIMIT = -1;

私はまた、このように定義されたDBでこれを試しました：

CREATE DATABASE project_trunk
  WITH OWNER = project
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'en_US.UTF-8'
       LC_CTYPE = 'en_US.UTF-8'
       CONNECTION LIMIT = -1;

そして、問題はまだ発生します。

何が起こっているのかというと、私のデータベースは私のappserverとは異なるエンコーディングを持っていると思います。データベースに入れて再度引き出すと、間違った方法でデコードされるため、ぎこちないように見えます。私はそこに何かをしていますか？

今、この問題の解決策になると、私は少し混乱しています。私がすべきことは、appserverのファイルエンコーディングをデータベースと同じになるように変更することだと思います。Glassfish2.1.1を使用しています。ロケールに移動application server -> advanced -> domain attributesして「UTF8」または「UTF-8」に設定すると、再起動が必要であると表示されます。Glassfishを再起動した後も、そのフィールドは空白のままで、エラーが発生します。多分それは財産を保存していないと思います。手動で構成ファイルに入れましたが、どこに何を入れるかわかりません。

または、ENCODING ='WIN1250'を使用してデータベースを作成しようとしましたが、作成すると、LC_CTYPEが「WIN1252」である必要があると表示されます。LC_CTYPEを「WIN1252」に設定すると、エンコーディングが存在しないと表示されます。

私はこれに多くの時間を費やしています、私はここで何かに取り組んでいるかどうか知りたいです。「appserverとdbの間の非同期エンコーディング」の私の理論は正しいように聞こえますか、それとも私は赤いニシンを追いかけていますか？誰かが私がglassfish2.1.1のこの設定を変更する方法を理解するのを手伝ってくれるなら、それも非常に役に立ちます。ありがとう

編集：人々は私が文字列を生のバイトとして保存している理由を尋ねています。それは私がしていることではありません。生のバイトが画像、PDF、またはバイナリを表す場合もあれば、テキストを表す場合もあります。私のテストでは、プレーンテキストの文字列を挿入して引き出し、正しく保存されていることを確認しています。このテストは、Linux上にあるCIサーバーで合格します。

EDIT2：生のバイナリ入力と生のバイナリ出力を表示するように求められました。

予想：[116、104、105、115、32、105、115、32、109、121、32、97、116、116、97、99、104、109、101、110、116、32、97、115 、32、97、32、83、116、114、105、110、103]

実際：[60、54、56、54、57、55、51、50、48、54、57、55、51、50、48、54、100、55、57、50、48、54、49、55 、52、55、52、54、49、54、51、54、56、54、100、54、53、54、101、55、52、50、48、54、49、55、51、50、48 、54、49、50、48、53、51、55、52、55、50、54、57、54、101、54、55]

私は、Macを使用している同僚にバイトをチェックする同じテストを行い、彼に合格しました。

4

2 に答える 2

2

生のバイトが画像、PDF、またはバイナリを表す場合もあれば、テキストを表す場合もあります

さて、あなたはそれらをテキストとして保存するべきではありません。

現在何が問題になっているのかに関わらず、実際にはテキストであるデータに対してこれを機能させることができたとしても、後で問題が発生します。

任意のバイナリデータをテキストとして保存する必要がある場合は、base64を使用してエンコードする必要があります。そうすれば、問題なく元のバイナリに戻ることができます。（ASCII文字列を転送できるようになるだけで、通常はかなり簡単です。）Base64用のサードパーティライブラリはたくさんあります。私はこの自己完結型のパブリックドメインが好きです。

または、データ型のフィールドを使用するなどして、データをバイナリデータとしてデータベースに保存します。byteaそうすれば、変換作業を行う必要はありません。バイト配列としてデータベースに入れ、バイト配列として取り出すことができるはずです。

編集：さて、あなたはバイナリデータの16進表現を取り戻しているように見えますが、ASCIIです。それは明らかに奇妙です。

于 2013-02-12T19:34:17.860 に答える
0

これは、PostgreSQLがバージョン9とバージョン8で機能する方法が原因であることがわかりました。同僚のほとんどはバージョン8を使用していましたが、最近新しいコンピューターを入手したため、最新のPostgreSQLを使用しました。

output_byteaを「escape」に設定する必要があります。

jpaを使用してpostgresからbyte[]を読み取るときに長さがほぼ2倍になる

答えは十分ではありませんでしたが、メーリングリストで見つけたので、問題が修正されました： http ://www.postgresql.org/message-id/AANLkTikkE-jQ9srZ9VL1JuJ5h=UCutx8ZLim+OfQ1T4z@mail.gmail .com

親愛なるリスト、

9.0でのbytea_output形式のエスケープからhexへの最近の変更は、dbテーブルのbytea列にピクルスされたデータ構造を格納するApache :: Session::Postgresのような一般的な永続セッション処理perlモジュールを明らかに壊します。上記のモジュールによってスローされた例外から根本的な原因を推測することは困難です。この問題は、postgresql.confにbytea_output ='escape'を追加し、pg_ctlreloadを発行することで修正されています。

たとえば、RTアプリケーションでは、エラーは次のとおりです。エラー：RTはセッションを保存できませんでした。これは、ディレクトリ/ blah / blah / foo / barが書き込み可能でないか、データベーステーブルが見つからないか破損していることを意味している可能性があります

Regds RajeshKumarMallah。

于 2013-02-13T00:24:36.840 に答える