同僚からtarアーカイブを受け取り、解凍した後、いくつかのテキストファイルが破損していることがわかりました。より正確にはゼロで埋められます。サイズは正確ですが、すべてのバイトは0x00に等しくなります。
このような状況は、tarバージョンの一部の非互換性のためですか？ファイルに中国語の文字が含まれているか、圧縮中にファイルが破損していますか？コントロールチェックサムが良好なため、転送中の問題は予想されません。
答え1
確かなみんなバイトは0x00？この場合、ファイルにはサイズ以外の情報は含まれません。どのプログラムも情報をすべてゼロとして保存または転送できません（テレパシー以外の場合）。
何できるファイルにテキストとゼロバイトが交互に含まれる場合が発生します。意味：UTF-16（または同様の値）でエンコードされたUnicodeテキストを含むファイルを受け取りました。各文字は16ビット（2バイト）を占めます。 Unicodeは、ASCII文字コードに英語の文字と記号を割り当てます。つまり、たとえば、文字はAASCIIでは16進数41、Unicodeでは00 41です。その結果、「Hello」をUTF-16として作成し、それを8ビットテキストとして読み取ると、次のようになります。
\0 H \0 e \0 l \0 l \0 o
もしそうなら、それはあなたのせいではありませんtar。ただし、チェックサムチェックですべてゼロのファイルを受け取った場合、作成者に問題があることは明らかです。バージョンの問題ではありませんが、誰が知っていますか？ジェネレータがすべてゼロを読み取るハードウェアの問題がある可能性があります。
（もちろんファイルが正しくアーカイブされ、プログラムにバグが存在する場合もあります。作られたアーカイブファイル）。
答え2
最も可能性の高い問題は、tarが作成されたときに破損したことです。 tar形式が定義された方法で（ストリーミングアーカイバとして使用されるため）、ファイルの長さを事前に決定する必要があります。この長さをtarヘッダーに書き込んでから、ファイルの内容をtarファイルに書き込み始めます。何らかの理由でファイルの読み込み中にエラーが発生したりアーカイブしたりすると、ファイルが折りたたまれた場合はNULLが埋められます。これは、抽出時にヘッダーで指定された長さをまだ有効にするために必要です。 （ストリーミング属性のため、ヘッダーを再変更できず、ファイルにNULLを埋めないとエラーが発生します。）アーカイブ内の次のファイル）。
また、tarはバイナリデータを処理するので（「テキスト」モードはありません）、他の言語エンコーディングに問題はないはずです（tarに関する限り）。