进制转换实战：二进制、八进制、十进制、十六进制手算与工程应用

前几天调一个界面配色，设计稿上写着#3A7BD5，我顺手把它丢进代码里当色值用。旁边一位刚入行的同事问了一句：“这个 D5 到底是多大？”我愣了一下才反应过来，他问的不是颜色，而是这个十六进制字符串背后代表的那个 0 到 255 的数值。这个问题看着幼稚，其实很关键——很多人天天在写0xFF、0o755、#RRGGBB，却从没认真想过这些符号和十进制数字之间到底是什么换算关系，一旦遇到权限配置、子网掩码、串口抓包、协议文档，就立刻卡壳。

二进制、八进制、十进制、十六进制这四个东西，本质上描述的是同一批数字，只是“分组方式”不一样。十进制是给人看的，二进制是给电路看的，八进制和十六进制是给工程师偷懒用的中间层。这篇内容适合两类人：一类是刚学编程、被0x和0o前缀搞晕的新手；另一类是写了几年代码、但转换全靠计算器、遇到需要手算的场合心里发虚的老手。我会把概念、位权、手算路径、代码里的写法、真实场景中的混用，以及我自己踩过的几个坑完整拆一遍，看完之后你应该能做到不借助工具也能在四个进制之间来回倒。

1. 进制这件事的底层其实只有三个词：基数、数码、位权

很多人学进制是死记“逢二进一、逢八进一”，背完就忘。真正要抓住的只有三样东西，理解了这三样，四个进制就没有任何神秘感。我习惯用“打包”来类比：十进制是十个一打包，二进制是两个一打包，八进制是八个一打包，十六进制是十六个一打包。打包的容量就是基数，能被塞进一个包里的符号就是数码，每个包所在的位置值多少钱就是位权。

1.1 基数决定了你需要几个符号，也决定了进位的时机

基数说白了就是“数到几就进位”。十进制基数 10，所以你只需要 0 到 9 这十个符号；数到 9 再加一，这一位装不下了，就得往前进一位，本位归零。二进制基数 2，符号只有 0 和 1，数到 1 再加一就必须进位，所以二进制的世界极其单调，但单调恰恰是它适合硬件的原因——一根线上只有“有电”和“没电”两种状态，判别起来最不容易出错。

八进制基数 8，理论上需要 0 到 7 八个符号；十六进制基数 16，超过了我们手头十个数码的数量，所以只能借字母来凑：A 到 F 分别代表 10 到 15。这里有个细节很多人没想过：为什么十六进制借的是 A~F 而不是别的？因为这是约定俗成的历史选择，大小写都能用，但在代码里通常统一成大写或者统一成小写，混着写虽然多数解析器能认，可读性会很差。我个人习惯在文档和注释里用大写0xFF，在输出的十六进制字符串（比如哈希值）里用标准的小写，因为那些场景下小写是通行惯例。

这里还要提醒一句：数码的取值范围永远是 0 到基数减一。你在八进制里看到数字 9，那这个数一定是错的；在二进制里看到 2，同样说明哪里搞混了。这个判断法则在排查配置文件、日志、报文的时候非常好用，一眼就能看出某段数据到底被当成了几进制。

1.2 位权是每个位置的“身价”，小数点的位置同样由基数决定

位权是这套体系里最容易被忽略、但最值钱的概念。一个数字写在不同的位置上，代表的大小完全不同。十进制里从右往左依次是 10⁰、10¹、10²……；二进制里就是 2⁰、2¹、2²……；八进制是 8 的幂，十六进制是 16 的幂。小数点左边第一位永远是基数的 0 次方，也就是 1，往左每移一位乘一次基数，往右每移一位除一次基数。这条规则对四个进制完全通用。

举个具体的：二进制1011，从右往左拆开是 1×2⁰ + 1×2¹ + 0×2² + 1×2³ = 1 + 2 + 0 + 8 = 11。十六进制2F就是 15×16⁰ + 2×16¹ = 15 + 32 = 47。八进制755就是 5×8⁰ + 5×8¹ + 7×8² = 5 + 40 + 448 = 493。你会发现这套位权展开法不需要任何技巧，只要老老实实乘加，任何进制转十进制都能一步到位，而且不会出错。这也是我建议所有人在转换时保留的“兜底方法”——其他技巧忘了都不要紧，位权展开永远管用。

小数部分同理。二进制0.101展开是 1×2⁻¹ + 0×2⁻² + 1×2⁻³ = 0.5 + 0 + 0.125 = 0.625。这里要特别注意：十进制能精确表示的小数，二进制未必能精确表示。0.1 在二进制里是无限循环小数，这就是为什么浮点数做加法会出现0.1 + 0.2 = 0.30000000000000004这种结果。这个问题跟进制转换直接相关，后面讲坑的时候还会展开。

1.3 四个进制的分工是怎么形成的：为什么偏偏是 2、8、10、16

有人会问，为什么没有三进制、五进制？其实历史上真的有过别的进制，比如某些文明用过十二进制、六十进制（我们现在的角度和时间划分就是六十进制的遗留）。计算机领域最后锁定这四个，是因为它们之间存在整数幂关系：8 = 2³，16 = 2⁴。这个关系是全部便利的来源，也是后面“分组转换法”能成立的根本原因。

具体说，一个八进制位恰好对应三个二进制位，一个十六进制位恰好对应四个二进制位。因为二进制写起来太长太容易看花眼——一个 32 位整数要写 32 个 0 和 1——工程师就发明了这种“压缩表示”。八进制在早期计算机（字长是 3 的倍数，比如 12 位、24 位）时代很流行，后来 8 位字节成为标准，一个字节正好 8 位，能被两个十六进制位完整覆盖，十六进制就取代八进制成了主流。现在你在内存地址、颜色值、哈希、字节流里看到的几乎全是十六进制，八进制基本只剩下文件权限和少数语言的整数字面量还在用。

十进制则始终是人和机器之间的接口层。人输入的是十进制，输出给人看的也是十进制，中间的存储和传输用二进制。所以真正的转换压力其实集中在“十进制 ↔ 二进制”这条主线上，八进制和十六进制只是这条主线的快捷方式。

2. 十进制往外转：短除法为什么总是从最低位开始吐余数

从其他进制转十进制用位权展开，这个方向很顺。反过来，从十进制转其他进制，最常见的做法是“除基取余，逆序排列”，也就是短除法。很多人会用这个方法但说不清原理，一旦遇到需要判断“我算的余数顺序对不对”的场合就没有把握。我拆一遍它的内在逻辑。

2.1 余数天生就是最低位，这是短除法不用倒着想的根本原因

把十进制数 N 转成 base 进制，第一步做的是 N ÷ base，得到商 q 和余数 r。写成等式就是 N = q × base + r。你盯着这个式子看：q × base 这一项必然是 base 的整数倍，也就是说它在 base 进制下的最低位一定是 0，所有“不满一个包”的部分全部落到了 r 身上。所以r 就是转换结果的最后一位，没有任何疑问。

接下来把 q 再除以 base，得到 q = q₂ × base + r₂，那么 r₂ 就是倒数第二位。如此循环，直到商变成 0，说明所有位都吐完了，把余数从后往前读就是结果。这就是为什么短除法必须逆序读余数——因为第一个吐出来的余数是最低位，最后一个吐出来的才是最高位。

拿 45 转二进制走一遍：45 ÷ 2 = 22 余 1（最低位）；22 ÷ 2 = 11 余 0；11 ÷ 2 = 5 余 1；5 ÷ 2 = 2 余 1；2 ÷ 2 = 1 余 0；1 ÷ 2 = 0 余 1（最高位）。余数从下往上读是101101。验证一下：32 + 8 + 4 + 1 = 45，对上了。这个过程我建议你至少手算二十遍不同大小的数，形成肌肉记忆之后，看到 45 这种量级的数几乎能直接对着位权表拼出来，根本不用列竖式。

同理，45 转八进制：45 ÷ 8 = 5 余 5；5 ÷ 8 = 0 余 5，结果55，验证 5×8 + 5 = 45。45 转十六进制：45 ÷ 16 = 2 余 13（D）；2 ÷ 16 = 0 余 2，结果2D，验证 2×16 + 13 = 45。你会发现同一个数转不同进制，短除法的骨架完全一样，只是除数变了，所以真正需要记的只有一件事：除数等于目标基数。

2.2 二进制转八进制和十六进制根本不用算，靠分组就行

这是四个进制之间最省力的一条路径，也是我最常用的方式：先把数转成二进制，然后按 3 位一组（转八进制）或 4 位一组（转十六进制）切开，每组独立翻译成一个数码。因为 8 = 2³、16 = 2⁴，这种切分绝不会错位。

分组必须从右往左切，最左边一组不够位数时在左侧补零。这条规则是排错时的高频考点。比如二进制11010111；转八进制，从右往左每 3 位切：11010111→11|010|111，最左边的11不足三位，补成011，于是变成011|010|111，翻译成 3、2、7，结果327。如果反过来从左往右切，就会切出完全错误的答案。

转十六进制就每 4 位切：11010111→1101|0111，翻译成 D 和 7，结果D7。验证一下，D7= 13×16 + 7 = 215，二进制 11010111 = 128 + 64 + 16 + 4 + 2 + 1 = 215，吻合。反方向转换更简单：十六进制每一位直接展开成固定的 4 位二进制，D展开成1101，7展开成0111，拼起来即可。八进制每一位展开成 3 位。

这里有一张表我建议直接背下来，背熟之后十六进制和二进制之间的转换基本不需要思考：

这张表还有个隐藏用法：看到 8、4、2、1 这四个数要敏感，它们分别是 4 位二进制里各位置的位权。任何 0 到 15 的数，都能用 8、4、2、1 里的几个加起来表示，能加上的位置写 1，加不上写 0，四位立刻出来。比如 11 = 8 + 2 + 1，就是1011。这个方法比背表更灵活，遇到记不清的数码现推也来得及。

2.3 小数转换方向相反：乘基数取整数部分，正着读

整数部分是除，小数部分是乘，很多人搞混就是因为没想清楚方向。小数转其他进制的做法是：小数部分乘以基数，取乘积的整数部分作为当前位，剩下的小数部分继续乘，直到小数部分为 0 或者达到所需精度，结果按生成的顺序正着读。

拿 0.625 转二进制：0.625 × 2 = 1.25，取整 1，剩 0.25；0.25 × 2 = 0.5，取整 0，剩 0.5；0.5 × 2 = 1.0，取整 1，剩 0，结束。结果是0.101。转八进制：0.625 × 8 = 5.0，取整 5，直接结束，结果是0.5，验证 5/8 = 0.625。转十六进制：0.625 × 16 = 10.0，取整 A，结果0.A，验证 10/16 = 0.625。

要提醒的是，很多十进制小数在二进制下是无限循环的，永远乘不到 0。比如 0.1 转二进制会得到0.0001100110011...无限循环。所以实际编程里做小数进制转换，必须设定一个精度上限（比如保留 10 位），否则就是死循环。这也是浮点数精度问题的数学根源，跟语言实现无关，换任何语言都一样。

3. 三个真实场景：颜色、权限、网络地址里的进制混用

光会算没用，得知道这些东西在哪儿出现。我挑了三个最常见、也最容易出错的场景，这三个场景基本覆盖了日常开发中 80% 的进制使用需求。

3.1 颜色值 #RRGGBB：十六进制在视觉领域的标准打法

网页和设计工具里的颜色几乎都是#RRGGBB格式，本质是三个 0 到 255 的字节，每个字节用两位十六进制表示。为什么用十六进制？因为一个字节正好 8 位，两位十六进制正好 8 位，长度刚好，不用补零也不用截断，换算也最直接。

拿#3A7BD5举例拆解：3A= 3×16 + 10 = 58，是红色分量；7B= 7×16 + 11 = 123，是绿色分量；D5= 13×16 + 5 = 213，是蓝色分量。所以这个颜色在十进制 RGB 里就是rgb(58, 123, 213)。反过来，给我rgb(58, 123, 213)，我先把 58 拆成 3×16 + 10 =3A，123 拆成 7×16 + 11 =7B，213 拆成 13×16 + 5 =D5，拼起来就是#3A7BD5。这个拆法练熟之后，改色值完全不需要打开工具。

这里有个高频坑：缩写形式#3AD其实是#33AADD，每一位重复一次，不是补零。我见过有人把#3AD当成#03AD00处理，颜色直接跑偏。另外带 alpha 通道的#RRGGBBAA是四位一组，最后两位是透明度，别把八位色值的前六位当完整颜色后两位忽略掉，那样透明度就丢了。

3.2 文件权限 755：八进制在权限体系里为什么还没被淘汰

Linux 系的文件权限是九位二进制，分三组，每组三位，分别对应读、写、执行。读的位权是 4，写是 2，执行是 1，所以rwx= 4+2+1 = 7，r-x= 4+0+1 = 5，rw-= 4+2+0 = 6。三组拼起来正好是三个八进制数字，这就是八进制在这里活下来的原因——三位二进制刚好对应一个八进制位，用十进制表示会丢失分组信息，用二进制又太长。

常见的755拆开是：所有者7= rwx（读写执行全有），所属组5= r-x（读和执行，没有写），其他人5= r-x。644拆开是6= rw-（读写无执行），4= r--，4= r--，这是普通文件的默认配置。600是只有自己能读写，私钥文件通常就是这个。

我在实际项目里踩过的坑是：给目录设了 644，结果进不去。目录的“执行”位含义和文件不同，目录的执行位代表“能否进入/遍历”，所以目录至少要755，光有读权限是列不出内容的。另一个坑是脚本设成644之后直接执行会报权限不足，必须chmod +x补上执行位。这些坑的共同点是：都在八进制上算对了，但对位的语义理解错了。所以我一直强调，进制转换本身不难，难的是知道每一位代表什么。

3.3 IP 地址与子网掩码：二进制视角才是理解网络的入口

192.168.1.1这种写法叫点分十进制，每一段都是一个字节，范围 0 到 255。看起来很十进制，但真正做子网划分、判断两个地址是否同网段的时候，必须切到二进制视角，因为掩码的按位与运算只对二进制有意义。

把192.168.1.1展开：192 =11000000，168 =10101000，1 =00000001，1 =00000001。子网掩码/24对应255.255.255.0，二进制是 24 个 1 后面跟 8 个 0。要判断两台机器是否在同一网段，就把 IP 和掩码做按位与，比较结果是否相同。这个过程在手算时会大量用到十进制转二进制，所以前面说的位权表和 8/4/2/1 拆分法在这里极其好用——192 拆成 128+64 =11000000，两步就出来了。

/26这类掩码更考验基本功：26 个 1 加上 6 个 0，第四段是11111100，也就是 252。所以/26的掩码是255.255.255.192。这个 192 不是随便来的，是因为 8 位里前两位是 1，其余是 0，正好 128+64。我在配网络的时候习惯把这个推导过程在心里过一遍，比查表更可靠，因为一旦配错一个掩码，整个网段的地址范围都会错。

4. 代码里的四个进制：字面量写法、解析函数和格式化输出

纸上算明白只是第一步，落到代码里还有一堆细节。不同语言对进制的支持方式有差异，前缀、函数名、默认行为都不一样，跨语言切换的时候特别容易栽跟头。

4.1 各语言的字面量前缀对照，八进制是最不统一的一个

二进制和十六进制的前缀基本统一，二进制是0b，十六进制是0x，这两个跨语言几乎没有分歧。八进制是重灾区，C 系语言（C、C++、Java）用前导0，Python 2 也用前导0但 Python 3 改成了0o，JavaScript 的严格模式要求写0o而不是前导零。

这张表最该记住的是那一行 C/Java：013不是十三，是十一。我在接手别人代码的时候见过因为int x = 010;导致计算结果差 2 的事故，排查了半天才发现是把十进制 10 写成了八进制写法的 10。这种错误编译器不会报，运行时也不崩，就是结果悄悄错掉，属于最难查的一类问题。

4.2 解析函数必须显式给基数，这是踩过最多次的坑

JavaScript 的parseInt是全场景里最危险的一个。它的第二个参数是基数，不传的时候会做推断：字符串以0x开头按十六进制解析，其余按十进制解析。早期引擎还会把前导零的字符串按八进制处理，虽然现在的规范已经从十进制处理，但历史包袱导致行为在不同环境里不一致。

parseInt("10"); // 10，按十进制 parseInt("10", 2); // 2，按二进制 parseInt("0x1F"); // 31，自动识别十六进制 parseInt("08"); // 8，现代引擎按十进制，老引擎可能返回 0 parseInt("z", 36); // 35，基数最大到 36

我的做法是永远传第二个参数，没有例外。多打三个字符，省掉一整类排查成本。Python 的int()更严格，第二个参数默认是 10，但只要传了基数，字符串里就不能带前缀，int("0x1F", 16)会直接抛异常，需要写成int("1F", 16)或者用int("0x1F", 0)让它自己识别。这个差异我第一次遇到的时候也懵了一下。

int("1F", 16) # 31 int("0x1F", 16) # ValueError，带前缀不行 int("0x1F", 0) # 31，基数为 0 表示自动识别前缀 int("1011", 2) # 11 int("755", 8) # 493

Java 那边没有这个歧义，但要注意Integer.parseInt默认十进制，转其他进制得用Integer.parseInt("1F", 16)，且不接受前缀。这些细节看着琐碎，但真正卡住你的时候，往往就是这种“以为它认识前缀”的假设。

4.3 反向输出：格式化与补零对齐

把数值输出成其他进制字符串，各家都有现成的函数，但补零对齐这件事得自己做。#3A7BD5里的3A如果算出来是 5，直接拼上去就变成35，颜色完全错了，必须补成05。

// JavaScript (255).toString(16) // "ff"，小写 (255).toString(16).toUpperCase() // "FF" (255).toString(16).padStart(2, "0") // "ff"，补零

# Python hex(255) # '0xff'，自带前缀 format(255, 'x') # 'ff' format(255, '02x') # 'ff'，宽度 2 补零 format(255, '04x') # '00ff' f"{255:08b}" # '11111111'，二进制补足 8 位

f"{n:08b}"这个写法在打印字节、看位标志的时候特别好用，8 位对齐之后哪一位是 1 一目了然。我调试位掩码的时候几乎全靠它，比一个个算位权快得多。

5. 那些年踩过的进制坑：补码、前导零、精度和大数

前面零散提了几个坑，这里集中说几个最容易出事、而且出事之后最难定位的。这些问题的共同特征是：语法合法、运行不报错、结果就是不对。

5.1 负数的十六进制形态为什么是一长串 F

很多人第一次看到-1输出成0xFFFFFFFF或者ffffffff都会觉得莫名其妙。这背后是补码表示法：计算机里没有“负号”这个符号位，负数用“取反加一”的方式表示。以 32 位为例，-1 的绝对值是 1，二进制00000000000000000000000000000001，取反得全 1，加一之后进位溢出，最终还是全 1，所以就是FFFFFFFF。

这个特性带来的直接影响是：十六进制字符串本身不携带符号信息。0xFFFFFFFF按无符号理解是 4294967295，按有符号理解是 -1，取决于你怎么读。所以跨系统传数据的时候，必须约定好是有符号还是无符号，否则同一个字节序列在两端解析出来的数能差出几十亿。我在做协议对接的时候吃过这个亏，发过去的是一个 32 位有符号数，对端按无符号解析，一个小负数变成了一个巨大的正数，排查了两天才锁定。

// Java 里这个现象最直观 Integer.toHexString(-1) // "ffffffff" Integer.toHexString(255) // "ff"

5.2 前导零、精度陷阱和超出安全范围的整数

前导零的问题前面提过，013是八进制。这里补一个变体：从 CSV 或配置里读进来的一串数字，如果带着前导零，某些解析路径会把它当八进制。手机号、编号、邮编这类“看起来是数字但实际是字符串”的数据，最佳实践是一律按字符串处理，不要转成整数，转了不但可能丢前导零，还可能丢精度。

精度问题跟进制直接相关。JavaScript 的 Number 是双精度浮点，安全整数范围是 2⁵³ - 1，也就是 9007199254740991。超过这个范围，整数的加减就会开始出偏差，因为二进制尾数位不够了。这时候要么用 BigInt，要么把长整型当字符串传。

9007199254740991 + 1 === 9007199254740992 // true 9007199254740992 + 1 === 9007199254740993 // false，已经表示不出奇数了

还有一个隐蔽的点：JavaScript 的位运算（&、|、<<）只对 32 位有符号整数生效，超过 32 位的部分会被截断。你拿它处理大整数或者哈希，结果会静默出错。这个坑我在处理颜色 alpha 混合的时候遇到过，值本身不大所以没出问题，但如果扩展到 64 位掩码，就一定会崩。

5.3 手算时的三类失误，以及我自己的交叉验证习惯

手算阶段最常见的失误有三个：一是分组方向搞反（应该从右往左），二是最左组补零时补在了右边，三是小数部分读数方向搞反（应该正着读）。这三个错误我都犯过，而且当时都觉得自己算得挺对。

后来我给自己定了个规矩：任何手算结果，用另一条路径验一遍。比如十进制转十六进制用短除法算完，再把结果用位权展开算回十进制，看是否等于原数；二进制转八进制用三位分组算完，再转成十六进制看是否和直接四位分组的结果一致。多花的这十几秒，能挡掉绝大部分低级错误。这个习惯在配权限、算子网的时候尤其值得保留，因为那些场景出错代价很高。

6. 把转换练成条件反射：几张表和几条速算路径

最后分享一些实操层面的提速方法。这些不是理论，纯粹是我自己用下来觉得最省力的一套组合。

6.1 二进制位权表和十六进制对照表是唯一值得背的东西

背这两张表花的十分钟，能省掉后面几年的换算时间。位权表就是 1、2、4、8、16、32、64、128、256、512、1024……一直到 2¹⁰ 甚至 2¹⁶，记住之后任何 16 位以内的二进制转十进制都能口算。十六进制对照表就是前面那张 0 到 F 的四位二进制映射。

这两张表结合起来用，效果是：十六进制转二进制直接按位展开，二进制转十六进制按四位回查，二进制转十进制用位权表相加，十进制转十六进制先除或者先转二进制再分组。四个方向全通，而且每一步都能在脑子里完成，不需要纸笔。

实操中的一个加速技巧是“就近取整”：转 200 这种数，先找不超过它的最大位权 128，剩 72；再找 64，剩 8；直接 8。所以是11001000。这个思路比竖式除法快得多，熟练之后一个字节的转换两秒就够了。

6.2 遇到大数就交给程序，但要用两种方式互验

手算适合单字节、双字节这种量级。真遇到 64 位的大数，别硬撑，直接交给代码。但交出去之后也别全信，我的习惯是用两种不同的写法算一遍对比结果。

n = 123456789 print(bin(n), oct(n), hex(n)) # 内置函数 print(format(n, 'b'), format(n, 'o'), format(n, 'x')) # 格式化 print(int(hex(n), 16) == n) # 回环验证，应该是 True

回环验证这一步是我最推荐的。只要你把结果转回原进制，能对上原数，那这次转换基本就是对的。这个做法成本极低，但能挡住绝大多数手误和环境差异导致的问题。

6.3 一个我常用来练手的笨办法

如果你想让转换能力真正变成本能，我给一个很土但有效的办法：每天上下班路上，随手挑三个 0 到 255 之间的数，在心里做四个进制互转，然后回家用代码验一遍。连续做两周，一个字节范围内的转换基本就不需要思考了。这个范围选得有讲究，因为 0 到 255 正好覆盖一个字节，而实际工作里绝大多数进制转换都发生在字节级别——颜色、权限、报文、掩码，全都在这范围内。

超过 255 的数再往上走，规律是一样的，只是位数变多，思路不用改。真正需要重新思考的只有大数精度和符号问题，那些属于语言实现的层面，跟进制概念本身无关。

我个人在带人的时候发现，卡在进制上的往往不是不会算，而是没意识到“同一个数可以有多种写法”这件事会渗透到这么多地方。一旦你开始在看日志、读配置、调颜色的时候下意识地去想“这串数字是什么进制、每一位代表什么”，转换能力自然就上来了。工具该用就用，但心里那本账得自己会算。