蓝牙5.0规范第6卷翻译实战：从BLE链路层到术语表建设

蓝牙协议5.0的英文规范，光第6卷就够你翻一整天的。我记得第一次展开那份PDF时的感受：满屏的Link Layer、PDU、Connection Event、Channel Selection Algorithm，每个单词都认识，但它们连成句子之后，就是不知道在说什么。我所在的小团队做低功耗蓝牙外设，每次调试都离不开这份规范，可十几个人里真正能流畅读英文原版的没几个，遇到链路层问题就集中到我一个人头上。后来我们干脆组了一个翻译小组，把蓝牙协议5.0第6卷从头到尾翻译成了中文。做完之后最大的体会是：这个活儿表面上没有技术含量，实际非常考验对协议本身的理解，翻译过程中逼着我们把之前含糊的概念全部过了一遍。

这篇文章就把我们整个翻译过程、踩过的坑、定下来的措辞规范、以及翻译成果怎么反哺开发工作的经验都写出来。想啃规范原文、想做团队知识沉淀的朋友，可以参考我们的做法。

1. 为什么放着现成的资料不用，偏要去翻第6卷

1.1 第6卷在整套规范里扮演什么角色

蓝牙核心规范本身是分卷发行的，第6卷对应“低功耗控制器”这一层，也就是常说的LE Controller。它主要规范两块内容：一块是低功耗物理层（PHY），规定无线电信号怎么调制、信道怎么划分、三种PHY模式各自什么参数；另一块是低功耗链路层（Link Layer），规定设备状态怎么切换、广播和扫描报文怎么封装、连接事件怎么调度、加密怎么协商。

理解这一层的重要性在于，我们平时用厂商SDK开发BLE产品，调的大多是Host层的API，比如GATT、GAP的抽象接口。可是设备一旦出现连接不稳定、广播不出去、功耗异常这类问题，最终都要下沉到第6卷的规则里去解释。SDK有时候会对底层细节做封装甚至简化，让开发者远离这些概念，这当然友好，但出了问题也容易让人无从下手。

我们团队当时正准备把一个老旧的外设产品从蓝牙4.2升级到蓝牙5.0。新方案需要支持2M PHY、扩展广播和更大的数据包。这些功能全是第6卷新增或修订的内容。看原版规范是绕不过去的，可大家的阅读效率实在太低，我才提了一句“要不我们直接把这一卷翻译了”，没想到最后真做成了。

1.2 团队的真实痛点：中文资料太碎，术语不统一

没做过这个动作之前，我低估了术语不统一带来的沟通成本。团队里有人把Advertising叫“广播”，有人叫“广告”，还有人叫“通告”。开会的时候，光确认对方说的是不是同一个概念就要浪费好几分钟。网上中文技术文章写BLE的不少，但水平参差不齐，同一个术语在A文章里叫“连接事件”，在B文章里叫“连接时间窗”，在C文章里很可能直接不翻译，留着Connection Event。

对一个要长期维护的产品线来说，这种碎片化的认知是非常危险的。开发、测试、技术支持各按各的理解去处理问题，出的文档互相看不懂，新人进来更是两眼一抹黑。自己动手翻译第6卷，本质上不是做慈善，而是把团队里所有关于BLE链路层和物理层的公共认知，统一成一套可检索、可引用的内部文档。

1.3 自己翻译的收益不止是“有中文版”

翻译过程中我们被迫做的最有价值的一件事，是给每个关键术语写定义和上下文备注。比如“Channel Selection Algorithm”不能只译成“信道选择算法”，还要备注它决定的是每个连接事件在哪个物理信道上传数据，5.0新增的CSA#2和旧版CSA#1差别在哪。这些备注最终沉淀成了一份几十页的术语手册，比译文本身还好用。

另外一个隐藏收益是，翻译到哪一章，就相当于把那一章精读了一遍。以前我读规范常常跳着读，只看自己关心的参数范围，对前后文的约束关系并不敏感。翻译不允许这样，一个模棱两可的词都可能被别人挑出来问，逼着我把语境里的因果关系搞清楚。

2. 从协议栈分层看第6卷管到哪一层

2.1 协议栈的分工：Host和Controller是不一样的世界

读第6卷之前，我先给团队画了一条非常粗的分层线。BLE协议栈从上到下大致是：应用层、主机层（Host）、主机控制器接口（HCI）、控制器层（Controller）。其中Controller里核心的部分就是PHY和Link Layer，这两个模块恰好都在第6卷。

Host解决的是“数据怎么组织、服务怎么暴露”的问题，Controller解决的是“数据到底怎么通过无线电发出去、怎么保证收包对方能正确解调”的问题。两者之间通过HCI分包，控制器给主机提供命令和事件，主机不直接操作物理层。

这里有一个很常见的误区：很多人以为BLE的“广播”和“扫描”逻辑都写在应用代码里。实际上应用层只是通过GAP层发起请求，真正完成广播包发送、扫描窗口调度、接收地址过滤的，都是Controller里Link Layer的状态机。第6卷的链路层部分就是描述这个状态机的。

2.2 物理层部分到底写了什么

第6卷物理层部分描述的无非是几件事：频段和信道、调制方式和发射接收指标。

BLE工作在2.4GHz ISM频段，信道带宽2MHz，一共40个物理信道，其中3个广播信道、37个数据信道。物理层规定调制方式是GFSK，调制指数约0.5，并规定了不同PHY模式下的数据传输速率，比如1M PHY、2M PHY，以及用于长距离场景的Coded PHY。

翻译这部分时最大的坑是“给数字当搬运工”。物理层表格里有大量dbm、微安、微秒级别的参数，差一个小数点都是事故。我们当时的做法是不重新排版表格，直接在原文表格基础上做双语对照，把所有数字原封不动保留，中文只处理表头和注释。

2.3 链路层部分：状态机、事件和时序

链路层部分是第6卷的绝对大头。它定义了设备在一段时间内可以处于什么状态：待机（Standby）、广播（Advertising）、扫描（Scanning）、发起（Initiating）、连接（Connection）。状态之间的迁移由报文的接收和超时定时器触发。

除此之外，链路层还规定了广播信道的数据单元（PDU）格式、数据信道的PDU格式、链路层控制过程（比如连接参数更新、加密启动、信道地图更新）、连接事件调度机制，以及地址类型和过滤策略。

翻译这部分让我觉得最难的是“把状态机的时序关系讲清楚”。链路层行为像一张复杂的时序图，某一时刻能不能发包、收到包之后下一步做什么，都由Precise的条件约束着。译成中文时如果只翻译字面描述，读者大概率还是看不懂，我们就在每个关键事件后面补了简短的时序说明。

2.4 谁最需要关注第6卷的内容

做蓝牙产品，并不是所有人都需要读第6卷。我自己给团队做了一个划分：做应用层开发的同学，知道广播、连接、扩展广播的概念就够了；做协议栈适配的工程师，必须精读链路层章节；做认证和测试的同事，至少要把第6卷物理层里的指标要求看完。这样不同角色各取所需，不用被整卷内容吓退。

3. 翻译最容易翻车的三类规范句式，以及我的取舍

3.1 shall/should/may：中文怎么译才不产生歧义

蓝牙规范里最折磨人的不是生僻词，而是大量“法律条文式”的情态动词。英文原版的shall、should、may、can、must在不同章节能把人绕晕。翻译之前我们先统一了规则：

为什么不用很多中文翻译者习惯的“应”来对shall？因为我发现“应”在中文里语气不够强。读到“设备应支持XX”的时候，经验不足的开发者很容易当成一句建议，实际它是一条硬性要求。用“必须”后，新人至少不会误判强制力。后来我们做内部评审，大家一致认为这个选择是翻译质量最关键的决策之一。

3.2 嵌套条件句：先拆结构再翻译

规范里经常出现这类描述：“若设备处于连接状态且已收到包含有效LLData的包，则除非某个定时器未启动，否则该设备应执行事件A。”翻译这种句子，硬按英文语序会变成“中文长难句”，读三遍都理不清。

我们的处理方式是先拆主干，再补条件。先把“设备应执行事件A”放前面，然后在后面列出前置条件：处于连接状态、收到有效包、定时器已启动。用列表方式展开条件，让人一眼看清逻辑。这种操作在翻译时看起来很机械，但对读者非常友好。

不要试图美化这些句子。规范原文的表达很严谨，中文译文的目标是“严谨优先、流畅第二”。一旦为了顺口增删逻辑关系，很可能把约束条件写漏。

3.3 参数表和时序图：最不能自由发挥的地方

第6卷里有大量表格，像连接间隔的可选范围、超时时间的上下限、PDU类型编码值等。翻译时我们规定：表格里所有数值、枚举值、单位符号一律不允许改动，中文只处理表头、列名和脚注。

时序图也一样。图里的状态名可以翻译，但事件箭头的触发条件要保持和原文一模一样，不能因为中文表达习惯去合并或简化分支。

这块我吃过亏。早期有一张链路层状态迁移图，我图省事把“收到无效广播地址时回到待机状态”和“收到超时事件时回到待机状态”合并成了一条“异常时回到待机状态”。技术审校直接给我打回来了，因为两个条件后续跳转的时序完全不同。自那以后，图和表都改为逐条对照翻译，宁慢勿错。

3.4 专有名词：为什么“Advertising”不译成“广告”

行业里把“Advertising”译成“广告”的例子不少。但在蓝牙协议语境下，广告的含义容易和商业广告混淆，而且“广播”能更自然地和“广播信道”“广播包”组成系列词群。我们在术语表里统一：Advertising=广播，Advertiser=广播者，Advertisement=广播报文。

同理，"Scanner"不叫“扫描仪”，叫“扫描者”；"Initiator"叫“发起者”，不叫“初始化器”。这些词看着小，但统一之后就变成了团队内部的共同语言，后面做技术文档、写代码注释都受益。

4. 十几个人合译不打架的流程：术语表与翻译记忆库

4.1 先花一周定术语表，后面省三个月

翻译启动的头一周，我们没有让任何人动正文，全部精力都用来建术语表。我们把第6卷目录和索引里出现的高频术语整理出来，每一条都讨论翻译，讨论结果投票决定。这一周看起来进度为零，实际是整套流程里最值得的一周。

术语表的形式不复杂：英文术语、中文翻译、缩写形式、适用上下文、备注和示例。我摘几条当时定下的内容：

术语表定完之后，所有译者翻译时遇到术语只能往里填，不能临时发明新词。谁想新增或修改术语，必须先提交讨论，再更新表。这样做的结果是，十几个人分头翻译的不同章节，术语口径完全一致。

4.2 用CAT工具加Git：每条译文都可追溯

翻译的第6卷正文拆成了大约十几个子任务，按链路层状态机、广播与扫描、连接与数据、物理层等模块分给不同的人。人一多，版本管理就成了大问题。

我们采用“CAT工具留存句段翻译记忆 + Git做版本管理”的组合。翻译记忆库最大的好处是，规范里反复出现“设备必须支持XX”之类的高频句式，第一遍翻译后，后续相同句段能直接复用或只做微调。光这一项就省了大概三成工作量。

Git负责多人协作和回溯。每个人的译文先放自己的分支，每周合一次，合并时用diff工具检查有没有人误改别人的章节。某天发现物理层一章的发射功率数字对不上原版，我们用git历史直接定位到是哪个改动引入的，几分钟内完成回滚，这在普通网盘协作里不可想象。

4.3 版权红线：内部译文别外传

在这里必须提醒一句：蓝牙规范文本的版权归蓝牙技术联盟所有，没有授权的情况下，完整翻译稿不能公开分享、打包传播。我们翻译的目的纯粹是团队内部技术学习和开发参考，成稿只放在内部文档服务器上，不对外发布，也不拿它做商业用途。

不过面向团队内部，我们还是会做一个双语对照版，方便随时回到英文原版校对。处理版权问题时思路很简单：翻译是手段不是目的，我们既没有脱离原版标新立异，也没有靠它牟利。

5. 蓝牙5.0新内容的翻译实战：扩展广播、Coded PHY和数据长度扩展

5.1 扩展广播：Primary、Secondary和Auxiliary的关系

蓝牙5.0新增的LE Advertising Extensions是我们翻译时最吃力的一块。它的机制是让广播可以“变大”，但又不能占用太多广播信道资源，于是引入了主广播信道和次广播信道。

最初我们内部把“Primary Advertising”译成“主广播”、“Secondary Advertising”译成“次广播”，结果越往下翻译越别扭，因为很多句子里需要强调在哪个物理信道上发送。后来改成了“主信道广播”和“次信道广播”，一下子清晰了不少。

“Auxiliary Packet”我们也纠结了很久，直译是“辅助包”，但在实际上下文里它承载广告数据主体，一点都不“辅助”。最终我们选择了“扩展广播包”，并在术语表里注明它和传统ADV_IND广播包的区别。术语翻译不必拘泥于字面，重要的是让读者能准确理解它在一个机制里的作用。

5.2 LE Coded PHY：长距离模式下的编码与速率

5.0带来的另一个大变化是LE Coded PHY。它在物理层增加了前向纠错编码，用降低速率换传输距离。规范里定义了两档速率：一档用S=2编码，实际速率500kbps；另一档用S=8编码，实际速率125kbps。

翻译编码参数时我们差点译错一个关键概念：“Coded PHY”不等于“更高功率”，它本质上是通过冗余编码让接收端在更差信噪比下仍能解调。很多中文文章把它简单描述成“增大发射功率”，从这个角度理解长距离模式是错的。我们特意在译文里加了一句译注，提醒研发同事不要误解。

5.3 数据长度扩展：251字节背后的语义变化

LE Data Length Extension（DLE）让单包数据长度从27字节增加到251字节。翻译这一章比较轻松，但随后我们发现，代码注释、模块设计文档里几乎没人用对“有效载荷”这个概念。

规范原文里“payload”在不同章节指的位置不完全一样：在广播报文里指除去报头的完整MAC层数据；在L2CAP层又指去掉L2CAP头之后的用户数据。翻译时我们给“有效载荷”加了上下文限定词：MAC层有效载荷、HCI数据包有效载荷、L2CAP有效载荷。就这一个动作，避免了很多后续开发沟通歧义。

5.4 新术语从无到有的决策过程

翻译新特性时最忌讳一个人拍脑袋。我们遇到“Advertising Extensions”这类没有标准译法的词，会先在小组里讨论，大家各自说一遍对这个机制的理解，确认所有人都理解一致后再定译名。有一次围绕“Extended Advertising”和“Periodic Advertising”的区别，我们讨论了整整一个小时。前者是广播包的扩展发送机制，后者是周期性的广播序列，两者中文名称容易混淆，最终我们定下“扩展广播”和“周期性广播”，并在术语表里用一句话做了严格区分。

6. 双层审校和那些写不尽的勘误

6.1 技术审校：让懂协议栈的人逐条挑刺

初稿完成后，第一道关是技术审校。做法是让组里最熟悉链路层的工程师对照英文原版逐章过稿，重点检查三条：有没有漏译条件句，有没有参数抄错，有没有把“连接事件”和“广播事件”这类概念混用。

印象最深的一次，审校发现我们把“connection supervision timeout”译成了“连接监控超时”，本身不算错，但和术语表里定的“监管超时”不一致。这种不一致在单章里看不出来，跨章节放一起就容易困惑。技术审校要做的就是用同一把尺子量所有章节，把术语偏离的地方全部揪出来。

技术审校还会追问“这句是什么意思”。如果译者自己都没理解，译文大概率是照着字面硬译的。对这一类句子，我们要求译者写一段白话解释放在译注里，哪怕译文本身没问题，也要通过这个动作确认译者真读懂了。

6.2 语言审校：中文表达不够顺的地方再磨一遍

技术审校通过后，语言审校负责“读起来不像翻译腔”。这一步会调整句子的语序，把过长的定语拆开，把被动语态改成主动语态。

语言审校不能动数字，不能动术语。它只负责让一个懂技术但英文一般的人，读中文就能顺畅理解规则逻辑。我们当时有一句译文：“在连接事件期间，如果该设备没有接收到任何包含有效消息的数据包，该设备不得在事件结束前发送任何数据。”语言审校改成了：“连接事件中，若本设备未收到任何有效数据包，则事件结束前不得发送数据。”意思一样，阅读负担降低不少。

6.3 勘误机制：翻译完成不等于翻译结束

我们必须接受一个事实：几千页的规范翻译完，一定有错，一定有没读懂的地方。所以建立勘误机制非常必要。我们在内部wiki上给译文每章挂了一个勘误区，任何人读的时候发现问题随时登记，标清原文页码和问题描述，再由对应章节负责人确认和更新。

这个机制不花多少钱，却保证了译文是“活”的。半年里我们陆陆续续修正过十几个点，有的是术语统一问题，有的是翻译时漏了一个限定条件，还有一处是状态迁移的箭头描述错误。开发人员直接受益，因为他们不需要每次都被迫回原版核对。

最后说点个人体会。翻译完成之后的半年里，第6卷中文版成了组里最受欢迎的文档，没有之一。我后来带新人看协议的时候，基本路线都是：先看中文译文建立概念，再回到英文原版校准细节。有一次我们做设备断连排查，问题出在连接事件窗口太小而广播又太密，工程师直接对照译文里链路层那一章的时序描述定位了问题，比我以前口头解释半天高效太多。

如果你想做类似的事，我的建议是别贪多，先只翻译第6卷的链路层部分，拿到成果、建好术语库之后再考虑碰其他卷。目标小，见效快，团队也更愿意继续投入。始终记得术语表要“活着”维护，不要定完就锁死，随着阅读深入，对同一个英文术语的理解会越来越精准，术语表跟着迭代才是常态。