問題タブ [crc]

さまざまなアプリケーションレベルのデータのストレージメカニズムとしてGoogleGearsを使用するWebサイトを想像してみてください。このデータは、アプリケーションがアクティブな間、非同期Webサービス呼び出しを使用してサーバーで断続的に複製されます。

問題は、サブスクリプション監視メカニズムにあります。独自のPCに基づくこのサービスのサブスクリプションシステムを想像してみてください。Webサービスは、データを同期しているPC（またはより具体的にはWebブラウザー）をどのように一意に識別しますか？

私の自然な最初のアイデアは、マシンごとにローカルデータベースにGUIDを保存し、リクエストとともに送信することでしたが、Google Gearsのストレージドキュメントを見ると、データベースが暗号化されておらず、簡単に改ざんされる可能性があることがわかります（sqlliteファイルに添付する）必要なのはこれだけで、さまざまなツールを使用して実行できます）。

私が最近考えていたのは、マシンごとに繰り返し可能でありながら、JavaScriptのみを使用して一意である署名を計算する方法があることは確かですか？これまでのところ、これの実装は私にはわかりませんでした（navigator.userAgent.uniqueIDのみが存在する場合、プライバシーにはあまり効果がありませんが）。

最後に考えたのは、この機能を提供するためにActiveXコントロールとFirefoxプラグインを作成することですが、これはお尻に大きな苦痛を与えるでしょう...

任意の洞察をいただければ幸いです。

バイトのブロブが更新されているかどうかを検出できる必要があるシステムを構築しています。BLOB全体（最大5 MB）を保存するのではなく、BLOBが更新されているかどうかを確認するために、そのチェックサムを計算して保存し、少し後で同じチェックサムを計算する必要があると考えています。

目標は、以下を（この順序で）最小化することです。

• チェックサムのサイズ
• 計算する時間
• 衝突の可能性（コンテンツが変更されている場合でも、2つの同一のチェックサムが発生します）。

私たちのシステムの衝突は1/1,000,000以下で許容されます。問題はセキュリティではなく、単に更新/エラー検出であるため、まれな衝突は問題ありません。（これが、最小化するために最後に配置した理由です）。

また、テキストのブロブを自分で変更することはできません。

もちろん、md5またはcrc頭に浮かぶsha1ので、迅速な解決策が必要な場合は、それを選択します。ただし、簡単な解決策ではなく、さまざまな方法と長所と短所を比較できるものを探しています。

Ruby on railsで「入力フィールド値」の32ビットCRC値を計算したいのですが、サンプルコードが必要です、誰か助けてください。

以下のコードを実行しているときにこのエラーが発生します

誰かがこの問題の解決策を持っていますか？

ローカル マシンに保存され、Web サービスを使用して定期的に複製されるデータがあります。このデータは、このプログラムの適用にとって重要であり、ビジネス トランザクションのラインに沿っています。

それでは。

データを Web サービスに送信するときに、ある種の CRC チェックを使用する必要がありますか?それとも、これは TCP プロトコル自体によって十分に処理されますか?

EDIT：サーバーが受信を確認するまでデータがクライアントから削除されないことを明確にするために、Webサービスで強く型付けされたパラメーターを使用しますが、「マングルされた」データについてもっと考えています）。

C＃スクリプトによって提供されるCRC32コードを使用してJavaのファイルを比較する必要があります。java.util.zip.CRC32を使用してCRC32を計算すると、結果は完全に異なります...

私の推測では、C＃スクリプトの多項式= 0x2033は、zip.CRC32で使用されているものと同じではありません。多項式を設定することは可能ですか？または、独自の多項式を定義できるCRC32を計算するためのJavaクラスのアイデアはありますか？

更新：問題は多項式ではありません。これはC＃とJavaの間で同じです

これは私のコードです、多分私がファイルを読む方法に何か問題がありますか？

どうもありがとう、フランク

gzip は、-l および -v オプションを指定すると、次のように各ファイルのチェックサムを提供します。

同じチェックサムを取得できる外部ツールはありますか?

md5sum、同様の役割cksumをsum果たしますが、一致するコードを与えません (3915528286 の 16 進数は e962385e です)。

アプリケーションの詳細:

多くの大きなファイルを含むファイルシステムがあり、新しいファイルが継続的にコピーされます。着信ファイルの一部は既存のファイルと一致します。この場合、ディスク容量を節約するために、既存のファイルを単純にハードリンクしたいと考えています。解凍されたファイルの場合、md5sum はこの比較を迅速かつ効率的に行うのに役立ちます。一方、gzip されたファイルは、同じデータに対して異なる md5sum を持つことがよくあります (タイムスタンプまたは所有者が原因で、このアプリケーションでは関係ありません)。gzip は内部データのチェックサムを提供するので、2 つの gzip ファイルについて、チェックサムとサイズのリストを単純に比較できます。

また、gzip ファイルと「通常の」ファイルの比較もサポートしたいと考えています。その場合、gzip から外部で同じチェックサムを生成するユーティリティが必要です。簡単な解決策は、比較する前に常にプレーン ファイルを gzip することだと思いますが、これは回避したいオーバーヘッドです。現在、システムは CPU 時間によってボトルネックになっているからです。

MotorolaHCS08マイクロコントローラーアプリケーションにCRC16エラー検出を追加しようとしています。ただし、私のチェックサムは一致しません。1つのオンラインCRC計算機は、PCプログラムで表示される結果とマイクロで表示される結果の両方を提供します。

マイクロの結果を「XModem」、PCの結果を「カーミット」と呼びます。

これらの2つの古いプロトコルがCRC16の使用を指定する方法の違いは何ですか？

圧縮されたbzip2アーカイブのCRC32チェックサムを計算/検証しようとしています。

http://en.wikipedia.org/wiki/Bzip2

したがって、CRCチェックサムがbz2ファイルのどこにあるかはわかっていますが、それらを検証するにはどうすればよいでしょうか。binascii.crc32()両方のCRCを取得するには、どのチャンクが必要ですか？さまざまなチャンクのCRCをバイトごとに計算しようとしましたが、一致するものを取得できませんでした。

ありがとうございました。特にメソッドで何かを見つけるために、bzip2ソースとbz2Pythonライブラリコードを調べます。decompress()

アップデート1：

私が見る限り、ブロックヘッダーは次のタグで識別されます。ただし、小さなbz2ファイルにはENDMARKファイルが含まれていません。（adwのおかげで、圧縮データはバイトに埋め込まれていないため、ENDMARKのビットシフト値を探す必要があることがわかりました。）

これはbzlib2recover.cソースからのものであり、ブロックは常にCRCチェックサムの直前のビット80で開始するようです。これは、CRC計算から除外する必要があります。これは、自身のCRCを同じCRCにすることはできないためです（私のポイントを取得します） 。

これを計算するコードを調べます。

アップデート2：

bzlib2recover.cCRC計算機能はなく、破損したファイルからCRCをコピーするだけです。ただし、Pythonでブロック計算機能を複製して、bz2圧縮ファイル内の各ブロックの開始ビットと終了ビットをマークアウトすることができました。compress.c軌道に戻ると、それはの定義のいくつかを参照していることがわかりましたbzlib_private.h。

これらの定義はによってもアクセスさbzlib.cれ、s->blockCRCで初期化および更新されbzlib.c、でファイナライズされcompress.cます。2000行を超えるCコードがあり、何が入っているのか、何が入っていないのかを調べて理解するのに時間がかかります。C質問にもタグを追加しています。

ちなみに、bzip2のCソースは次のとおりですhttp://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz

アップデート3：

ブロックCRC32bzlib2は、次のアルゴリズムを使用して計算されていることがわかります。

dataInエンコードするデータです。

BZ2_crc32Tableが定義されている場所crctable.c

dataIn = "justatest"返されるCRCは、その7948C8CBデータでテキストファイルを圧縮しているため、bz2ファイル内のcrc：32チェックサム79 48 c8 cbは一致します。

結論：

bzlib2 CRC32は（引用符crctable.c）

comp.compression FAQのセクション51にある、RobWarnockによるコードから漠然と派生しています...

...したがって、私が理解している限り、標準のCRC32チェックサム計算機を使用して事前計算/検証することはできませんが、bz2lib実装が必要です（の155〜172行目bzlib_private.h）。

時々、ftp を介して (特に大きな) ファイルをダウンロードすると、エラーが発生します。それが、すべての主要なサイトがダウンロードとともに外部チェックサムを公開している理由の一部でもあると思います。

ftp が TCP を通過する場合、これはどのように可能でしょうか? TCP にはチェックサムが組み込まれており、データが破損して送信された場合にデータが再送信されます。

これは、TCP プロトコルの CRC の長さが短い (私が思うに 16 ビットか、またはそのようなもの) ためであり、衝突が頻繁に発生しているためであると主張することができます。しかし、1) これが真であるためには、CRC の衝突が存在する必要があるだけでなく、ランダムなネットワーク エラーによって、パケット内の CRC とパケット自体の両方が変更され、CRC が新しいパケットに対して有効になる必要があります。 . 16 bitCRC でも、そんな可能性はありますか? 2) たとえば、TCPIP も経由する Web のブラウジングでは、多くのエラーがないように見えます。