1字节！= 8位的系统？

所有的时候我都像读一样的句子

不要依靠8位大小的1个字节

使用CHAR_BIT而不是8作为常量来转换位和字节

等等。今天有什么真正的生活系统，这是真实的吗？ _{（我不确定C和C ++之间是否存在差异，或者实际上是否与语言无关，如果需要请重新标记）}

在较老的机器上，小于8位的代码是相当常见的，但其中大部分已经死了多年。

C和C ++已经规定char至less8位，至less早在C89标准的时候。 [编辑：例如，C90，§5.2.4.2.1需要CHAR_BIT > = 8和UCHAR_MAX > = UCHAR_MAX使用不同的节号（我相信这将是§2.2.4.2.1），但内容相同]。他们把“char”和“byte”视为基本同义[编辑：例如， CHAR_BIT被描述为：“不是位域（字节）”的最小对象的位数。]

然而，目前的机器（主要是DSP）的最小types大于8位，最less12,14甚至16位是相当普遍的。 Windows CE大致相同：最小的types（至less在微软的编译器中）是16位。但是，他们不把char视为16位，而是采取（不符合）的方式，根本不支持名为char的types。

如今，在x86处理器上的C ++世界中，依靠8位的一个字节是相当安全的。字大小不是2的幂（8,16,32,64）的处理器是非常罕见的 。

它并不总是如此。

控制数据6600（及其兄弟）中央处理器使用一个60位字，并且一次只能处理一个字。在某种意义上，CDC 6600上的“字节”是60位。

DEC-10字节指针硬件使用任意大小的字节。字节指针包含字节大小的位。我不记得字节是否可以跨越单词边界; 我认为他们不能这样做，这意味着如果字节大小不是3,4,9或18位，那么每个字都会有一些浪费。（DEC-10使用了一个36位字。）

除非您正在编写可能对DSP有用的代码，否则您完全有权假定字节是8位。全世界都可能不是VAX（或英特尔），但是全世界都必须进行通信，共享数据，build立通用协议等等。我们生活在build立在八位字节上的协议上的互联网时代，任何字节不是八位字节的C实现都将很难使用这些协议。

还值得注意的是，POSIX和Windows都有（和强制）8位字节。这涵盖了100％有趣的非embedded式机器，以及当今大部分非DSPembedded式系统。

维基百科：

一个字节的大小最初被select为现有电传打字机代码的倍数，特别是美国陆军（Fieldata）和海军使用的6位代码。 1963年，为了结束美国政府不同部门使用的不兼容的电传打字机代码，一种7位代码ASCII被采纳为联邦信息处理标准，使得6位字节在商业上被淘汰。在二十世纪六十年代初期，AT＆T首先在长途干线上引入数字电话。这些使用了8位μ律编码。这一大笔投资有望降低8位数据的传输成本。数字电话使用8位码也导致8位数据“八比特组”被用作早期因特网的基本数据单元。

首先， char中的位数不正式依赖于“系统”或“机器”，即使这种依赖性通常是由常识暗示的。 char的位数只取决于实现（即在编译器上）。对于任何“普通”系统或机器来说，实现一个编译器的char数超过8位是没有问题的。

其次，有几个embedded式平台，其中每个都有16位（我不记得这些平台的确切名称sizeof(char) == sizeof(short) == sizeof(int) ， sizeof(char) == sizeof(short) == sizeof(int) ）。而且，众所周知的Cray机具有类似的性质，其中所有这些types都具有32位。

作为主stream平台上的普通程序员，你不必太担心一个字节不是8位。然而，我仍然在我的代码中使用CHAR_BIT常量，并assert （或更好的static_assert ）任何地方，你依靠8位字节。这应该把你放在安全的一面。

（我不知道任何相关的平台，如果不是这样的话）。

在历史上，有一些奇怪的架构，不使用8的倍数原生字大小。如果你今天遇到任何这些，让我知道。

英特尔的第一个商用CPU是英特尔4004 （4位）
PDP-8 （12位）

字节的大小在历史上与硬件有关，并且不存在规定大小的确定性标准。

如果你做了很多embedded的东西，那么记住它可能是一件好事。

我做了很多embedded式操作，目前正在处理CHAR_BIT为16的DSP代码

在HP Saturn上的维基百科条目中添加一个作为参考：

土星build筑是基于蚕食的; 即数据的核心单元是4位，可以保存一个二进制编码的十进制（BCD）数字。