Assembly 非文本格式文件中的换行符序列如何？_Assembly_X86_Newline_X86 16_Emu8086

Assembly 非文本格式文件中的换行符序列如何？

assembly x86

Assembly 非文本格式文件中的换行符序列如何？,assembly,x86,newline,x86-16,emu8086,Assembly,X86,Newline,X86 16,Emu8086,到目前为止，我一直在练习组装IBM8086体系结构，我收到了编写一个程序的任务，该程序可以交换任意两行文件。（我通过参数给出了这两行的数据文件名和编号）。我的程序的算法如下： 1）我使用有限大小的缓冲区（例如20字节大小的缓冲区）。我将数据从文件读取到此缓冲区，如果到达文件末尾，则不断检查ax寄存器的值 2）我将这个缓冲区传递给程序，该程序检查13d符号（CR ASCII码），并将缓冲区的元素传递给新的写入文件缓冲区，如果检测到符号13d，则传递写入文件缓冲区将停止，并且新行触发器变量设置为

到目前为止，我一直在练习组装IBM8086体系结构，我收到了编写一个程序的任务，该程序可以交换任意两行文件。（我通过参数给出了这两行的数据文件名和编号）。我的程序的算法如下：

1）我使用有限大小的缓冲区（例如20字节大小的缓冲区）。我将数据从文件读取到此缓冲区，如果到达文件末尾，则不断检查ax寄存器的值

2）我将这个缓冲区传递给程序，该程序检查13d符号（CR ASCII码），并将缓冲区的元素传递给新的写入文件缓冲区，如果检测到符号13d，则传递写入文件缓冲区将停止，并且新行触发器变量设置为1。然后，如果找到这个换行符13D符号，我调用另一个过程，它将文件指针返回到正确的位置（因为我使用自定义大小缓冲器，我可能会在缓冲器的中间找到13D符号，所以我需要重置指针来纠正新的行）。因此，我的程序似乎可以正确地处理.txt文件，但当我尝试交换2行随机文件，例如.exe或.jpg文件，然后再次交换相同的行时，我无法打开该文件，因为操作系统说该文件已损坏

我的问题是：是否可以尝试交换任意两行非文本格式的文件，然后尝试将它们更改回来并期望新文件正常工作？这一概念在理论上是否可行？或者由于各种不同的新行序列解释（CF+NL、NL+CF等），转换后的程序是否损坏

换句话说：非文本文件中新行符号的解释是什么？它们的顺序对正确的程序操作重要吗

感谢您的回答，如果需要我的部分代码来回答问题，请注意。

可以在非文本文件中交换行。如果你做同样的事情两次，你应该收到相同的二进制文件

您不需要，因为其中一些：

缓冲区大小有限的算法无法正确处理这种情况？在二进制文件中，很有可能达到100k+字节长度的“行”
您没有使用二进制读/写API（无法从问题中分辨出来）？像Clib
```
fopen
```
和mode
```
“rt”
```
这样的文本API可能会转换一些字节值，因此文件的内容将被损坏

非文本文件中新行符号的解释是什么

二进制文件中新行符号的解释可以是任何内容，包括新行符号（在字符串数据中使用时），但从文件系统的角度来看，它只是

0x0D

和

0x0A

的字节（

）值，就像文件的任何其他字节一样

也许试着找到一些非常短的二进制文件，但失败了（可能是4096B的介绍），然后使用hexview或binary diff查看文件损坏的位置，然后在调试过程中试着找出这种情况是如何发生的

它们的顺序对正确的程序操作重要吗

当然，如果原始二进制文件在机器代码中包含

0d0a

，则仅将其替换为

0D

，或将两者翻转为

0a0d

将破坏原始机器代码指令。如果只损坏数据部分，程序可能仍能以某种方式处理损坏的数据，但随机更改代码将需要大量运气才能完成与原始数据几乎相同的工作

看到一些代码后：看起来像是使用了

int21h

文件处理程序服务，因此

int21h

本身可以处理文件的二进制内容（无转换）

任何文件损坏都是由应用程序代码本身造成的。因此，您必须调试您的算法，找出它失败的地方，然后修复它。

在非文本文件中交换行是可以的。如果你做同样的事情两次，你应该收到相同的二进制文件