App Inventor 2 蓝牙发送十六进制字节方案：文本转Hex字节详解

App Inventor 2

问题描述用户在文本框输入"ABCD"，想通过蓝牙发送 0xAB 0xCD 两个字节，而不是四个ASCII字符（0x41 0x42 0x43 0x44）。
每两个字符代表一个十六进制字节，需要将字符对解析为实际的字节值。
问题本质

输入	期望发送	实际发送（当前问题）
"ABCD"	[0xAB, 0xCD]（2字节）	[0x41, 0x42, 0x43, 0x44]（4字节ASCII）

解决方案核心思路：遍历字符串，每两个字符一组，分别解析高位和低位，组合成一个字节值，最后用 WriteBytes 发送。
1. HexCharToValue 辅助过程将单个十六进制字符（0-9, A-F, a-f）转换为对应的数值：

• "0"~"9" → 0~9
• "A"~"F" → 10~15
• "a"~"f" → 10~15
  

实现方法：通过比较 ASCII 码来判断字符范围，然后做减法运算。
2. HexTextToBytes 主转换过程伪代码逻辑：
过程 HexTextToBytes(hexText)  输入: hexText = "ABCD"  输出: 字节列表 [171, 205]    即 [0xAB, 0xCD]    清空字节列表  设置 i = 1  当 i < hexText的长度 时执行:    取高位字符 = hexText的子串(i, 1)       如 "A"    取低位字符 = hexText的子串(i+1, 1)      如 "B"    高位值 = HexCharToValue(高位字符)        A→10    低位值 = HexCharToValue(低位字符)        B→11    字节值 = 高位值 × 16 + 低位值            10×16+11 = 171 = 0xAB    将字节值添加到字节列表    i = i + 2  返回字节列表3. 蓝牙发送使用 BluetoothLE1.WriteBytes(serviceUuid, charUuid, signed=false, 字节列表) 直接发送转换后的数字列表。
WriteBytes 接收的列表里每个元素是数字（0-255），会自动转成对应字节。
关键注意事项

• 输入校验：字符串长度必须是偶数，只包含 0-9、A-F、a-f
• 大小写兼容：A-F 和 a-f 都要支持
• 空格处理：用户可能输入 "AB CD"，发送前需去除空格
• 字节范围：每对字符解析后值范围是 0-255，正好一个字节
  

验证示例

输入字符串	解析过程	发送字节
"ABCD"	AB→171, CD→205	[171, 205]
"FF00"	FF→255, 00→0	[255, 0]
"1A2B"	1A→26, 2B→43	[26, 43]
"0AFF"	0A→10, FF→255	[10, 255]

总结这个方案的核心就是：把用户输入的十六进制字符串，每两个字符一组，转成对应的数字字节值，再通过 WriteBytes 发送。整个过程用两个过程块即可实现，代码清晰且通用。

如有疑问欢迎回帖讨论！

App Inventor 2

补充：BLE 扩展源码分析与 WriteShorts 对比有同学问到：BLE 扩展的 WriteShorts 能不能实现这个需求？
结论是：能用，但有坑，不推荐。下面从源码角度详细分析。
1. 为什么直接传字符串给 WriteBytes 发的是4个字节？从 BLE 扩展源码（BluetoothLEint.java）分析，WriteBytes 内部的 toIntList() 方法会将字符串的每个字符转为 Unicode 码：
字符串 "ABCD"  → 取每个字符的 Unicode 码  → 'A'=65, 'B'=66, 'C'=67, 'D'=68  → Integer列表 [65, 66, 67, 68]然后 WriteBytes 按1字节逐个发送：[0x41, 0x42, 0x43, 0x44] —— 这就是4个ASCII字节，不是用户期望的2个十六进制字节。
2. WriteBytes 源码路径（无长度限制）位于 BluetoothLEint.java 第703-712行 BLEWriteOperation.write() 方法：
} else {    byte[] contents = new byte[size * data.size()]; // size=1 for Byte    long value;    int i = 0;    for (Number n : (List<? extends Number>) data) {        value = n.longValue();        for (int j = 0; j < size; j++) {            contents[i++] = (byte)(value & 0xFF);            value >>= 8;        }    }    characteristic.setValue(contents);}WriteBytes 走 Integer/Number 路径，没有硬编码长度限制，缓冲区大小等于实际数据大小。相比 WriteStrings 有23字节硬编码截断问题，WriteBytes 更可靠。
3. WriteShorts 能实现吗？WriteShorts 发送的是 16位短整型值（每值2字节），unsigned范围 0~65535。
用 WriteShorts 实现的思路：把 "ABCD" 拆成两个字符对，合成一个16位数值：
"ABCD" → 拆分 "AB" 和 "CD"AB → A=10, B=11 → 10×16+11 = 171 (高字节)CD → C=12, D=13 → 12×16+13 = 205 (低字节)合成16位值: 171 × 256 + 205 = 43981 (即 0xABCD)WriteShorts(serviceUuid, charUuid, signed=false, [43981])4. 各方法对比

方法	适合度	原因
WriteBytes	✅ 最佳选择	每个值1字节，直接对应，无字节序问题
WriteShorts	⚠️ 可用但有坑	16位整数有大小端（Little Endian）问题，实际字节流可能是 0xCD 0xAB（低字节在前），需接收端配合
WriteIntegers	❌ 不适合	32位（4字节），浪费空间
WriteStrings	❌ 不适合	发送ASCII编码，且有23字节截断问题

5. 结论对于"把十六进制字符串按字节发送"这个需求，转换后用 WriteBytes 是最正确的方案。WriteShorts 虽然也能发出相同的字节，但 BLE 传输默认小端序（Little Endian），源码中通过 value >>= 8 移位写入，低字节在前，实际发出的字节流可能是 0xCD 0xAB 而不是 0xAB 0xCD，容易导致数据解析错误。
更详细的 BLE 源码分析请参考：WriteBytes vs WriteStrings 源码分析