jpegファイルでの配布
メタ情報と jpeg ヘッダー データを無視すると、jpeg のペイロードは、ハフマン テーブルまたはエンコードされた MCU (Minimum-Coded-Units、サイズ 16x16 の正方形のブロック) を記述するブロックで構成されます。他にもあるかもしれませんが、これは最も頻繁なものです。
これらのブロックは で区切られています。0xFF 0xSS
ここ0xSS
で、 は特定の開始コードです。これが最初の問題です。コメントでtwalbergが言及したように、0xFF
もう少し頻繁です。
0xFF
エンコードされた MCUで発生する可能性があります。この通常のペイロードと新しいブロックの開始を区別するために、0xFF 0x00
が挿入されます。スタッフィングされていないペイロードの分布が完全に均一である0x00
場合、スタッフィングされたデータでは 2 倍の頻度になります。さらに悪いことに、すべての MCU はバイトアライメント (より大きな値へのわずかな偏り) を得るためにバイナリ 1 で満たされ、再度スタッフィングが必要になる場合があります。
私が気づいていない他の要因もあるかもしれません。さらに詳しい情報が必要な場合は、jpeg ファイルを提供する必要があります。
そして、あなたの基本的な仮定について:
rand_data の場合:
dd if=/dev/urandom of=rand_data count=4096 bs=256
rand_pseudo (python) の場合:
s = "".join(chr(i) for i in range(256))
with file("rand_pseudo", "wb") as f:
for i in range(4096):
f.write(s)
どちらもバイト値に関しては統一されているはずですよね? ;)
$ ll rand_*
-rw-r--r-- 1 apuch apuch 1048576 2012-12-04 20:11 rand_data
-rw-r--r-- 1 apuch apuch 1048967 2012-12-04 20:13 rand_data.tar.gz
-rw-r--r-- 1 apuch apuch 1048576 2012-12-04 20:14 rand_pseudo
-rw-r--r-- 1 apuch apuch 4538 2012-12-04 20:15 rand_pseudo.tar.gz
均一な分布はエントロピーが高いことを示している可能性がありますが、それを保証するものではありません。また、rand_data は 1MB から構成される場合があり0x00
ます。その可能性は非常に低いですが、可能です。