MiB 转吉字节（GB）

使用方法

把二进制前缀与十进制前缀对齐，最容易出错的不是算术而是选错单位。本页默认摆好 1024 MiB 换 GB 的样本，改任一输入框都会立刻重算；下拉框里带 i 的是 IEC 二进制前缀（KiB、MiB、GiB、TiB），不带 i 的是 SI 十进制前缀（kB、MB、GB、TB），先认清这一层再填数。

1. 「数值」框只收数字，默认 1024。填好后单按 Enter（不叠 Ctrl、Cmd、Shift）就出结果，点击按钮反而多余。
2. 源与目标在「从」「换算为」两个下拉里各选一个，字节、kB、MB、GB、TB 与 KiB、MiB、GiB、TiB 共九项任意两两可换；要反查就把 GB 选成源、MiB 选成目标，仍走同一套系数表。
3. 「结果小数位」给到 9 是特意为 1.073741824 这类九位系数准备的，0 到 10 之间可调；它只管显示位数，脚本内部始终按完整双精度算完再舍入。
4. 「交换单位」一键对调两个下拉并立即复核反向结果；「复制结果」把当前等式送进剪贴板；「载入示例」连同批量框一起还原成出厂样本。
5. 多行文本框是给一批容量值用的：每行一个，按 Ctrl/Cmd + Enter 一次算完；哪行不合法会点名行号与原文说明跳过，绝不补成零。

下面的速查表先露 12 行，「加载更多」展开到 16 行；带 BOM 的 CSV 与 TSV 复制都取自同一份数组。结果区带 role="alert"，读屏软件会朗读换算值。

能解决什么

第一类是看懂硬盘标称容量与系统报数的落差。磁盘厂商按十进制标容量，1 TB 就是 10 的 12 次方字节；操作系统按二进制报可用空间，把同一批字节数除以 2 的 30 次方，得到的是 931.322575 GiB。很多人第一眼以为硬盘缩水了，其实两边都没算错，只是用了不同的前缀体系，本页把这条除法摊开给你看。

第二类是核对内存、文件与流量报表的口径。把 1 GiB 直接当成 1 GB 会高估 7.3741824%，在批量采购、云盘配额、日志体积核算里，这个比例会随量级放大成可观的偏差。用本页把 GiB 换成 GB、把 MiB 换成 MB，报表就能对齐到同一把尺子上。

第三类是写文档时选对单位符号。不少人搜索「MiB转吉字节」，真正想问的是「我看到的这个数到底是二进制还是十进制」。结论是别看「兆」这个汉字，只看单位符号有没有那个 i；带 i 的按 2 的幂，不带的按 10 的幂。

凡是能靠一套字节基准系数解决的问题，都在这里收敛成同一条公式。

原理和变量

两套前缀的定义完全不同。IEC 60027-2 定义的二进制前缀以 2 的幂为底：1 KiB = 2 的 10 次方 = 1024 字节，1 MiB = 2 的 20 次方 = 1048576 字节，1 GiB = 2 的 30 次方 = 1073741824 字节，1 TiB = 2 的 40 次方。而 SI 十进制前缀以 10 的幂为底：1 kB = 1000 字节，1 MB = 10 的 6 次方，1 GB = 10 的 9 次方，1 TB = 10 的 12 次方。两者名字里都带「G」或「M」，系数却不是同一套，这正是 MiB 转 GB 属于跨体系换算、而不是同体系里除以 1024 的原因。

系数怎么来。把字节定为基准，给每个单位记一个系数 F：字节 F = 1，MiB F = 1048576，GB F = 1000000000。换算时先把输入值换成基准量，再除以目标单位的系数，即 out = v × F[from] / F[to]。选 MiB 转 GB 时乘 1048576 再除 10 的 9 次方，得到 0.001048576；选 GB 转 MiB 时取倒数，即 953.67431640625。页面脚本里没有把这两个长小数写成魔法数字，而是把九个单位各自的字节系数存成一张表，任何人都能顺着代码回溯到 2 的幂与 10 的幂的定义。

1 GiB 与 1 GB 的差。1 GiB = 1073741824 字节，换成十进制就是 1073741824 / 1000000000 = 1.073741824 GB，比 1 GB 多出 7.3741824%。这个百分比不是测量误差，而是两个定义之比减 1 的必然结果，量级越大差得越多，到 TiB 与 TB 这一档会更明显。

1 TB 硬盘为什么是 931.322575 GiB。厂商说的 1 TB 是 1000000000000 字节，操作系统以 GiB 为单位报数，于是 1000000000000 / 1073741824 = 931.322575 GiB。本页把 TB 与 GiB 都放进同一张系数表，这条结果由公式现场算出，不是额外背下来的常数，也不会在切换方向时忽然换一套算法。

那个字母 i 的来历。KiB、MiB、GiB 里的 i 来自 kibi、mebi、gibi，是 binary 与 kilo、mega、giga 缩合出来的专名，专门用来消除「千、兆、吉」到底指 1000 还是 1024 的歧义。内存条、文件大小、网络流量常用不同口径，读数值时先看单位符号而不是看汉字，才不会把两套体系混用。

完整示例

默认样本是 1024 MiB，页面加载时结果区直接给出 1024 MiB = 1.073741824 GB。它不是预先写死的一句话：脚本把 1024 乘 0.001048576 得到 1.073741824，再按 9 位小数显示。你把数值改成别的数、交换两个下拉框，或把小数位调小，这条等式会立刻被重新算出来。

• 正向：1、10、100、512、1024、1000000 MiB 分别得到 0.001048576、0.010485760、0.104857600、0.536870912、1.073741824、1048.576 GB，正好覆盖从单字节量级到百万量级的校验点。
• 反向：1 GB 换回 953.674316406 MiB，10 GB 换回 9536.743164063 MiB，1024 GB 换回 976562.5 MiB。把 953.674316406 再换回 GB 得到 1，误差只在显示位数上。
• 跨体系：1 GiB = 1.073741824 GB，1 TB = 931.322575 GiB，1 MiB = 1.048576 MB。这些结果同样出自同一张系数表，不需要为「二进制转十进制」另写一条分支。

批量框默认填了六行示例，按 Ctrl/Cmd + Enter 一次列出结果；某行非法时会点名那一行并说明跳过，不会输出一个莫名其妙的零。

对照表

速查表把正向、反向和跨体系三类换算排在一起，共 16 行，默认只显示前 12 行，点「加载更多」展开剩余 4 行。表格每一行都由脚本用同一条 out = v × F[from] / F[to] 现场算出：输入值取自上面那组示例，结果列算完再按当前小数位格式化，改小数位后整张表跟着变，不会出现两套数字。备注只标换算方向，不含数值；导出与复制都取自同一份数组，不会漏掉屏幕上未展开的行。

更能说明问题的是把两套前缀并排放。下表左列是二进制前缀及其字节数，右列是同名字头的十进制前缀及其字节数，两者只差一个字母 i，系数却逐档拉开：

可以看到 GiB 档比 GB 档多出 7.3741824%，正是这个差距让报表在 GB 量级必须分清体系。表中的字节数都是定义值，页面换算用的也是同一张系数表，二者不会出现两套数字。

结果边界与舍入

• 输入范围：数值框允许负一万亿到正一万亿，超出会给出具体越界提示并停止换算，不会截断成一个相近的大数。容量通常取非负，负数在数学上仍可换算，本页照实计算并保留符号。
• 零值：0 是合法输入，结果为 0，不会被当成非法值补零。
• 舍入：显示用固定小数位，默认 9 位，按四舍五入处理；内部始终用完整双精度浮点数计算，先算完再格式化，不会把中间结果提前截断。把小数位调到 0 会看到整数结果，调回 9 又恢复，数值本身没变。
• 浮点尾差：十进制系数在二进制里无法精确表示，且 2 的幂与 10 的幂之比本身是无限小数，反算回原值末位可能差一个最小单位；严格对齐时以字节定义式为准，别拿显示的九位小数反推。
• 量级显示：超大或超小的结果自动改用科学计数法，日常量级仍用带千分位的写法。
• 不联网：所有换算、批量处理、表格生成与复制都在当前浏览器内完成，页面不发请求、不写 Cookie，也不把数值存进本地存储。

常见问题

相关工具

下面三个工具都与整理数值和文案有关，按需取用，内链均为站内已上线页面。

• 随机数生成器：批量造一组测试数值，直接粘进本页的批量换算框，验证各量级是否稳定。
• Base64编码：数据编码后体积会变化，可用本页把编码前后的字节数统一成同一套前缀再比较。
• 字数统计工具：把容量核算写成说明或报告之前，用它核对文案篇幅与中英混排字数。