简介：这份资源面向仍在维护 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 认下 C++98 时代的 jsoncpp，怎么把 UTF-8 的中文安全落到 GBK 界面上，以及反方向把 GBK 拼回合法 JSON。适合还在维护 MFC、工控上位机、要对接 HTTP 或本地配置文件的开发者，尤其是那种"工程不能升、只能原地修"的场景。

2. 选源码与搭工程：让 VC6 认下 C++98 时代的 jsoncpp

VC6 的编译器停在上世纪末，auto、nullptr、右值引用一概不认。jsoncpp 现在主线早就 C++11 化了，随手下一份最新源码丢进 VC6，迎面的是一片 C2059 和 C2143。案例包里用的那份是 0.x 系列的老分支，只依赖标准 C++98 的std::string、std::map、std::vector、std::ostringstream，正好卡在 VC6 的能力边界内。选型理由很朴素：不是老版本更好，而是新版本在这个编译器上根本站不住，改造成本远大于收益。

2.1 先用关键字筛一遍源码，别急着建工程

拿到任何一份 jsoncpp 源码，先别开 VC6，用任意文本编辑器全局搜下面这些词。命中一个就说明这份源码进不了 VC6，要么换版本，要么逐个改。

搜完没有命中，基本就能编译。还有一处容易漏：老版本 jsoncpp 的目录结构是include/json/*.h加src/lib_json/*.cpp，头文件里会#include "json_valueiterator.inl"。.inl是被头文件包含的，不要把它单独加进工程去编译，否则会出现重复定义或莫名其妙的模板报错。案例里已经按这个结构摆好，工程只需要指一个包含目录。

2.2 三种接法里，加源码最稳

常见接法有三种：直接把三个.cpp加进工程、编译成静态库再链、编成 DLL 再导出。VC6 上我一般选第一种，理由是调试时能单步进 jsoncpp 内部，看它到底把哪个字符吃掉了；静态库和 DLL 一旦运行期出问题，就变成黑匣子了。

具体动作：

1. Project → Add To Project → Files，把json_reader.cpp、json_value.cpp、json_writer.cpp三个文件加进来。
2. Project → Settings → C/C++ → Preprocessor → Additional include directories，填..\jsoncpp\include（按你实际放的层级改）。别用Tools → Options → Directories那个全局设置，换台机器就失效。
3. 选中这三个 cpp，Project → 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一般是漏加了某个 cpp；LNK2005: 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 的，那压根不是合法 JSON（JSON 规范要求 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::vector<wchar_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::vector<char> 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::vector<wchar_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::vector<char> 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 上就是 936（GBK），别硬编码成 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::vector<std::string>的 typedef，VC6 上能正常用，但注意它是按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，可以直接往流里写，工程里用得少。

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 和 0，type()取到的是intValue和stringValue，一旦对端做了严格类型校验就直接拒收。键名如果是中文，同样要AnsiToUtf8包一层，很多人只转值忘了转键，结果 JSON 结构本身不是合法 UTF-8，怎么查都查不出问题出在键上。

5. 避坑与排查：VC6 上五个真实翻车现场

下面这几条都是我在实际工程里撞过的，按"现象 → 原因 → 解决"记，遇到时对号入座比重头分析快得多。

5.1 报 C1010：unexpected end of file while looking for precompiled header

现象：jsoncpp 的三个 cpp 一加进 MFC 工程就编译不过，报 C1010，但文件明明完整。

原因：工程开了预编译头（stdafx.h），编译器要求每个 cpp 开头都有#include "stdafx.h"，jsoncpp 的源码当然没有。

解决：在Project → Settings里选中这三个文件（注意是选中文件，不是选中整个工程），C/C++ 页 → Category 选Precompiled Headers→ 选Not using precompiled headers。逐个文件设，别图省事设成整个工程。

5.2 LNK4098：LIBCMTD 和其他库冲突

现象：编译全过，链接期报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()返回 false，getFormatedErrorMessages()给的是* Line 1, Column 1 Syntax error: value, object or array expected。

原因：三种可能，概率从高到低——文件开头有 UTF-8 BOM（EF 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(r"D:\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 读写，不管改的是一行还是一段，都强制走一遍这份脏样本加交叉验证，不再靠"上次是好的"这种玄学判断。案例包里那份已经调通的工程和转换封装，省的就是这段反复试错的时间，拿去对着自己的接口改字段名就能用。希望帮到你。

本文还有配套的精品资源，点击获取