先说个我自己的经历。前阵子帮一个刚转行的朋友看代码他在一个协议解析程序里把缓冲区长度写成了strlen(buf)结果中文消息一多就崩。我一问他连“一个汉字在 UTF-8 里占几个字节”都有点含糊更别提“bit 和 byte 到底差多少倍”这种基础问题了。其实字节、字、bit、byte、KB 这几个词几乎每个写代码、搞网络、甚至只是买电脑的人都见过但真要说清楚它们之间的关系不少人会卡壳。这篇文章就用大白话把这条线捋一遍顺便把高低字节、字节对齐、容量换算这些高频出坑点也一起讲透。1. 先搞懂 bit计算机里那个“非 0 即 1”的最小开关1.1 一个 bit 就是一个二选一的开关bit 是 binary digit二进制数字的缩写中文通常翻译成“比特”。它代表计算机里最小的信息单位本质上就是一个二选一的开关要么是 0要么是 1没有第三种状态。在硬件层面这个开关可以是一根导线上的高低电平也可以是硬盘上一个微小磁区的南北极还可以是闪存里一个浮栅晶体管的电荷状态。反正不管物理形式怎么变逻辑上就是一个“是/否”的判断。你可以把 bit 想成家里走廊的电灯开关按下去是开1弹起来是关0。一个开关能表达两种状态两个开关放在一起就能表达四种状态开开、开关、关开、关关也就是00、01、10、11。三个开关就是八种状态。对应到数学上n 个 bit 能表示的不同状态数量是 2 的 n 次方。有个很经典的问题“一个 bit 能存多少种信息”答案是 2 种。那 8 个 bit 呢2 的 8 次方等于 256 种。这个数字后面还会不断遇到。1.2 为什么网上老说“高低字节”里的“高低”既然 bit 只有 0 和 1 两种状态那多个 bit 排成一串的时候就得给每个位置约定一个“权重”。比如二进制数1010从右往左数第 0 位最右边是权重 1 的位第 1 位权重 2第 2 位权重 4第 3 位权重 8。于是1010就等于 8×1 4×0 2×1 1×0也就是十进制的 10。 这个过程中最左边的那一位叫最高位Most Significant BitMSB因为它的权重最大最右边叫最低位Least Significant BitLSB权重最小。所谓“高低字节”指的就是一个多字节数据里权重高的那些字节叫高字节权重低的叫低字节。我在实际看协议文档时经常遇到一种情况文档里只写了某个字段是“高字节在前”还是“低字节在前”如果你不懂最高位和最低位的概念后面解析数据就是纯靠猜。所以别看 bit 简单它是理解字节序、位运算、掩码操作的地基。1.3 bit 与网络带宽的关系bit 还有一个特容易踩的坑就是它跟“字节”在缩写上长得太像。运营商宣传的“100M 宽带”单位其实是 Mbps也就是每秒 100 兆比特Million bits per second。但下载软件里显示的“12.5MB/s”单位是兆字节每秒。这里换算关系是 1 byte 8 bits所以 100 Mbps 的理论最大下载速度是 100 ÷ 8 12.5 MB/s。你可能实际跑到 10MB/s 左右就算不错了因为还有协议开销、信号衰减这些因素。 我帮人排查“宽带速率不达标”问题时十次有八次都是把 bit 和 byte 搞混最后发现根本不是运营商的问题。2. byte字节的诞生从字符编码到 8 个 bit 的“标准答案”2.1 为什么偏偏是 8 个 bit 组成一个字节你可能会问为什么不是一个 bit 一个 bit 地数非要 8 个捆在一起这就要从计算机发展的早期说起了。早期计算机的字长并不统一有的机器一个“字”是 6 位有的是 7 位。直到 ASCII 码美国信息交换标准代码逐渐普及人们发现英文字母大小写共 52 个、数字10 个、标点符号和控制字符加在一起用 7 位二进制刚好能覆盖2 的 7 次方等于 128。但 7 位在硬件设计上不够规整因为计算机内部的数据总线、寄存器通常按 8 的倍数来设计。IBM System/360 系列计算机在 1964 年推出时确立了以 8 位为一个基本存储单位的方案一个字节正好能放一个 ASCII 字符多出来的第 8 位还可以用来做奇偶校验或者扩展字符集。后来 8 位字节就成了业界事实标准“byte字节 8 bits”这个换算关系就这么定下来了。现在你去看各种编程语言的规范基本上sizeof(char)都是 1而这个 1 指的就是 1 个字节。注意C 语言标准只规定char的大小是 1 个字节并没有强制说一个字节一定是 8 位但在我们日常接触的 x86、ARM 这些主流平台上一个字节就是 8 位不用纠结特殊情况。2.2 字母 b 和 B 的区别差 8 倍的大坑大小写这个问题我从入行到现在见过太多人栽跟头了。小写bbit 的缩写表示位。大写Bbyte 的缩写表示字节。比如你买固态硬盘标注是 500GB这里的 GB 是字节。但你写代码时如果网络带宽是 10Mbps这里的 Mb 是兆比特。一个不小心把 8 倍给忽略了整个系统的吞吐量估算就全错了。我在做日志采集系统时经常需要估算峰值流量。假设单机每秒产生 10 万条日志每条日志平均 1KB那一小时就是 10 万 × 1KB × 3600 秒算下来约 360GB。但如果上游给的指标是“每秒 100Mbps”你就得先除以 8 得到 12.5MB/s再对照 10 万条 × 1KB 100MB/s 的写入需求发现带宽根本不够。这种量级错误全靠对 b 和 B 敏感才能避开。3. 字、字长与字节CPU 一次性能“咽下”多少数据3.1 字是 CPU 处理数据的“一口量”接下来讲“字”。字Word这个概念比字节抽象因为它没有固定的位数而是跟具体 CPU 的体系结构有关。你可以把 CPU 想象成一个吃饭的人字节是他的饭勺大小而字是他一口能吃下的量。对 64 位的 CPU 来说它最顺手的处理长度是 64 位也就是 8 个字节所以这个 CPU 的“字”就是 8 字节字长就是 64 位。对 32 位的老 CPU 来说字是 4 字节字长 32 位。再早一点的 16 位 CPU比如 8086一个字是 2 字节。字长通常跟 CPU 内部寄存器宽度、数据总线宽度是一致的。它决定了 CPU 一次能直接处理的整数范围、能访问的内存地址空间上限也直接影响性能。所以当有人问你“字和字节啥关系”标准回答是字长除以 8 就是每个字的字节数。32 位系统字长 32 位 4 字节64 位系统字长 64 位 8 字节。不过注意“字”这个词在不同上下文里有不同含义。在中文文档里“字数统计”指的是人类语言里的字跟这里的机器字完全不是一回事在 C 语言里根本没有标准的“word”类型很多嵌入式编译器会定义WORD为 16 位或 32 位你得先看头文件。这就是为什么我建议在技术讨论里尽量说“32 位系统”“64 位系统”少说“字是多少位”避免误会。3.2 字节、字、位的关系速算表为了方便对比我整理了一张表单位英文缩写常见大小位常见大小字节典型用途位bit, b1 位1/8 字节表示二进制状态、带宽计量字节byte, B8 位1 字节存储基本单位一个 ASCII 字符字word16/32/64 位不等2/4/8 字节CPU 一次处理的数据宽度双字dword32 位4 字节Windows API、寄存器组合四字qword64 位8 字节x86 下的 64 位整数、地址这张表里你只要抓住两行核心1 字节 8 位1 字 字长 ÷ 8 字节。其他都是衍生品。3.3 高低字节、大小端序多字节数据怎么摆放讲完字必须聊高低字节和大小端因为这两者几乎是孪生关系。假设有一个 16 位整数0x1234。0x12是高字节权重高0x34是低字节。在内存里存放时有两种主流做法大端序Big-Endian高字节存在低地址也就是先存0x12再存0x34。读起来就像我们正常人写数字一样从左往右读很符合直觉。网络协议里规定用大端序所以也叫网络字节序。小端序Little-Endian低字节存在低地址先存0x34再存0x12。x86、ARM 这类主流处理器默认是小端。你可能觉得小端序反直觉但它在硬件设计上有优势从地址递增方向看低字节先出来CPU 做加法进位时更自然。我在解析一个 32 位传感器数据时就是通过((uint32_t)buf[0] 24) | ((uint32_t)buf[1] 16) | ((uint32_t)buf[2] 8) | buf[3]这样的移位操作把 4 个大端字节组装成一个整数。如果顺序搞反读出来的数据直接差个十万八千里。所以凡是跨系统、跨网络传二进制数据一定要明确字节序。你自己写死一个平台还好一旦换到另一个平台齐头发的 bug 就来了。4. KB、MB、GB 的换算1024 的来历以及硬盘容量的“缩水”之谜4.1 为什么 1KB 是 1024 字节而不是 1000 字节现在进入“KB”这个单位。这里的 K 是 kilo 的缩写直译是“千”。但计算机内部是二进制世界最接近 1000 的 2 的幂是 2 的 10 次方 1024。所以早期计算机科学家干脆约定在存储领域1KB 1024 字节。同理1MB 1024KB1GB 1024MB1TB 1024GB这个 1024 的进制贯穿了内存、文件大小和各种存储设备的计量。为什么会选 1024因为计算机里地址线、数据线的位数是 2 的幂次内存容量天然就是 2 的幂次累计出来的。比如一条地址线能寻址 2 个字节两条能寻址 4 个字节十条能寻址 1024 个字节。用 1024 做换算内存容量就能直接对应到地址线的根数特别方便。4.2 硬盘厂商按 1000 算系统按 1024 算接下来是我认为最迷惑人的地方硬盘“缩水”。你买一个标称 500GB 的机械硬盘或固态硬盘插到电脑上操作系统显示通常是 465GB 左右。这是厂商做手脚吗不完全是而是进制不统一导致的。硬盘厂商按十进制计算1KB 1000 字节所以 500GB 500 × 1000 × 1000 × 1000 字节。操作系统按二进制计算1GB 1024 × 1024 × 1024 字节。所以操作系统显示容量 500,000,000,000 字节 ÷ (1024 × 1024 × 1024) ≈ 465GB。民用产品一直沿用这个规则才造成你“买 500G 变 465G”的观感。注意内存条和 U 盘又不一样U 盘很多也是按十进制标称但内存条因为本身容量就是 2 的幂次比如 8GB 内存其换算基本是按 1024 来衡量的。我记得早年帮人挑电脑有人看到硬盘 465GB 就觉得买到了假货。后来我教他一个公式标称值 × 0.9313 约等于系统显示的“GiB”值他这才放心。这个 0.9313 就是 1000 的 3 次方除以 1024 的 3 次方得出的系数。4.3 KiB 与 KB一个规范解决混乱为了终结这种混乱国际电工委员会IEC在 1998 年制定了新标准KiBKibibyte基比字节1 KiB 1024 字节明确用于二进制倍数。KBKilobyte1 KB 1000 字节明确用于十进制倍数。同理还有 MiB、GiB、TiB。理论上操作系统应该用 GiB 来显示容量但 Windows 一直显示“GB”实际上是按 GiB 算的所以永远跟厂商的 GB 对不上。macOS 系统现在显示的是真正的十进制 GB所以苹果电脑里硬盘容量反而跟标称值更接近。这个知识在买 VPS 时特别有用。很多云厂商套餐写“50GB SSD”但你在 Linux 里执行df -h看到的是 50G 还是 46G取决于文件系统怎么算。心里有 1024 和 1000 这两把尺子就不容易被搞晕。5. 代码里的字节世界8 字节能干什么、字节对齐、字符串转数字、编码差异5.1 8 字节能干什么现在我们进入更“程序员日常”的部分。8 字节是很多语言里长整型long long / long、双精度浮点数double的标准大小也是 64 位平台上指针的大小。8 字节 64 位 2 的 64 次方这个数大约是 1.844 亿亿也就是 18446744073709551616。如果是用来表示无符号整数范围是 0 到 18446744073709551615如果是地址空间理论上能寻址的字节数就是这个数也就是约 1600 万 TB。当然实际硬件不会让你用满但这也是 64 位比 32 位能装下更多内存的根本原因。我在处理二进制文件格式时经常用 8 字节来存时间戳Unix 纳秒时间戳、文件偏移量或者大文件的校验值。比如一个 4GB 以上的文件用 32 位整数来偏移肯定是放不下的必须用 64 位8 字节。所以如果你在某些解析代码里看到long long或者int64_t它天然就是 8 字节这是语言规范保证的x86 和 ARM 上基本如此。5.2 结构体字节对齐为什么 C 结构体“虚报”内存占用说到字节C/C 程序员绕不开字节对齐alignment。字节对齐的本质是 CPU 访问内存时对特定类型数据的起始地址有偏好。比如一个 4 字节的 int如果它放在能被 4 整除的地址上CPU 一次就能读完整如果跨在两个“边界”上CPU 可能需要读两次再拼接效率低下。所以编译器会在结构体成员之间插入 padding填充字节让每个成员都“对齐”到自己该在的位置。我写一个经典例子#include stdio.h struct Test { char c; // 1 字节 int i; // 4 字节 short s; // 2 字节 }; int main() { printf(sizeof(struct Test) %zu\n, sizeof(struct Test)); return 0; }直觉上1 4 2 7 字节。但在 x86 上这个结构体的大小通常是 12 字节。为什么char c从偏移 0 开始占 1 字节。int i要求 4 字节对齐所以编译器在 c 后面填充 3 个字节把 i 放到偏移 4 的位置。short s要求 2 字节对齐放在偏移 8 处没问题。整个结构体的大小必须是最大成员对齐数的整数倍这里是 4所以结尾还要填充 2 字节凑成 12。如果成员排列顺序优化一下struct Test2 { char c; short s; int i; };这样是 1c 1填充 2s 4i 8 字节省了 4 字节。所以结构体成员顺序从大到小排往往能省内存。我在做嵌入式开发时结构体经常要发到网络上内部有几百个成员如果不管对齐规则结构体体积可能膨胀三分之一直接影响网络传输效率。有时还会遇到跨平台问题不同编译器、不同架构对齐规则不完全一样导致二进制无法互通。这时可以用#pragma pack(1)或__attribute__((packed))强制紧凑排列但代价是运行效率变低只能在明确需要的场景下用。5.3 字符串转数字本质是处理一串字节再来说“字符串转数字”这个热搜词。很多人一听到“字符转数字”第一反应是parseInt、atoi这种函数。但底层到底发生了什么在内存里字符串123其实是一串字节ASCII 码是0x31字符1、0x32字符2、0x33字符3。要把它们转成一个整数 123程序是这样做的int my_atoi(const char *str) { int result 0; while (*str 0 *str 9) { result result * 10 (*str - 0); str; } return result; }这里*str - 0就是把单个字符的 ASCII 码减去0x30得到 0 到 9 的数字。然后不断乘 10 累加。这是典型的“字符串转数字”实现原理看起来简单但涉及的一个重要思想就是字符在计算机中就是字节数字也是字节序列操作它们本质上都是操作位和字节。在处理 UTF-8 编码时这个问题更值得注意。UTF-8 是一种变长的字节编码英文字母和数字占 1 字节很多欧洲文字占 2 字节中文汉字通常占 3 字节甚至部分生僻字和 emoji 占 4 字节。所以一个“字”在不同编码方案下占的字节数完全不同。比如汉字“中”在 UTF-8 里是 3 个字节E4 B8 AD在 GBK 里是 2 个字节D6 D0所以“UTF 编码不一样字一样”的热搜词说的就是这种现象字符相同但在不同编码规则下底层字节序列完全不同。如果你把一个 UTF-8 字符串按 GBK 去解析就会出现乱码。我之前写一个日志清洗程序时就是没注意源文件是 GBK 编码结果中文全部变成“锟斤拷”查了半天才发现是编码声明的问题。5.4 实操用一个工具把字节看个明白说了这么多最好还是自己动手看一眼。Windows 上可以用 HxDLinux 上用xxd或hexdumpmacOS 上可以用xxd。比如写一个文本文件里面只有三个字符“AB中”然后在 Linux 终端执行echo -n AB中 test.txt xxd test.txt假设终端使用 UTF-8 编码输出会是00000000: 41 42 e4 b8 ad AB...41是 A42是 B后面跟着的三个字节e4 b8 ad就是“中”的 UTF-8 编码。你一眼就能看出这个文件一共 5 个字节A 和 B 各占 1 字节中文占 3 字节。如果在 Windows 记事本里用 ANSIGBK保存同样的内容再用xxd看中字会变成 2 字节d6 d0文件总大小就变成 4 字节。这就是为什么同一个字在不同编码下文件大小不一样的直观证据。6. 常见问题速查与避坑清单6.1 一张表看清常见单位换算题我把平时答疑时最常遇到的几个换算问题做成表格问题答案关键点1 byte 等于多少 bit8 bit大写 B 是字节小写 b 是位1 KB 等于多少字节1024严格 1 KiB十进制下 1 KB 10001 字等于多少字节取决于 CPU 字长64 位系统 8 字节32 位系统 4 字节一个汉字在 UTF-8 占多少字节通常 3 字节GBK 中占 2 字节100Mbps 宽带理论下载速度12.5MB/s比特转字节要除以 8为什么 500G 硬盘系统显示 465G进制不同厂商用 1000系统用 1024这几道题基本覆盖了日常碰到的 80% 的困惑。你只要抓住bit 是最小单位byte 是存储基本单位word 看 CPUKB 以上有十进制和二进制两套标准就能应付绝大多数场景。6.2 我踩过的几个字节相关的坑第一个坑是sizeof和strlen混用。sizeof是编译期计算出的类型或变量占用的字节数strlen是运行期数到\0为止的字符个数。对char buf[] hello来说sizeof(buf)是 6包括结尾的\0strlen(buf)是 5。在分配缓冲区和复制内存时用错这两个函数轻则浪费空间重则缓冲区溢出。第二个坑是网络字节序转换。我以前接手过一个跨平台通信模块发送端是小端机器接收端也是小端机器中间经过一个网关后某天突然所有整数都变成了乱序。排查半天发现网关其实是按大端解析的需要手动做字节序转换。从那以后我只要写二进制协议一定会在文档里明确标注“所有多字节字段一律采用网络字节序大端”。第三个坑是位宽陷阱。在 32 位系统上long是 4 字节在 64 位 Linux 上long是 8 字节但在 64 位 Windows 上long仍然是 4 字节。这种跨平台差异只有实际编译运行才会暴露。所以我建议在涉及文件格式、协议时尽量用int32_t、uint64_t这类固定宽度类型而不是int、long这种“自然类型”。6.3 个人建议怎么把这些概念记牢如果你还在学习阶段我推荐一个很笨但很有效的方法写一个小的二进制查看器或者直接用xxd多看看各类文件的十六进制内容。看多了之后你会形成一个直觉一切文件不管是文本、图片还是可执行程序在底层都是一串字节而这些字节之所以有“意义”是因为我们人为规定了编码规则和解析方式。把“字节是存储世界的原子bit 是信息世界的原子”这句话记在脑子里后面遇到带宽计算、结构体大小、编码转换、协议解析你都会比旁人更快反应过来。很多看起来玄乎的问题拆到底无非就是几个字节在那排列组合而已。