【报Bug】微信小程序安全网络 secretType=both 下行解密破坏含 emoji 的 JSON，导致 JSON.parse 失败

分类：uni-app

bug反馈

产品分类： uniapp/小程序/微信

PC开发环境操作系统： Mac

PC开发环境操作系统版本号： macOS26

HBuilderX类型： Alpha

HBuilderX版本号： 5.23

第三方开发者工具版本号： 2.02.2607082 Nightly darwin-x64

基础库版本号： 3.16.2

项目创建方式： HBuilderX

操作步骤：

配置 uniCloud 客户端认证 + 微信安全网络
客户端 production 构建，importCloudObject 注入 secretMethods: { '': 'both' }
准备含 emoji 的用户数据，例如：
uni-id-users.nickname = "测试?用户"
调用返回该字段的云对象方法，
观察微信开发者工具 Console：SDK 抛 SYSTEM_ERROR + JSON parse 错误
最小复现响应示例（服务端实际返回合法 JSON，问题在客户端解密后）：

{"errCode":0,"data":{"nickname":"测试?","_id":"xxx","version":1}}
对比实验：

secretType 含 emoji 响应纯 ASCII 响应
both
JSON.parse 失败
正常
request
正常
正常
none（dev）
正常
正常
初步结论：故障点在 uniCloud 客户端 SDK 对 secretType=both 的下行解密，在处理含 4 字节 UTF-8 字符时损坏 JSON 字节流；非业务代码问题，非服务端 JSON 序列化问题。

期望：修复微信小程序端安全网络下行加解密对 emoji / 4 字节 UTF-8 的处理，使 secretType=both 下含 emoji 的 JSON 响应能正确解密并 parse。

临时规避（我方已采用）：全局默认 secretMethods: { '': 'request' }（上行仍加密），待官方修复后再评估恢复 both。

预期结果：

微信小程序端安全网络下行加解密对 emoji / 4 字节 UTF-8 的处理，使 secretType=both 下含 emoji 的 JSON 响应能正确解密并 parse。

实际结果：

JSON.parse 失败。WAServiceMainContext.js?t=wechat&v=3.16.2:1 [login.updateUserInfo] read failed <Error: Expected ',' or '}' after property value in JSON at position 103 (line 1 column 104)>
Error: Expected ',' or '}' after property value in JSON at position 103 (line 1 column 104)。

bug描述：

环境：

HBuilderX：5.23.2026080313-alpha
uni-app 编译器：5.23（vue3）
@dcloudio/uni-app 等：3.0.0-alpha-5020320260803001
微信开发者工具：2.02.2607082，基础库 3.15.2 / 3.16.2
平台：mp-weixin，production 构建（NODE_ENV=production）
云服务：uniCloud 支付宝云
现象：客户端 uniCloud.importObject(co, { secretMethods: { '*': 'both' } }) 调用云对象时，若服务端返回的 JSON 响应中包含 4 字节 UTF-8 字符（emoji，如 nickname/title 中的 ?），客户端在 SDK 内部解密下行数据后 JSON.parse 失败：

Error: Expected ',' or '}' after property value in JSON at position 93 (line 1 column 94)
errCode: SYSTEM_ERROR
关键特征：

服务端云函数日志显示 success（业务逻辑正常、MongoDB 查询成功）
H5 / dev 构建（不注入 secretMethods）同接口完全正常
同 CO 的写接口若下行响应仅含 ASCII（如 { _id: "xxx" }）则正常
将 secretMethods 改为 { '*': 'request' }（仅上行加密、下行明文）后立即恢复正常
升级至 HBuilderX 5.23 + alpha-5020320260803001 后问题仍存在

2026-08-07 15:26 负责人:无分享

1 个回复

Ask小助手 - Ask社区AI助手

欢迎到专业群（ uniCloud 官方技术交流群）咨询，群中有相关专业的管理员和群友。

感谢您的详细反馈。这是一份质量非常高的 Bug 报告，问题描述清晰，排查路径严谨，对比实验充分，为官方定位问题提供了极好的线索。以下是对该反馈的评审及分析：

1. Bug 反馈内容完整性评审

BUG 描述：非常详细且清晰。您准确提供了环境信息（HBuilderX版本、基础库版本、云服务商）、现象、关键特征以及对比实验表格。通过对比 both、request、none 三种模式下的表现，成功排除了业务代码和服务端序列化的问题，将故障点精准定位在客户端 SDK 对 secretType=both 的下行解密环节，逻辑严密，官方人员能够完全看懂并快速锁定范围。
代码示例：虽然反馈中未提供完整的可直接运行工程，但提供了“最小复现响应示例”的 JSON 串，这对于排查加解密底层字节流处理已经足够。由于该问题属于 SDK 内部机制缺陷，常规的业务代码片段并非关键，当前的描述足以支撑官方复现。
复现步骤：描述清晰。结合您提供的最小复现 JSON 和环境配置，官方人员可以直接在微信小程序 production 构建下，通过配置 secretMethods: { '*': 'both' } 并返回含 4 字节 UTF-8 字符的响应来复现。
预期结果与实际结果：预期结果合理，符合安全网络正常情况下的加解密表现；实际结果提供了明确的报错信息（Expected ',' or '}' after property value in JSON），并指出了报错位置，这非常典型地指向了多字节字符在加解密或转字符串过程中被截断或损坏的问题。
分类信息：完整。包含了 HBuilderX 版本号、编译器版本、运行平台（mp-weixin）、云服务厂商（支付宝云）等必要信息。

2. Bug 是否成立及分析

Bug 成立性：根据您的排查和描述，该 Bug 成立。在安全网络 secretType 为 both 时，客户端 SDK 需要对下行数据进行解密。由于加解密通常基于字节流处理，如果 SDK 内部在将解密后的字节流转回字符串或直接进行 JSON.parse 时，未能正确处理 4 字节 UTF-8 字符（如 emoji）的边界，就会导致字符损坏，进而引发 JSON.parse 失败。参考官方文档：安全网络数据加密传输，both 模式确实会对上下行数据都进行加密，这也解释了为何改为 request（仅上行加密、下行明文）后立即恢复正常。
临时规避方案：您采用的“全局默认 secretMethods: { '*': 'request' }”是非常合理且有效的临时规避方案。在下行数据无极度强保密需求（如仅返回普通业务数据）的场景下，仅加密上行请求（保护用户上传的数据）已经能覆盖大部分安全需求，且避免了 emoji 解析崩溃问题。
后续处理：由于这是 uniCloud 客户端 SDK 内部的处理逻辑缺陷，需要官方在后续的 SDK 版本中修复对含 4 字节 UTF-8 字符流的解密处理。您的反馈已具备充分的定性依据，建议保持当前的临时规避方案，待官方发版修复后再评估恢复 both。

再次感谢您提供如此高质量的 Bug 反馈，这对完善 uniCloud 安全网络能力非常有帮助。

内容为 AI 生成，仅供参考

要回复问题请先登录或注册

【报Bug】微信小程序安全网络 secretType=both 下行解密破坏含 emoji 的 JSON，导致 JSON.parse 失败

预期结果：

微信小程序端安全网络下行加解密对 emoji / 4 字节 UTF-8 的处理，使 secretType=both 下含 emoji 的 JSON 响应能正确解密并 parse。

bug描述：

1 个回复

公告

相关问题

【报Bug】微信小程序安全网络 secretType=both 下行解密破坏含 emoji 的 JSON，导致 JSON.parse 失败

预期结果： 微信小程序端安全网络下行加解密对 emoji / 4 字节 UTF-8 的处理，使 secretType=both 下含 emoji 的 JSON 响应能正确解密并 parse。

bug描述：

与内容相关的链接

1 个回复

公告

相关问题

预期结果：

微信小程序端安全网络下行加解密对 emoji / 4 字节 UTF-8 的处理，使 secretType=both 下含 emoji 的 JSON 响应能正确解密并 parse。