GAP规范【3. User interface aspects】

这部分属于 GAP 规范中关于"用户界面表达"的说明，重点不是讲 BLE 空口通信流程，也不是讲 GAP 的广播、扫描、连接参数，而是在规定：

当蓝牙相关术语、参数、数值出现在用户能看到的地方时，应该使用什么样的通用表达方式。

一、原文大意翻译

3. User interface aspects

3. 用户界面方面

3.1. The user interface level

3.1 用户界面层级

在本规范的语境中，用户界面层级指的是用户在使用蓝牙设备时，会看到蓝牙术语、参数名称、参数值、数字表示方式的地方。

这些地方包括但不限于：

显示屏
对话框
用户手册
包装
广告宣传材料
其他用户能接触到的展示位置

本 Profile 规定了在用户界面层级上应该使用的通用术语。

二、这段话想表达什么？

它想表达的是：

GAP 不只是规定设备之间怎么发现、怎么连接、怎么广播，它还规定了一些蓝牙相关信息在"用户可见层面"应该如何表达。

也就是说，蓝牙规范不仅关心底层通信，也关心用户看到的名称、参数、术语是否统一。

比如用户在 App、系统设置、产品说明书、包装盒上看到：

Bluetooth
Bluetooth device
discoverable
connectable
pairing
bonded
device name
passkey
PIN
address

这些词应该怎么写、怎么显示、怎么解释，规范会给出通用要求。

三、关键信息

1. "user interface level" 不是指 App 的 UI 层代码

这里的 user interface level 不要理解成 iOS / Android App 开发里的 View 层、Controller 层、界面层代码。

它在规范里的意思是：

凡是用户能看到蓝牙相关信息的地方，都属于 user interface level。

所以它包括 App 界面，但不只包括 App 界面。

例如：

复制代码

手机蓝牙设置页面
蓝牙耳机说明书
蓝牙模块包装盒
设备屏幕上的蓝牙状态提示
App 扫描到设备后显示的设备名称
配对弹窗
产品广告中的蓝牙功能描述

这些都属于规范这里说的用户界面层级。

2. 这部分主要关注"术语统一"

这段话最后一句很关键：

This profile specifies the generic terms that should be used on the user interface level.

意思是：

GAP 会规定在用户界面层级应该使用哪些通用术语。

也就是说，后面的内容很可能会告诉你：

某个蓝牙概念在用户界面上应该叫什么
某些术语应该避免混乱
不同蓝牙设备在展示名称、状态、参数时应该保持一致
用户看到的表达应尽量符合蓝牙规范的通用说法

这对底层协议理解不是最核心的，但对做蓝牙 App、产品说明、调试工具界面很有价值。

3. 它强调的是"用户看到的名称、值、数字表示"

原文中提到：

复制代码

names, values, and numeric representations

这三个词很重要。

分别表示：

names：名称

例如：

复制代码

Bluetooth device name
Local Name
Device Name

在 App 或文档中应该怎么叫，不能随便乱写。

比如 BLE 广播数据里面可能有：

复制代码

Complete Local Name
Shortened Local Name

App 展示时就要注意这是"广播中的本地名称"，不一定等同于系统缓存的设备名称，也不一定等同于 GATT Device Name Characteristic。

values：值

例如某些状态值：

复制代码

discoverable
connectable
bonded
paired

用户界面上应该用清晰、统一的方式表达。

比如一个设备当前是否可被发现、是否可连接、是否已经配对，这些状态展示给用户时不能乱用术语。

numeric representations：数字表示方式

例如：

复制代码

Bluetooth address
UUID
Appearance value
Class of Device
Company Identifier

这些数字在用户界面上怎么显示，也会涉及规范表达。

比如 BLE 地址通常是 48 bit，常见显示方式是：

复制代码

AA:BB:CC:DD:EE:FF

UUID 可能是 16-bit、32-bit、128-bit，不同场景显示方式也要注意。

四、对学习 BLE 的具体提醒

这部分可以这样理解：

它不是 BLE 通信机制的核心章节，但它是做蓝牙 App、蓝牙调试工具、蓝牙产品说明时非常有用的规范内容。

如果你的目标是理解 BLE 的广播、扫描、连接、GATT 通讯，那么这一节不需要花太多时间深挖。

但是你做蓝牙 App，尤其是类似 nRF Connect、LightBlue 这种工具类 App，就很值得关注。

因为你的 App 里会大量展示：

复制代码

设备名称
设备地址
广播数据
RSSI
Tx Power
UUID
Service
Characteristic
Descriptor
Notify
Indicate
Read
Write
Pairing
Bonding
Connection
Advertising
Scanning

这些内容展示给用户时，如果术语不规范，容易造成误解。

这部分讲的是 Bluetooth Device Address（蓝牙设备地址，BD_ADDR）在用户界面上应该怎么称呼、怎么显示。

它不是在重点讲地址分类，而是在讲：

当蓝牙地址出现在用户能看到的地方时，应该用什么名称，以及应该用什么格式展示。

一、原文大意翻译

3.2 Bluetooth 参数的表示方式

3.2.1 Bluetooth Device Address，BD_ADDR

3.2.1.1 定义

BD_ADDR 是蓝牙设备使用的地址，具体定义见 Section 15.1。

在设备发现过程中，可以从远端设备那里接收到这个地址。

3.2.1.2 用户界面层级上的术语

当在 UI 层面提到 Bluetooth address 时，应该使用术语：

Bluetooth Device Address

也就是：

蓝牙设备地址

3.2.1.3 表示方式

在 Baseband 层面，BD_ADDR 表示为 48 bit。

在 Link Layer 层面，Public Device Address 和 Random Device Address 也都表示为 48-bit address。

在 UI 层面，Bluetooth address 应该表示为 12 个十六进制字符 ，可以选择用冒号 : 分成几个部分。

例如：

复制代码

000C3E3A4B69

或者：

复制代码

00:0C:3E:3A:4B:69

在 UI 层面，任何数字都应该按照 MSB → LSB 的自然顺序显示，也就是从左到右显示高位到低位。

二、这部分想表达什么？

这部分主要想表达 3 件事：

第一，蓝牙设备地址在规范中的正式术语是：

复制代码

Bluetooth Device Address

第二，蓝牙设备地址本质上是一个：

复制代码

48-bit address

第三，如果要在 App、说明书、界面、日志、包装、广告中显示蓝牙地址，推荐显示成：

复制代码

00:0C:3E:3A:4B:69

或者：

复制代码

000C3E3A4B69

而不是随便换顺序、随便加分隔符、或者用低位在前的方式展示。

三、关键信息 1：BD_ADDR 是什么？

BD_ADDR 的全称是：

复制代码

Bluetooth Device Address

可以翻译为：

复制代码

蓝牙设备地址

它是蓝牙设备用来标识自己的地址。

在设备发现过程中，本地设备可以从远端设备那里得到这个地址。

比如你的手机作为中心设备扫描 BLE 外设时，扫描结果里通常会包含类似这样的地址：

复制代码

DC:0D:30:00:06:F6

这个地址就是远端设备在广播/发现过程中暴露出来的设备地址。

不过要注意：

在 BLE 里面，不要简单粗暴地把它都叫成"MAC 地址"。

更规范的说法应该是：

复制代码

Bluetooth Device Address

或者：

复制代码

Device Address

因为 BLE 地址还涉及地址类型，例如：

复制代码

Public Device Address
Random Device Address
Resolvable Private Address
Non-resolvable Private Address
Static Random Address

所以只看到一个地址值还不够，很多时候还要结合 Address Type 一起看。

四、关键信息 2：UI 上应该叫 Bluetooth Device Address

这一句很关键：

When the Bluetooth address is referred to on the UI level, the term 'Bluetooth Device Address' should be used.

意思是：

在用户界面层面，如果你要提到蓝牙地址，推荐使用：

复制代码

Bluetooth Device Address

而不是只写：

复制代码

Bluetooth Address
MAC Address
Device MAC
BLE MAC

当然，在实际 App 里，很多用户更熟悉"MAC 地址"这个说法，所以可以根据产品面向的人群调整。

如果是面向普通用户，可以写：

复制代码

蓝牙地址

如果是面向开发者或调试工具，可以写得更规范一些：

复制代码

Bluetooth Device Address
Device Address
Address + Address Type

如果是 BLE 调试工具类 App，我更建议界面上拆成：

复制代码

Address: DD:2D:31:00:06:F6
Address Type: Random / Public

这样比单独显示一个"MAC 地址"更严谨。

五、关键信息 3：BD_ADDR 是 48 bit

规范明确说：

复制代码

BD_ADDR is represented as 48 bits

也就是说，蓝牙设备地址长度是：

复制代码

48 bit = 6 byte

因为 1 byte = 8 bit，所以：

复制代码

6 byte × 8 bit = 48 bit

而一个 byte 用两个十六进制字符表示，所以 6 个 byte 就是：

复制代码

12 个十六进制字符

例如：

复制代码

00:0C:3E:3A:4B:69

拆开来看：

复制代码

00    0C    3E    3A    4B    69
1字节 1字节 1字节 1字节 1字节 1字节

一共 6 个字节，也就是 48 bit。

六、关键信息 4：UI 上用 12 个十六进制字符显示

规范说 UI 层面应该显示成：

复制代码

12 hexadecimal characters

也就是 12 个十六进制字符。

可以不加冒号：

复制代码

000C3E3A4B69

也可以加冒号：

复制代码

00:0C:3E:3A:4B:69

实际开发中，冒号分隔的方式更常见，也更易读。

所以在 App 界面、日志、文档中更推荐：

复制代码

00:0C:3E:3A:4B:69

而不是：

复制代码

000C3E3A4B69

后者虽然符合规范，但阅读体验差一些。

七、关键信息 5：显示顺序是 MSB → LSB

这一句很重要：

On the UI level any number shall have the MSB → LSB natural ordering.

意思是：

在用户界面上，数字应该按照自然顺序显示，也就是：

复制代码

最高有效位 MSB 在左边
最低有效位 LSB 在右边

例如：

复制代码

00:0C:3E:3A:4B:69

这里左边的 00 是更高位，右边的 69 是更低位。

这和底层协议、内存存储、HCI 数据包里的字节顺序可能不是一回事。

你要特别注意：

规范这里说的是 UI 显示顺序，不一定等同于底层传输顺序。

也就是说，用户界面上看到的是：

复制代码

00:0C:3E:3A:4B:69

但是在某些底层数据包、HCI Event、控制器返回数据中，可能会看到字节顺序是反过来的，例如：

复制代码

69 4B 3A 3E 0C 00

这不是地址变了，而是底层数据的字节序和 UI 展示习惯不同。

八、结合 BLE 开发怎么理解？

对于做 BLE App 开发来说，这部分最有用的地方是：

1. App 展示地址时，尽量使用规范格式

例如扫描结果列表中显示：

复制代码

Name: TWS876
Address: DD:2D:31:00:06:F6
Address Type: Random
RSSI: -63 dBm

这样比下面这种更清楚：

复制代码

MAC: DC0D300006F6

尤其是 BLE 里面有随机地址、私有地址、可解析私有地址等概念，只写 MAC 容易让人误以为这是一个固定不变的硬件地址。

2. 不要只保存 Address Value，最好同时保存 Address Type

在 BLE 中，地址值本身不一定足够。

例如：

复制代码

Address: DD:2D:31:00:06:F6
Address Type: Public

和：

复制代码

Address: DD:2D:31:00:06:F6
Address Type: Random

它们在规范语义上不是完全一样的。

所以更规范的设备标识信息应该包含：

复制代码

Address Value + Address Type

这也是你之前总结"BLE 地址不是只有一个固定类型，而是要同时看 Address Value + Address Type"的原因。

这个理解是对的。

3. HCI 日志里看到的地址顺序，可能和 UI 显示相反

你用 ATS 查看 btsnoop 日志时，可能会看到 HCI Event 里地址字段是类似这样的：

复制代码

F6 06 00 30 0D DC

但是 App 或系统 UI 里显示成：

复制代码

DD:2D:31:00:06:F6

这时候不要以为是两个地址。

这是因为：

复制代码

HCI 数据中的字段顺序

和：

复制代码

UI 层面自然显示顺序

可能不同。

所以分析日志时，看到地址字段一定要结合具体协议字段说明，看它是按什么字节序放置的。

九、这一节你应该怎么记？

可以直接记成下面这几句话：

复制代码

BD_ADDR 是 Bluetooth Device Address，也就是蓝牙设备地址。

在 UI 层面，规范建议使用 Bluetooth Device Address 这个术语。

蓝牙设备地址是 48 bit，也就是 6 字节。

UI 上应该显示为 12 个十六进制字符，可以写成 000C3E3A4B69，也可以写成 00:0C:3E:3A:4B:69。

UI 显示时采用 MSB → LSB 的自然顺序，也就是高位在左、低位在右。

BLE 开发中不要只看地址值，还要结合 Address Type 一起判断。

十、对当前学习 BLE 的提醒

这部分内容虽然属于 GAP，但它更偏向 显示规范，不是 BLE 通信流程的核心。

不过它对做 App 非常实用，因为做蓝牙 App 时经常要展示：

复制代码

设备名称
设备地址
地址类型
广播数据
RSSI
Tx Power
Service UUID
Characteristic UUID

其中设备地址是最容易被写错、理解错的内容之一。

重点记住两点就够了：

复制代码

1. UI 上显示蓝牙地址，推荐用 12 位十六进制字符，常见格式是 XX:XX:XX:XX:XX:XX。

2. BLE 中更严谨的说法不是单独的"MAC 地址"，而是 Device Address，并且要结合 Address Type 理解。

这部分讲的是 Bluetooth Device Name（蓝牙设备名称），也就是用户平时在手机蓝牙列表、App 扫描列表、设备说明中看到的那个"人类容易识别的名字"。

它的重点不是广播数据里的 Local Name，而是更通用地规定：

蓝牙设备应该有一个用户友好的设备名称，并且在 UI 层面应该称为 Bluetooth Device Name。

一、原文大意翻译

3.2.2 Bluetooth Device Name

蓝牙设备名称，也就是用户友好的名称

3.2.2.1 Definition

定义

Bluetooth Device Name 是蓝牙设备暴露给远端设备的用户友好名称。

对于 只支持 BR/EDR 的实现 ，这个名称是在收到 LMP_NAME_REQ 请求后，通过 LMP_NAME_RES 返回的字符串。

对于 只支持 LE 的实现 ，这个名称保存在 Device Name Characteristic 中，也就是 GATT 的 Device Name 特征值。

3.2.2.1.1 Bluetooth Device Name in a BR/EDR/LE implementation

BR/EDR/LE 双模实现中的蓝牙设备名称

一个同时支持 BR/EDR 和 LE 的设备，应该只有一个 Bluetooth Device Name。

这个名称不应该因为使用不同物理信道进行名称发现而不同。

也就是说：

通过 BR/EDR 查到的名称
通过 LE 查到的名称

应该是同一个名字。

对于 BR/EDR 物理信道，名称通过 LMP_NAME_RES 获得。

对于 LE 物理信道，名称可以通过读取 Device Name Characteristic 获得。

注意：如果本地设备支持 ATT over BR/EDR，那么远端设备也可以通过 ATT over BR/EDR 读取本地设备的 Device Name Characteristic。

3.2.2.2 Term on user interface level

用户界面层级上的术语

当在 UI 层面提到 Bluetooth Device Name 时，应该使用术语：

复制代码

Bluetooth Device Name

也就是：

复制代码

蓝牙设备名称

3.2.2.3 Representation

表示方式

Bluetooth Device Name 最多可以是 248 字节。

它应该使用 UTF-8 编码。

因此，如果名称中使用了超出 U+0000 到 U+007F 范围的字符，那么在 UI 层面输入的名称可能会被限制到最少 62 个字符。

一个设备不能假设普通远端设备一定能处理超过 Bluetooth Device Name 前 40 个字符 的内容。

如果远端设备显示能力有限，它可能只使用前 20 个字符。

二、这部分想表达什么？

这部分主要表达的是：

Bluetooth Device Name 是蓝牙设备暴露给其他设备看的"用户友好名称"，不同类型的蓝牙实现获取这个名称的方式不同，但 UI 层面应该统一称为 Bluetooth Device Name。

对于 BLE 学习来说，你要重点理解：

复制代码

Bluetooth Device Name 不是一个随便显示的名字；
它在规范中有明确来源、编码方式和长度限制。

尤其是 BLE 开发中，很多人会把几个"名字"混在一起：

复制代码

广播数据里的 Local Name
GATT 里面的 Device Name Characteristic
手机系统缓存的 peripheral.name
App 扫描列表里显示的 name

这几个东西有关联，但不一定完全等同。

三、关键信息 1：Bluetooth Device Name 是"用户友好的名称"

原文说：

复制代码

the user-friendly name that a Bluetooth device exposes to remote devices

意思是：

Bluetooth Device Name 是设备暴露给远端设备的、便于用户识别的名称。

例如：

复制代码

AirPods Pro
BLE Sensor
Heart Rate Monitor
My Keyboard

这些都属于用户容易理解的名字。

它和设备地址不同。

设备地址类似：

复制代码

DB:3C:19:00:06:F6

这个是机器识别更方便。

设备名称类似：

复制代码

TWS876

这个是人识别更方便。

所以可以这样理解：

复制代码

Bluetooth Device Address：设备的地址，偏机器识别
Bluetooth Device Name：设备的名称，偏用户识别

四、关键信息 2：BR/EDR-only 和 LE-only 获取名称的方式不同

规范分别说了两种情况。

1. BR/EDR-only 实现

对于经典蓝牙 BR/EDR-only 设备，名称通过：

复制代码

LMP_NAME_REQ
LMP_NAME_RES

获得。

也就是说，本地设备向远端设备请求名称，远端设备通过 LMP_NAME_RES 返回名称字符串。

这是经典蓝牙链路层/基带相关的名称发现方式。

2. LE-only 实现

对于 BLE-only 设备，名称保存在：

复制代码

Device Name Characteristic

也就是 GATT 的 Device Name 特征值 中。

它属于 GAP Service 里的一个 Characteristic。

常见 UUID 是：

复制代码

GAP Service UUID:        0x1800
Device Name UUID:        0x2A00
Appearance UUID:         0x2A01

所以对于 BLE 来说，规范意义上的 Bluetooth Device Name 可以通过读取：

复制代码

Generic Access Service / Device Name Characteristic

获得。

也就是：

复制代码

Service: 0x1800
Characteristic: 0x2A00

五、关键信息 3：双模设备应该只有一个 Bluetooth Device Name

这句话很重要：

复制代码

A BR/EDR/LE implementation shall have a single Bluetooth Device Name

意思是：

如果一个设备同时支持经典蓝牙和 BLE，那么它应该只有一个 Bluetooth Device Name。

不能出现：

复制代码

经典蓝牙名称：TWS876-SPP
BLE 名称：TWS876-BLE

从规范要求看，双模设备的 Bluetooth Device Name 应该保持一致。

也就是说，无论通过 BR/EDR 物理信道还是 LE 物理信道进行名称发现，发现到的 Bluetooth Device Name 应该是同一个。

不过在实际产品中，很多厂商可能会在广播 Local Name、系统显示名称、GATT Device Name 中使用不同名字，这就会造成 App 侧看到的名称不一致。

所以你在实际开发中要区分：

复制代码

规范意义上的 Bluetooth Device Name
实际广播包里的 Local Name
系统扫描回调里的 name
GATT 0x2A00 读取到的 Device Name

六、关键信息 4：UI 层面应该叫 Bluetooth Device Name

规范明确说：

当 UI 层面提到这个名称时，应该使用：

复制代码

Bluetooth Device Name

中文可以翻译为：

复制代码

蓝牙设备名称

如果你做蓝牙调试工具 App，可以这样显示：

复制代码

Bluetooth Device Name: TWS876

或者中文界面：

复制代码

蓝牙设备名称：TWS876

但如果你要做得更严谨，尤其是在 BLE 扫描结果中，建议区分不同来源：

复制代码

Local Name: TWS876
Device Name: TWS876
System Name: TWS876

因为扫描阶段拿到的名称，通常可能来自广播数据或扫描响应数据中的 Local Name，而不一定是通过 GATT 读取到的 Device Name Characteristic。

七、关键信息 5：Bluetooth Device Name 最多 248 字节

规范说：

复制代码

The Bluetooth Device Name can be up to 248 bytes

也就是说，Bluetooth Device Name 最大长度是：

复制代码

248 bytes

注意，这里是 字节 bytes，不是字符 characters。

这点很关键。

因为它使用 UTF-8 编码，不同字符占用的字节数不同。

例如：

复制代码

通常占 1 个字节。

复制代码

蓝

通常占 3 个字节。

某些 emoji 可能占 4 个字节。

所以不能简单理解成"最多 248 个字符"。

更准确地说：

复制代码

最多 248 字节，具体能输入多少个字符取决于字符编码后占几个字节。

八、关键信息 6：Bluetooth Device Name 使用 UTF-8 编码

规范说：

复制代码

It shall be encoded according to UTF-8

也就是：

复制代码

Bluetooth Device Name 必须按照 UTF-8 编码。

这意味着它理论上可以支持非英文字符，例如中文、日文、韩文等。

例如：

复制代码

蓝牙温度计
智能手环
键盘

但是，由于 UTF-8 中中文字符通常占 3 个字节，所以可用字符数会减少。

例如：

复制代码

蓝牙温度计

5 个中文字符，通常占 15 字节。

九、为什么原文说可能少到 62 个字符？

原文说：

复制代码

therefore the name entered on the UI level may be restricted to as few as 62 characters if codepoints outside the range U+0000 to U+007F are used

意思是：

如果使用了超出 U+0000 到 U+007F 范围的字符，UI 层面输入的名称可能会被限制到最少 62 个字符。

原因是：

U+0000 到 U+007F 基本对应 ASCII 范围
ASCII 字符在 UTF-8 中通常占 1 字节
超出这个范围的字符可能占多个字节
某些 Unicode 字符在 UTF-8 中最多可能占 4 字节

所以：

复制代码

248 bytes ÷ 4 bytes = 62 characters

这就是 62 个字符的来源。

也就是说，如果 UI 要保证任何 Unicode 字符都能输入，那么为了不超过 248 字节，可能要限制到 62 个字符。

十、关键信息 7：远端设备不一定能处理完整名称

规范最后两句话非常实用：

复制代码

A device cannot expect that a general remote device is able to handle more than the first 40 characters of the Bluetooth Device Name.

意思是：

一个设备不能假设普通远端设备一定能处理 Bluetooth Device Name 的前 40 个字符之后的内容。

也就是说，虽然规范允许最多 248 字节，但你不能指望所有远端设备都能完整显示或处理这么长的名称。

后面又说：

复制代码

If a remote device has limited display capabilities, it may use only the first 20 characters.

意思是：

如果远端设备显示能力有限，它可能只使用前 20 个字符。

这对产品命名很关键。

如果设备名称很长，比如：

复制代码

MyDevice Bluetooth Low Energy Temperature Sensor Version 2026

有些设备或 App 可能只显示：

复制代码

MyDevice Bluetooth

甚至更短。

因此，设备名称的关键信息应该尽量放在前面。

十一、结合 BLE App 开发怎么理解？

做 BLE App 时，这部分非常有价值。

因为 App 中经常会显示设备名称，但名称来源可能不止一种。

1. 广播数据中的 Local Name

BLE 广播包或扫描响应包中可以带：

复制代码

Complete Local Name
Shortened Local Name

比如广播数据中可能有：

复制代码

09 09 41 54 46 22 42 58 35 32 31

其中 09 是 AD Type，表示 Complete Local Name。

这个是广播/扫描响应里的 Local Name。

2. GATT 中的 Device Name Characteristic

连接设备后，可以读取：

复制代码

Service UUID: 0x1800
Characteristic UUID: 0x2A00

得到 Device Name。

这个才是规范这里说的 LE-only 实现中持有的 Device Name Characteristic。

3. 系统 API 返回的 name

在 iOS / Android 中，扫描回调里可能也会返回设备名称。

但是这个名称可能来自：

复制代码

广播数据
扫描响应数据
系统缓存
历史连接记录
GATT Device Name

不同平台、不同系统版本、不同设备行为可能有差异。

所以做调试工具类 App 时，建议不要只显示一个笼统的 name，而是尽量区分：

复制代码

Advertised Local Name
GATT Device Name
System Device Name

这样用户更容易理解为什么有时"名称不一致"。

十二、这部分和广播 Local Name 的关系

这里要特别注意：

Bluetooth Device Name 不等于广播数据里的 Local Name，但两者通常会有关联。

广播数据中可以携带：

复制代码

Shortened Local Name
Complete Local Name

它是广播数据的一部分，用于扫描阶段让中心设备看到一个名字。

而 Bluetooth Device Name 在 BLE-only 实现中，是 GAP Service 中 Device Name Characteristic 的值。

理想情况下，它们应该一致。

但实际中可能出现：

复制代码

广播 Local Name: TWS876
GATT Device Name: nRF BLE Module
系统显示 Name: nRF-TWS876

所以在分析问题时，要问清楚：

复制代码

你说的"设备名称"，是扫描广播里解析出来的 Local Name？
还是连接后读取 0x2A00 得到的 Device Name？
还是手机系统 API 返回的 name？

这个区分非常重要。

十三、这一节应该怎么记？

可以直接记成下面这些话：

复制代码

Bluetooth Device Name 是蓝牙设备暴露给远端设备的用户友好名称。

在 UI 层面，规范建议使用 Bluetooth Device Name 这个术语。

对于 BR/EDR-only 设备，名称通过 LMP_NAME_REQ / LMP_NAME_RES 获取。

对于 LE-only 设备，名称保存在 GAP Service 的 Device Name Characteristic 中，也就是 0x1800 服务下的 0x2A00 特征。

对于 BR/EDR/LE 双模设备，应该只有一个统一的 Bluetooth Device Name，不应该因为经典蓝牙和 BLE 通道不同而显示不同名称。

Bluetooth Device Name 最多 248 字节，使用 UTF-8 编码。

由于 UTF-8 中非 ASCII 字符可能占多个字节，所以 248 字节不等于 248 个字符。

普通远端设备不一定能处理超过前 40 个字符的名称，显示能力有限的设备可能只使用前 20 个字符。

因此设备名称不要太长，关键信息应该尽量放在前面。

十四、对当前学习 BLE 的提醒

这部分虽然在 GAP 里，但它对做 BLE App 很实用。

重点不是记 BR/EDR 的 LMP_NAME_REQ 和 LMP_NAME_RES，那是经典蓝牙相关内容，可以先不用深挖。

应该重点记 BLE 相关的 3 点：

复制代码

1. LE-only 设备的 Bluetooth Device Name 来自 Device Name Characteristic，也就是 GAP Service 0x1800 里的 0x2A00。

2. 扫描阶段看到的 Local Name 和连接后读取的 Device Name Characteristic，不一定完全一样。

3. 设备名称是 UTF-8 编码，最大 248 字节，但实际产品命名要尽量短，前 20～40 个字符最好能表达核心信息。

对于现在理解 BLE 来说，这一节可以不用死磕，但是要建立一个很重要的概念：

复制代码

"设备名称"不是一个单一来源的东西。
BLE 开发中要区分：广播名称、GATT Device Name、系统缓存名称、UI 显示名称。

这部分讲的是 Bluetooth Passkey（蓝牙配对码 / 蓝牙 PIN） 在配对过程中的作用、在 UI 上应该怎么叫、以及它的表示方式。

它的核心不是讲完整的蓝牙安全机制，而是规定：

蓝牙配对过程中用于认证的 PIN / Passkey，在用户界面上应该统一称为 Bluetooth Passkey，并说明不同配对机制下 Passkey/PIN 的格式限制。

一、这部分想表达什么？

这部分主要表达 4 件事：

Bluetooth Passkey 可以用于两个蓝牙设备在配对时进行认证。
用户界面上不要叫 Bluetooth PIN，应该叫 Bluetooth Passkey。
在 Secure Simple Pairing / Security Manager 中，Bluetooth Passkey 是 6 位数字。
在 Legacy Pairing 中，PIN 的表示更复杂，可能是字符形式，也可能转换成底层使用的字节形式。

可以先简单理解成：

复制代码

Bluetooth Passkey / Bluetooth PIN 都是配对认证时用到的"配对码"。

但在 UI 层面，规范推荐统一叫 Bluetooth Passkey。

对于现代 BLE 配对，通常看到的是 6 位数字 Passkey，例如 000000 ~ 999999。

对于传统 Legacy Pairing，PIN 可能涉及字符、编码、长度、字节转换等问题。

二、原文大意翻译

3.2.3 Bluetooth Passkey（Bluetooth PIN）

3.2.3.1 定义

Bluetooth Passkey 可以在配对过程中用于两个蓝牙设备之间的相互认证，也就是在创建共同链路密钥时使用。

Passkey 可以在配对过程中用于生成初始链路密钥。

PIN 可以由用户在 UI 层面输入，也可以预先存储在设备中。

例如，有些设备没有输入和显示数字的界面，这种设备可能会把 PIN 固定存储在设备内部。

3.2.3.2 用户界面层级上的术语

当在 UI 层面提到 Bluetooth PIN 时，应该使用术语：

复制代码

Bluetooth Passkey

也就是：

复制代码

蓝牙配对码

或者：

复制代码

Bluetooth Passkey

3.2.3.3 表示方式

Bluetooth Passkey 有多种不同表示方式。

从高层来看，主要有两类：

复制代码

1. 用于 Secure Simple Pairing 和 Security Manager 的表示方式
2. 用于 Legacy Pairing 的表示方式

在 Legacy Pairing 中，它通常被称为 Bluetooth PIN。

对于 Secure Simple Pairing 和 Security Manager，Bluetooth Passkey 是一个 6 位数字值。

它用整数表示，范围是：

复制代码

0x00000000 ~ 0x000F423F

也就是十进制：

复制代码

000000 ~ 999999

菜单值可以用作：

复制代码

Authentication stage 1 的输入值

或者用作：

复制代码

Security Manager 中的 TK 值

对于 Legacy Pairing，Bluetooth PIN 在不同层级有不同表示。

其中：

复制代码

PINBB：Baseband 层使用
PINUI：用户界面层使用

PINBB 用于 Pairing 过程中的初始化密钥计算。

PINUI 是用户在 UI 上输入的 PIN 字符表示形式。

从 PINUI 转换到 PINBB 时，应按照 UTF-8 编码转换。

PINBB 最大可以是：

复制代码

128 bit = 16 bytes

PIN code 最多可以是 16 个字符。

为了达到完整安全等级，所有 PIN 都应该是 16 个字符长。

可变 PIN 应该由 Basic Latin 范围内的字母数字字符组成，也就是 Unicode 范围：

复制代码

U+0000 ~ U+007F

如果 PIN 中包含十进制数字，那么这些数字应该使用 Unicode Basic Latin 字符编码，也就是：

复制代码

U+0030 ~ U+0039

为了兼容带数字键盘的设备，固定 PIN 应该只由十进制数字组成，可变 PIN 也应该只由十进制数字组成。

如果设备支持输入 Basic Latin 之外的字符，也可以使用其他 Unicode 字符，但不应该使用 Halfwidth and Fullwidth Forms 范围：

复制代码

U+FF00 ~ U+FFEF

三、关键信息 1：Bluetooth Passkey 用于配对认证

原文说：

复制代码

The Bluetooth Passkey may be used to authenticate two Bluetooth devices with each other during the creation of a mutual link key via the pairing procedure.

意思是：

Bluetooth Passkey 可以在配对过程中，用于两个蓝牙设备之间的认证。

通俗说，就是：

复制代码

设备 A 和设备 B 要建立可信关系时，需要确认"你确实是我要配对的那个设备"。

这个确认过程里，可能会用到 Passkey。

例如手机连接某个蓝牙设备时，可能出现：

复制代码

请输入配对码：123456

或者：

复制代码

请确认另一台设备上显示的数字是否为 123456

这里的 123456 就属于 Passkey 相关内容。

四、关键信息 2：UI 上应该叫 Bluetooth Passkey，不建议叫 Bluetooth PIN

这一句很关键：

复制代码

When the Bluetooth PIN is referred to on the UI level, the term 'Bluetooth Passkey' should be used.

意思是：

在用户界面上，如果要提到 Bluetooth PIN，应该使用：

复制代码

Bluetooth Passkey

也就是说，规范更推荐在 UI 上叫：

复制代码

蓝牙配对码
Bluetooth Passkey

而不是：

复制代码

Bluetooth PIN
PIN code
PIN

当然，实际产品中很多系统和 App 仍然会说"PIN 码"或"配对码"，这是历史习惯。

如果你做蓝牙 App，我建议中文界面写：

复制代码

蓝牙配对码

英文界面写：

复制代码

Bluetooth Passkey

如果面向开发者，也可以写成：

复制代码

Bluetooth Passkey / PIN

这样兼顾规范术语和用户理解。

五、关键信息 3：Secure Simple Pairing / Security Manager 中是 6 位数字

这部分对 BLE 最重要。

原文说：

复制代码

For Secure Simple Pairing and Security Manager, the Bluetooth Passkey is a 6-digit numeric value.

也就是：

复制代码

对于 Secure Simple Pairing 和 Security Manager，Bluetooth Passkey 是一个 6 位数字值。

范围是：

复制代码

000000 ~ 999999

规范里用十六进制写成：

复制代码

0x00000000 ~ 0x000F423F

这里的 0x000F423F 换成十进制就是：

复制代码

所以 BLE 配对时经常看到的 6 位数字码，比如：

复制代码

都属于这个范围。

六、关键信息 4：这个 6 位 Passkey 和 BLE Security Manager 有关

原文中提到：

复制代码

Security Manager
TK value

这对 BLE 很关键。

在 BLE 里，配对、安全、加密相关流程主要由：

复制代码

SMP：Security Manager Protocol

处理。

在 Legacy Pairing 阶段，可能会用到：

复制代码

TK：Temporary Key，临时密钥

Passkey 可以作为 Security Manager 流程中的 TK 值参与后续密钥生成。

现在不需要立刻把 SMP 的所有细节啃完，但要知道：

复制代码

BLE 里面看到的 6 位配对码，不只是 UI 上的数字，它会参与安全配对过程中的密钥生成或认证。

七、关键信息 5：Legacy Pairing 里的 PIN 更复杂

原文说：

复制代码

For legacy pairing, the Bluetooth PIN has different representations on different levels.

意思是：

在 Legacy Pairing 中，Bluetooth PIN 在不同层级有不同表示。

主要有两个：

复制代码

PINUI：用户界面层看到/输入的 PIN
PINBB：Baseband 层使用的 PIN

可以这样理解：

复制代码

PINUI 是人输入的形式，比如 "1234" 或 "0196554200906493"。

PINBB 是底层计算配对初始化密钥时使用的字节序列。

二者之间需要转换，转换方式按：

复制代码

UTF-8

八、关键信息 6：PINBB 最大 128 bit，也就是 16 字节

原文说：

复制代码

PINBB may be 128 bits (16 bytes).

也就是说，Legacy Pairing 中底层使用的 PINBB 最大是：

复制代码

128 bit = 16 bytes

这里要注意：

复制代码

16 bytes 不一定等于 16 个字符

如果 PINUI 全是 ASCII 数字或英文字母，那么：

复制代码

1 个字符 = 1 byte

所以最多可以是 16 个字符。

例如：

复制代码

0196554200906493

这是 16 个数字字符，每个数字 1 字节，刚好 16 字节。

但如果包含非 ASCII 字符，比如：

复制代码

Børnelitteratur

其中 ø 在 UTF-8 中占 2 个字节，所以虽然看起来字符数可能没有超过 16，但编码后字节数可能已经达到 16 字节。

九、关键信息 7：为了完整安全性，PIN 最好是 16 个字符

原文说：

复制代码

In order to take advantage of the full level of security all PINs should be 16 characters long.

意思是：

为了利用完整的安全等级，PIN 应该是 16 个字符长。

这是 Legacy Pairing 时代的说法，主要是因为 PIN 会参与密钥计算，PIN 越短，被猜测或暴力破解的空间越小。

例如下面这种固定 PIN：

复制代码

0000
1234

虽然兼容性好，但安全性很弱。

而 16 位 PIN：

复制代码

0196554200906493

安全性更高。

不过在实际消费电子设备里，很多经典蓝牙设备为了方便，仍然使用：

复制代码

0000
1234
8888

这就是典型的兼容性优先、安全性较弱的设计。

十、关键信息 8：固定 PIN 和可变 PIN 的推荐组成

规范提到两种 PIN：

复制代码

Fixed PIN：固定 PIN
Variable PIN：可变 PIN

1. 固定 PIN

固定 PIN 是设备预置好的 PIN，例如：

复制代码

0000
1234
8888

用户不能改，或者通常不需要输入复杂内容。

规范为了兼容带数字键盘的设备，建议固定 PIN 只由十进制数字组成。

也就是：

复制代码

0 ~ 9

2. 可变 PIN

可变 PIN 是可以变化的 PIN，可能由用户输入或设备动态生成。

规范也建议为了兼容性，可变 PIN 也尽量只由十进制数字组成。

所以从实际产品角度看：

复制代码

最兼容的 Passkey / PIN 形式就是纯数字。

这也是为什么蓝牙配对码常见形式是：

复制代码

6 位数字

而不是复杂密码。

十一、关键信息 9：数字应该使用 Basic Latin 的数字字符

规范特别说：

如果 PIN 中包含十进制数字，这些数字应该使用 Unicode Basic Latin 字符编码：

复制代码

U+0030 ~ U+0039

也就是普通 ASCII 数字：

复制代码

0 1 2 3 4 5 6 7 8 9

不要使用其他看起来像数字的字符。

例如不要用全角数字：

复制代码

１２３４５６

虽然肉眼看起来像数字，但它们不是 Basic Latin 范围内的数字字符。

这是为了避免兼容性问题。

十二、关键信息 10：不应该使用 Halfwidth and Fullwidth Forms

规范说：

不应该使用 Unicode 的 Halfwidth and Fullwidth Forms 范围：

复制代码

U+FF00 ~ U+FFEF

原因是这些字符容易和普通 ASCII、日文片假名、韩文、标点符号等产生兼容性问题。

例如：

复制代码

Ａ

这是全角 A。

它看起来像：

复制代码

但编码和码点完全不同。

同样：

复制代码

１

这是全角数字 1。

它看起来像：

复制代码

但不是同一个字符。

蓝牙 PIN / Passkey 涉及配对认证，不能出现"看起来一样、编码不一样"的情况，否则用户输入正确但设备不认，或者不同设备解析不一致。

十三、表格示例在说明什么？

截图中的表格给了两个例子。

示例 1

用户输入：

复制代码

0196554200906493

对应 PINBB：

复制代码

length = 16
value = 0x30 0x31 0x39 0x36 0x35 0x35 0x34 0x32 0x30 0x30 0x39 0x30 0x36 0x34 0x39 0x33

这里每个数字字符都是 ASCII 编码。

例如：

复制代码

'0' -> 0x30
'1' -> 0x31
'9' -> 0x39

所以 16 个数字字符正好转换成 16 个字节。

示例 2

用户输入：

复制代码

Børnelitteratur

对应 PINBB 长度也是 16。

原因是其中的 ø 不是 Basic Latin 字符，它在 UTF-8 中不是 1 个字节，而是 2 个字节：

复制代码

ø -> 0xC3 0xB8

所以这个字符串虽然字符数少于或等于 16，但编码成 UTF-8 后占用 16 字节。

这个例子是为了说明：

复制代码

PIN 的限制最终看的是字节长度，不只是字符数量。

十四、结合 BLE 开发怎么理解？

对于你现在学习 BLE，最应该关注的是 Secure Simple Pairing / Security Manager 这一块，而不是经典蓝牙 Legacy PIN 的所有细节。

你可以这样分层理解：

复制代码

经典蓝牙 BR/EDR：
更容易遇到 PIN、0000、1234、LMP、Baseband 这些概念。

BLE：
主要关注 Security Manager、Pairing、Passkey、TK、LTK、加密、绑定等概念。

在 BLE App 开发中，你通常会遇到几种配对方式：

复制代码

Just Works
Passkey Entry
Numeric Comparison
Out of Band

其中和这节最相关的是：

复制代码

Passkey Entry

例如：

复制代码

外设显示 123456，手机输入 123456

或者：

复制代码

手机显示 123456，用户在外设上输入 123456

这就是典型的 Passkey 参与认证。

十五、这部分和做 App 有什么关系？

如果做蓝牙 App，尤其是 BLE 调试工具 App，需要注意：

1. UI 上尽量叫"配对码"或 "Bluetooth Passkey"

中文用户更容易理解：

复制代码

请输入蓝牙配对码

英文界面更规范：

复制代码

Enter Bluetooth Passkey

不要只写：

复制代码

PIN

因为 PIN 在传统蓝牙和 UI 规范里容易产生历史混淆。

2. BLE Passkey 通常是 6 位数字

所以输入框应该限制为：

复制代码

只能输入数字
长度 6 位
范围 000000 ~ 999999

注意：

复制代码

000000 是合法的 6 位表示

不要因为转成整数后变成 0，就把前导 0 丢掉。

例如用户看到的 Passkey 是：

复制代码

App UI 上就应该显示：

复制代码

不能显示成：

复制代码

因为 Passkey 在用户界面上是 6 位数字表达。

3. 对 Legacy PIN，不要随便支持复杂 Unicode 字符

如果做经典蓝牙相关工具，最好优先支持纯数字 PIN，例如：

复制代码

0000
1234
8888

如果要支持字符 PIN，也要注意：

复制代码

UTF-8 编码
最大 16 bytes
不是简单最大 16 characters

不过如果当前主要目标是 BLE，可以暂时不深挖 Legacy PIN 的复杂编码问题。

十六、这节容易混淆的点

1. Passkey 和 PIN 是不是一回事？

可以这样理解：

复制代码

历史上很多地方叫 PIN；
规范在 UI 层面推荐叫 Bluetooth Passkey；
在 Legacy Pairing 中，PIN 这个叫法更常见；
在 Secure Simple Pairing / BLE Security Manager 中，更常说 Passkey。

所以它们高度相关，但语境不同。

2. Passkey 是不是一定用于所有配对？

不是。

Bluetooth Passkey may be used，也就是"可能被使用"。

蓝牙配对不一定都要用户输入 Passkey。

例如 BLE 中的：

复制代码

Just Works

通常就没有用户输入 6 位配对码的过程。

而：

复制代码

Passkey Entry

才会涉及用户输入或显示 6 位 Passkey。

3. 6 位 Passkey 是字符串还是整数？

规范说它是一个：

复制代码

6-digit numeric value

同时又说它用整数表示，范围是：

复制代码

0 ~ 999999

但是在 UI 展示上，应该把它当成 6 位数字码 来处理。

比如：

复制代码

底层数值是 123，但 UI 上必须保留 6 位：

复制代码

否则用户会误解。

十七、这一节你应该怎么记？

可以直接记成下面这段：

复制代码

Bluetooth Passkey 是蓝牙配对过程中可能用于认证的配对码。

在 UI 层面，规范推荐使用 Bluetooth Passkey，而不是 Bluetooth PIN。

对于 Secure Simple Pairing 和 BLE Security Manager，Bluetooth Passkey 是 6 位数字，范围是 000000 到 999999。

在 Legacy Pairing 中，PIN 的表示更复杂，用户界面输入的是 PINUI，底层 Baseband 使用的是 PINBB，PINUI 到 PINBB 按 UTF-8 转换，PINBB 最大 16 字节。

Legacy PIN 为了完整安全性建议 16 个字符；为了兼容性，固定 PIN 和可变 PIN 都建议使用十进制数字。

对于 BLE App 开发，重点关注 6 位数字 Passkey，不要把前导 0 丢掉。

十八、对你当前学习 BLE 的建议

这部分里面有很多经典蓝牙 Legacy Pairing 的内容，现在可以先不用死磕。

现在重点记 BLE 相关的这几条就够了：

复制代码

1. UI 上应该叫 Bluetooth Passkey，中文可以叫"蓝牙配对码"。

2. BLE Security Manager 里的 Passkey 是 6 位数字，范围 000000 ~ 999999。

3. Passkey 不一定每次配对都会用，只有某些配对方式才会涉及，例如 Passkey Entry。

4. 处理 Passkey 时要保留 6 位显示，不要把 001234 显示成 1234。

5. Legacy PIN 的 PINUI / PINBB / UTF-8 / 16 bytes 这些内容，属于经典蓝牙兼容细节，可以先快速看过。

一句话总结：

复制代码

这一节主要是告诉你：蓝牙配对码在 UI 上应该叫 Bluetooth Passkey；在 BLE 安全管理中，它通常是 6 位数字；而传统蓝牙 PIN 的表示和编码规则更复杂。

这部分讲的是 Class of Device（设备类别，CoD）。

不过要先注意一个重点：这一节主要偏 经典蓝牙 BR/EDR，不是 BLE-only 的核心内容。

它想说明的是：

Class of Device 是在 BR/EDR 设备发现过程中获得的一个参数，用来粗略描述设备类型和服务类型；但它不能被当成判断设备具体支持哪些服务的可靠依据。

一、原文大意翻译

3.2.4 Class of Device

设备类别

3.2.4.1 Definition

定义

Class of Device 是在 BR/EDR 物理传输 的设备发现过程中接收到的一个参数，用来表示设备类型。

Class of Device 参数只用于：

复制代码

使用 BR/EDR 物理传输的 BR/EDR 设备
以及使用 BR/EDR 物理传输的 BR/EDR/LE 双模设备

也就是说，它不是 BLE-only 设备的核心参数。

3.2.4.2 Term on user interface level

用户界面层级上的术语

Class of Device 参数中的信息，在 UI 层面应该称为：

复制代码

Bluetooth Device Class

也就是：

复制代码

蓝牙设备类别

这里主要指：

复制代码

Major Device Class
Minor Device Class

也就是主设备类别和次设备类别。

Class of Device 中的 service class 字段，在 UI 层面应该称为：

复制代码

Bluetooth Service Type

也就是：

复制代码

蓝牙服务类型

如果 UI 上把 Bluetooth Device Class 和 Bluetooth Service Type 的信息混合起来使用，那么应该称为：

复制代码

Bluetooth Device Type

也就是：

复制代码

蓝牙设备类型

3.2.4.3 Representation

表示方式

Class of Device 是一个 bit field，也就是位字段。

它的具体定义在规范引用的章节中。

在 UI 层面，Class of Device 信息如何展示，由具体实现决定。

也就是说，规范没有强制要求 App 或系统界面必须按某一种固定格式显示。

3.2.4.4 Usage

用途

有些设备会提供多个服务，而同一个服务也可能由不同类型的设备提供。

所以，设备类型和设备支持的服务之间不是一一对应关系。

因此，不能通过 Major Device Class 和 Minor Device Class 来判断某个设备是否支持某个具体服务。

Class of Device 可以用作一种指示信息：

复制代码

1. 指示哪些设备最可能支持目标服务
2. 在进行服务发现请求之前，先粗略筛选设备
3. 当多个设备支持同一个服务时，帮助用户选择设备

但是它不能替代真正的服务发现。

二、这部分想表达什么？

这部分主要想表达：

Class of Device 是经典蓝牙设备发现阶段用来描述设备大致类型的参数，但它只是一个粗略分类，不能拿它来准确判断设备支持哪些服务。

比如一个设备的 Class of Device 显示它是：

复制代码

Audio/Video Device
Headset

这能说明它大概率是音频设备，但不能严格证明它一定支持某个具体 Profile 或服务。

再比如一个设备看起来像：

复制代码

Phone
Computer
Keyboard
Mouse
Speaker

这些只是设备类别层面的信息，不等于完整的服务能力列表。

真正要知道它支持什么服务，仍然需要做服务发现。

三、关键信息 1：Class of Device 主要用于 BR/EDR

原文第一段很关键：

复制代码

Class of Device is a parameter received during the device discovery procedure on the BR/EDR physical transport

意思是：

Class of Device 是在 BR/EDR 物理传输上的设备发现过程 中接收到的参数。

所以它主要属于经典蓝牙语境。

你现在学习 BLE 时要注意：

复制代码

Class of Device 不是 BLE-only 设备的核心概念。

BLE 里面更常见的是：

复制代码

Advertising Data
Appearance
Service UUID
Local Name
Manufacturer Specific Data
Service Data

而不是 Class of Device。

所以如果你的目标是理解 BLE 广播、扫描、连接、GATT，这一节可以快速看过，不需要深挖。

四、关键信息 2：Class of Device 用来表示设备类型

Class of Device 的作用是表示设备类型。

比如经典蓝牙设备发现时，可能通过这个字段知道远端设备大致是：

复制代码

Computer
Phone
Audio/Video
Peripheral
Imaging
Wearable
Toy
Health

进一步还可以有更细的分类，例如：

复制代码

Keyboard
Mouse
Joystick
Headset
Loudspeaker
Smartphone
Laptop

不过这里要强调：它是"类别信息"，不是"能力清单"。

也就是说，它更像是设备的标签，而不是设备的完整功能描述。

五、关键信息 3：UI 上有三个术语要区分

这一节最容易混的是几个 UI 术语。

1. Bluetooth Device Class

这个对应 Class of Device 里面的：

复制代码

Major Device Class
Minor Device Class

也就是设备大类和设备小类。

可以理解为：

复制代码

这个设备是什么类型？

例如：

复制代码

Phone
Computer
Audio/Video
Peripheral
Keyboard
Mouse

所以 UI 上可以显示为：

复制代码

Bluetooth Device Class: Keyboard

或者中文：

复制代码

蓝牙设备类别：键盘

2. Bluetooth Service Type

这个对应 Class of Device 里面的：

复制代码

Service Class field

可以理解为：

复制代码

这个设备声称自己大概提供什么类型的服务？

例如可能和下面这些服务类别相关：

复制代码

Audio
Rendering
Capturing
Object Transfer
Networking
Telephony
Information

所以 UI 上可以显示为：

复制代码

Bluetooth Service Type: Audio

或者：

复制代码

蓝牙服务类型：音频

3. Bluetooth Device Type

如果 UI 同时混合使用了设备类别和服务类型，那么应该叫：

复制代码

Bluetooth Device Type

也就是：

复制代码

蓝牙设备类型

例如 UI 上综合显示：

复制代码

Bluetooth Device Type: Audio Headset

这里可能既包含设备类别信息，也包含服务类型信息，所以用 Bluetooth Device Type 更合适。

六、关键信息 4：Class of Device 是 bit field

原文说：

复制代码

The Class of Device is a bit field

意思是：

Class of Device 不是一个普通字符串，而是一个按 bit 位划分含义的字段。

它内部可能包含：

复制代码

Service Class
Major Device Class
Minor Device Class
Format Type

你可以简单理解成：

复制代码

Class of Device 是一个数字；
这个数字的不同 bit 位代表不同含义；
解析后才能得到设备类别和服务类型。

例如某个经典蓝牙设备的 CoD 可能是一个十六进制值：

复制代码

0x240404

这个值本身不直观，需要按 bit 位解析，才能知道它表示什么设备类别和服务类别。

七、关键信息 5：UI 怎么显示由实现决定

原文说：

复制代码

The UI-level representation of the information in the Class of Device is implementation specific.

意思是：

Class of Device 在 UI 上怎么显示，规范没有强制统一格式，由具体实现决定。

所以不同系统或 App 可能显示成：

复制代码

Audio Device
Headset
Bluetooth Audio
Unknown Device
Phone
Computer
Peripheral

也可能完全不显示 CoD 解析结果。

这和前面 BD_ADDR 的显示要求不同。

BD_ADDR 规范明确说 UI 上用 12 个十六进制字符表示，例如：

复制代码

00:0C:3E:3A:4B:69

但 Class of Device 这里没有给出固定 UI 格式。

八、关键信息 6：不要用设备类别判断具体服务支持

这是本节最重要的一句话：

复制代码

The major and minor device class field should not be used to determine whether a device supports any specific service(s).

意思是：

不能用 Major Device Class 和 Minor Device Class 来判断设备是否支持某个具体服务。

原因是：

复制代码

设备类型 和 服务支持 不是一一对应关系。

比如：

复制代码

一个手机可以支持音频、文件传输、网络共享、HID 等多个服务。

一个音频服务也可能由耳机、音箱、车机、电脑等不同设备类型提供。

一个键盘类设备可能支持 HID，但不能只凭 Keyboard 类别就完全替代服务发现。

一个设备类别显示为 Audio/Video，也不代表它一定支持你想要的具体音频 Profile。

所以 CoD 只能作为粗略参考，不能作为最终判断依据。

九、Class of Device 的正确用途

Class of Device 可以用于"预筛选"，但不能用于"最终确认"。

可以做的事情

比如你在经典蓝牙扫描结果里看到很多设备，可以用 Class of Device 帮用户快速识别：

复制代码

这个看起来像耳机
这个看起来像手机
这个看起来像电脑
这个看起来像键盘

或者在服务发现之前，先猜测：

复制代码

这个设备更可能支持音频相关服务
这个设备更可能是输入设备
这个设备更可能是电话类设备

也可以在多个候选设备中帮助用户选择：

复制代码

用户要连接耳机时，优先展示 Audio/Video 类设备。

不能做的事情

不能写死逻辑说：

复制代码

只要 Class of Device 是 Keyboard，就一定支持某个 HID 服务。

只要 Class of Device 是 Audio，就一定支持某个具体音频协议。

只要 Class of Device 不是某个类别，就一定不支持目标服务。

因为最终能力还是要靠真正的服务发现确认。

经典蓝牙里要看 SDP 等服务发现结果。

BLE 里则要看广播中的 Service UUID，或者连接后进行 GATT Service Discovery。

十、和 BLE 里的 Appearance 有点像，但不是一回事

如果你学习 BLE，这里可以顺便建立一个对比：

复制代码

经典蓝牙 BR/EDR：Class of Device
BLE：Appearance

它们都有点像"设备外观/设备类别提示"。

BLE 的 Appearance 也可以告诉远端设备：

复制代码

Generic Phone
Generic Computer
Generic Watch
Heart Rate Sensor
Keyboard
Mouse

但是 Appearance 同样不能完全替代服务发现。

比如 BLE 设备的 Appearance 显示为 Heart Rate Sensor，说明它看起来像心率设备，但真正是否支持 Heart Rate Service，还是要看广播的 Service UUID 或连接后的 GATT 服务发现结果。

所以你可以这样理解：

复制代码

Class of Device 是 BR/EDR 设备发现里的设备类别提示；
Appearance 是 BLE/GAP 中用于描述设备外观/类别的提示；
二者都不能替代真正的服务发现。

十一、结合你做蓝牙 App 怎么理解？

如果你做的是 BLE 调试工具，比如类似 nRF Connect / LightBlue，那么这一节不是重点。

因为 BLE 扫描结果里，你更应该关注：

复制代码

Address
Address Type
RSSI
Advertising Data
Local Name
Service UUIDs
Manufacturer Specific Data
Service Data
Tx Power
Appearance

而不是 Class of Device。

但如果你的 App 同时支持经典蓝牙，比如：

复制代码

SPP
A2DP
HFP
HID over BR/EDR
双模设备发现

那么 Class of Device 就有参考价值。

你可以在界面中显示：

复制代码

Bluetooth Device Class: Audio/Video - Headset
Bluetooth Service Type: Audio
Bluetooth Device Type: Audio Headset

但是不要只靠这个字段决定能不能连接或能不能通信。

十二、学习优先级建议

对于你当前目标是理解 BLE，可以这样处理：

复制代码

Class of Device：快速了解即可，不需要深挖。

因为它主要属于：

复制代码

BR/EDR discovery
经典蓝牙设备发现
双模设备使用 BR/EDR 传输时的发现参数

如果你现在主要学习：

复制代码

BLE Advertising
BLE Scanning
BLE Connection
GATT
GAP
HCI LE Commands

那么更应该优先学习：

复制代码

Advertising Data
AD Type
Local Name
Service UUID
Appearance
Manufacturer Specific Data
Service Data
Address Type
Filter Policy
GATT Service Discovery

十三、这一节你应该怎么记？

可以直接记成下面这段：

复制代码

Class of Device 是 BR/EDR 设备发现过程中获得的一个参数，用来粗略表示设备类型。

它只用于使用 BR/EDR 物理传输的 BR/EDR 设备或 BR/EDR/LE 双模设备，不是 BLE-only 的核心参数。

UI 层面上，设备类别信息应称为 Bluetooth Device Class；服务类别字段应称为 Bluetooth Service Type；如果混合使用设备类别和服务类别信息，则称为 Bluetooth Device Type。

Class of Device 是 bit field，UI 如何展示由具体实现决定。

Class of Device 只能用于辅助判断和预筛选，不能用来确定设备是否支持某个具体服务。真正的服务支持情况必须通过服务发现确认。

一句话总结：

复制代码

这一节主要告诉你：Class of Device 是经典蓝牙设备发现中的"设备类别提示"，可以帮助用户粗略识别设备类型，但不能替代真正的服务发现。

这部分讲的是 Appearance characteristic（外观特征值）。

它属于 BLE / GATT / GAP 相关内容，比上一节 Class of Device 更贴近 BLE。

它想表达的是：

BLE 设备可以通过 GAP Service 里的 Appearance characteristic，用一个 16-bit 数值告诉远端设备：我"看起来像什么设备"。远端设备可以把这个数值映射成图标或文字，帮助用户从视觉上识别设备类型。

一、原文大意翻译

3.2.5 Appearance characteristic

外观特征值

3.2.5.1 Definition

定义

Appearance characteristic 包含一个 16-bit 数值。

这个 16-bit 数值可以被映射成一个图标或字符串，用来描述设备在设备发现过程中的物理表现形式。

Appearance characteristic 是设备 GATT Server 上 GAP Service 的一个 Characteristic。

3.2.5.2 Usage at user interface level

用户界面层级上的使用

Appearance characteristic 的值应该被映射成一个图标、字符串，或者类似的内容，用来向用户传达设备的视觉描述。

这样用户就可以根据外观判断当前发现的是什么设备。

如果显示字符串，这个字符串应该被翻译成用户设备所选择的语言。

3.2.5.3 Representation

表示方式

Appearance characteristic 的值应该设置为 Bluetooth SIG 分配并定义的某一个 16-bit 数值。

在 UI 层面，Appearance characteristic 的值如何展示，由具体实现决定。

二、这部分想表达什么？

这部分主要表达的是：

Appearance 是 BLE 设备用来描述自己"外观类别"的一个 GAP 特征值。

比如一个 BLE 设备可以通过 Appearance 表示自己是：

复制代码

Generic Phone
Generic Computer
Generic Watch
Generic Clock
Generic Display
Generic Remote Control
Generic Thermometer
Heart Rate Sensor
Blood Pressure Sensor
Keyboard
Mouse
Joystick
Gamepad

这些值本质上不是字符串，而是一个 16-bit 数字。

远端设备拿到这个数字后，可以把它显示成：

复制代码

一个图标
一个设备类型文字
一个本地化后的名称

比如：

复制代码

Appearance value: 0x03C1
UI 显示：Keyboard
中文 UI 显示：键盘

三、关键信息 1：Appearance 是 BLE 中 GAP Service 的 Characteristic

原文说：

复制代码

It is a characteristic of the GAP Service located on the device's GATT Server.

意思是：

Appearance characteristic 是设备 GATT Server 上 GAP Service 的一个特征值。

在 BLE 里，GAP Service 通常是：

复制代码

Generic Access Service
UUID: 0x1800

其中常见的 Characteristic 包括：

复制代码

Device Name
UUID: 0x2A00

Appearance
UUID: 0x2A01

所以 Appearance 对应的是：

复制代码

Service: 0x1800
Characteristic: 0x2A01

这点非常重要。

也就是说，Appearance 不是广播包里随便写的字段，而是 GAP Service 里的一个标准 Characteristic。

四、关键信息 2：Appearance 是一个 16-bit 数值

Appearance characteristic 里面存的是：

复制代码

16-bit number

也就是：

复制代码

2 bytes

这个数值由 Bluetooth SIG 统一分配和定义。

也就是说，它不是厂商自己随便定义的。

例如，某个 Appearance 值可能表示：

复制代码

Generic Phone
Generic Computer
Generic Watch
Keyboard
Mouse
Heart Rate Sensor
Thermometer

远端设备读取到这个数值后，再根据 Bluetooth SIG 定义的表进行解释。

你可以这样理解：

复制代码

Appearance 本身是数字；
数字背后对应一个设备外观类别；
UI 可以把它转换成图标或文字。

五、关键信息 3：Appearance 用来描述设备"看起来像什么"

原文说：

复制代码

describes the physical representation of the device

意思是：

Appearance 用来描述设备的物理表现形式，或者说设备外观类别。

通俗理解就是：

复制代码

这个 BLE 设备从外观上看像什么？

例如：

复制代码

它像手机？
它像手表？
它像键盘？
它像鼠标？
它像心率传感器？
它像温度计？

它不是用来描述设备完整功能的。

比如一个设备 Appearance 是：

复制代码

Keyboard

只能说明它的外观或类别像键盘，不能完全替代 GATT 服务发现。

真正要判断它是否支持 HID over GATT，还要看它是否有相关 GATT Service。

六、关键信息 4：UI 上应该映射成图标或字符串

原文说：

复制代码

The Appearance characteristic value should be mapped to an icon or string or something similar

意思是：

UI 不应该直接把 Appearance 原始数值丢给普通用户看。

比如不建议普通用户界面只显示：

复制代码

Appearance: 0x03C1

更好的显示方式是：

复制代码

Appearance: Keyboard

或者中文：

复制代码

外观类型：键盘

甚至直接显示一个键盘图标。

对于调试工具 App，可以同时显示：

复制代码

Appearance: Keyboard
Value: 0x03C1

这样既方便普通理解，也方便开发者调试。

https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Assigned_Numbers/out/en/Assigned_Numbers.pdf

七、关键信息 5：如果显示字符串，应该做语言本地化

原文说：

复制代码

If a string is displayed, this string should be translated into the language selected by the user for the device.

意思是：

如果 UI 用文字显示 Appearance，那么这个文字应该翻译成用户设备选择的语言。

比如英文系统可以显示：

复制代码

Keyboard
Mouse
Heart Rate Sensor
Thermometer

中文系统可以显示：

复制代码

键盘
鼠标
心率传感器
温度计

这说明 Appearance 是偏用户界面的信息，不只是开发者调试信息。

八、关键信息 6：UI 展示方式由具体实现决定

原文最后说：

复制代码

The UI-level representation of the Appearance characteristic value is implementation specific.

意思是：

Appearance 在 UI 上到底怎么展示，规范没有强制规定。

可以显示成：

复制代码

图标
文字
图标 + 文字
原始数值 + 解析含义

比如不同 App 可以这样显示：

复制代码

方式一：
⌨️ Keyboard

方式二：
Appearance: Keyboard

方式三：
Appearance: 0x03C1 (Keyboard)

方式四：
设备类型：键盘

对于你做 BLE 调试工具 App，我建议使用：

复制代码

Appearance: Keyboard
Appearance Value: 0x03C1

这样更适合开发者。

九、Appearance 和 Class of Device 的区别

这一节可以和上一节 Class of Device 对比理解。

复制代码

Class of Device：
主要用于 BR/EDR 设备发现，也就是经典蓝牙场景。

Appearance：
属于 BLE GAP Service 中的 Characteristic，更贴近 BLE。

可以简单记成：

复制代码

经典蓝牙 BR/EDR：Class of Device
BLE：Appearance characteristic

它们都可以帮助用户粗略判断设备类型，但都不能完全代表设备实际支持的服务。

例如：

复制代码

Appearance = Keyboard

这只能说明设备外观类别是键盘。

但真正是否支持键盘输入相关功能，还需要看 GATT 服务，例如是否支持 HID Service。

十、Appearance 和 GATT Service Discovery 的关系

Appearance 是"外观类别提示"，不是"服务能力证明"。

比如一个 BLE 设备的 Appearance 显示为：

复制代码

Heart Rate Sensor

它大概率是心率设备。

但 App 如果真的要使用心率数据，不能只看 Appearance。

还应该检查它是否真的存在：

复制代码

Heart Rate Service
UUID: 0x180D

再比如 Appearance 显示：

复制代码

Keyboard

如果 App 想确认它是否是 BLE HID 键盘，还要看是否存在：

复制代码

Human Interface Device Service
UUID: 0x1812

所以正确逻辑是：

复制代码

Appearance：帮助用户识别设备外观/类别
Service UUID / GATT Discovery：确认设备实际支持的服务能力

十一、结合 BLE App 开发怎么理解？

做 BLE 扫描和调试工具时，可以把 Appearance 当作设备展示信息的一部分。

比如设备详情页可以显示：

复制代码

Device Name: BLE Keyboard
Address: DD:2D:31:00:06:F6
Address Type: Random
RSSI: -62 dBm
Appearance: Keyboard
Appearance Value: 0x03C1

如果是在普通用户 App 中，可以更简单：

复制代码

设备类型：键盘

如果是在调试工具 App 中，建议同时显示原始值和解析值：

复制代码

Appearance: Keyboard
Raw Value: 0x03C1

因为开发者有时需要确认设备设置的 Appearance 是否正确。

十二、Appearance 和广播数据的关系

这里要特别注意：

Appearance 是 GAP Service 里的 Characteristic，但 BLE 广播数据中也可以携带 Appearance 相关 AD Type。

所以你可能在两个地方看到 Appearance：

复制代码

1. 广播数据中的 Appearance AD Structure
2. 连接后读取 GAP Service 0x1800 下的 Appearance Characteristic 0x2A01

这两个值理论上应该表达同一个设备外观类别，但实际产品中不一定总是完全一致。

所以调试时要区分来源：

复制代码

Advertising Appearance
GATT Appearance Characteristic

如果你做调试工具，可以分别显示：

复制代码

Advertising Appearance: Keyboard
GATT Appearance: Keyboard

如果两者不一致，也方便定位模块配置问题。

十三、这一节你应该怎么记？

可以直接记成下面这段：

复制代码

Appearance characteristic 是 BLE GAP Service 里的一个标准特征值，对应 UUID 0x2A01。

它保存的是一个 16-bit 数值，这个数值由 Bluetooth SIG 分配，用来描述设备的外观类别。

远端设备可以把这个数值映射成图标或字符串，让用户知道当前发现的设备大概是什么类型。

如果 UI 显示字符串，应该根据用户设备语言进行本地化。

Appearance 只能作为设备外观/类别提示，不能代替真正的服务发现。

在 BLE 中，它有点类似经典蓝牙 BR/EDR 里的 Class of Device，但它们不是同一个东西。

一句话总结：

复制代码

Appearance characteristic 主要告诉远端设备："我这个 BLE 设备从外观或类别上看像什么"，方便 UI 显示图标或文字，但不能用它来最终判断设备支持哪些服务。

十四、对当前学习 BLE 的建议

这一节你应该认真记一下，因为它是 BLE GAP / GATT 中比较基础的内容。

不过不用死记所有 Appearance 数值表，先掌握概念即可：

复制代码

重点掌握：
1. Appearance 是 GAP Service 里的 Characteristic。
2. UUID 是 0x2A01。
3. 它是 16-bit 数值。
4. 它用于描述设备外观类别。
5. UI 可以把它显示成图标或文字。
6. 它不能替代 Service UUID 或 GATT Service Discovery。

后面你如果做 BLE 调试工具，可以考虑在设备详情页增加一项：

复制代码

Appearance

并把原始值和解析后的设备类型一起展示出来。

这部分讲的是 Broadcast Code ，也就是用于 加密广播音频 BIG 的一段"广播访问/隐私代码"。

它属于比较新的 BLE Audio / Isochronous Broadcast 相关内容，不是普通 Legacy Advertising、普通 GATT 通信的核心内容。

简单说：

Broadcast Code 用来支持加密 BIG。广播源发送加密的广播音频数据时，需要用它参与加密；接收端接收这个 BIG 中的 BIS 时，需要用它参与解密。

一、原文大意翻译

3.2.6 Broadcast Code

3.2.6.1 Definition

定义

Broadcast_Code 参数用于支持一个加密的 BIG。

它会用于两个过程：

复制代码

1. 发送加密 BIG 时，对数据进行加密
2. 接收该 BIG 中的 BIS 时，对数据进行解密

3.2.6.2 Terms at user interface level

用户界面层级上的术语

当在 UI 层面提到 Broadcast_Code 参数时，应该使用术语：

复制代码

Bluetooth Privacy Code

也就是可以理解为：

复制代码

蓝牙隐私码

3.2.6.3 Representation

表示方式

Broadcast_Code 参数在不同层级有不同表示方式。

在 UI 层面，Broadcast Code 应该表示为一个字符串。

这个字符串至少是：

复制代码

4 octets

也就是至少 4 字节。

并且它需要满足前面 Bluetooth Passkey / PINUI 相关章节里的要求。

例如：

复制代码

用 UTF-8 编码后不能超过 16 octets

为了更高安全性，推荐使用：

复制代码

16 octets

在 UI 之外的其他层级，Broadcast Code 应该表示为一个：

复制代码

128-bit value

也就是：

复制代码

16 bytes

从字符串转换成数字时，需要先把字符串表示成 UTF-8，然后把得到的字节放入这个 128-bit 值的 8-bit 字段中，从最低有效位开始放；如果需要，则在最高有效位补 0。

例如字符串：

复制代码

Børne House

会表示成：

复制代码

0x00000000_6573756F_4820656E_72B8C342

二、这部分想表达什么？

这部分主要表达 4 件事：

复制代码

1. Broadcast Code 是加密 BIG 使用的参数。
2. 在 UI 层面不要直接叫 Broadcast Code，而应该叫 Bluetooth Privacy Code。
3. UI 上它表现为一个字符串，至少 4 字节，最多按 PINUI 要求通常不超过 16 字节。
4. 在底层协议层面，它表现为一个 128-bit 数值。

你可以先这样记：

复制代码

Broadcast Code 是给加密广播音频用的"密码/隐私码"。

用户看到的是 Bluetooth Privacy Code；
底层使用的是 128-bit Broadcast_Code。

三、关键信息 1：Broadcast Code 用于加密 BIG

这里有两个重要缩写：

复制代码

BIG = Broadcast Isochronous Group
BIS = Broadcast Isochronous Stream

在 BLE Audio 里，一个广播源可以发送同步广播音频数据。

例如：

复制代码

电视机广播音频
公共场所广播音频
助听器接收广播音频
多人同时收听同一个音频广播

这里可能会用到 BIS。

多个 BIS 可以组成一个 BIG。

如果这个 BIG 是加密的，那么接收端想要正确解密，就需要知道对应的 Broadcast Code。

所以它的作用有点像：

复制代码

加入这个加密广播音频流所需的访问码/隐私码

但规范在 UI 上建议叫：

复制代码

Bluetooth Privacy Code

四、关键信息 2：它不是普通 BLE 广播的广播数据

看到 Broadcast Code 这个名字，很容易误解为普通 BLE Advertising 里的广播数据字段。

但这里不是普通 Legacy Advertising 的内容。

它和下面这些不是一个层面的东西：

复制代码

Advertising Data
Scan Response Data
Local Name
Manufacturer Specific Data
Service UUID
Tx Power
Appearance AD Type

这节讲的 Broadcast Code 更偏向：

复制代码

LE Audio
Isochronous Broadcast
BIG / BIS
Encrypted Broadcast

所以如果你当前正在学习：

复制代码

BLE Legacy 广播
LE Set Advertising Parameters
LE Set Advertising Data
LE Set Scan Response Data
LE Advertising Report

那这一节可以先快速了解，不需要深挖。

五、关键信息 3：UI 上应该叫 Bluetooth Privacy Code

原文说：

复制代码

When the Broadcast_Code parameter is referred to on the UI level, the term 'Bluetooth Privacy Code' should be used.

意思是：

在用户界面上，如果要显示这个参数，不应该直接写：

复制代码

Broadcast Code

而应该写：

复制代码

Bluetooth Privacy Code

中文可以理解成：

复制代码

蓝牙隐私码

比如用户界面可以显示：

复制代码

请输入 Bluetooth Privacy Code

或者中文：

复制代码

请输入蓝牙隐私码

为什么不直接叫 Broadcast Code？

因为 Broadcast Code 是偏协议参数名，而 Bluetooth Privacy Code 更像用户能理解的名称。

对于普通用户来说：

复制代码

Broadcast Code

可能不知道是什么。

但：

复制代码

Privacy Code

更容易理解为"访问这个加密广播所需的隐私码"。

六、关键信息 4：UI 层面是字符串

原文说：

复制代码

On the UI level, the Broadcast Code parameter shall be represented as a string

也就是说，在用户界面上，它不是显示成十六进制大整数，而是显示成字符串。

例如可以是：

复制代码

1234
BorneHouse
Børne House
MyAudioCode

但它不是随便无限长的字符串。

它有长度要求：

复制代码

至少 4 octets
建议 16 octets 更安全

这里的 octet 可以理解为 byte。

所以：

复制代码

4 octets = 4 bytes
16 octets = 16 bytes

注意，和前面 Bluetooth PIN 一样，这里说的是字节，不一定等于字符数量。

七、关键信息 5：至少 4 字节，推荐 16 字节

原文说 UI 层面字符串至少：

复制代码

4 octets

也就是说，编码后至少要有 4 字节。

例如：

复制代码

如果用 UTF-8 编码，4 个 ASCII 数字就是 4 字节，所以满足最低要求。

但为了更高安全性，规范建议：

复制代码

16 octets should be used for higher level of security.

也就是：

复制代码

为了更高安全性，应该使用 16 字节。

原因很直观：

复制代码

Broadcast Code 越短，猜测空间越小；
Broadcast Code 越长，安全性越高。

例如：

复制代码

虽然满足 4 字节，但安全性弱。

而：

复制代码

A9k2M7q8Z1p4X6r0

如果是 16 个 ASCII 字符，就是 16 字节，安全性会高很多。

八、关键信息 6：底层表示是 128-bit value

原文说：

复制代码

On all levels other than UI, the Broadcast Code parameter shall be represented as a 128-bit value.

意思是：

除了 UI 层面以外，其他层级的 Broadcast Code 都应该表示为：

复制代码

128-bit value

也就是：

复制代码

16 bytes

所以它有两个形态：

复制代码

UI 层面：
字符串，例如 "Børne House"

底层协议层面：
128-bit 数值，例如 0x00000000_6573756F_4820656E_72B8C342

这和前面的 Passkey / PIN 也有点像：

复制代码

用户输入的是字符串或数字码；
底层使用的是转换后的二进制值。

九、关键信息 7：字符串如何转换成 128-bit 值？

原文描述了转换规则：

复制代码

The transformation from string to number shall be by representing the string in UTF-8,
placing the resulting bytes in 8-bit fields of the value starting at the least significant bit,
and then padding with zeros in most significant bits if necessary.

拆开理解：

第一步：字符串先转成 UTF-8 字节

例如：

复制代码

Børne House

UTF-8 编码后得到一串字节。

其中普通英文字母通常是 1 字节：

复制代码

B -> 0x42
r -> 0x72
n -> 0x6E
e -> 0x65
空格 -> 0x20
H -> 0x48
o -> 0x6F
u -> 0x75
s -> 0x73
e -> 0x65

但是：

复制代码

ø

不是 Basic Latin 字符，UTF-8 编码为 2 字节：

复制代码

ø -> 0xC3 0xB8

所以：

复制代码

Børne House

对应字节大概是：

复制代码

42 C3 B8 72 6E 65 20 48 6F 75 73 65

第二步：从最低有效位开始放入 128-bit value

也就是说，这些 UTF-8 字节不是简单按平时阅读顺序写成最高位在前。

它们会从 128-bit 数值的低位开始填。

所以最后原文示例得到：

复制代码

0x00000000_6573756F_4820656E_72B8C342

把它按 byte 拆开是：

复制代码

00 00 00 00 65 73 75 6F 48 20 65 6E 72 B8 C3 42

你会发现从右往左看，低位字节就是：

复制代码

42 C3 B8 72 6E 65 20 48 6F 75 73 65

这正好是 "Børne House" 的 UTF-8 字节序列。

第三步：不足 16 字节时，高位补 0

Børne House 编码后没有占满 16 字节，所以剩余高位补 0。

所以前面有：

复制代码

0x00000000

最终得到：

复制代码

0x00000000_6573756F_4820656E_72B8C342

这说明：

复制代码

UI 字符串不是直接按视觉顺序变成十六进制展示；
而是先 UTF-8 编码，再按低位开始填入 128-bit 数值。

十、为什么这里要引用前面 Bluetooth Passkey / PINUI 的要求？

原文说它要满足 Section 3.2.3.3 里 PINUI 的要求。

这意味着 Broadcast Code 在 UI 字符串上也要注意类似问题：

复制代码

1. 用 UTF-8 编码
2. 编码后不要超过 16 octets
3. 尽量避免容易造成兼容问题的字符
4. 如果包含数字，最好使用 Basic Latin 的 0~9
5. 不建议使用全角/半角变体等容易混淆的 Unicode 字符

所以实际产品里，最好不要设计成很奇怪的 Unicode 字符串。

比较稳妥的方式是：

复制代码

纯数字
英文字母 + 数字
Basic Latin 范围内的字符

例如：

复制代码

12345678
Audio2026
BLEAUDIOCODE1234

十一、结合 BLE 开发怎么理解？

这部分对当前做普通 BLE App 开发，不是最高优先级。

现在如果主要做的是：

复制代码

BLE 扫描
BLE 连接
GATT Read / Write / Notify
广播数据解析
设备透传
OTA
AT 指令

那么 Broadcast Code 暂时不会经常遇到。

它更可能出现在：

复制代码

BLE Audio
Auracast
Broadcast Audio
Encrypted BIG
BIS 接收
音频广播共享
助听器 / 耳机 / 电视音频广播

如果未来做 LE Audio 相关 App 或设备调试工具，就需要理解它。

比如用户想加入一个加密的广播音频流，App 可能需要提示用户：

复制代码

请输入蓝牙隐私码

用户输入后，系统或协议栈会把这个字符串转换为 128-bit Broadcast_Code，用于解密接收到的 BIS 数据。

十二、Broadcast Code 和普通配对码的区别

它很容易和 Bluetooth Passkey 混淆。

可以这样区分：

复制代码

Bluetooth Passkey：
主要用于两个设备配对时的认证。
常见形式是 6 位数字，例如 123456。

Broadcast Code：
用于加密广播音频 BIG。
UI 上称为 Bluetooth Privacy Code。
它是字符串，底层转换为 128-bit 值。

简单对比：

复制代码

Bluetooth Passkey：
点对点配对认证

Broadcast Code：
加密广播音频接收/解密

Passkey 常见于：

复制代码

手机连接蓝牙键盘
手机连接 BLE 外设并配对

Broadcast Code 常见于：

复制代码

加入一个加密的 LE Audio 广播
接收 Auracast 音频广播

十三、Broadcast Code 和普通广播数据的区别

Broadcast Code 也容易让人误以为是广播包里公开发出来的 Code。

但它不是普通 Advertising Data 里的随便一个字段。

它是用于加密 BIG/BIS 的参数。

可以这样理解：

复制代码

普通广播数据：
用于发现设备、携带名称、服务 UUID、厂商数据等。

Broadcast Code：
用于加密广播音频的加密/解密过程。

尤其注意：

复制代码

如果 BIG 是加密的，接收端需要 Broadcast Code 才能解密；
如果没有正确 Broadcast Code，即使能发现广播，也无法正确解密音频数据。

十四、这一节应该怎么记？

可以直接记成下面这段：

复制代码

Broadcast Code 是 BLE Audio / Isochronous Broadcast 中用于加密 BIG 的参数。

它参与加密 BIG 发送数据的加密，也参与接收端对 BIG 中 BIS 数据的解密。

在 UI 层面，规范要求使用 Bluetooth Privacy Code 这个术语，也就是蓝牙隐私码。

UI 上它表现为字符串，至少 4 字节，推荐 16 字节以获得更高安全性。

在非 UI 层面，它表现为 128-bit value，也就是 16 字节。

字符串转换到底层 128-bit 值时，先按 UTF-8 编码，再从最低有效位开始填入，不足的高位补 0。

一句话总结：

复制代码

这一节主要告诉你：Broadcast Code 是加密广播音频 BIG 的"隐私码/访问码"，用户看到的是 Bluetooth Privacy Code，底层使用的是 128-bit Broadcast_Code。

十五、对当前学习 BLE 的建议

这部分可以先了解，不建议现在深挖。

因为它不是普通 BLE 广播扫描连接的基础内容，而是偏：

复制代码

LE Audio
Broadcast Isochronous Group
Broadcast Isochronous Stream
Encrypted Broadcast
Auracast

当前如果还在学习 GAP 基础、Legacy Advertising、HCI LE Advertising Commands，那么优先级可以这样排：

复制代码

高优先级：
Bluetooth Device Address
Bluetooth Device Name
Appearance
Advertising Data
Scanning
Connection
GATT Service / Characteristic

中优先级：
Passkey
Pairing
Bonding
Privacy
Resolvable Private Address

低优先级，暂时了解：
Broadcast Code
BIG / BIS
LE Audio Broadcast

不过要记住它和普通广播的区别：

复制代码

Broadcast Code 不是普通广播数据；
它是加密 LE Audio 广播 BIG/BIS 用的隐私码。

这一节开始进入 GAP 中非常重要的一部分------Pairing（配对）。

虽然只有短短一段话，但它实际上是在定义 Pairing 在用户视角下是什么意思，以及 Pairing、Bonding、Authentication 三者之间的关系。

对于你后面学习 BLE Security Manager（SMP） 、Just Works 、Passkey Entry 、Numeric Comparison 等内容，这一段就是一个总纲。

一、原文翻译

3.3 Pairing（配对）

对于 BR/EDR（经典蓝牙） ，配对是在 LMP（Link Manager Protocol） 层定义的（参见 Vol 2 Part B）。

对于 LE（BLE） ，配对由 Security Manager（SM）规范 定义（参见 Vol 3 Part H Section 2.3）。

在用户角度来看，通常有两种情况：

第一种情况：

用户主动发起 Bonding（绑定）过程，并输入 Passkey，其明确目的就是为了在两个蓝牙设备之间建立 Bond（绑定关系），同时可能建立一个安全关系（Secure Relationship）。

这种情况下，用户执行的是：

Bonding（with entering of passkey）

输入配对码进行绑定。

第二种情况：

设备之间之前没有共享 Link Key（链路密钥）。

当设备建立连接时，系统要求用户输入 Passkey。

这种情况下，用户执行的是：

Authenticate using the passkey

使用配对码进行身份认证。

二、这一段真正想表达什么？

很多人看到 Pairing，会认为：

Pairing = 输入 6 位数字。

其实规范这里想表达的是：

Pairing 只是整个安全建立过程的统称。

而用户输入 Passkey，只是 Pairing 过程中可能发生的一步。

更重要的是，规范开始区分三个概念：

复制代码

Pairing
Bonding
Authentication

很多资料把这三个词混着翻译，其实规范里含义不同。

三、关键信息一：BR/EDR 和 BLE 的 Pairing 完全不是同一个协议

原文第一句话：

Pairing over a BR/EDR physical link is defined on LMP level.

意思是：

经典蓝牙：

复制代码

LMP
(Link Manager Protocol)

负责 Pairing。

而第二句：

Pairing over an LE physical link is defined by the Security Manager specification.

意思是：

BLE：

复制代码

Security Manager
(SM / SMP)

负责 Pairing。

这意味着：

复制代码

经典蓝牙 Pairing
        │
        ▼
       LMP

BLE Pairing
        │
        ▼
Security Manager（SMP）

所以以后你学习 BLE 时：

不要再去看 LMP Pairing。

因为：

BLE 的 Pairing 全部都在 Vol 3 Part H（Security Manager）里面。

四、关键信息二：Pairing ≠ Bonding

这是 BLE 初学者最容易混淆的地方。

规范这里实际上已经暗示：

Pairing 和 Bonding 不是同一件事。

可以理解成：

复制代码

Pairing
│
├── 身份认证
├── 密钥协商
├── 加密建立
└── （可能）产生 Bond

而：

复制代码

Bonding

只是：

复制代码

保存密钥
建立长期信任关系

例如：

第一次连接：

复制代码

手机
     │
     │ Pairing
     ▼
设备

Pairing 完成以后：

双方得到：

复制代码

LTK
IRK
CSRK

如果保存这些密钥：

就叫：

复制代码

Bonding

以后再次连接：

复制代码

手机
     │
     │
     ▼
设备

不用重新输入 Passkey。

因为：

复制代码

Bond 已存在

所以：

Pairing 是一次安全建立过程。

而：

Bonding 是把这次 Pairing 得到的密钥保存下来。

五、关键信息三：Passkey 有两种使用场景

规范这里举了两个例子。

很多人一直认为：

输入 Passkey 就一定是在 Pairing。

其实不是。

规范说：

有两种情况。

第一种：

用户主动去：

复制代码

Pair Device

例如：

手机：

复制代码

蓝牙
↓
添加设备
↓
输入 123456

目的就是：

建立：

复制代码

Bond

规范叫：

复制代码

Bonding
(with entering of passkey)

也就是说：

用户的目标就是把设备配成长期可信设备。

例如：

耳机

键盘

鼠标

BLE 门锁

这些都属于这种。

第二种：

设备之间以前没有：

复制代码

Link Key

或者 BLE 里的：

复制代码

LTK

但是：

用户只是：

复制代码

开始使用设备

例如：

第一次连接。

系统突然弹出：

复制代码

请输入配对码

这里：

用户其实没有想：

复制代码

我要去配对。

而只是：

复制代码

我要连接。

于是：

系统为了完成：

复制代码

Authentication

要求输入 Passkey。

所以规范说：

这种情况叫：

复制代码

Authenticate
using the passkey

注意：

这里强调的是：

认证（Authentication）

不是：

Bonding。

六、为什么规范要区分这两种情况？

因为：

用户视角不同。

例如：

BLE 门锁。

第一次：

复制代码

点击连接

手机：

复制代码

请输入 123456

你可能觉得：

我只是连接。

实际上：

底层：

正在：

复制代码

Authentication

而：

另一种：

复制代码

设置
↓

配对新设备
↓

输入 123456

这里：

用户就是：

我要把设备配对。

底层：

可能：

复制代码

Pairing
+
Bonding

所以：

规范区分：

复制代码

Authentication

vs

Bonding

是从：

用户行为

来区分。

七、关键信息四：Link Key 是什么？

原文提到：

common link key

这是经典蓝牙的叫法。

对于 BLE：

对应的是：

复制代码

LTK
(Long Term Key)

可以简单理解：

复制代码

BR/EDR

Link Key

≈

BLE

LTK

都是：

以后重新连接时：

用于恢复安全连接的长期密钥。

所以：

规范说：

如果：

复制代码

devices did not share
a common link key

意思就是：

以前没有建立过长期可信关系。

于是：

需要：

重新认证。

八、这一节最容易误解的地方

很多初学 BLE 的人会认为：

复制代码

Pairing
=
输入密码

其实规范不是这么定义的。

更准确应该理解成：

复制代码

Pairing

↓

身份认证

↓

协商密钥

↓

建立加密

↓

（可选）

Bonding

输入 Passkey：

只是：

其中某一种认证方式。

例如：

BLE Pairing：

还有：

复制代码

Just Works

Numeric Comparison

Passkey Entry

Out Of Band

只有：

复制代码

Passkey Entry

才需要输入：

6 位数字。

所以：

Pairing 不一定需要 Passkey。

例如：

Just Works：

用户：

什么都不用输入。

但是：

仍然完成：

复制代码

Pairing

九、结合目前学习 BLE，应该如何理解？

目前已经学习了：

GAP
Advertising
Scanning
Address
Appearance

那么下一步马上会进入：

复制代码

Security Manager

这一段实际上就是：

整个 BLE 安全章节的导读。

建议建立下面这个知识框架：

复制代码

BLE Security
│
├── Pairing（建立安全关系）
│
├── Authentication（身份认证）
│      ├── Just Works
│      ├── Passkey Entry
│      ├── Numeric Comparison
│      └── OOB
│
├── Key Distribution（密钥分发）
│      ├── LTK
│      ├── IRK
│      └── CSRK
│
├── Bonding（保存密钥）
│
└── Encryption（后续连接加密）

以后学习 Vol 3 Part H（Security Manager） 时，会发现所有内容都可以放进这个框架里。

十、这一节最值得记住的内容

建议直接记住下面几句话：

复制代码

1. Pairing 是建立 BLE 安全关系的整个过程，不只是输入配对码。

2. BR/EDR 的 Pairing 由 LMP 定义；BLE 的 Pairing 由 Security Manager（SMP）定义。

3. Pairing 不等于 Bonding。Pairing 是建立安全关系，Bonding 是保存密钥，建立长期信任关系。

4. 用户输入 Passkey 可能是为了建立 Bond（绑定），也可能只是为了完成一次身份认证（Authentication）。

5. Pairing 并不一定需要输入 Passkey，例如 Just Works 配对方式就无需用户输入任何数字。

对当前学习路线的建议

这一节开始，已经从 GAP 的用户界面规范 进入 BLE 安全模型。后续建议不要直接跳进 SMP 的算法细节，而是先把下面几个概念建立起来：

Pairing、Bonding、Authentication、Encryption 四者分别是什么、是什么关系。
Just Works、Passkey Entry、Numeric Comparison、Out of Band 四种认证方式各自的特点。
LTK、IRK、CSRK 分别是什么、什么时候生成、什么时候使用。

这三个知识点弄清楚之后，再去阅读 Security Manager 规范，会容易得多。