简介这份资源面向仍在维护 Visual C 6.0 老项目的开发者以及需要在 VC6.0 环境中实现 JSON 读写、又受困于中文字符乱码问题的 C 程序员提供一套可直接编译运行的 jsoncpp 集成案例。压缩包共 72 个文件、约 3.77MB以 h 头文件与 cpp 源文件为主体配套 inl 内联实现、dsw/dsp 工程文件、rc 资源脚本、exe 可执行程序以及 txt 说明和 doc 使用文档完整保留了工程目录与调试中间文件便于对照排查。资源内含经测试通过的 jsoncpp 源码类使用说明围绕解析与序列化两个方向给出编码处理思路说明如何让中文字段在读取和输出时保持一致同时附带示例数据文件与对话框程序可直接观察解析结果是否正确显示帮助读者少走编码配置与工程集成的弯路。目前已有 591 人学习下载适合需要快速验证方案、减少试错成本的 VC6.0 使用者参考。1. VC6 接 jsoncpp编译过了不算赢中文不乱码才算跑通VC6 的老工程还在跑上游接口全换成 JSON 了多数人的第一反应是拽一份 jsoncpp 进来。结果往往是英文和数字解析得干干净净一到msg:成功就变成????或者界面上直接甩出一串\u6210\u529f。这不是库的问题是编码链路没接上——jsoncpp 内部一律按 UTF-8 存字节而 VC6 的 MBCS 工程、CString、GDI 绘制全走本机代码页GBK。这份案例要解决的就是这条链路怎么让 VC6 认下 C98 时代的 jsoncpp怎么把 UTF-8 的中文安全落到 GBK 界面上以及反方向把 GBK 拼回合法 JSON。适合还在维护 MFC、工控上位机、要对接 HTTP 或本地配置文件的开发者尤其是那种工程不能升、只能原地修的场景。2. 选源码与搭工程让 VC6 认下 C98 时代的 jsoncppVC6 的编译器停在上世纪末auto、nullptr、右值引用一概不认。jsoncpp 现在主线早就 C11 化了随手下一份最新源码丢进 VC6迎面的是一片 C2059 和 C2143。案例包里用的那份是 0.x 系列的老分支只依赖标准 C98 的std::string、std::map、std::vector、std::ostringstream正好卡在 VC6 的能力边界内。选型理由很朴素不是老版本更好而是新版本在这个编译器上根本站不住改造成本远大于收益。2.1 先用关键字筛一遍源码别急着建工程拿到任何一份 jsoncpp 源码先别开 VC6用任意文本编辑器全局搜下面这些词。命中一个就说明这份源码进不了 VC6要么换版本要么逐个改。源码里的写法VC6 的反应处理方式auto x ...C2065 / C2143换成显式类型声明nullptrC2065 未声明的标识符换成NULL或0enum classC2059 语法错误改成普通enum加前缀std::unique_ptr/make_sharedC2039 不是成员的成员退回裸指针加deletelong longC2632 两个类型连写换成__int64连续尖括号C2059中间强制加空格 override/finalC2059直接删掉static_assertC2065换成注释或#pragma message搜完没有命中基本就能编译。还有一处容易漏老版本 jsoncpp 的目录结构是include/json/*.h加src/lib_json/*.cpp头文件里会#include json_valueiterator.inl。.inl是被头文件包含的不要把它单独加进工程去编译否则会出现重复定义或莫名其妙的模板报错。案例里已经按这个结构摆好工程只需要指一个包含目录。2.2 三种接法里加源码最稳常见接法有三种直接把三个.cpp加进工程、编译成静态库再链、编成 DLL 再导出。VC6 上我一般选第一种理由是调试时能单步进 jsoncpp 内部看它到底把哪个字符吃掉了静态库和 DLL 一旦运行期出问题就变成黑匣子了。具体动作Project → Add To Project → Files把json_reader.cpp、json_value.cpp、json_writer.cpp三个文件加进来。Project → Settings → C/C → Preprocessor → Additional include directories填..\jsoncpp\include按你实际放的层级改。别用Tools → Options → Directories那个全局设置换台机器就失效。选中这三个 cppProject → Settings → C/C → Category 选 Precompiled Headers → 选 Not using precompiled headers。这一步不做必然报 C1010。建个控制台工程先验一遍别一上来就塞进 MFC 大工程里排查// 最小验证能编译、能解析、能取到值三件事一次确认 #include string #include iostream #include json/json.h // 老版本的头文件在 json/ 子目录下 int main() { const char* text {\id\:1,\name\:\test\}; Json::Reader reader; Json::Value root; if (!reader.parse(text, root)) { // 老版本拼 Formated新一点拼 Formatted按头文件里实际的名字写 std::cout reader.getFormatedErrorMessages() std::endl; return 1; } std::cout root[name].asString() std::endl; // 输出 test std::cout root[id].asInt() std::endl; // 输出 1 return 0; }这段代码里Json::Reader负责把文本解析成一棵Json::Value树parse的返回值必须判不判就等于把错误信息丢了。asString()只有在节点确实是字符串时才安全asInt()遇到非数字会给你 0 而不是报错这两点决定了后面所有取值代码都得先isString()/isInt()判断类型否则调试版会直接断言。MFC 工程里记得把#include stdafx.h放在第一行jsoncpp 的三个 cpp 则要设成不使用预编译头两边不冲突。2.3 报错按这个顺序定位能省一半时间VC6 的报错信息质量很差一个头文件没找到能引出几十行模板错误。我习惯按下面这个顺序看先看第一条错误。VC6 的编译错误是链式的第一条往往才是真因后面的全是连坐。如果第一条是C1083: Cannot open include file就是包含目录没配对先解决这个再看别的。再看是不是C1010。这个报错原文是unexpected end of file while looking for precompiled header含义是某个 cpp 里没有#include stdafx.h却被要求用预编译头。jsoncpp 的源码显然不会有stdafx.h所以只能对这三个文件单独关掉预编译头。最后看链接错误。LNK2001: unresolved external symbol一般是漏加了某个 cppLNK2005: xxx already defined或LNK4098: defaultlib LIBCMTD conflicts with use of other libs说明工程的运行库设置和 jsoncpp 编译时的运行库不一致。VC6 里在Project → Settings → C/C → Code Generation → Use run-time library统一成Debug Multithreaded/MTD或Debug Multithreaded DLL/MDD所有参与链接的工程必须一模一样Debug 和 Release 也要各自对齐。3. 解析中文UTF-8 到 GBK 的两次跳转与 \u 转义乱码这件事九成的根因不是jsoncpp 不支持中文而是没人说清楚中间那段字节到底是什么编码。jsoncpp 解析完Value里存的是 UTF-8 字节序列VC6 的 MBCS 工程里CString、SetWindowText、TextOut期待的是 GBK。你把 UTF-8 字节直接喂给CString界面显示成涓枃之类的串这是典型的UTF-8 被当 GBK 解读。反过来把 GBK 字节塞进Value再序列化落盘的文件就不是合法 UTF-8对端解析直接失败。3.1 先确认 jsoncpp 到底交给你什么判断方法很直接调用asString()拿到std::string把每个字节按十六进制打出来。中文成功的 UTF-8 是E6 88 90 E5 8A 9F六个字节GBK 是B3 C9 B9 A6四个字节。看到六个字节说明拿到的确实是 UTF-8问题出在往下传的环节看到四个字节说明上游给你的 JSON 本身就是 GBK 的那压根不是合法 JSONJSON 规范要求 UTF-8得先跟前端或对端把编码这件事掰扯清楚。还有两个顺手要注意的点。asCString()返回的是指向Value内部缓冲区的指针Value一析构这块内存就没了把它存进CString成员变量里迟早出问题要用就立刻拷贝成std::string。另外老版本 jsoncpp 对非字符串节点调asString()会抛异常或断言取值前老老实实isString()判断一次。3.2 写两个转换函数一次写对反复用VC6 上没有std::codecvt那套东西可用就算有也不敢用标准做法是走 Win32 的MultiByteToWideChar和WideCharToMultiByte中间以 UTF-16 为桥梁。案例包里封装了两个函数逻辑是一样的先转宽字符再转目标代码页。// 编码转换封装VC6 MBCS 工程通用放在一个独立的 .h/.cpp 里 #include windows.h #include string #include vector // UTF-8 - 本机 ANSI(GBK)。转换失败返回空串调用方自己判空 std::string Utf8ToAnsi(const std::string utf8) { if (utf8.empty()) return std::string(); // 第一步UTF-8 - UTF-16。第四个参数传长度而不是 -1 // 避免字符串中间出现 \0 时被提前截断 int wlen ::MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), (int)utf8.size(), NULL, 0); if (wlen 0) return std::string(); std::vectorwchar_t wbuf(wlen, L\0); ::MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), (int)utf8.size(), wbuf[0], wlen); // 第二步UTF-16 - GBK。lpUsedDefaultChar 用来发现转不过去的字符 BOOL usedDefault FALSE; int alen ::WideCharToMultiByte(CP_ACP, 0, wbuf[0], wlen, NULL, 0, NULL, usedDefault); if (alen 0) return std::string(); std::vectorchar abuf(alen, \0); ::WideCharToMultiByte(CP_ACP, 0, wbuf[0], wlen, abuf[0], alen, NULL, usedDefault); // usedDefault 为 TRUE 表示有字符在 GBK 里没有对应项比如 emoji // 已被替换成 ?要不要告警由业务决定 return std::string(abuf[0], alen); } // GBK - UTF-8方向相反用于把界面输入拼进 JSON std::string AnsiToUtf8(const std::string ansi) { if (ansi.empty()) return std::string(); int wlen ::MultiByteToWideChar(CP_ACP, 0, ansi.c_str(), (int)ansi.size(), NULL, 0); if (wlen 0) return std::string(); std::vectorwchar_t wbuf(wlen, L\0); ::MultiByteToWideChar(CP_ACP, 0, ansi.c_str(), (int)ansi.size(), wbuf[0], wlen); int ulen ::WideCharToMultiByte(CP_UTF8, 0, wbuf[0], wlen, NULL, 0, NULL, NULL); if (ulen 0) return std::string(); std::vectorchar ubuf(ulen, \0); ::WideCharToMultiByte(CP_UTF8, 0, wbuf[0], wlen, ubuf[0], ulen, NULL, NULL); return std::string(ubuf[0], ulen); }几个参数值得单独说。CP_UTF8和CP_ACP是两个代码页常量CP_ACP在中文 Windows 上就是 936GBK别硬编码成 936换到别的语言环境就错了。第二个参数dwFlags传 0 即可传WC_NO_BEST_FIT_CHARS可以让近似匹配也走替换字符做严格校验时有用。字符串长度一律用(int)s.size()不要图省事写-1——-1会让 API 自己去找结尾的\0一旦 JSON 里有转义后的空字符就断在半路。返回空串而不是抛异常是因为 VC6 时代很多 MFC 代码没有异常安全的概念抛出去反而没人接。3.3 完整解析示例对象、数组、嵌套一次走通下面这段是案例里的主流程源文件本身是 GBK 保存的所以 JSON 文本里干脆用\u转义写中文——全 ASCII不受源文件编码影响也顺便验证了 jsoncpp 的转义解码能力。// 带中文、数组、嵌套结构的完整解析 const char* kSample {\code\:0,\msg\:\\\u6210\\u529f\, \data\:{\title\:\\\u6d4b\\u8bd5\\u4efb\\u52a1\, \tags\:[\\\u4e2d\\u6587\,\utf8\],\count\:3}}; void ParseSample() { Json::Reader reader; Json::Value root; if (!reader.parse(kSample, root)) { std::string err reader.getFormatedErrorMessages(); ::OutputDebugStringA(err.c_str()); // 解析失败一定要把位置打出来 return; } // msg 拿到的仍是 UTF-8 字节界面要 GBK转一次 std::string msgAnsi Utf8ToAnsi(root[msg].asString()); // 遍历对象老版本用 getMemberNames()返回键名列表同样 UTF-8 Json::Value::Members names root.getMemberNames(); for (size_t i 0; i names.size(); i) { std::string key Utf8ToAnsi(names[i]); // 键名也要转别只转值 const Json::Value v root[names[i]]; if (v.isObject()) { Json::Value::Members sub v.getMemberNames(); for (size_t k 0; k sub.size(); k) { const Json::Value sv v[sub[k]]; if (sv.isString()) std::string s Utf8ToAnsi(sv.asString()); else if (sv.isInt()) int n sv.asInt(); } } else if (v.isArray()) { // 数组下标类型是 Json::Value::UInt别用 int 接 for (Json::Value::UInt j 0; j v.size(); j) { if (v[j].isString()) std::string s Utf8ToAnsi(v[j].asString()); } } } }逻辑顺序是解析 → 校验 → 按键名取 → 按类型分派 → 转码落地每一步都不能省。getMemberNames()返回的Members是std::vectorstd::string的 typedefVC6 上能正常用但注意它是按std::map的键序排的不是原始 JSON 里的顺序——需要保序就得改用数组结构这是 JSON 对象的固有特性不是 jsoncpp 的锅。v.size()返回UInt用int接会在 64 位上有告警虽然 VC6 只有 32 位但养成习惯没坏处。3.4 \uXXXX 和代理对jsoncpp 已经替你做了\u6210\u529f这两组转义jsoncpp 在解析阶段就还原成了 UTF-8 字节你拿到的std::string里是E6 88 90 E5 8A 9F不需要自己再写一遍 unescape。代理对\ud83d\ude00这种也是同理jsoncpp 会合成一个四字节的 UTF-8 字符。真正需要自己动手的只有一种情况上游把 JSON 转义了两次你拿到的字符串字面量里是\\u6210\\u529f带反斜杠的六字符文本。这时候asString()返回的是\u6210这么一串 ASCII得自己在业务层再做一次解转义。判断方法很简单看返回值是不是以\u开头。案例里给了这种情况的处理分支但更该做的是推动上游把 JSON 序列化改对别在消费端兜底。4. 生成中文 JSON保证落盘是 UTF-8 的几个动作解析只是半个流程。上位机要把本地参数、报警记录写成 JSON 给别的系统读中文一旦用 GBK 字节写进去Python、Java、Go 那边一读就是乱码或者直接解析失败——UTF-8 校验严格的解析器会当场报错。这块要盯住三件事Writer 选哪个、写之前转不转、文件怎么打开。4.1 FastWriter 和 StyledWriter 怎么选两个都够用差别在格式和性能。老版本还有Json::StyledStreamWriter可以直接往流里写工程里用得少。Writer输出形态适用场景注意点FastWriter单行紧凑无缩进网络报文、日志、写配置文件末尾自带一个\n部分对端会因此解析失败StyledWriter带缩进换行可读人工查看的配置文件、调试输出体积大字符串里的换行不会影响结构StyledStreamWriter直接写std::ostream大结构体避免中间字符串出错时不返回错误码只能靠流状态判断FastWriter::write()返回值末尾那个换行是个实打实的坑我在接口联调时被它坑过一次对端用的是严格的 JSON 解析器多一个\n就报trailing characters。稳妥做法是拿到结果先裁一次尾巴。4.2 写之前转 UTF-8落盘用二进制// 把 Value 写成 UTF-8 文件 bool SaveJsonAsUtf8(const std::string path, const Json::Value root) { Json::FastWriter writer; std::string out writer.write(root); // 末尾自带 \n if (!out.empty() out[out.size() - 1] \n) out.erase(out.size() - 1); // 裁掉避免对端报尾随字符 // 必须二进制打开文本模式会把 \n 翻成 \r\n // 更坑的是读到 0x1A 会被当成 EOF 提前结束 std::ofstream ofs(path.c_str(), std::ios::out | std::ios::binary | std::ios::trunc); if (!ofs.is_open()) return false; // 给 Windows 记事本看可以加 BOM给 jsoncpp 或跨平台程序读就别加 // const char kBom[3] { (char)0xEF, (char)0xBB, (char)0xBF }; // ofs.write(kBom, 3); ofs.write(out.c_str(), (std::streamsize)out.size()); ofs.close(); return true; }std::ios::binary这个标志在 VC6 上比在新编译器上重要得多。文本模式下 CRT 会做两件事写的时候把\n转成\r\n读的时候把\r\n转回\n同时把0x1A当文件结束符。JSON 里如果有中文UTF-8 字节流中出现0x1A的概率不低比如某些生僻字的某个字节读文件时直接截断排查起来极其费劲。案例里读写一律二进制就是为了绕开这一层。ofs.write的长度参数用out.size()而不是strlen(out.c_str())因为std::string里理论上可以存空字符虽然 JSON 序列化结果里不会有但统一按长度写更安全。4.3 键名、数组、类型三件事别写错Json::Value root; // 数值就写数值别写成字符串对端做类型判断会挂 root[code] 0; root[count] 3; // 值必须先转 UTF-8 再赋值直接塞 GBK 字面量等于埋雷 root[msg] AnsiToUtf8(成功); root[title] AnsiToUtf8(测试任务); // 数组用 arrayValue 显式声明append 会自动扩容 Json::Value tags(Json::arrayValue); tags.append(AnsiToUtf8(中文)); tags.append(utf8); // 纯 ASCII 不用转 root[tags] tags; // 嵌套对象直接赋值即可 Json::Value data; data[items] tags; root[data] data;root[code] 0和root[code] 0序列化出来是0和0看起来只差一对引号但对端asInt()取到的是 0 和 0type()取到的是intValue和stringValue一旦对端做了严格类型校验就直接拒收。键名如果是中文同样要AnsiToUtf8包一层很多人只转值忘了转键结果 JSON 结构本身不是合法 UTF-8怎么查都查不出问题出在键上。5. 避坑与排查VC6 上五个真实翻车现场下面这几条都是我在实际工程里撞过的按现象 → 原因 → 解决记遇到时对号入座比重头分析快得多。5.1 报 C1010unexpected end of file while looking for precompiled header现象jsoncpp 的三个 cpp 一加进 MFC 工程就编译不过报 C1010但文件明明完整。原因工程开了预编译头stdafx.h编译器要求每个 cpp 开头都有#include stdafx.hjsoncpp 的源码当然没有。解决在Project → Settings里选中这三个文件注意是选中文件不是选中整个工程C/C 页 → Category 选Precompiled Headers→ 选Not using precompiled headers。逐个文件设别图省事设成整个工程。5.2 LNK4098LIBCMTD 和其他库冲突现象编译全过链接期报defaultlib LIBCMTD conflicts with use of other libs或者 LNK2005 一堆already defined。原因工程用的是/MDD多线程调试 DLL 版运行库而之前编好的 jsoncpp 静态库用的是/MTD两套 CRT 混在一起同一个符号有两份实现。解决把所有参与链接的工程、所有配置Debug/Release、Win32的运行库设置拉到一致。纯静态工程统一/MTD带 MFC 动态库的统一/MDD。改完记得 Rebuild All只 Build 会留下旧的 obj。5.3 解析永远失败错误信息却说不出所以然现象reader.parse()返回 falsegetFormatedErrorMessages()给的是* Line 1, Column 1 Syntax error: value, object or array expected。原因三种可能概率从高到低——文件开头有 UTF-8 BOMEF BB BF读文件时用了文本模式0x1A截断或\r\n转换把内容弄坏了字符串末尾有多余的\0或垃圾字节。解决先十六进制看一眼文件头三字节是EF BB BF就在读取时跳过前三个字节再交给reader.parse()。读取统一用std::ios::binary。可以先用reader.parse(str, root, false)关掉注释收集排除注释解析的干扰。5.4 中文变问号或者出现双重乱码现象界面上显示??或者显示成涓枃、测试这种一看就不对的串。原因??是转换时目标编码里没有对应字符被替换成了问号通常是 emoji 或生僻字往 GBK 转涓枃是 UTF-8 字节被当 GBK 解读测试是 UTF-8 字节被当 Latin-1 解读。还有一种是自己坑自己把已经是 GBK 的串又Utf8ToAnsi了一次。解决在转换函数入口打日志把输入输出的字节数以十六进制打出来跟 3.1 里的对照表比一比立刻能定位方向错了还是转重了。检查WideCharToMultiByte的lpUsedDefaultChar出参为 TRUE 就说明有字符丢了这种字符要么过滤、要么改用 UTF-8 存储。5.5 Release 正常、Debug 崩或者偶发崩溃现象同一份数据Debug 版跑着跑着在asString()处断言Release 版看起来正常但结果偶尔不对。原因asCString()返回的指针指向Value内部缓冲区Value一析构就悬空跨函数传递这个指针在 Release 下不一定立刻崩但数据已经错了。另一种是没判类型就调asString()Debug 版断言、Release 版返回空串。解决asCString()只在同一个函数体内临时用出了作用域一律转成std::string或CString拷贝。所有取值前加isString()/isInt()/isObject()判断宁可多写一行判断也别赌类型对。6. 上线前拿一份最脏样本跑一遍回归功能写完不算完我习惯留一份自己造的脏样本做回归每次改编码相关的代码都拿它跑一次。样本里塞这些东西中文键名和中文值、一个四字节 emoji\ud83d\ude00、一个超过 65535 的长字符串、一个空对象{}、一个空数组[]、一个大整数超过int范围的用asDouble()接、一段带引号和反斜杠需要转义的文本。这份样本能把九成的编码和边界问题提前逼出来。验证输出是不是真 UTF-8别靠自己眼睛看。最简单的办法是用另一门语言读一遍# 交叉验证文件能被严格按 UTF-8 解开且中文能正确显示 import json with open(rD:\out\config.json, rb) as f: raw f.read() assert not raw.startswith(b\xef\xbb\xbf), 带 BOM很多解析器会拒收 obj json.loads(raw.decode(utf-8)) # 解码失败会直接抛异常 print(obj[msg], obj[data][title]) # 中文能原样打出来才算过json.loads对非法 UTF-8 是零容忍的能过这一关说明落盘字节干净。再加一条把这份文件重新喂给 VC6 那端的解析代码跑一遍写出去 → 读回来 → 值相等的往返比对中文、转义、数组顺序都要对上。往返不一致的地方八成是某一侧多转或少转了一次码。血泪经验是编码问题从来不会在写代码的当天暴露都是交付之后对端说你给的中文是乱码。从那以后我每次动到 JSON 读写不管改的是一行还是一段都强制走一遍这份脏样本加交叉验证不再靠上次是好的这种玄学判断。案例包里那份已经调通的工程和转换封装省的就是这段反复试错的时间拿去对着自己的接口改字段名就能用。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源面向仍在维护 Visual C 6.0 老项目的开发者以及需要在 VC6.0 环境中实现 JSON 读写、又受困于中文字符乱码问题的 C 程序员提供一套可直接编译运行的 jsoncpp 集成案例。压缩包共 72 个文件、约 3.77MB以 h 头文件与 cpp 源文件为主体配套 inl 内联实现、dsw/dsp 工程文件、rc 资源脚本、exe 可执行程序以及 txt 说明和 doc 使用文档完整保留了工程目录与调试中间文件便于对照排查。资源内含经测试通过的 jsoncpp 源码类使用说明围绕解析与序列化两个方向给出编码处理思路说明如何让中文字段在读取和输出时保持一致同时附带示例数据文件与对话框程序可直接观察解析结果是否正确显示帮助读者少走编码配置与工程集成的弯路。目前已有 591 人学习下载适合需要快速验证方案、减少试错成本的 VC6.0 使用者参考。1. VC6 接 jsoncpp编译过了不算赢中文不乱码才算跑通VC6 的老工程还在跑上游接口全换成 JSON 了多数人的第一反应是拽一份 jsoncpp 进来。结果往往是英文和数字解析得干干净净一到msg:成功就变成????或者界面上直接甩出一串\u6210\u529f。这不是库的问题是编码链路没接上——jsoncpp 内部一律按 UTF-8 存字节而 VC6 的 MBCS 工程、CString、GDI 绘制全走本机代码页GBK。这份案例要解决的就是这条链路怎么让 VC6 认下 C98 时代的 jsoncpp怎么把 UTF-8 的中文安全落到 GBK 界面上以及反方向把 GBK 拼回合法 JSON。适合还在维护 MFC、工控上位机、要对接 HTTP 或本地配置文件的开发者尤其是那种工程不能升、只能原地修的场景。2. 选源码与搭工程让 VC6 认下 C98 时代的 jsoncppVC6 的编译器停在上世纪末auto、nullptr、右值引用一概不认。jsoncpp 现在主线早就 C11 化了随手下一份最新源码丢进 VC6迎面的是一片 C2059 和 C2143。案例包里用的那份是 0.x 系列的老分支只依赖标准 C98 的std::string、std::map、std::vector、std::ostringstream正好卡在 VC6 的能力边界内。选型理由很朴素不是老版本更好而是新版本在这个编译器上根本站不住改造成本远大于收益。2.1 先用关键字筛一遍源码别急着建工程拿到任何一份 jsoncpp 源码先别开 VC6用任意文本编辑器全局搜下面这些词。命中一个就说明这份源码进不了 VC6要么换版本要么逐个改。源码里的写法VC6 的反应处理方式auto x ...C2065 / C2143换成显式类型声明nullptrC2065 未声明的标识符换成NULL或0enum classC2059 语法错误改成普通enum加前缀std::unique_ptr/make_sharedC2039 不是成员的成员退回裸指针加deletelong longC2632 两个类型连写换成__int64连续尖括号C2059中间强制加空格 override/finalC2059直接删掉static_assertC2065换成注释或#pragma message搜完没有命中基本就能编译。还有一处容易漏老版本 jsoncpp 的目录结构是include/json/*.h加src/lib_json/*.cpp头文件里会#include json_valueiterator.inl。.inl是被头文件包含的不要把它单独加进工程去编译否则会出现重复定义或莫名其妙的模板报错。案例里已经按这个结构摆好工程只需要指一个包含目录。2.2 三种接法里加源码最稳常见接法有三种直接把三个.cpp加进工程、编译成静态库再链、编成 DLL 再导出。VC6 上我一般选第一种理由是调试时能单步进 jsoncpp 内部看它到底把哪个字符吃掉了静态库和 DLL 一旦运行期出问题就变成黑匣子了。具体动作Project → Add To Project → Files把json_reader.cpp、json_value.cpp、json_writer.cpp三个文件加进来。Project → Settings → C/C → Preprocessor → Additional include directories填..\jsoncpp\include按你实际放的层级改。别用Tools → Options → Directories那个全局设置换台机器就失效。选中这三个 cppProject → Settings → C/C → Category 选 Precompiled Headers → 选 Not using precompiled headers。这一步不做必然报 C1010。建个控制台工程先验一遍别一上来就塞进 MFC 大工程里排查// 最小验证能编译、能解析、能取到值三件事一次确认 #include string #include iostream #include json/json.h // 老版本的头文件在 json/ 子目录下 int main() { const char* text {\id\:1,\name\:\test\}; Json::Reader reader; Json::Value root; if (!reader.parse(text, root)) { // 老版本拼 Formated新一点拼 Formatted按头文件里实际的名字写 std::cout reader.getFormatedErrorMessages() std::endl; return 1; } std::cout root[name].asString() std::endl; // 输出 test std::cout root[id].asInt() std::endl; // 输出 1 return 0; }这段代码里Json::Reader负责把文本解析成一棵Json::Value树parse的返回值必须判不判就等于把错误信息丢了。asString()只有在节点确实是字符串时才安全asInt()遇到非数字会给你 0 而不是报错这两点决定了后面所有取值代码都得先isString()/isInt()判断类型否则调试版会直接断言。MFC 工程里记得把#include stdafx.h放在第一行jsoncpp 的三个 cpp 则要设成不使用预编译头两边不冲突。2.3 报错按这个顺序定位能省一半时间VC6 的报错信息质量很差一个头文件没找到能引出几十行模板错误。我习惯按下面这个顺序看先看第一条错误。VC6 的编译错误是链式的第一条往往才是真因后面的全是连坐。如果第一条是C1083: Cannot open include file就是包含目录没配对先解决这个再看别的。再看是不是C1010。这个报错原文是unexpected end of file while looking for precompiled header含义是某个 cpp 里没有#include stdafx.h却被要求用预编译头。jsoncpp 的源码显然不会有stdafx.h所以只能对这三个文件单独关掉预编译头。最后看链接错误。LNK2001: unresolved external symbol一般是漏加了某个 cppLNK2005: xxx already defined或LNK4098: defaultlib LIBCMTD conflicts with use of other libs说明工程的运行库设置和 jsoncpp 编译时的运行库不一致。VC6 里在Project → Settings → C/C → Code Generation → Use run-time library统一成Debug Multithreaded/MTD或Debug Multithreaded DLL/MDD所有参与链接的工程必须一模一样Debug 和 Release 也要各自对齐。3. 解析中文UTF-8 到 GBK 的两次跳转与 \u 转义乱码这件事九成的根因不是jsoncpp 不支持中文而是没人说清楚中间那段字节到底是什么编码。jsoncpp 解析完Value里存的是 UTF-8 字节序列VC6 的 MBCS 工程里CString、SetWindowText、TextOut期待的是 GBK。你把 UTF-8 字节直接喂给CString界面显示成涓枃之类的串这是典型的UTF-8 被当 GBK 解读。反过来把 GBK 字节塞进Value再序列化落盘的文件就不是合法 UTF-8对端解析直接失败。3.1 先确认 jsoncpp 到底交给你什么判断方法很直接调用asString()拿到std::string把每个字节按十六进制打出来。中文成功的 UTF-8 是E6 88 90 E5 8A 9F六个字节GBK 是B3 C9 B9 A6四个字节。看到六个字节说明拿到的确实是 UTF-8问题出在往下传的环节看到四个字节说明上游给你的 JSON 本身就是 GBK 的那压根不是合法 JSONJSON 规范要求 UTF-8得先跟前端或对端把编码这件事掰扯清楚。还有两个顺手要注意的点。asCString()返回的是指向Value内部缓冲区的指针Value一析构这块内存就没了把它存进CString成员变量里迟早出问题要用就立刻拷贝成std::string。另外老版本 jsoncpp 对非字符串节点调asString()会抛异常或断言取值前老老实实isString()判断一次。3.2 写两个转换函数一次写对反复用VC6 上没有std::codecvt那套东西可用就算有也不敢用标准做法是走 Win32 的MultiByteToWideChar和WideCharToMultiByte中间以 UTF-16 为桥梁。案例包里封装了两个函数逻辑是一样的先转宽字符再转目标代码页。// 编码转换封装VC6 MBCS 工程通用放在一个独立的 .h/.cpp 里 #include windows.h #include string #include vector // UTF-8 - 本机 ANSI(GBK)。转换失败返回空串调用方自己判空 std::string Utf8ToAnsi(const std::string utf8) { if (utf8.empty()) return std::string(); // 第一步UTF-8 - UTF-16。第四个参数传长度而不是 -1 // 避免字符串中间出现 \0 时被提前截断 int wlen ::MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), (int)utf8.size(), NULL, 0); if (wlen 0) return std::string(); std::vectorwchar_t wbuf(wlen, L\0); ::MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), (int)utf8.size(), wbuf[0], wlen); // 第二步UTF-16 - GBK。lpUsedDefaultChar 用来发现转不过去的字符 BOOL usedDefault FALSE; int alen ::WideCharToMultiByte(CP_ACP, 0, wbuf[0], wlen, NULL, 0, NULL, usedDefault); if (alen 0) return std::string(); std::vectorchar abuf(alen, \0); ::WideCharToMultiByte(CP_ACP, 0, wbuf[0], wlen, abuf[0], alen, NULL, usedDefault); // usedDefault 为 TRUE 表示有字符在 GBK 里没有对应项比如 emoji // 已被替换成 ?要不要告警由业务决定 return std::string(abuf[0], alen); } // GBK - UTF-8方向相反用于把界面输入拼进 JSON std::string AnsiToUtf8(const std::string ansi) { if (ansi.empty()) return std::string(); int wlen ::MultiByteToWideChar(CP_ACP, 0, ansi.c_str(), (int)ansi.size(), NULL, 0); if (wlen 0) return std::string(); std::vectorwchar_t wbuf(wlen, L\0); ::MultiByteToWideChar(CP_ACP, 0, ansi.c_str(), (int)ansi.size(), wbuf[0], wlen); int ulen ::WideCharToMultiByte(CP_UTF8, 0, wbuf[0], wlen, NULL, 0, NULL, NULL); if (ulen 0) return std::string(); std::vectorchar ubuf(ulen, \0); ::WideCharToMultiByte(CP_UTF8, 0, wbuf[0], wlen, ubuf[0], ulen, NULL, NULL); return std::string(ubuf[0], ulen); }几个参数值得单独说。CP_UTF8和CP_ACP是两个代码页常量CP_ACP在中文 Windows 上就是 936GBK别硬编码成 936换到别的语言环境就错了。第二个参数dwFlags传 0 即可传WC_NO_BEST_FIT_CHARS可以让近似匹配也走替换字符做严格校验时有用。字符串长度一律用(int)s.size()不要图省事写-1——-1会让 API 自己去找结尾的\0一旦 JSON 里有转义后的空字符就断在半路。返回空串而不是抛异常是因为 VC6 时代很多 MFC 代码没有异常安全的概念抛出去反而没人接。3.3 完整解析示例对象、数组、嵌套一次走通下面这段是案例里的主流程源文件本身是 GBK 保存的所以 JSON 文本里干脆用\u转义写中文——全 ASCII不受源文件编码影响也顺便验证了 jsoncpp 的转义解码能力。// 带中文、数组、嵌套结构的完整解析 const char* kSample {\code\:0,\msg\:\\\u6210\\u529f\, \data\:{\title\:\\\u6d4b\\u8bd5\\u4efb\\u52a1\, \tags\:[\\\u4e2d\\u6587\,\utf8\],\count\:3}}; void ParseSample() { Json::Reader reader; Json::Value root; if (!reader.parse(kSample, root)) { std::string err reader.getFormatedErrorMessages(); ::OutputDebugStringA(err.c_str()); // 解析失败一定要把位置打出来 return; } // msg 拿到的仍是 UTF-8 字节界面要 GBK转一次 std::string msgAnsi Utf8ToAnsi(root[msg].asString()); // 遍历对象老版本用 getMemberNames()返回键名列表同样 UTF-8 Json::Value::Members names root.getMemberNames(); for (size_t i 0; i names.size(); i) { std::string key Utf8ToAnsi(names[i]); // 键名也要转别只转值 const Json::Value v root[names[i]]; if (v.isObject()) { Json::Value::Members sub v.getMemberNames(); for (size_t k 0; k sub.size(); k) { const Json::Value sv v[sub[k]]; if (sv.isString()) std::string s Utf8ToAnsi(sv.asString()); else if (sv.isInt()) int n sv.asInt(); } } else if (v.isArray()) { // 数组下标类型是 Json::Value::UInt别用 int 接 for (Json::Value::UInt j 0; j v.size(); j) { if (v[j].isString()) std::string s Utf8ToAnsi(v[j].asString()); } } } }逻辑顺序是解析 → 校验 → 按键名取 → 按类型分派 → 转码落地每一步都不能省。getMemberNames()返回的Members是std::vectorstd::string的 typedefVC6 上能正常用但注意它是按std::map的键序排的不是原始 JSON 里的顺序——需要保序就得改用数组结构这是 JSON 对象的固有特性不是 jsoncpp 的锅。v.size()返回UInt用int接会在 64 位上有告警虽然 VC6 只有 32 位但养成习惯没坏处。3.4 \uXXXX 和代理对jsoncpp 已经替你做了\u6210\u529f这两组转义jsoncpp 在解析阶段就还原成了 UTF-8 字节你拿到的std::string里是E6 88 90 E5 8A 9F不需要自己再写一遍 unescape。代理对\ud83d\ude00这种也是同理jsoncpp 会合成一个四字节的 UTF-8 字符。真正需要自己动手的只有一种情况上游把 JSON 转义了两次你拿到的字符串字面量里是\\u6210\\u529f带反斜杠的六字符文本。这时候asString()返回的是\u6210这么一串 ASCII得自己在业务层再做一次解转义。判断方法很简单看返回值是不是以\u开头。案例里给了这种情况的处理分支但更该做的是推动上游把 JSON 序列化改对别在消费端兜底。4. 生成中文 JSON保证落盘是 UTF-8 的几个动作解析只是半个流程。上位机要把本地参数、报警记录写成 JSON 给别的系统读中文一旦用 GBK 字节写进去Python、Java、Go 那边一读就是乱码或者直接解析失败——UTF-8 校验严格的解析器会当场报错。这块要盯住三件事Writer 选哪个、写之前转不转、文件怎么打开。4.1 FastWriter 和 StyledWriter 怎么选两个都够用差别在格式和性能。老版本还有Json::StyledStreamWriter可以直接往流里写工程里用得少。Writer输出形态适用场景注意点FastWriter单行紧凑无缩进网络报文、日志、写配置文件末尾自带一个\n部分对端会因此解析失败StyledWriter带缩进换行可读人工查看的配置文件、调试输出体积大字符串里的换行不会影响结构StyledStreamWriter直接写std::ostream大结构体避免中间字符串出错时不返回错误码只能靠流状态判断FastWriter::write()返回值末尾那个换行是个实打实的坑我在接口联调时被它坑过一次对端用的是严格的 JSON 解析器多一个\n就报trailing characters。稳妥做法是拿到结果先裁一次尾巴。4.2 写之前转 UTF-8落盘用二进制// 把 Value 写成 UTF-8 文件 bool SaveJsonAsUtf8(const std::string path, const Json::Value root) { Json::FastWriter writer; std::string out writer.write(root); // 末尾自带 \n if (!out.empty() out[out.size() - 1] \n) out.erase(out.size() - 1); // 裁掉避免对端报尾随字符 // 必须二进制打开文本模式会把 \n 翻成 \r\n // 更坑的是读到 0x1A 会被当成 EOF 提前结束 std::ofstream ofs(path.c_str(), std::ios::out | std::ios::binary | std::ios::trunc); if (!ofs.is_open()) return false; // 给 Windows 记事本看可以加 BOM给 jsoncpp 或跨平台程序读就别加 // const char kBom[3] { (char)0xEF, (char)0xBB, (char)0xBF }; // ofs.write(kBom, 3); ofs.write(out.c_str(), (std::streamsize)out.size()); ofs.close(); return true; }std::ios::binary这个标志在 VC6 上比在新编译器上重要得多。文本模式下 CRT 会做两件事写的时候把\n转成\r\n读的时候把\r\n转回\n同时把0x1A当文件结束符。JSON 里如果有中文UTF-8 字节流中出现0x1A的概率不低比如某些生僻字的某个字节读文件时直接截断排查起来极其费劲。案例里读写一律二进制就是为了绕开这一层。ofs.write的长度参数用out.size()而不是strlen(out.c_str())因为std::string里理论上可以存空字符虽然 JSON 序列化结果里不会有但统一按长度写更安全。4.3 键名、数组、类型三件事别写错Json::Value root; // 数值就写数值别写成字符串对端做类型判断会挂 root[code] 0; root[count] 3; // 值必须先转 UTF-8 再赋值直接塞 GBK 字面量等于埋雷 root[msg] AnsiToUtf8(成功); root[title] AnsiToUtf8(测试任务); // 数组用 arrayValue 显式声明append 会自动扩容 Json::Value tags(Json::arrayValue); tags.append(AnsiToUtf8(中文)); tags.append(utf8); // 纯 ASCII 不用转 root[tags] tags; // 嵌套对象直接赋值即可 Json::Value data; data[items] tags; root[data] data;root[code] 0和root[code] 0序列化出来是0和0看起来只差一对引号但对端asInt()取到的是 0 和 0type()取到的是intValue和stringValue一旦对端做了严格类型校验就直接拒收。键名如果是中文同样要AnsiToUtf8包一层很多人只转值忘了转键结果 JSON 结构本身不是合法 UTF-8怎么查都查不出问题出在键上。5. 避坑与排查VC6 上五个真实翻车现场下面这几条都是我在实际工程里撞过的按现象 → 原因 → 解决记遇到时对号入座比重头分析快得多。5.1 报 C1010unexpected end of file while looking for precompiled header现象jsoncpp 的三个 cpp 一加进 MFC 工程就编译不过报 C1010但文件明明完整。原因工程开了预编译头stdafx.h编译器要求每个 cpp 开头都有#include stdafx.hjsoncpp 的源码当然没有。解决在Project → Settings里选中这三个文件注意是选中文件不是选中整个工程C/C 页 → Category 选Precompiled Headers→ 选Not using precompiled headers。逐个文件设别图省事设成整个工程。5.2 LNK4098LIBCMTD 和其他库冲突现象编译全过链接期报defaultlib LIBCMTD conflicts with use of other libs或者 LNK2005 一堆already defined。原因工程用的是/MDD多线程调试 DLL 版运行库而之前编好的 jsoncpp 静态库用的是/MTD两套 CRT 混在一起同一个符号有两份实现。解决把所有参与链接的工程、所有配置Debug/Release、Win32的运行库设置拉到一致。纯静态工程统一/MTD带 MFC 动态库的统一/MDD。改完记得 Rebuild All只 Build 会留下旧的 obj。5.3 解析永远失败错误信息却说不出所以然现象reader.parse()返回 falsegetFormatedErrorMessages()给的是* Line 1, Column 1 Syntax error: value, object or array expected。原因三种可能概率从高到低——文件开头有 UTF-8 BOMEF BB BF读文件时用了文本模式0x1A截断或\r\n转换把内容弄坏了字符串末尾有多余的\0或垃圾字节。解决先十六进制看一眼文件头三字节是EF BB BF就在读取时跳过前三个字节再交给reader.parse()。读取统一用std::ios::binary。可以先用reader.parse(str, root, false)关掉注释收集排除注释解析的干扰。5.4 中文变问号或者出现双重乱码现象界面上显示??或者显示成涓枃、测试这种一看就不对的串。原因??是转换时目标编码里没有对应字符被替换成了问号通常是 emoji 或生僻字往 GBK 转涓枃是 UTF-8 字节被当 GBK 解读测试是 UTF-8 字节被当 Latin-1 解读。还有一种是自己坑自己把已经是 GBK 的串又Utf8ToAnsi了一次。解决在转换函数入口打日志把输入输出的字节数以十六进制打出来跟 3.1 里的对照表比一比立刻能定位方向错了还是转重了。检查WideCharToMultiByte的lpUsedDefaultChar出参为 TRUE 就说明有字符丢了这种字符要么过滤、要么改用 UTF-8 存储。5.5 Release 正常、Debug 崩或者偶发崩溃现象同一份数据Debug 版跑着跑着在asString()处断言Release 版看起来正常但结果偶尔不对。原因asCString()返回的指针指向Value内部缓冲区Value一析构就悬空跨函数传递这个指针在 Release 下不一定立刻崩但数据已经错了。另一种是没判类型就调asString()Debug 版断言、Release 版返回空串。解决asCString()只在同一个函数体内临时用出了作用域一律转成std::string或CString拷贝。所有取值前加isString()/isInt()/isObject()判断宁可多写一行判断也别赌类型对。6. 上线前拿一份最脏样本跑一遍回归功能写完不算完我习惯留一份自己造的脏样本做回归每次改编码相关的代码都拿它跑一次。样本里塞这些东西中文键名和中文值、一个四字节 emoji\ud83d\ude00、一个超过 65535 的长字符串、一个空对象{}、一个空数组[]、一个大整数超过int范围的用asDouble()接、一段带引号和反斜杠需要转义的文本。这份样本能把九成的编码和边界问题提前逼出来。验证输出是不是真 UTF-8别靠自己眼睛看。最简单的办法是用另一门语言读一遍# 交叉验证文件能被严格按 UTF-8 解开且中文能正确显示 import json with open(rD:\out\config.json, rb) as f: raw f.read() assert not raw.startswith(b\xef\xbb\xbf), 带 BOM很多解析器会拒收 obj json.loads(raw.decode(utf-8)) # 解码失败会直接抛异常 print(obj[msg], obj[data][title]) # 中文能原样打出来才算过json.loads对非法 UTF-8 是零容忍的能过这一关说明落盘字节干净。再加一条把这份文件重新喂给 VC6 那端的解析代码跑一遍写出去 → 读回来 → 值相等的往返比对中文、转义、数组顺序都要对上。往返不一致的地方八成是某一侧多转或少转了一次码。血泪经验是编码问题从来不会在写代码的当天暴露都是交付之后对端说你给的中文是乱码。从那以后我每次动到 JSON 读写不管改的是一行还是一段都强制走一遍这份脏样本加交叉验证不再靠上次是好的这种玄学判断。案例包里那份已经调通的工程和转换封装省的就是这段反复试错的时间拿去对着自己的接口改字段名就能用。希望帮到你。本文还有配套的精品资源点击获取
