ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

从bit到TB:网速与硬盘容量为何总对不上?一文搞懂单位换算

从bit到TB:网速与硬盘容量为何总对不上?一文搞懂单位换算 你有没有遇到过这种情况刚办了 1000M 宽带结果测速软件里死活只显示 120MB/s新买一块 1TB 移动硬盘插上电脑却只剩 931GB把标称 64GB 的存储卡塞进行车记录仪格式化完发现可用空间只有 58GB。每次都觉得容量被人“偷走”了但真要解释又说不清楚到底差在哪。其实这些看似玄学的现象背后就是同一套从 bit 到 TB 的单位换算规则在起作用。我虽然不是搞计量出身但在存储、网络、嵌入式和日常文件管理里折腾了十几年发现绝大多数容量纠纷和单位混淆都是因为三条线没理清bit 和 Byte 的 8 倍关系、十进制和二进制两种进位制、厂商标称和系统显示用的不是同一套口径。这篇文章我就把这整条换算链从头到尾拆开讲一遍不绕弯子直接把公式、坑点和心算技巧都给你。1. 从电子信号讲起bit 为什么是计算机的“最小筹码”1.1 0 和 1 不是数学概念而是物理状态很多人一听 bit 就觉得是二进制数字但它在硬件层面的本质其实是一组物理状态。CPU、内存、闪存芯片内部靠的是电压高低、电流通断、磁极方向或电荷有无来区分信息。比如一块 NAND 闪存单元里有没有电荷对应读出 0 还是 1DDR 内存里电容充电和放电也对应两种稳定状态。既然电路天然只有两个稳定状态那用 0 和 1 去表达就最省事这也是整个计算机体系以二进制为地基的原因。一个 bit 能表达的信息量很有限只有 0 或 1 两种取值。两个 bit 组合起来有 2 的 2 次方也就是 4 种状态三个 bit 是 8 种八个 bit 就是 2 的 8 次方256 种。这个规律往后面看特别重要因为存储容量、地址空间、字符编码全在跟“2 的 n 次方”打交道。你只要记住bit 是信息量的最小单位它不是给人看的而是给机器电路认的。顺便说一句很多做开发的朋友一开始写代码变量用 int、数组开多大很少回过头想这些数字到底占了几个 bit。可一旦做嵌入式或网络协议要面对寄存器位宽、报文头长度、数据对齐这些问题就得重新把 bit 的账一笔一笔算清楚。我曾经调试一个通信协议收发两端怎么都对不上数据最后发现是结构体里某个字段使用了位域编译器按 4 字节对齐后接收端按 1 字节去解析整个报文错位。这就是典型的不把 bit 当回事的后果。1.2 8 个 bit 凑成一个 byte背后是字符与寻址的历史有了 bit 之后计算机还得解决“怎么读写方便”的问题。如果每个 bit 单独编一个地址地址表会庞大到不可接受而且早期的字符编码也需要一个能覆盖字母、数字、符号的固定位数。ASCII 用 7 位就能覆盖 128 个字符但计算机内部按字节处理更顺手最终行业统一成 8 位一组也就是 1 Byte 等于 8 bit。Byte 中文翻译叫“字节”这名字起得很直观——它确实是计算机处理文字、图片、程序指令的“最小可寻址单位”。字节还有一个很容易忽略的特性内存地址是按字节编址的。也就是说你给一个变量分配空间地址每次挪动 1 个字节而不可能精确到某一位。日常开发里数组越界、指针偏移、文件指针跳转底层其实全都在跟字节打交道。举个例子一个 char 数组在 C 语言里占用多少字节取决于平台和字符集但基本单位永远是字节而不是 bit。这里要特别区分两个词bit 中文叫“比特”Byte 中文叫“字节”。中文语境里“位”和“字节”差 8 倍英文语境里 b 和 B 也差 8 倍。很多人写文档时顺手写“1MB1024KB”“1M1024K”都不带单位在口语里问题不大一旦进入正式规格书或者技术方案里不写明白是 bit 还是 Byte后面就会出大乱子。2. 网速与文件大小总对不上bit/Byte 的 8 倍陷阱在这里2.1 宽带的 100M 是 bps下载工具的 12.5MB/s 才是“体感速度”先回答开头那个疑问为什么办了 100M 宽带下载最快也就 10MB/s 出头运营商标称的 100M、300M、1000M单位是 Mbps也就是兆比特每秒Mbit/s。这里的 M 是 10 的 6 次方bit 是比特。而下载工具、浏览器进度条显示的 MB/s是兆字节每秒。比特换算成字节要除以 8所以理论上限是100 ÷ 8 12.5MB/s300M 宽带的理论上限就是 300 ÷ 8 37.5MB/s1000M 宽带是 125MB/s。但实际使用中几乎跑不到这个理论值。原因有几个以太网帧本身有前导码、帧间隔、IP 头和 TCP 头这些开销无线网络还会受信号衰减、信道干扰、双工模式影响运营商的接入网也可能存在峰值限速。我自己常年帮朋友测速1000M 宽带在千兆网口下实际跑到 110~118MB/s 是正常的100M 宽带稳定在 9~11MB/s 也属于健康范围。所以这里有个很实用的经验跟人解释宽带速度时与其精确除以 8不如直接按 1:10 估。也就是 100M 宽带按 10MB/s 估1000M 宽带按 100MB/s 估。这个估算值更贴近真实体感而且心算特别快——去掉一个 0 就行了。真要谈理论极限再用除以 8。2.2 大小写规则B 和 b 差 8 倍很多技术文档、商品页面、甚至软件界面里单位符号的大小写是混乱的。这里有一条硬规则大写 B 表示 Byte字节小写 b 表示 bit比特。所以1B 8b1KB 8Kb1MB 8Mb1GB 8Gb网速通常写成 Mbps 或 Gbps存储容量通常写成 MB 或 GB。如果一个设备参数写着“传输速率 150MB/s”另一个写着“接口带宽 150Mb/s”这俩差了 8 倍完全不是一个量级。尤其是在买交换机、路由器、网卡的时候很多入门用户把 Mbps 和 MB/s 混为一谈结果买回来发现局域网传文件远没有商家暗示的那么快。我个人的习惯是凡是看到单位带“ps”也就是每秒的意思先警惕这可能是比特率凡是描述存储文件大小几乎必然是字节。两者要换算时就记住一句话大写 B 是 Byte小写 b 是 bit一个大写字母差了 8 倍。2.3 视频码率推存储容量一个能直接套用的公式单位换算不只存在于宽带测速视频监控、录像存储、直播推流每天都在用。假设一个摄像头码率是 4Mbps也就是每秒产生 4 兆比特数据那它一小时会产生多少录像先把比特换算成字节4Mbps ÷ 8 0.5MB/s也就是每秒 0.5 兆字节。一个小时是 3600 秒所以0.5 × 3600 1800MB按十进制换算成 GB 是 1.8GB按二进制换算是约 1.76GiB。如果你硬盘标称容量按 1000 进制算那实际占用的就是 1.8GB。这个差别在容量规划里可以忽略但偶尔会有人卡在这里。为了减少心算负担我直接给一个衍生公式1Mbps 码率录制 1 小时约等于 0.45GB。推导过程是 1Mbps ÷ 8 × 3600 秒 450MB再除以 1000就是 0.45GB。那么 4Mbps 的摄像头一小时就是 4 × 0.45 1.8GB一天 24 小时就是 43.2GB。如果装 1TB 硬盘按这个码率能存大约 23 天。这类计算做监控方案或者规划 NAS 存储空间时特别有用。你不需要每次都打开计算器直接把码率乘以 0.45 再乘以小时数容量需求就出来了。3. 完整换算链与 1000/1024 之争KB、KiB 到底谁说了算3.1 从 bit 到 TB 的级联表与幂运算现在把整条链摆出来。从 bit 往上依次是 bit、Byte、KB、MB、GB、TB。每一级之间有两种进位法十进制进位1KB 1000B1MB 1000KB1GB 1000MB1TB 1000GB二进制进位1KiB 1024B1MiB 1024KiB1GiB 1024MiB1TiB 1024GiB十进制写法背后是 10 的幂二进制写法背后是 2 的幂。更完整的对照如下单位英文名十进制数值二进制数值常见用途bit比特11网络速率、寄存器位宽Byte字节8 bit8 bit文件大小、内存寻址KB / KiB千字节1000B1024B小文件、缓存MB / MiB兆字节1000KB1024KiB照片、软件安装包GB / GiB吉字节1000MB1024MiB视频、硬盘、内存TB / TiB太字节1000GB1024GiB硬盘、NAS、监控存储如果你要一路推下去二进制里 1TB 1024GB 1024 × 1024MB 1024 × 1024 × 1024KB。也就是说1TiB 2 的 40 次方字节约等于 1.0995 × 10 的 12 次方字节。而十进制 1TB 10 的 12 次方字节两者差了大约 9.95%。严格来说工程师手册里的“KB”默认是十进制 1000“KiB”才是二进制 1024。But 在现实世界Windows 系统、内存容量、Linux 的 df 命令仍然大量使用“KB、MB、GB”来表示 1024 进制。这种混乱才是容量纠纷的真正来源。3.2 十进制前缀和二进制前缀厂商、系统、标准三方纠葛为什么会有两套进位制本质原因是行业没有从一开始就统一口径。硬盘、U 盘、SD 卡这类存储介质厂商为了标称容量数字更好看也为了符合国际单位制 SI 的十进制前缀按照 1000 进位来标注容量。操作系统内部为了寻址方便很多地方按 1024 进位来管理空间但显示时又沿用了 KB、MB、GB 这些名称。于是同一个 1TB 硬盘厂商心里想的是 10 的 12 次方字节Windows 却按 2 的 40 次方字节去除显示成 931GB。你说厂商虚标在标准意义上并没有因为 GB 作为 SI 前缀就是 10 的 9 次方你说系统显示错也没有因为 Windows 在磁盘管理里打印“GB”时实际用的是 GiB 的数值。后来国际电工委员会 IEC 在 1998 年推出了 KiB、MiB、GiB、TiB 这套二进制前缀想终结这种混乱。Linux 的df -h、ls -lh早期输出里默认显示的 G 其实经常是 GiB新版工具则更严格区分。macOS 从 10.6 开始将磁盘容量显示改为十进制 GB所以同样一块 1TB 硬盘插到 Mac 上显示约 1TB插到 Windows 上却显示 931GB。这经常被网友当成“Mac 更良心”真相只是显示口径不同。内存行业基本不走十进制DDR4 8GB 模组就是实实在在的 8GiB因为内存寻址天然按二进制设计用 2 的幂做容量最合理。固态硬盘、机械硬盘、U 卡则普遍用十进制标称因为你买到的物理介质虽然也是二进制存储但厂商选择了 SI 标注方式。3.3 心算口诀不用计算器也能快速换算日常用得最多的是两个心算套路。第一个是网络带宽换算Mbps 除以 8 得 MB/s 理论值除以 10 得实际体验值。这条前面已经说过。第二个是硬盘容量换算标称十进制容量换算到 Windows 显示的二进制容量GB 级乘 0.931TB 级乘 0.909。比如 512GB 固态硬盘Windows 显示约 512 × 0.931 ≈ 477GB2TB 硬盘Windows 显示约 2 × 0.909 ≈ 1.82TB。这里的 0.931 来自 1000 ÷ 1024TB 对应的是 (1000 ÷ 1024) 的三次方。如果你想知道具体少了多少百分比也有个现成结论GB 级大约少 6.9%TB 级大约少 9.1%。所以看到一块 1TB 移动硬盘显示 931GB不用惊讶这是正常现象而不是质量问题。再送一个小技巧算法题或项目代码里凡是要做容量规划我统一以字节为中间单位。写入日志时记录字节数展示时再转成可读格式。这样至少能保证统计口径一致不会今天按 1024 算明天按 1000 算最后排查问题时对不上数。4. 1TB 硬盘为何只剩 931GB容量“缩水”的完整计算4.1 一步步算给你看从 10 的 12 次方字节到 931.32GiB拿标称 1TB 的机械硬盘举例。厂商按十进制标注1TB 1,000,000,000,000 字节。Windows 文件资源管理器按 1024 进制计算容量它把一个 GiB 定义为 1,073,741,824 字节然后用这个数去除总字节数1,000,000,000,000 ÷ 1,073,741,824 931.32所以显示为 931GB 或者 931GiB取决于系统版本。如果是 2TB 硬盘就是 2,000,000,000,000 ÷ 1,073,741,824 1,862.64GiB。Windows 会四舍五入显示 1.86TB。这里看起来像是“买了 2TB 只剩 1.86TB”实际差值约 138GB跟 1TB 差了 69GB 的逻辑一致。这个差异不是故障不是固件 bug也不属于质量问题。它纯粹是两种进位制在你眼前“打架”的结果。你在任何正规渠道买的硬盘只要健康状态正常容量显示都是这个套路。4.2 除了进制差异还有哪些空间悄悄溜走进制差异是最主要的原因但绝对不是全部。格式化文件系统时硬盘还会被以下几个部分占掉一部分空间分区表和引导区比如 GPT 头部、EFI 系统分区占几十到几百 MB。文件系统元数据包括文件分配表、inode、日志区、块组描述符。NTFS 的 MFT、ext4 的 inode 表都会预分配空间。Windows 系统恢复分区、厂商预装的隐藏镜像这部分能轻松吃掉 10~20GB。SSD 的 OP 预留空间Over-Provisioning主控会保留一部分闪存空间用于磨损均衡、垃圾回收和坏块替换。这部分虽然不在用户可见分区里但保证了 SSD 的寿命和性能。所以一块标称 512GB 的固态硬盘全新安装 Windows 后在“此电脑”里看到的不只有进制换算后的 477GB还要再扣除系统保留分区和文件系统开销最终可用空间往往只有 460~470GB。这在买电脑时很常见也是不少人觉得“缩水严重”的原因。4.3 扩容盘识别与可移动存储的“虚标”风险除了正常的进制差异还有一种情况是真·虚标那就是扩容盘。有些劣质 U 盘、SD 卡、移动硬盘主控芯片被刷成了假容量。插上电脑时系统读到 1TB、2TB实际物理存储可能只有 8GB、16GB。你往里面写超过真实容量的数据时要么写不进去要么能写但读出来全是损坏文件。识别扩容盘最有效的办法是用大文件做填充测试。往盘里写满接近标称容量的数据比如标称 128GB 就写 110GB 左右然后再读回来校验。很多免费工具能自动完成写入和校验比如 Windows 上常见的 H2testw跑完一轮基本就能确认有没有虚标。我自己踩过坑在路边摊买的所谓 128GB U 盘实际只有 16GB写文件超过 16GB 后复制进去的视频一个都打不开。后来买存储设备我只认京东自营和品牌旗舰店线下和无名小店的低价高容量盘基本都不碰。另外还要留个心眼格式化显示的容量大不代表真实容量大因为扩容盘可以伪造分区表和容量信息。5. 把 TB 拉回日常生活这些文件体积和存储容量能对应上吗5.1 常见文件体积对照文本、图片、音乐、视频每次讲容量都绕不开一个问题1TB 到底能装多少东西这个问题没有一个标准答案因为不同文件体积天差地别。我先给一组常见参考值普通 UTF-8 编码的中文文本1 个汉字大约占 3 字节1MB 大约能装 30~50 万汉字一本书大概 50 万字也就是 1~2MB。手机随手拍的一张 JPEG 照片1200 万像素大约 2~5MB如果开 RAW 格式一张能到 20~40MB。MP3 音乐按 320kbps 码率1 分钟约 2.4MB一首歌 4 分钟大约 10MB无损 FLAC 一首歌普遍 25~40MB。1080p 电影按 H.264 编码、平均码率 8Mbps 估算1 小时约 3.6GB4K H.265 按 20Mbps 估算1 小时约 9GB。这是比较粗略的区间实际取决于画面复杂度。一个 Docker 镜像或者游戏安装包从几百 MB 到几十 GB 都有所以别拿“一个文件”做统一预期。这套对照能帮你快速判断1TB 硬盘存照片按一张 5MB 算大约能存 20 万张存无损音乐按一首 30MB 算大约 3 万多首存 1080p 电影按一部 10GB 算大约 100 部。看起来很大但如果你拍 4K 视频或者存蓝光原盘容量消耗会快得多。5.2 反向推算按你的使用习惯反推容量需求与其问“1TB 能存多少”不如反过来问“我每天产生多少数据要保留多久”。假设你每天用手机拍 20 张照片每张 4MB再拍 3 段 1 分钟的 4K 视频4K 视频码率按 50Mbps 算一段 1 分钟大约 375MB3 段就是 1.125GB。加上杂七杂八的截图和文档一天产生大约 1.2GB。如果要保留一年不清理那你就需要大约1.2GB × 365 438GB考虑到移动硬盘或 NAS 通常预留 20% 以上剩余空间选一个 1TB 的存储设备才比较稳妥。再比如家里装监控4 个 400 万像素摄像头码率都设在 4Mbps一天会产生大约 4 × 43.2GB 172.8GB。想存 30 天回放容量需求就是 5.2TB一块 6TB 监控盘正好。如果你用的是 8Mbps 的高清模式容量就得翻倍到 10TB 以上。我这里反复用“码率”这个词是因为视频对容量的消耗完全由码率决定。你只要记住码率越高画质越好占的空间也越大。做存储规划时先确定码率再算清楚日增量最后乘以保留天数这个思路在任何场景都适用。5.3 别忘了嵌入式世界.bit 文件是“比特流”不是 bit 单位搜索“bit”相关的内容时很多人其实不是在找存储单位而是在找 FPGA 开发里的 .bit 文件。这两者碰巧用了同一个词常让人误解。FPGA 领域的 .bit 文件是 Xilinx Vivado 或 ISE 工具链生成的比特流文件bitstream。它不是以 bit 为单位的“容量单位”而是一段二进制配置数据里面包含了 FPGA 内部查找表、触发器、布线资源、BRAM 初始化等所有配置信息。上电后FPGA 从配置源读取这个比特流加载到内部配置存储器才能完成逻辑功能的“定型”。开发中经常遇到一个操作从 .bit 文件生成 .bin 文件。.bit 文件里除了原始配置数据还包含了同步头、设备 ID、CRC 校验、附加的 MetaData 等结构信息。而 Flash 烧写时很多方案只需要裸数据流所以需要用工具把 .bit 转成 .bin。比如在 Vivado 的 Tcl 控制台里可以用write_cfgmem命令生成适合 SPI Flash 的格式配合 .mmi 文件把 MicroBlaze 的 ELF 软件执行程序合并进去最终烧写到 Flash 里实现上电自启动。这个过程对很多刚接触 FPGA 的朋友来说是个大坑——.bit 文件能直接 JTAG 下载让板子跑起来但一断电就没了要固化程序就得生成 .bin 或 .hex 并烧进 Flash这俩文件格式和用途完全不同。顺带提一句类似 K210 这类 RISC-V AI 开发板比如 Sipeed Maix Bit也存在“固件烧写”的需求。K210 的固件需要用特定工具写入 Flash这种“下载固件”的行为同样会被人误叫成“下载 bit 文件”。因此当你搜索“bit”相关关键词时先想清楚你找的是单位换算还是开发板固件、FPGA 比特流、软件位数方向完全不一样。6. 留下几个趁手的换算技巧命令行、脚本与自查清单6.1 用 Python 或 Linux 命令代替在线转换器很多人做单位换算会去搜索引擎找在线转换器但容量换算的数据不涉及隐私完全可以用本机命令更快解决。Linux 和 macOS 自带numfmt能把字节数转成人类可读格式# 把字节数按十进制转成可读格式 echo 1000000000000 | numfmt --tosi # 输出1.0T # 把字节数按二进制转成可读格式 echo 1000000000000 | numfmt --toiec # 输出932G注意这里--tosi表示 1000 进制--toiec表示 1024 进制。两条命令结果不同正好对应厂商和系统的两套口径。如果你在写脚本或者做算题直接用 Python 最省事size_bytes 2_000_000_000_000 # 2TB 标称字节数 # 按 Windows 二进制口径显示 print(size_bytes / 1024**3, GiB) # 输出1862.64 GiB # 按厂商十进制口径显示 print(size_bytes / 1000**3, GB) # 输出2000.0 GB这个脚本能直观看出两套系统的数值差异。我自己做容量统计时凡是数据从数据库或日志里取出来统一转成字节数再计算最后要给人看时再格式化这样最不容易出错。6.2 日常自查清单和“最后一条经验律”把本文知识点压缩成几张自查卡片遇到问题时对号入座场景看什么单位换算要点办理宽带运营商写 Mbps理论下载速度 MB/s 约等于数值除以 8实际按除以 10 估买硬盘/U 盘/SD 卡厂商标称 GB/TB插到 Windows 显示会缩水约 7% ~ 9%属正常现象看文件大小系统显示 KB/MB/GB文件制作工具通常按二进制计算空间占用以系统为准摄像头录像Mbps 码率1Mbps 录制 1 小时约 0.45GB数据库日志统计字节数统一一律按字节存展示时再换算FPGA 开发.bit / .binbitstream 不是容量单位.bin 是从 .bit 转换的固化数据流最后分享一条我摸索了很久才固化的经验律日常生活看带宽用 b看文件用 B做容量规划先确定存储设备的进制口径再做乘法任何需要写代码处理的容量数据中间过程一律用字节展示层再做格式化。只要你把这三点变成习惯绝大多数单位换算复杂场景都能一眼看穿。我自己刚接触这些东西时也被 1TB 硬盘“缩水”成 931GB 的事困惑了很久甚至一度怀疑是商家坑人。后来搞清楚了十进制和二进制两套进位制再回头看这些现象一切都有了解释。希望这篇能把你的容量焦虑也一并治好了。
返回列表