非テキスト形式のファイルで改行記号の並びはどうですか？

Question

これまでのところ、IBM 8086アーキテクチャーを組み立てて練習していましたが、2行のファイルを交換するプログラムを作成する作業を受けました。 （私は、データファイル名とその2行のうちのnoをパラメータで与える）。私のプログラムのアルゴリズムは以下の通りです：

1）私は制限されたサイズのバッファ（例えば、20バイトのサイズのバッファ）を使用しています。私はファイルからこのバッファにデータを読み込み、ファイルの終わりに達すると常にaxレジスタの値をチェックします。

2）私は、このバッファを13dシンボル（CR ASCIIコード）をチェックし、バッファの要素を新しいwrite-to-fileバッファに渡すプロシージャに渡します。シンボル13dが検出されたらwrite-to-fileバッファが停止し、新しい行トリガ変数が1に設定されます。次に、この改行13dシンボルが見つかった場合、正しい位置にファイルポインタを返す別のプロシージャを呼び出します（カスタムサイズバッファを使用するため、バッファの真ん中にシンボルがあるので、新しい行を修正するためにポインタをリセットする必要があります）。

私のプログラムは.txtファイルで正しく動作しているようですが、たとえば.exeや.jpgファイルの2行をランダムに交換しようとしたときに、同じ行を再び交換するとそのファイルを開くことができませんOSはそれが壊れていると言いますから。

質問：2行の非テキスト形式のファイルを交換してから、変更して新しいファイルが正常に動作することを期待してもいいですか？このコンセプトは理論的には機能すべきでしょうか？または、さまざまな異なる改行シーケンスの解釈（CF + NL、NL + CFなど）によって、変換されたプログラムが破損するのは間違いありませんか？

つまり、テキスト以外のファイルの改行記号の解釈は何ですか？それらのシーケンスは正しいプログラム操作にとって重要ですか？

ご回答ありがとうございます。質問に答えるためにコードの一部が必要な場合は、私にご連絡ください。

Answer 1

テキスト以外のファイルで行を交換しても問題ありません。同じことを2回行う場合は、同じバイナリファイルを受け取る必要があります。

あなたはので、これらのいくつかはありません：限られたバッファサイズで

• あなたのアルゴリズムが正しく状況を処理していませんか？バイナリファイルでは、100k +バイト長の "行"をヒットする可能性があります。

• バイナリ読み取り/書き込みAPIを使用していません。モード"rt"のClib fopenのようなテキストAPIは、一部のバイト値を変換することがあります。そのため、ファイルの内容が壊れます。

非テキストファイル内の改行記号の解釈は何ですか？

（文字列データに使用した場合）は、バイナリファイル内の改行記号の解釈が改行記号を含め、何もすることができますが、ファイルシステムの観点から、それだけでバイト（0から255）だ0x0Dと0x0Aの値は、そのファイルの他のバイトと同様です。

非常に短いバイナリファイル（おそらく4096Bのイントロ）が見つかり、hexviewやbinary diffを使用してファイルが破損している場所を確認してから、デバッグ中にその状況がどのようになったのかを調べてみてください。

正しいプログラム操作にはその配列が重要ですか？もちろん

オリジナルバイナリマシンコードの内部0D 0Aが含まれている場合、のみ0Dことによってそれを置換又は二0A 0Dとを反転すると、元のマシンコード命令を破壊します。データセクションのみにダメージを与えた場合でも、プログラムは何らかの形で損傷したデータで動作する可能性がありますが、コードをランダムに変更すると、元のように動作するもので終わるのは大変です。いくつかのコードを見た後

---

：int 21hファイルハンドラサービスが使用されているように見えますので、int 21h自体はファイルのバイナリコンテンツ（変換なし）で動作します。

ファイルの損傷は、アプリケーションコード自体によって行われます。だから、アルゴリズムをデバッグして、どこが失敗したのかを突き止め、修正しなければなりません。