根据Joel Spolsky在这篇博文中的说法，

这是因为发明了UNIX和C编程语言的PDP-7微处理器有一个ascii字符串类型。ASCIZ的意思是“以Z(零)结尾的ASCII”。

在看到这里所有其他的答案后，我相信即使这是真的，这也只是C具有以空结束的“字符串”的部分原因。这篇文章很有启发性，因为像字符串这样简单的东西实际上是相当困难的。

这个问题是作为长度前缀字符串(LPS)与零终止字符串(SZ)的问题提出的，但主要暴露了长度前缀字符串的好处。这似乎有些势不可挡，但老实说，我们也应该考虑到LPS的缺点和SZ的优点。

在我看来，这个问题甚至可以被理解为一种带有偏见的提问方式:“零终止字符串的优势是什么?”

零终止字符串的优点(我看到了):

very simple, no need to introduce new concepts in language, char arrays/char pointers can do. the core language just include minimal syntaxic sugar to convert something between double quotes to a bunch of chars (really a bunch of bytes). In some cases it can be used to initialize things completely unrelated with text. For instance xpm image file format is a valid C source that contains image data encoded as a string. by the way, you can put a zero in a string literal, the compiler will just also add another one at the end of the literal: "this\0is\0valid\0C". Is it a string ? or four strings ? Or a bunch of bytes... flat implementation, no hidden indirection, no hidden integer. no hidden memory allocation involved (well, some infamous non standard functions like strdup perform allocation, but that's mostly a source of problem). no specific issue for small or large hardware (imagine the burden to manage 32 bits prefix length on 8 bits microcontrollers, or the restrictions of limiting string size to less than 256 bytes, that was a problem I actually had with Turbo Pascal eons ago). implementation of string manipulation is just a handful of very simple library function efficient for the main use of strings : constant text read sequentially from a known start (mostly messages to the user). the terminating zero is not even mandatory, all necessary tools to manipulate chars like a bunch of bytes are available. When performing array initialisation in C, you can even avoid the NUL terminator. Just set the right size. char a[3] = "foo"; is valid C (not C++) and won't put a final zero in a. coherent with the unix point of view "everything is file", including "files" that have no intrinsic length like stdin, stdout. You should remember that open read and write primitives are implemented at a very low level. They are not library calls, but system calls. And the same API is used for binary or text files. File reading primitives get a buffer address and a size and return the new size. And you can use strings as the buffer to write. Using another kind of string representation would imply you can't easily use a literal string as the buffer to output, or you would have to make it have a very strange behavior when casting it to char*. Namely not to return the address of the string, but instead to return the actual data. very easy to manipulate text data read from a file in-place, without useless copy of buffer, just insert zeroes at the right places (well, not really with modern C as double quoted strings are const char arrays nowaday usually kept in non modifiable data segment). prepending some int values of whatever size would implies alignment issues. The initial length should be aligned, but there is no reason to do that for the characters datas (and again, forcing alignment of strings would imply problems when treating them as a bunch of bytes). length is known at compile time for constant literal strings (sizeof). So why would anyone want to store it in memory prepending it to actual data ? in a way C is doing as (nearly) everyone else, strings are viewed as arrays of char. As array length is not managed by C, it is logical length is not managed either for strings. The only surprising thing is that 0 item added at the end, but that's just at core language level when typing a string between double quotes. Users can perfectly call string manipulation functions passing length, or even use plain memcopy instead. SZ are just a facility. In most other languages array length is managed, it's logical that is the same for strings. in modern times anyway 1 byte character sets are not enough and you often have to deal with encoded unicode strings where the number of characters is very different of the number of bytes. It implies that users will probably want more than "just the size", but also other informations. Keeping length give use nothing (particularly no natural place to store them) regarding these other useful pieces of information.

也就是说，在标准C字符串确实效率低下的罕见情况下，没有必要抱怨。图书馆是可用的。如果我遵循这个趋势，我应该抱怨标准C不包括任何正则表达式支持函数……但实际上每个人都知道这不是一个真正的问题，因为有库可以用于此目的。因此，当字符串操作效率是需要的，为什么不使用像bstring库?或者甚至是c++字符串?

编辑:我最近看了看D弦。有趣的是，所选择的解决方案既不是大小前缀，也不是零终止。与C语言一样，双引号括起来的字面值字符串只是不可变字符数组的简写，并且该语言也有一个字符串关键字表示(不可变字符数组)。

但是D数组比C数组丰富得多。在静态数组的情况下，长度在运行时是已知的，因此不需要存储长度。编译器在编译时拥有它。在动态数组的情况下，长度是可用的，但D文档没有说明它保存在哪里。就我们所知，编译器可以选择将它保存在某个寄存器中，或者存储在远离字符数据的某个变量中。

正常char数组或非字符串没有最终为零,因此程序员必须把它本身如果他想叫一些C函数从D .字符串字面量的具体情况,然而D编译器仍然把零在每个字符串(允许容易把C字符串容易调用C函数?),但这零不是字符串的一部分(D不计算字符串大小)。

The only thing that disappointed me somewhat is that strings are supposed to be utf-8, but length apparently still returns a number of bytes (at least it's true on my compiler gdc) even when using multi-byte chars. It is unclear to me if it's a compiler bug or by purpose. (OK, I probably have found out what happened. To say to D compiler your source use utf-8 you have to put some stupid byte order mark at beginning. I write stupid because I know of not editor doing that, especially for UTF-8 that is supposed to be ASCII compatible).

围绕C语言的许多设计决策都源于这样一个事实:在最初实现C语言时，参数传递的代价有些昂贵。如果在两者之间作选择。

void add_element_to_next(arr, offset)
  char[] arr;
  int offset;
{
  arr[offset] += arr[offset+1];
}

char array[40];

void test()
{
  for (i=0; i<39; i++)
    add_element_to_next(array, i);
}

与

void add_element_to_next(ptr)
  char *p;
{
  p[0]+=p[1];
}

char array[40];

void test()
{
  int i;
  for (i=0; i<39; i++)
    add_element_to_next(arr+i);
}

后者会稍微便宜一点(因此是首选)，因为它只需要传递一个参数而不是两个。如果被调用的方法不需要知道数组的基址，也不需要知道其中的索引，那么将这两个值组合在一起传递一个指针比分别传递值要便宜。

While there are many reasonable ways in which C could have encoded string lengths, the approaches that had been invented up to that time would have all required functions that should be able to work with part of a string to accept the base address of the string and the desired index as two separate parameters. Using zero-byte termination made it possible to avoid that requirement. Although other approaches would be better with today's machines (modern compilers often pass parameters in registers, and memcpy can be optimized in ways strcpy()-equivalents cannot) enough production code uses zero-byte terminated strings that it's hard to change to anything else.

PS——为了在某些操作上稍微降低速度，以及在较长的字符串上稍微增加一点额外开销，可以让处理字符串的方法直接接受指向字符串的指针、经过边界检查的字符串缓冲区或标识另一个字符串的子字符串的数据结构。像“strcat”这样的函数看起来像[现代语法]

void strcat(unsigned char *dest, unsigned char *src)
{
  struct STRING_INFO d,s;
  str_size_t copy_length;

  get_string_info(&d, dest);
  get_string_info(&s, src);
  if (d.si_buff_size > d.si_length) // Destination is resizable buffer
  {
    copy_length = d.si_buff_size - d.si_length;
    if (s.src_length < copy_length)
      copy_length = s.src_length;
    memcpy(d.buff + d.si_length, s.buff, copy_length);
    d.si_length += copy_length;
    update_string_length(&d);
  }
}

比K&R strcat方法大一点，但它支持边界检查，而K&R方法不支持。此外，与当前的方法不同，它可以轻松地连接任意子字符串，例如。

/* Concatenate 10th through 24th characters from src to dest */

void catpart(unsigned char *dest, unsigned char *src)
{
  struct SUBSTRING_INFO *inf;
  src = temp_substring(&inf, src, 10, 24);
  strcat(dest, src);
}

注意，由temp_substring返回的字符串的生命周期将受到s和src的生命周期的限制，后者更短(这就是为什么该方法需要传入inf——如果它是本地的，它将在方法返回时死亡)。

In terms of memory cost, strings and buffers up to 64 bytes would have one byte of overhead (same as zero-terminated strings); longer strings would have slightly more (whether one allowed amounts of overhead between two bytes and the maximum required would be a time/space tradeoff). A special value of the length/mode byte would be used to indicate that a string function was given a structure containing a flag byte, a pointer, and a buffer length (which could then index arbitrarily into any other string).

当然，K&R并没有实现任何这样的东西，但这很可能是因为他们不想在字符串处理上花费太多精力——即使在今天，许多语言在这方面似乎都相当薄弱。

C语言中没有字符串。C语言中的“string”只是一个指向char的指针。所以也许你问错问题了。

“省略字符串类型的基本原理是什么”可能更相关。对此，我要指出C不是面向对象的语言，只有基本的值类型。字符串是一个更高级别的概念，必须以某种方式组合其他类型的值来实现。C处于较低的抽象级别。

鉴于下面的狂风暴雨

我只是想指出，我并不是想说这是一个愚蠢或糟糕的问题，或者C语言表示字符串的方式是最好的选择。我试图澄清的是，如果考虑到C语言没有区分字符串作为数据类型与字节数组的机制这一事实，那么这个问题就会更简洁。考虑到今天计算机的处理和存储能力，这是最好的选择吗?可能不会。但事后诸葛总是20/20之类的。

Calavera是对的，但由于人们似乎没有理解他的观点，我将提供一些代码示例。

首先，让我们考虑一下C是什么:一种简单的语言，其中所有代码都可以直接转换为机器语言。所有类型都适合寄存器和堆栈，并且它不需要一个操作系统或一个大的运行时库来运行，因为它是用来编写这些东西的(考虑到今天甚至没有一个可能的竞争对手，这个任务非常适合)。

如果C语言有一个字符串类型，比如int或char，它将是一种不适合寄存器或堆栈的类型，并且需要以任何方式处理内存分配(及其所有支持的基础设施)。所有这些都违背了C语言的基本原则。

因此，C语言中的字符串是:

char s*;

那么，我们假设这是有长度前缀的。让我们编写代码来连接两个字符串:

char* concat(char* s1, char* s2)
{
    /* What? What is the type of the length of the string? */
    int l1 = *(int*) s1;
    /* How much? How much must I skip? */
    char *s1s = s1 + sizeof(int);
    int l2 = *(int*) s2;
    char *s2s = s2 + sizeof(int);
    int l3 = l1 + l2;
    char *s3 = (char*) malloc(l3 + sizeof(int));
    char *s3s = s3 + sizeof(int);
    memcpy(s3s, s1s, l1);
    memcpy(s3s + l1, s2s, l2);
    *(int*) s3 = l3;
    return s3;
}

另一种方法是使用struct来定义字符串:

struct {
  int len; /* cannot be left implementation-defined */
  char* buf;
}

此时，所有的字符串操作都需要进行两次分配，这实际上意味着您将通过一个库来进行任何处理。

有趣的是……这样的结构体在C中确实存在!它们只是不用于日常显示消息给用户处理。

所以，这就是Calavera的观点:在c语言中没有字符串类型，要对它做任何事情，你必须获取一个指针，并将其解码为指向两个不同类型的指针，然后字符串的大小就变得非常相关，而不能仅仅是“实现定义”。

现在，C可以以任何方式处理内存，并且库中的mem函数(甚至在<string.h>中!)提供了将内存作为一对指针和大小来处理所需的所有工具。C语言中所谓的“字符串”的创建只有一个目的:在为文本终端编写操作系统的上下文中显示消息。因此，空终止就足够了。

我觉得更好的问题是你为什么觉得C欠你什么?C语言的设计是为了满足你的需要，仅此而已。你需要摆脱那种认为语言必须为你提供一切的心态。或者只是继续使用你的高级语言，这将给你奢侈的字符串，日历，容器;而在Java中，你会得到一种千变万化的东西。多个类型字符串，多个类型的unordered_map(s)。

这对你来说太糟糕了，这不是C的目的。C并不是被设计成一种从大头针到锚的臃肿语言。相反，您必须依赖第三方库或您自己的库。没有什么比创建一个包含字符串及其大小的简单结构体更容易的了。

struct String
{
 const char *s;
 size_t len;
};

你知道问题出在哪里。它不标准。另一种语言可能决定将len组织在字符串之前。另一种语言可能决定使用指针来代替结束。另一个人可能决定使用六个指针来提高String的效率。然而，null结尾的字符串是字符串的最标准格式;你可以用它来与任何语言进行交互。甚至Java JNI也使用以空结尾的字符串。

Lastly, it is a common saying; the right data structure for the task. If you find that need to know the size of a string more than anything else; well use a string structure that allows you to do that optimally. But don't make claims that that operation is used more than anything else for everybody. Like, why is knowing the size of a string more important than reading its contents. I find that reading the contents of a string is what I mostly do, so I use null terminated strings instead of std::string; which saves me 5 pointers on a GCC compiler. If I can even save 2 pointers that is good.