先说我碰到的真实场景：对接一个硬件消息网关时，设备上报的业务字段里，中文全被编码成了“\u6D4B\u8BD5”这样的转义文本，我盯着日志看了半天才反应过来，这不是乱码，是Unicode码点的十六进制表示。更诡异的是，同一个网关的另一路接口，给的却是“4E2D 6587”这种纯十六进制字符串，不带\u前缀，也不带0x。前端拿到这种数据直接渲染，页面上就是一排\u；后端想入库，也得先转换才能得到“测试”。这类问题的本质其实就是一件事：Unicode字符的十六进制码点表示，和常规文本（通常是UTF-8编码）之间怎么做双向转换。这篇文章把我用C++和Java分别实现的方案、编码细节、代理对处理和踩坑记录都整理出来，适合做网关协议解析、IM消息适配、数据清洗，或者只是被\uXXXX搞烦了的开发者。
1. 需求拆解：先分清“码点十六进制”和“字节十六进制”
1.1 两种“转十六进制”，差的不止一个量级
先问一个非常基础、但特别容易栽跟头的问题：“中”字的十六进制是多少？
两个答案都有人会答：一个是4E2D，一个是E4B8AD。前者是Unicode码点U+4E2D，后者是“中”这个汉字在UTF-8编码下的字节序列E4 B8 AD。这俩完全不是一回事，但日常交流里都会被称作“转成十六进制”。
本文标题里说的“16进制字符串表示的Unicode字符”，指的是码点形式，也就是\u4E2D、0x4E2D、4E2D这类写法，本质都是U+xxxx。字节序列十六进制通常来自抓包、二进制文件或者网络传输层的数据，那种转换是逐字节输出hex，属于另一套逻辑。如果你把“中”字节序列E4B8AD当成码点去解析，一次转换就是一个非法字符。所以拿到需求第一步，一定要先确认输入到底是码点还是字节序列，这一步错了，后面全是无用功。
1.2 实际输入会有这么几种形态
真实项目里，输入形态远比教科书里的示例复杂，我把见过的情况归类成这样一张表：
| 输入形态 | 示例 | 含义 |
|---|---|---|
| 纯码点hex | 4E2D / 0x4E2D / 0041 | 一个字符的Unicode码点 |
| 转义文本 | \u4E2D\u6587 | 一串字符，每个\uXXXX表达一个UTF-16编码单元 |
| 代理对 | \uD83D\uDE00 | 一个超出基本平面的字符用两个\uXXXX表示 |
| 混合串 | abc\u4E2D! | ASCII正常文本里夹着\u转义 |
不同形态，解析难度完全不一样。纯码点最简单，一个Integer.parseInt就搞定；转义文本就需要一个扫描器；代理对则要求你识别高代理和低代理，并正确合并成完整码点。后面Java和C++的章节，我会把这几种形态的完整代码都给出。
1.3 转换前后的形态定义
动手写代码之前，先把接口的输入输出定义清楚，我通常按这四个方向来约束：
- 输入“4E2D”这种十六进制码点，输出字符“中”；
- 输入字符“中”，输出十六进制码点“4E2D”；
- 输入“\u4E2D\u6587”这种转义文本，输出“中文”；
- 输入“E4 B8 AD”这种UTF-8字节hex，输出字符“中”。
最后一个方向虽然不属于标题严格意义上的码点转换，但因为太容易混淆，我也会在第4章里顺带给出实现，方便对照。
2. 前置知识：码点、UTF-8变长编码与代理对
2.1 码点（Code Point）到底是个什么东西
Unicode给每个字符分配一个唯一的整数编号，这个编号就叫码点，范围从U+0000到U+10FFFF。基本平面（BMP）覆盖U+0000到U+FFFF，也就是绝大多数常用字符，用四个十六进制位就能表示；超出BMP的字符（比如各种表情符号、生僻字）码点超过U+FFFF，需要五到六个十六进制位。
这里必须强调一个Java初学者特别容易踩的坑：Java的char类型是UTF-16编码单元，不是码点。对于BMP内的字符，char值和码点一样；但对BMP外的字符，一个字符要占两个char，也就是一个代理对。前面那个\uD83D\uDE00就是笑脸表情的代理对表示，它俩凑一起才是一个完整字符。很多人把charAt()取出来的单个char当码点用，表情符号就会碎成两个“乱码”。
2.2 UTF-8的变长编码规则
UTF-8是一种变长编码，把码点按范围切成1到4个字节，规则如下：
| 码点范围 | 字节数 | 字节格式 |
|---|---|---|
| U+0000 ~ U+007F | 1 | 0xxxxxxx |
| U+0080 ~ U+07FF | 2 | 110xxxxx 10xxxxxx |
| U+0800 ~ U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx |
| U+10000 ~ U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
拿“中”字手算一遍最有感觉。U+4E2D等于十进制20013，二进制约等于0100 1110 0010 1101，总共14位。按3字节格式，把这14位从高位开始填入1110xxxx 10xxxxxx 10xxxxxx的x位置：
- 前4位0100 → 第一个字节是11100100，也就是E4；
- 中间6位111000 → 第二个字节是10111000，也就是B8；
- 最后6位101101 → 第三个字节是10101101，也就是AD。
于是“中”的UTF-8字节序列就是E4 B8 AD。这个手算过程理解了，后面写编码器和解码器就是纯位运算的事，没有任何黑魔法。
2.3 为什么要懂代理对
代理对是UTF-16编码下的产物，但做码点解析时绕不开，因为\uXXXX这种转义本质上就是UTF-16编码单元的十六进制表示。一个BMP外字符U+1F600，在Java字符串里用两个char保存：高代理\uD83D和低代理\uDE00。合并算法是固定的：
- 码点减去0x10000，得到20位中间值；
- 高10位加上0xD800得到高代理；
- 低10位加上0xDC00得到低代理。
反过来拆解就是减回去。如果只解析了高代理\uD83D，把它当独立码点直接转UTF-8，你得到的是一个非法字符，因为U+D800到U+DFFF是保留的代理区，根本不属于任何合法字符。
2.4 三个常见认知误区
第一，别把UTF-16编码单元当码点。Java的char不等于码点，除非你确定字符在BMP内。第二，别把码点按1比1映射到字节。一个码点转成UTF-8，可能是1到4个字节，直接强转成char或只取低8位，中文和表情符号必然乱码。第三，别放过非法输入。解析码点时，代理区（0xD800到0xDFFF）和超过0x10FFFF的值都是非法的，要主动拦截，而不是等出现乱码再来排查。
3. Java实现：Integer与Character的组合拳
3.1 十六进制码点转成字符串，三行核心代码
Java做码点到字符的转换，核心就是Integer.parseInt加上Character.toChars。
public static String hexCodePointToString(String hex) { String clean = hex.trim(); if (clean.startsWith("0x") || clean.startsWith("0X")) { clean = clean.substring(2); } int codePoint = Integer.parseInt(clean, 16); if (codePoint > 0x10FFFF || (codePoint >= 0xD800 && codePoint <= 0xDFFF)) { throw new IllegalArgumentException("非法码点: " + hex); } return new String(Character.toChars(codePoint)); }测试结果很直观：
System.out.println(hexCodePointToString("4E2D")); // 中 System.out.println(hexCodePointToString("41")); // A System.out.println(hexCodePointToString("1F600")); // 笑脸表情 System.out.println(hexCodePointToString("0x4E2D")); // 中，带0x前缀也能处理Integer.parseInt第二个参数是进制，传16就行，它自己会处理a到f和A到F。Character.toChars的好处在于：如果码点在BMP外，它会自动返回一个包含两个char的char[]，new String直接吃掉，不用自己拼代理对。我在代码里顺手过滤了代理区，原因前面说了，代理值不是合法字符。
这里有个细节：Integer.parseInt遇到超过int范围的输入会抛NumberFormatException。合法码点最大0x10FFFF是1114111，int完全装得下，所以正常输入不会触发。但如果输入源不可控，比如给了“FFFFFFFF”，直接抛异常也算一种防御。真要对齐协议规范，可以改用Long.parseLong再做范围检查，看你的容错策略。
3.2 字符串转成十六进制码点，关键是codePointAt
反向转换同样简单，但要额外注意代理对的存在：
public static String stringToHexCodePoint(String input) { StringBuilder sb = new StringBuilder(); int i = 0; while (i < input.length()) { int codePoint = input.codePointAt(i); sb.append(String.format("%X", codePoint)); i += Character.charCount(codePoint); } return sb.toString(); }用codePointAt而不是charAt，是为了让BMP外字符一次取到完整码点。Character.charCount返回该码点在UTF-16里占几个char，BMP内返回1，代理对返回2。这样一来，遍历时索引不会走一半卡在代理中间。
System.out.println(stringToHexCodePoint("中文")); // 4E2D6587 System.out.println(stringToHexCodePoint("A😀")); // 411F600“A😀”这个例子最能说明问题：A占一个char，😀占两个char，codePointAt(1)恰好跳过高代理直接返回完整码点1F600，最终输出411F600，而不是把代理对拆成D83DDE00。
3.3 解析完整\uXXXX转义文本，含代理对合并
单条码点转换只是基本功，实际协议里更多是“\u4E2D\u6587”这种整串转义。这种情况需要一个扫描器，逐字符判断是否遇到\u，然后截取4位hex。但很多实现没有处理代理对，遇到“\uD83D\uDE00”会解析成两个孤立字符，表情照样崩。完整的实现是这样：
public static String unescapeUnicode(String input) { StringBuilder sb = new StringBuilder(); int i = 0; while (i < input.length()) { char c = input.charAt(i); if (c == '\\' && i + 1 < input.length() && input.charAt(i + 1) == 'u') { int j = i + 2; StringBuilder hex = new StringBuilder(); while (j < input.length() && hex.length() < 4) { char h = input.charAt(j); if (isHexChar(h)) { hex.append(h); j++; } else { break; } } if (hex.length() == 4) { int codePoint = Integer.parseInt(hex.toString(), 16); if (codePoint >= 0xD800 && codePoint <= 0xDBFF && j + 6 <= input.length() && input.startsWith("\\u", j)) { int low = Integer.parseInt(input.substring(j + 2, j + 6), 16); if (low >= 0xDC00 && low <= 0xDFFF) { codePoint = Character.toCodePoint((char) codePoint, (char) low); j += 6; } } sb.appendCodePoint(codePoint); i = j; continue; } } sb.append(c); i++; } return sb.toString(); } private static boolean isHexChar(char c) { return (c >= '0' && c <= '9') || (c >= 'a' && c <= 'f') || (c >= 'A' && c <= 'F'); }逻辑分三块：找到\u后截至少4位hex；如果截出来的码点落在高代理区，并且后面紧跟着另一个\u，再截4位作为低代理；合并成完整码点后追加进结果。Character.toCodePoint就是前面公式的封装，把两个char转成一个int码点。
System.out.println(unescapeUnicode("\\u4E2D\\u6587")); // 中文 System.out.println(unescapeUnicode("abc\\u4E2D!")); // abc中! System.out.println(unescapeUnicode("\\uD83D\\uDE00")); // 笑脸表情3.4 Java侧几个容易忽略的坑
第一，输出大小写要统一。很多人用Integer.toHexString，默认小写输出“4e2d”，而协议文档里写的是“4E2D”，如果不统一，后续比对和验签会很痛苦。第二，无条件信任输入会死得很难看。外部数据里可能混着“\u”但后面不是4位hex，比如“\u123”，我的实现里hex.length()不到4会直接跳过，把原字符原样追加，这种容错比粗暴throw更稳。第三，如果你确认你的数据源只有单条码点，不需要用扫描器逻辑，直接用第3.1节的函数就行，别为了通用性牺牲可读性。
4. C++实现：手写UTF-8编解码器
4.1 为什么我建议手写，而不是依赖codecvt
C++标准库曾经给过一个看似省事的方案：std::wstring_convert配合std::codecvt_utf8_utf16。但现实是，这个组件在C++17里被标记为deprecated，在不少编译器下会直接报警告，比如MSVC的C4996。而且它处理的是UTF-8到UTF-16的转换，你拿到UTF-16后还得再转成码点，绕了一圈。更麻烦的是wchar_t在不同平台宽度不一样：Windows下是2字节，Linux下是4字节，同一份代码换平台行为就变，协议代码这么写就是给自己埋雷。
手写一个UTF-8编解码器其实只有几十行，而且完全是位运算，不依赖任何平台特性和标准库冷门组件。再加上我们这里还有十六进制解析的需求，反正都要自己写，不如一次写透，还更容易做错误处理。
4.2 十六进制码点转成UTF-8编码
先准备一个十六进制字符解析函数，注意要用unsigned char避免符号位问题：
#include <cstdio> #include <string> #include <stdexcept> static unsigned int hex_char_value(char c) { if (c >= '0' && c <= '9') return static_cast<unsigned int>(c - '0'); if (c >= 'a' && c <= 'f') return static_cast<unsigned int>(c - 'a' + 10); if (c >= 'A' && c <= 'F') return static_cast<unsigned int>(c - 'A' + 10); throw std::invalid_argument("invalid hex character"); }然后是码点转UTF-8，核心是前面那张规则表倒过来用：
static void utf8_encode_one(std::string& out, unsigned int cp) { if (cp < 0x80) { out.push_back(static_cast<char>(cp)); } else if (cp < 0x800) { out.push_back(static_cast<char>(0xC0 | (cp >> 6))); out.push_back(static_cast<char>(0x80 | (cp & 0x3F))); } else if (cp < 0x10000) { out.push_back(static_cast<char>(0xE0 | (cp >> 12))); out.push_back(static_cast<char>(0x80 | ((cp >> 6) & 0x3F))); out.push_back(static_cast<char>(0x80 | (cp & 0x3F))); } else if (cp < 0x110000) { out.push_back(static_cast<char>(0xF0 | (cp >> 18))); out.push_back(static_cast<char>(0x80 | ((cp >> 12) & 0x3F))); out.push_back(static_cast<char>(0x80 | ((cp >> 6) & 0x3F))); out.push_back(static_cast<char>(0x80 | (cp & 0x3F))); } else { throw std::runtime_error("invalid code point"); } } std::string hex_to_utf8(const std::string& hex_text) { unsigned int cp = 0; for (char c : hex_text) { cp = (cp << 4) | hex_char_value(c); } std::string out; utf8_encode_one(out, cp); return out; }这里把“4E2D”逐位读进来，cp = 0x4E2D，然后utf8_encode_one按3字节分支压出三个字节。对“中”来说，压出的就是0xE4 0xB8 0xAD，也就是平常看到的UTF-8字节序列。
4.3 UTF-8解码成十六进制码点
解码是编码的逆过程。先看首字节的高位模式，决定后面跟几个连续字节，然后逐个取出6位有效数据：
static unsigned int utf8_decode_one(const char*& p, const char* end) { unsigned char lead = static_cast<unsigned char>(*p++); if (lead < 0x80) { return lead; } int extra = 0; unsigned int cp = 0; if ((lead & 0xE0) == 0xC0) { extra = 1; cp = lead & 0x1Fu; } else if ((lead & 0xF0) == 0xE0) { extra = 2; cp = lead & 0x0Fu; } else if ((lead & 0xF8) == 0xF0) { extra = 3; cp = lead & 0x07u; } else { throw std::runtime_error("invalid UTF-8 leading byte"); } if (p + extra > end) { throw std::runtime_error("truncated UTF-8 sequence"); } for (int i = 0; i < extra; i++) { unsigned char cc = static_cast<unsigned char>(*p++); if ((cc & 0xC0) != 0x80) { throw std::runtime_error("invalid UTF-8 continuation byte"); } cp = (cp << 6) | (cc & 0x3Fu); } return cp; } std::string utf8_to_hex(const std::string& utf8_text) { const char* p = utf8_text.data(); const char* end = p + utf8_text.size(); std::string hex; while (p < end) { unsigned int cp = utf8_decode_one(p, end); char buf[16]; snprintf(buf, sizeof(buf), "%X", cp); hex.append(buf); } return hex; }用“中”验证一遍：首字节E4，二进制11100100，匹配1110xxxx分支，extra=2，cp=0x04；后面取B8得到0x04<<6|0x38=0x138，再取AD得到0x138<<6|0x2D=0x4E2D。输出“4E2D”，和Java侧完全一致。
4.4 顺带把“字节序列hex”模式也做了
前面说了码点hex和字节hex是两回事。既然工具类都写了，我把字节序列模式也补上，正好给和第1章呼应：
std::string utf8_bytes_to_hex(const std::string& utf8_text) { static const char* digits = "0123456789ABCDEF"; std::string hex; for (unsigned char c : utf8_text) { hex.push_back(digits[c >> 4]); hex.push_back(digits[c & 0x0F]); } return hex; } std::string hex_to_utf8_bytes(const std::string& hex_text) { if (hex_text.size() % 2 != 0) { throw std::invalid_argument("hex length must be even"); } std::string out; for (size_t i = 0; i < hex_text.size(); i += 2) { unsigned char b = static_cast<unsigned char>( (hex_char_value(hex_text[i]) << 4) | hex_char_value(hex_text[i + 1])); out.push_back(static_cast<char>(b)); } return out; }测试用例对照：
std::cout << hex_to_utf8("4E2D") << std::endl; // 中 std::cout << utf8_to_hex("中") << std::endl; // 4E2D std::cout << utf8_bytes_to_hex("中") << std::endl; // E4B8AD std::cout << hex_to_utf8_bytes("E4B8AD") << std::endl; // 中4.5 C++侧的几个坑位
第一，char比较一定要转unsigned char。char是有符号的，遇到E4这种高位字节，直接比较或者移位会做符号扩展，结果全错。第二，测试字符串的字面量编码取决于源文件保存格式。我在代码里写“中”，如果源文件是UTF-8，它就是E4B8AD三个字节，utf8_to_hex("中")才能得到4E2D；如果源文件是GBK，结果就完全不是这个。正式代码里建议直接用“\xE4\xB8\xAD”这样的字节转义写测试用例，避免环境差异。第三，C++标准库的codecvt方案虽然标记了deprecated，但短期内还能用，如果你的环境允许关告警，拿来在Java/C++之间跑通原型确实快；可一旦要跨平台或长期维护，还是手写的这版更可控。
5. 边界情况与参数选择的经验清单
5.1 大小写、补零、前缀，一个都不能缺省
十六进制输入可能带0x前缀、大小写混写，甚至带前导零。我的经验是：输入侧统一清前缀、大小写通吃；输出侧统一大写，并且按协议要求决定是否补零。有的协议要求码点定长4位，比如“0041”，有的要求最短形式“41”。要做定长，Java用String.format("%04X", cp)或者%06X，C++用snprintf的%04X，把这条写进封装参数里，不要在调用方各写各的。\uXX前缀的处理也一样，是输入的一部分，还是协议固定写法，决定了你要不要剥掉。
5.2 非法输入要主动拦截，不要等着乱码
常见非法输入大致这么几类：非十六进制字符混入、字节hex长度为奇数、码点落在代理区、码点超过0x10FFFF、UTF-8里出现孤立的连续字节。对应的处理策略我用一张表记下来：
| 非法情况 | 现象 | 处理方式 |
|---|---|---|
| 输入含非hex字符 | 解析值错乱 | 逐字符校验或捕获异常 |
| 字节hex长度为奇数 | 末尾字节错位 | 提前检查长度 |
| 码点在0xD800~0xDFFF | 输出非法字符 | 按代理对合并或直接报错 |
| 码点大于0x10FFFF | 编码时溢出截断 | 范围检查后报错 |
| UTF-8孤立连续字节 | 解码错乱 | 检查连续字节高位是否为10 |
5.3 空串、单字符、混合串的语义要分开
输入是空字符串时，所有函数都应该返回空，不要抛异常。输入是单个字符时，“41”这种单字节和“4E2D”这种三字节走同一个流程。输入是混合串时，比如“abc\u4E2D!”，必须用第3.3节那种扫描器，而不是先把整个串按4位分组再逐块转，后者会把“abc”也切坏。所以封装API时，我建议明确区分“单码点转换”和“整串转义解析”两个入口，语义清晰，调用方不容易误用。另外，BOM也要留意。UTF-8文本开头如果带EF BB BF，按码点解析会多出一个U+FEFF字符，很多隐性问题都是它引起的，协议对接时要么剥掉，要么确认双方都不带。
6. 常见问题与排查技巧实录
6.1 现象：转换后中文变成问号
这个问题90%不是转换函数的问题，而是显示环节编码错乱。同一个“中”字，控制台用GBK显示UTF-8字节就出问号；页面声明ISO-8859-1也会出乱码。我的排查顺序是：先确认源数据的编码，再确认自己代码输出的字节串，最后确认显示终端。把“中”转成hex输出，如果得到4E2D，说明转换本身没问题，问题在链路其他人的手里。
6.2 现象：表情符号变成两个方框
这就是代理对没合并。Java里用了charAt而不是codePointAt，C++里只按三字节规则解码而没处理四字节分支，都会造成BMP外字符碎成两个非法单元。检查代码里是否用了codePointAt、Character.toCodePoint，以及UTF-8解码是否覆盖0xF0开头的四字节分支。
6.3 现象：C++编译报codecvt相关警告或错误
C++17之后，wstring_convert和codecvt_utf8_utf16进入deprecated状态，有的编译器默认报错。处理方式有三种：关掉对应告警方言继续用；升级到支持C++23的std::text_encoding之后查阅新版用法；或者干脆用手写编解码器。我个人推荐第三种，几十行代码不依赖标准库版本，彻底根治这个告警。
6.4 快捷排查速查表
| 现象 | 可能原因 | 处理 |
|---|---|---|
| 单字符转换全错 | 把字节hex当码点解析 | 确认输入是4E2D还是E4B8AD |
| \uXXXX转出来英文正常中文乱码 | 没走扫描器逐块切分 | 用整体转义解析函数 |
| 部分字符多出\uFEFF | UTF-8带BOM | 先剥BOM再转换 |
| Java转出D83DDE00 | 用了charAt取char | 改用codePointAt |
| C++解码遇到截断异常 | 字符串被误截断 | 检查数据源和字节长度 |
最后分享一点我的体会
这套工具函数，我第一次写的时候因为代理对和字节hex两个概念没捋清，来回改了三次。后来把“码点”和“字节序列”两个词刻在脑子里，再遇到十六进制字符串，第一反应永远是问一句：这到底是码点还是字节？是单个字符还是整串转义？有没有可能带代理对？三个问题问完，选对应方案，基本不再返工。如果你也是做网关协议或数据清洗的，建议把第3章和第4章的代码各留一份，遇到\uXXXX，直接用现成的。另外，如果你要跑通Java和C++互转的联调，记住两侧输出大小写统一、定长规则统一，这两条对齐了，联调能少吵一半的架。
