今天不聊大道理，聊聊最近让我头秃的一个小问题。做 .net 开发这么多年，自认为对编码这块挺熟，但微信那个昵称，真是把我搞得够呛。

很多兄弟在后台问我，说用 .net 获取微信昵称的时候，返回来的是一堆问号，或者是乱码。心里那个急啊，明明接口文档写得清清楚楚，怎么到自己手里就变样了呢？

我最近接了个外包，客户是个传统行业的老总，非要搞个微信小程序，还要把用户的微信昵称存到数据库里，顺便做个简单的会员积分。看着挺简单，结果第一步卡住了。

我写了个标准的 HTTP 请求，拿到 access_token，再调 getUserInfo。代码跑起来，没报错，日志里看着也正常。可一查数据库，好家伙，全是“???”或者一些看不懂的符号。

我第一反应是数据库字符集没设对。赶紧去检查 MySQL 的表结构，utf8mb4 都设好了，索引也建了，没毛病。

那难道是 .net 的字符串处理有问题？

我把返回的 JSON 反序列化出来，打印到控制台。结果还是乱码。这时候我才想起来，微信返回的数据，有时候编码方式挺奇怪的。

特别是那些带 Emoji 表情的昵称。微信的昵称支持 Emoji，但 .net 默认的编码有时候处理不好这种多字节字符。

我试着把返回的字节数组，用 UTF-8 重新编码了一遍。

byte[] bytes = Encoding.UTF8.GetBytes(jsonString);

string result = Encoding.UTF8.GetString(bytes);

这么一改，大部分正常昵称显示正常了。但是，还是有个别客户的昵称，比如带个笑脸或者爱心，依然显示成方块或者问号。

这就尴尬了。客户说，你看，我就想存个名字，怎么这么难？

我只能耐着性子解释，说微信的昵称底层是用 Unicode 存储的，而有些特殊符号在 UTF-8 下需要四个字节，也就是 utf8mb4 才能存。

但这只是数据库层面的事。代码层面，我怀疑是 HttpWebRequest 或者 HttpClient 的默认编码设置有问题。

后来我翻了翻老代码，发现以前用 WebClient 的时候，好像没遇到过这问题。于是我把 HttpClient 换回了 WebClient，并显式指定了 Encoding.UTF8。

WebClient client = new WebClient();

client.Encoding = Encoding.UTF8;

string json = client.DownloadString(url);

嘿，你还别说，这次再查数据库，那个带爱心的昵称终于显示出来了。

不过，这还不是最坑的。

有些用户故意起一些生僻字或者特殊符号做昵称，比如“?”或者“_”。这些字符在微信里是合法的，但在某些老旧的 .net 框架或者特定的服务器环境下，可能会引发编码转换异常。

我甚至遇到过一次，因为一个用户的昵称里包含了不可见的控制字符，导致整个 JSON 解析失败，程序直接崩溃。

这让我意识到，.net 获取微信昵称，不能只靠一套代码走天下。

你得做好异常捕获。

try {

// 解析逻辑

} catch (Exception ex) {

// 记录日志，用默认昵称或者用户ID代替

logger.Error(ex);

}

另外，建议在存入数据库之前，先对字符串做一次清洗。去掉那些可能引起编码问题的特殊字符，或者统一替换成通用的占位符。

虽然这有点不完美，但为了保证系统的稳定性，有时候得妥协。

我还发现，微信官方文档有时候更新不及时。比如之前推荐用的 getUserInfo 接口，后来限制越来越严，现在大部分情况只能拿到 openid，昵称得通过 wx.getUserProfile 接口获取，而且这个接口在 2023 年之后改动很大。

如果你还在用老方法，大概率会拿到空值或者错误数据。

所以，大家在用 .net 获取微信昵称 的时候，一定要看清楚当前微信 API 的最新文档。别拿几年前的代码去跑现在的接口，肯定不行。

还有一点，测试的时候，多准备几个测试账号。

有的号是纯中文，有的号带英文，有的号带 Emoji，有的号全是符号。这样能覆盖大部分场景。

我这次就是测试账号不够，导致上线后被客户投诉。虽然最后解决了，但时间成本太高了。

总之，技术这东西，细节决定成败。

别小看一个昵称的存储，它背后涉及编码、数据库、API 版本、异常处理等一系列问题。

希望我的这点经验，能帮大家在 .net 获取微信昵称 的时候少走点弯路。

要是你还遇到其他奇葩问题，欢迎在评论区留言，咱们一起讨论。毕竟，一个人琢磨不如大家一起坑，哦不，一起填坑。

记住，代码是写给人看的，顺便给机器执行。写得清晰点，调试的时候能少掉几根头发。