0

POF (Plain Old Files ;)) の形式でアプリケーション インスタンス間でデータを渡すためのバイナリ形式を考え出します。

前提条件:

  1. クロスプラットフォームであるべき
  2. 永続化される情報には、単一の POJO と任意のバイト [] が含まれます (実際にはファイル、POJO はその名前を String[] に格納します)
  3. 順次アクセスのみが必要です
  4. データの一貫性をチェックする方法であるべき
  5. 小さくて速くなければならない
  6. アーカイバーとメモ帳を使用する平均的なユーザーがデータを変更できないようにする必要があります

現在、私は DeflaterOutputStream + OutputStreamWriter を InflaterInputStream + InputStreamReader と共に使用して、XStream でシリアル化されたオブジェクトをファイルごとに 1 つのオブジェクトで保存/復元しています。リーダー/ライターは UTF8 を使用します。ここで、前述の機能をサポートするためにこれを拡張する必要があります。私のフォーマットの考え：

{serialized to XML object}
{delimiter}
{String file name}{delimiter}{byte[] file data}
{delimiter}
{another String file name}{delimiter}{another byte[] file data}
...
{delimiter}
{delimiter}
{MD5 hash for the entire file}
  1. これは正気に見えますか？
  2. 区切り文字には何を使用し、どのように決定しますか?
  3. この場合、MD5 を計算する正しい方法は?
  4. このテーマについて何を読むことをお勧めしますか?

ティア。

4

8 に答える 8

3

それは非常識に見えます。

  • なぜ新しいファイル形式を発明したのですか?
  • 愚かなユーザーだけがファイルを変更するのを防ごうとするのはなぜですか?
  • なぜバイナリ形式を使用するのですか (圧縮が難しい)?
  • 受信中に解析できない形式を使用するのはなぜですか? (受信者は、ファイルを処理する前にファイル全体を受信する必要があります。)
  • XML はすでに圧縮可能なシリアル化形式です。したがって、シリアル化された形式をシリアル化しています。
于 2009-02-21T08:20:52.373 に答える
2

これはかなり簡単なはずです。

前提条件：

0.クロスプラットフォームである必要があります

1.永続化される情報には、単一のPOJOと任意のbyte []が含まれます（実際のファイルでは、POJOはその名前をString []に格納します）

2.シーケンシャルアクセスのみが必要です

3.データの整合性をチェックする方法である必要があります

4.小さくて速い必要があります

5.アーカイバとメモ帳を使用する平均的なユーザーがデータを変更できないようにする必要があります

よく推測してください、あなたはすでにそれを持っています、それはすでにプラットフォームに組み込まれています：オブジェクトのシリアル化

有線で送信されるデータの量を減らし、カスタムシリアル化を提供する必要がある場合（たとえば、属性名などを使用せずに、特定のオブジェクトに対して1、2、3のみを送信し、同じ順序でそれらを読み取ることができます） 、）なんとなくこれが使える「隠し機能」

「テキストプレーン」で本当に必要な場合は、エンコードすることもできます。これには、ほぼ同じ量のバイトが必要です。

たとえば、このBean：

import java.io.*;
public class SimpleBean implements Serializable  { 
    private String website = "http://stackoverflow.com";
    public String toString() { 
        return website;
    }
}

このように表すことができます：

rO0ABXNyAApTaW1wbGVCZWFuPB4W2ZRCqRICAAFMAAd3ZWJzaXRldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0ABhodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20=

この答えを見る

さらに、適切なプロトコルが必要な場合は、Googleの内部交換形式であるProtobufを確認することもできます。

于 2009-02-21T10:05:59.827 に答える
2

1）これは正気に見えますか？

それはかなり正気に見えます。ただし、 Javaシリアル化を使用するだけでなく、独自の形式を発明する場合は、正当な理由があります。何か正当な理由がありますか（場合によっては存在します）？XStreamを使用する標準的な理由の1つは、結果を人間が読める形式にすることです。これは、バイナリ形式ではすぐに失われます。人間が読める形式ではなく、バイナリ形式を使用する正当な理由がありますか？人間が読める形式が良い（そして悪い）理由については、この質問を参照してください。

署名された瓶にすべてを入れるだけの方が簡単ではないでしょうか。これを行うための標準のJavaライブラリとツールがすでにあり、圧縮と検証が提供されます。

2）区切り文字には何を使用し、どのように決定しますか？

区切り文字ではなく、ブロックの前の各ブロックの長さを明示的に格納します。それは同じように簡単で、それがそれ自体で出てきた場合に区切り文字をエスケープする必要がなくなります。

3）この場合のMD5を計算する正しい方法は？

賢明に見えるサンプルコードがここにあります。

4）このテーマについて何を読むことをお勧めしますか？

シリアル化については？Javaのシリアル化、 JSON 、XStreamのシリアル化について読んだので、それぞれの長所と短所、特に人間が読めるファイルの利点を理解しました。また、たとえばMicrosoftの従来のファイル形式を調べて、すべてのバイトが重要だった時代から考えられる設計上の決定と、それらがどのように拡張されたかを理解します。例：WAVファイル形式。

于 2009-02-20T08:03:50.673 に答える
2

モデルのシリアル化 (MVC を使用している場合) は別の方法ではないでしょうか? 可能であれば、自分で作成するよりも、言語 (または標準ライブラリ) で使用することを好みます。私が見ることができる唯一の問題は、ファイルサイズが必要以上に大きくなる可能性があることです.

于 2009-02-19T22:30:58.833 に答える
1

新しい形式やバイナリ形式が必要なようには思えないという点で、私は同意します。本当にバイナリ形式が必要な場合は、最初に次のいずれかを検討してください。

  • バイナリ XML (高速情報セット、Bnux)
  • ヘシアン
  • Google パケット バッファ

しかし、それ以外にも、多くのテキスト形式は問題なく (またはおそらくより良く) 機能するはずです。デバッグが容易で、広範なツールがサポートされ、バイナリとほぼ同じサイズに圧縮されます (バイナリ圧縮は不十分であり、情報理論は、同じ効果的な情報に対して同じ圧縮率が達成されることを示唆しています。これは私のテストでは真実でした)。

したがって、おそらく次のことも考慮してください。

  • Jsonはうまく機能します。base64 によるバイナリ サポート (たとえば、http://jackson.codehaus.org/を使用)
  • XML も悪くありません。効率的なストリーミング パーサー。base64 をサポートするものもあります ( http://woodstox.codehaus.org/、「org.codehaus.stax2.typed.TypedXMLStreamReader」の下の「型付きアクセス API」)。

ですから、自分で何かを作りたいだけのように聞こえます。趣味としては悪いことではありませんが、趣味として考える必要があります。構築しているシステムの要件ではない可能性があります。

于 2009-02-24T20:33:15.333 に答える
1

zip (rar / 7z / tar.gz / ...) ライブラリを使用できます。多くのものが存在し、ほとんどは十分にテストされており、おそらく時間を節約できます。

あまり面白くないかもしれませんが。

于 2009-02-19T22:36:12.143 に答える
0

おそらく、これが JAR などの既存のファイル形式を使用するよりも優れていることを説明できます。

このタイプのほとんどの標準ファイル形式は、計算が高速な CRC を使用しています。意図的な変更を防ぎたい場合は、MD5 が適しています。

于 2009-02-20T21:02:39.100 に答える