为什么fwrite（）在Mac OS X上使用C中的“wb”写入二进制文件？
为了学习C并理解二进制文件和文本文件之间的区别，我试图将一个字符串写入文件，因为两种文件类型都是这样的：
char * string = "I am a string!"; FILE * filePtrA = fopen("/output.txt", "wt"); fwrite(string, strlen(string), 1, filePtrA); FILE * filePtrB = fopen("/output.bin", "wb"); fwrite(string, strlen(string), 1, filePtrB); fclose(filePtrA); fclose(filePtrB); 但是"wt"和"wb"都是作为文本文件写入的，其中"wb"应该写为二进制文件。 Hex对于这两个文件都是这样的：
49 20 61 6D 20 61 20 73 74 72 69 6E 67 21
为什么会发生这种情况，我怎样才能将内容写成二进制文件？
我已经读过操作系统（Mac OS X 10.6 – GCC 4.2）可能无法区分二进制文件和文本文件，但我仍然难以理解为什么hex编辑器不会发现任何差异。
所有文件都是二进制的
fopen上下文中“文本文件”和“二进制文件”之间的区别在于标准库可能在文本模式下使用filter来读取和写入文件。 在二进制模式下，你写的东西总是写的。
我所知道的唯一实际例子是在Windows中，在文本模式下打开文件将使它在Windows风格的行结尾（CRLF， "\r\n" ）和C风格/ Unix风格的行结尾之间进行转换（ LF， "\n" ）。 例如，当您在文本模式下打开用于在Windows中读取的文件时，行结尾将在程序中显示为"\n" 。 如果要以二进制模式打开它，行结尾将在程序中显示为"\r\n" 。
您还可以使用cat检查文件，例如：
猫文件名
你应该得到输出： I am a string!
两个文件都是二进制文件。 它们是您发送给fwrite的数据的精确副本。 一些损坏的操作系统具有非二进制的文本文件; 他们有额外的垃圾，如\r\n替换\n ，或固定大小的行记录等.POSIX禁止所有这些。 在任何POSIX OS上，文本和二进制模式都是相同的。
顺便说一句， "wt"不是fopen的有效模式参数。 文本模式是默认的。 请求文本模式的t修饰符是破坏的Windows实现的扩展，其中二进制是默认的，但文本模式可通过请求获得。
唯一不同的文本模式使其成为行结尾。 所以，如果你fprintf一个\n它将根据平台进行翻译。 对于您的示例，二进制或文本模式与写入文件的内容没有区别。
在大多数类Unix系统上，在文本和二进制模式下打开文件没有区别。 此外，即使在许多以不同方式处理“文本”和“二进制”文件的系统上，您上面写的数据也不会显示出差异。
例如，在Windows上以文本模式打开文件通常意味着您编写的“\ n”将在实际文件中转换为“\ r \ n”（并且在读取期间完成相反的操作）。 由于您没有写“\ n”，因此不会进行翻译。
你是对的。 这在类Unix系统上无关紧要。 来自cygwin阵营的讨论 。 你期望看到什么区别？ 您正在将ASCII文本写入文件，而不是任意二进制数据。
像操作系统这样的Unix将两者视为相同。 我不确定这是正确的答案，但是如果你想将文本作为hex文件放入文件中，尝试在text.eg之前应用\ x，如果你试图将hello写入文件，那么你的缓冲区将是是：
char * buf =“你好”;
如果你想在文件中写入“hello”的hex，你的缓冲区应该是这样的
char * buff =“\ x68 \ x65 \ x6c \ x6c \ x6f”;
希望它有所帮助