今天我遇到了一个有点烦人的错误，其中一个字符串（存储为char []）将在末尾打印垃圾。假设要打印的字符串（使用arduino打印/写入功能）是正确的（正确包含\ r和\ n）。但是，最后会印上垃圾。
然后我分配了一个额外的元素来存储'\ r'和'\ n'之后的'\ 0'（这是要打印的字符串中的最后2个字符）。然后，print（）正确打印字符串。似乎'\ 0'用于向print（）函数指示字符串已终止（我记得在Kernighan的C中读过这个）。
此错误出现在我的代码中，该代码从文本文件中读取。在我设计我的代码时，我突然意识到我没有遇到'\ 0'。这让我相信'\ 0'在文本编辑器中没有实际用途，仅用于打印功能。这是对的吗？
答案 0 :(得分：5)
C字符串由NUL字节（'\0'）终止 - 这隐式附加到双引号中的任何字符串文字，并用作在字符串上运行的所有标准库函数的终止符。由此可见，C字符串不能在其他字符之间包含'\0'终止符，因为无法判断它是否是字符串的实际结尾。
（当然你可以处理C语言中的字符串而不是C字符串 - 例如，简单地添加一个整数来记录字符串的长度会使终结符变得不必要，但是这样的字符串不能与期望的函数完全互操作C字符串。）
“文本文件”通常不受C标准的约束，并且C程序的用户可以想象一个包含NUL字节的文件作为C程序的输入（它将无法正确处理它） “由于上述原因，如果它将文件读入C字符串）。但是，NUL字节没有在纯文本文件中存在的正当理由，并且它可能至少被认为是文本文件的事实标准，它们不包含NUL字节（或某些其他控制字符，这可能会破坏传输通过一些终端或串行协议的文本。
我认为，对于处理纯文本输入的程序来说，如果输入中有NUL字节，则不能保证输出正确，这是可接受的（尽管不是必需的！）限制。但是，程序员应该意识到这种可能性，无论它是否被正确处理，并且不允许它在程序中导致未定义的行为。与所有用户输入一样，它应该被视为“不安全”，因为它可以包含任何内容（例如，它可能是故意恶意形成的）。
答案 1 :(得分：4)
这让我相信'\ 0'在文本中没有实际用途 编辑器，仅供打印功能使用。这是对的吗？
这是错误的。在C中，字符串的结尾由<string.h>字符指定。这通常称为 null终结符。在\0下的C库中声明的几乎所有字符串函数都使用此条件来检查或查找字符串的结尾。
另一方面，文本文件通常不会包含任何{{1}}个字符。因此，当从文件中读取文本时，您必须 null-terminate 您的字符缓冲区，然后再打印它。
答案 2 :(得分：0)
\0是空字符（ASCII代码0）的C转义序列，广泛用于表示内存中字符串的结尾。该字符通常不会在文本文件中显式出现，但是，按照惯例，大多数C字符串在末尾都包含空终止符。将字符串读入内存的函数通常会附加\0来表示字符串的结尾，而从内存中输出字符串的函数同样会期望\0。
请注意，还有其他方法可以在内存中表示字符串，例如作为(length, content)对（Pascal特别使用此表示形式），它不需要空终止符，因为字符串的长度在提前知道时间。
答案 3 :(得分：0)
空字符'\0'，即使很少见，也可以出现在文本文件中。代码应该准备好'\0'。
这还包括典型ASCII范围之外的其他char。此外，一些＆＃34;文本＆＃34;文件使用UTF-16编码和代码遇到，但期待典型的＆＃34;文本＆＃34;会遇到很多空字符。线条太长，太短，可能＆＃34;文字＆＃34;问题存在。
简单地说，健全的代码在合格并满足期望之前不信任使用/文件输入。