乐鑫将通过 BLE 向设备发送 Wi-Fi 凭证的功能称为“BluFi”。此功能通过 16 位服务 UUID 0xFFFF 进行宣传。
我的理解是，所有 16 位 BLE 服务 UUID 都是为标准化 BLE 服务保留的。虽然 BluFi 服务 UUID 目前不会造成冲突，但这是否仍应被视为违反 BLE 标准？
BLE 分配的号码： https://www.bluetooth.com/specifications/an/
蓝光： https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/blufi.html
如果我们查看您链接的分配编号文档，我们可以找到以下内容：
3. 16 位 UUID
请参阅蓝牙核心规范 [第 3 卷] B 部分，第 2.5.1 节 [4]。
根据该参考文献，我们发现：
2.5.1 UUID
UUID 是一个通用唯一标识符，预计在所有空间和所有时间中都是唯一的（更准确地说，独立生成的 UUID 相同的概率可以忽略不计）。 UUID 可以以分布式方式独立创建。不需要分配 UUID 的中央注册表。 UUID 是一个 128 位值。
为了减轻存储和传输 128 位 UUID 值的负担，已“预分配”UUID 值的“范围”，以分配给常用的“注册”用途。此预分配范围中的第一个 UUID 称为 Bluetooth_Base_UUID，其值为 00000000-0000-1000-8000-00805F9B34FB。预分配范围内的 UUID 值具有表示为“16 位或 32 位值”的别名。这些别名通常称为 16 位和 32 位 UUID，但每个别名实际上代表一个 128 位 UUID 值。 请注意，本节位于 SDP 章节中，通常与 BLE 或 GATT 无关。然而，本节也适用于 ATT 协议（由 GATT 使用），如 ATT 章节中的 3.2.1 节所示。 也就是说，我的解释是所有 16 位和 32 位 UUID 都“已经”分配用于注册目的。请注意，分配的所有这些 UUID 可能尚未指定用途，因此应保留以供将来使用。 蓝牙核心 v5.4 标准的“Vol 1, Part E: General Terminology and Interpretation”章节进一步证实了这一点：
2.6 指定号码要求
蓝牙 SIG 在蓝牙 SIG 分配号码网页上维护一组已发布的分配号码。这些分配的数字被分组在不同的数字空间中。分配的号码可能与不同号码空间中的其他分配的号码重叠，但号码空间内的号码不会被重复使用。各种数字空间在定义所分配数字的用途的规范中进行了定义。 给定数字空间内的所有分配数字只能由蓝牙 SIG 指定，并且只能用于其预期目的
当在定义为采用该数字空间内的值的字段、参数或其他变量对象中使用时。给定数字空间内未明确分配的所有值均保留供将来使用，并遵守第 2.4 节中的要求。
[第 3 卷] B 部分第 2.5.1 节中定义的所有 16 位和 32 位 UUID都被视为分配编号。所有其他 UUID 值可以在允许 UUID 的任何上下文中使用，前提是它们是根据 ITU-T Rec.1 中的建议生成的。 X.667(10/2012)，也称为 ISO/IEC 9834.8:2014。
由于分配编号文档中不存在 UUID 0xFFFF 的 16 位服务，因此看来它们确实违反了标准。 此外，根据
https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers，不可能注册成员特定的 16 位特征 UUID（仅限服务） UUID）。尽管如此，BluFi 仍然使用特征 UUID 0xFF01 和 0xFF02。 我敢打赌，他们在内部测试期间使用了这些短 UUID，然后忘记更换它们或忘记在发布时购买自己的 16 位 UUID，并且没有人注意到这个错误。