简介：面向Visual C++ 6.0开发者的JSONCPP调用完整案例，解决在老旧IDE中解析与生成JSON数据时的中文乱码问题。资源基于jsoncpp-src-0.5.0源码，无需额外编译库文件，直接集成到Win32控制台或对话框工程即可使用，适合需要在VC6.0中处理JSON格式的C++程序员。包内共72个文件，以h头文件、cpp源文件、inl内联模板文件为主，另有obj/sbr中间文件、使用说明doc和可直接运行的exe，整体约3.77MB，目录结构清晰，便于对照学习。作者额外提供《重要》使用说明文档，对源码集成、编码设置、测试步骤和常见陷阱做了详细梳理，配合调用.h/cpp、json_reader/value/writer等核心源码，能帮助读者快速搭建可解析中文的JSON功能模块。已有587人学习，是一份针对VC6.0+JSONCPP中文场景的高完成度参考案例。 掐指一算，我摸VC6.0已经有二十年了。最近接了一个老项目改造，上位机是MFC对话框程序，跑在工控机的Windows XP上，客户要求新增一个数据上报功能，后端接口返回的格式是JSON。我第一反应是引入JSONCPP，结果去拉最新版，编译错误刷满了一屏——这才意识到VC6.0调用JSONCPP远没有想象中那么简单，尤其是还要支持中文解析、防乱码，坑一个接一个。折腾完整个流程之后，我决定把它整理成一篇完整的案例笔记，版本和配置都验证过，直接照着做就能跑通。如果你也在维护VC6.0时代的老代码，或者准备给老项目加一个JSON解析模块，这篇东西能帮你少走至少两天的弯路。
1. 老项目为什么要动JSON——VC6场景与选型思路
1.1 还在用VC6的是什么场景
很多人会问，都什么年代了还在用VC6.0？我接触到的实际情况是，这类项目主要集中在几个领域：工控上位机、老MFC管理系统、医疗设备客户端、银行业务终端。这些系统的共同点是运行稳定、业务逻辑复杂、客户不愿意花成本迁移，但又不断有新需求冒出来。新需求十有八九要上网关、上接口，而后端现在的主流数据格式就是JSON，跑不掉。
另一个现实是，这类项目的开发环境往往定死了。客户维护文档里写的就是VC6.0，产线机器上装的就是VC6.0，换VS2015意味着MFC Runtime都要重新部署一遍，风险太大。所以讨论换不换编译器没有意义，核心问题是：在VC6.0这个老古董里面，怎么把JSON这套东西跑起来。
1.2 VC6下能用的JSON库其实没几个
我当时做了个选型对比，列出来给团队看：
| 方案 | 能否在VC6编译 | 工作量 | 结论 |
|---|---|---|---|
| jsoncpp 最新版 | 否，需要C++11 | 无法编译 | 排除 |
| jsoncpp 老版本 | 能 | 小 | 选用 |
| rapidjson | 需要一点改造 | 中 | 备用 |
| 自己写解析器 | 能 | 巨大 | 排除 |
rapidjson是header-only的，按道理也能用，但它是template库，在VC6下实例化时容易出现诡异编译问题，而且rapidjson对Unicode的处理需要外部配合，老项目里折腾起来不划算。自己写一个JSON解析器看着简单，真正处理嵌套、转义、异常输入时会发现坑深得很，不在考虑范围内。
jsoncpp老版本当时是唯一省心省力的选择：源码稳定，API设计贴近STL习惯，解析和序列化都够用。确定方向之后，真正的挑战来了——选哪个版本。
2. 版本选择是最大的坑——只有老版本jsoncpp能过VC6编译
2.1 新版jsoncpp为什么编不过
jsoncpp从1.x开始全面转向C++11，源码里大量使用auto、nullptr、std::unique_ptr、lambda表达式这类现代特性。VC6对C++标准的支持停留在1998年之前，auto还是老式的存储类说明符，nullptr压根不存在，模板部分特化也支持得残缺不全，编译直接糊了一脸错误。我试过把新版本硬塞进VC6工程，报错排了三百多行，最后放弃了。
这里要说明一点，别指望通过打补丁的方式把新版用起来。jsoncpp内部的Value实现依赖RVO、移动语义优化，强行修改源码等于给自己埋雷，改完之后的正确性没人能保证。
2.2 推荐版本与源码获取方式
经验直接给结论：用jsoncpp 0.5.0版本。这个版本发布于2010年前后，设计时还兼顾老编译器，代码风格保守，没用到VC6不支持的特性。0.6.0我也试过，整体能用，但某些模板细节在VC6下要多调几处，纯属给自己找事。
获取方式很简单，在GitHub仓库的Tags列表里找到0.5.0这个tag，下载Source code的zip包即可。解压之后把整个目录放到项目ThirdParty文件夹里，后面配置用得到。
2.3 源码目录结构认一遍
0.5.0的目录结构比新版本清爽得多：
jsoncpp-0.5.0/ ├── include/ │ └── json/ │ ├── config.h │ ├── features.h │ ├── forwards.h │ ├── reader.h │ ├── value.h │ └── writer.h └── src/ └── lib_json/ ├── json_reader.cpp ├── json_value.cpp ├── json_writer.cpp └── json_tool.h我们要的就是include/json目录和src/lib_json下的三个cpp文件。老版本没有后来那堆cmake脚本和测试代码，干净得很。新版才有json_batchallocator之类的历史遗留文件，0.5.0已经移除了，不用管。
3. 工程配置与编译：直接把源码拖进来最省心
3.1 为什么我不用编译好的lib
有人图省事，想在网上下一个编译好的jsoncpp.lib直接链接。我的建议是别这么干。VC6时代编译器的ABI和现在有很大差异，你根本不知道网上的lib是用什么编译器、什么运行库选项编出来的。Debug版和Release版混用会引发内存崩溃，跨编译器版本混用更是灾难。
正确而且稳妥的做法是：把三个cpp源文件直接加入当前VC6工程。这样代码同源编译，运行库完全一致，不存在ABI不匹配的问题。代价只是编译时间多个几秒钟，微不足道。
3.2 VC6工程配置三步走
第一步是拷贝文件。把jsoncpp-0.5.0/include/json整个目录拷到工程目录下的ThirdParty/jsoncpp/include/，把src/lib_json下的三个cpp文件拷到ThirdParty/jsoncpp/src/。
第二步是添加源文件。在VC6的Workspace窗口里，右键工程名，选择Add Files to Project，选中json_reader.cpp、json_value.cpp、json_writer.cpp，确认加进去。
第三步是配置头文件路径。菜单Project -> Settings -> C/C++ -> Preprocessor，在Additional include directories里填相对路径：
./ThirdParty/jsoncpp/include这里必须用相对路径，否则换一台机器工程就崩了。
3.3 四个常遇到的编译错误和处理
我实际编译时遇到过几个问题，逐个说。
第一个是预编译头冲突。VC6默认的MFC工程用stdafx.h作为预编译头，jsoncpp的cpp文件不包含stdafx.h，会报错。解决办法是对这三个cpp文件单独设置：Project Settings里选中jsoncpp的.cpp文件，C/C++ -> Precompiled Headers，改成Not using precompiled headers。
第二个是snprintf未定义。VC6的CRT没有snprintf，只有_snprintf。解决办法是在jsoncpp使用前加一个宏：
#ifdef _MSC_VER #define snprintf _snprintf #endif放在stdafx.h里或者json头文件包含前都行。0.5.0源码里用到snprintf的地方不多，但这个宏加上绝对没坏处。
第三个是warning C4018和C4267，有符号无符号不匹配。这些是VC6多年的老毛病，不影响运行。在Project Settings -> C/C++ -> Preprocessor -> 忽略warning编号里填上4018,4267,4244，眼不见为净。
第四个是Debug模式编译特别慢。VC6的STL在Debug下会塞一大堆检测代码，jsoncpp的Value里大量用std::string，首次编译确实慢。耐心等一次，后面增量编译就快了。
4. 中文乱码的根源：UTF-8与ANSI的两张皮
4.1 乱码究竟出现在哪个环节
中文乱码问题是VC6项目接JSON时最容易被忽视的地方。JSON标准规定文本传输必须用UTF-8，而VC6时代的Windows程序，只要不做额外处理，字符串就是ANSI编码，简体中文环境就是GBK。这两套编码体系不一致，处理不好必然乱码。
乱码出现在两个方向：一个是解析方向，接口返回或文件读取到的JSON是UTF-8，jsoncpp解析成std::string后里面存的是UTF-8字节序列，直接扔给MFC的CString或MessageBox显示，出来就是乱码；另一个是生成方向，界面输入的GBK中文字符串直接赋给Json::Value，再由jsoncpp写出去，生成的文件其他程序读出来还是乱码。
搞清楚这个链条后，方案就很清楚了：解析出来的UTF-8必须转成GBK再显示，写进去的GBK必须转成UTF-8再赋值。
4.2 两段式编码转换函数
Windows API里有个经典的两段式方案：先转成宽字符，再由宽字符转成目标编码。我用的是MultiByteToWideChar和WideCharToMultiByte这对函数，VC6的windows.h里就有，不需要额外依赖。
std::string Utf8ToAnsi(const std::string& utf8) { if (utf8.empty()) return ""; int wLen = MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, NULL, 0); if (wLen <= 0) return ""; wchar_t* wBuf = new wchar_t[wLen]; MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, wBuf, wLen); int aLen = WideCharToMultiByte(CP_ACP, 0, wBuf, -1, NULL, 0, NULL, NULL); char* aBuf = new char[aLen]; WideCharToMultiByte(CP_ACP, 0, wBuf, -1, aBuf, aLen, NULL, NULL); std::string result(aBuf); delete[] wBuf; delete[] aBuf; return result; }AnsiToUtf8就是把CP_UTF8和CP_ACP对调。这个转换过程要注意一点：UTF-8里有些字符（比如Emoji）在GBK中没有对应编码，转出来会变成问号。处理工控项目的数据基本够用，但如果要处理怪字符，得先跟业务方确认字符集范围。另外，这里的-1参数表示处理到字符串结尾的'\0'，如果字符串内嵌了'\0'会被截断，JSON数据里一般不会出现这种情况，可以放心用。
4.3 什么情况下不用转换
如果程序所有环节都保持UTF-8，不需要转换。比如纯C++控制台程序，逻辑层和存储层统一用UTF-8，只在显示给用户前转换。这种情况下jsoncpp的std::string从头到尾就是UTF-8，解析、遍历、比较都没有乱码问题。
但如果程序用了MFC的CString、CEdit、ListCtrl这类控件，或者要往Windows注册表读写中文，转换就躲不掉。我的建议是定义一个公共编码工具类，把这俩函数放进去，全项目统一调用，别今儿一个地方转明儿一个地方不转，不然查乱码查到怀疑人生。
5. 全套案例：读取、解析、修改、写回一个都不能少
5.1 从UTF-8文件读入并解析
下面给一个完整的案例流程，包含读文件、解析、取字段、遍历数组、嵌套对象、修改新增、写回，每一步都验证过。先是读取UTF-8文件：
#include <stdio.h> #include <string> #include <windows.h> #include "json/json.h" std::string ReadTextFileAsUtf8(const char* path) { FILE* fp = fopen(path, "rb"); if (fp == NULL) return ""; fseek(fp, 0, SEEK_END); long len = ftell(fp); fseek(fp, 0, SEEK_SET); std::string text; text.resize(len); if (len > 0) fread(&text[0], 1, len, fp); fclose(fp); if (len >= 3 && (unsigned char)text[0] == 0xEF && (unsigned char)text[1] == 0xBB && (unsigned char)text[2] == 0xBF) { text = text.substr(3); } return text; }注意这里用"rb"二进制模式打开文件，绝不能用"r"文本模式。VC6的文本模式会在读文件时自动把\r\n转成\n，导致JSON解析器拿到的内容和文件字节不一致，轻则解析失败，重则数据内容被改。BOM的处理也很关键：Windows记事本生成的UTF-8文件会带三个字节的BOM（EF BB BF），jsoncpp不认识BOM，不跳过直接解析会报错。
5.2 取普通字段
接下来是解析和取值：
int main() { std::string jsonText = ReadTextFileAsUtf8("config.json"); if (jsonText.empty()) { printf("读取文件失败或文件为空\n"); return -1; } Json::Reader reader; Json::Value root; if (!reader.parse(jsonText, root)) { printf("JSON解析失败: %s\n", reader.getFormattedErrorMessages().c_str()); return -1; } if (root.isMember("name")) { std::string nameUtf8 = root["name"].asString(); std::string nameAnsi = Utf8ToAnsi(nameUtf8); printf("姓名: %s\n", nameAnsi.c_str()); } int age = root.get("age", 0).asInt(); printf("年龄: %d\n", age); ... }取字段这里有个经验：能用isMember判断就先判断，能用get带默认值就带默认值。jsoncpp的operator[]在键不存在时会向Value里插入一个空节点，如果后续逻辑走到parent节点再序列化，原JSON对象会被"污染"，多出一些原本不存在的null字段。这在调试时很难发现，等数据回传后端才在日志里看出来。
5.3 数组与嵌套对象
数组遍历用下标最稳，VC6的STL迭代器在这里会有const_iterator相关的兼容问题：
if (root.isMember("hobbies") && root["hobbies"].isArray()) { for (unsigned int i = 0; i < root["hobbies"].size(); i++) { std::string hobby = Utf8ToAnsi( root["hobbies"][i].asString()); printf("爱好[%u]: %s\n", i, hobby.c_str()); } } std::string city = Utf8ToAnsi( root["address"]["city"].asString()); printf("城市: %s\n", city.c_str());嵌套对象直接用链式下标访问，jsoncpp在这方面设计得很顺手。但要注意，访问嵌套对象前最好先确认父节点存在，直接root["address"]["city"]，如果"address"本身不存在，会自动创建出两级空节点，逻辑上没问题，但同样会污染原JSON。生产环境里我习惯先isMember判断再取。
5.4 修改并写回文件
修改和新增节点也非常直接：
root["name"] = AnsiToUtf8("李四"); root["age"] = 20; root["remark"] = "通过VC6.0+JSONCPP写入"; Json::StyledWriter writer; std::string output = writer.write(root); WriteTextFileFromUtf8("output.json", output, true); printf("完成，输出文件: output.json\n"); return 0; }写入函数我单独封了一个：
void WriteTextFileFromUtf8(const char* path, const std::string& utf8Text, bool withBom) { FILE* fp = fopen(path, "wb"); if (fp == NULL) return; if (withBom) { fputc(0xEF, fp); fputc(0xBB, fp); fputc(0xBF, fp); } fwrite(utf8Text.c_str(), 1, utf8Text.size(), fp); fclose(fp); }这里withBom参数是个经验选项。如果生成的文件要拿给Windows记事本看，建议带BOM，记事本能自动识别；如果是要提交给后端服务器或其他程序自动解析，建议不带BOM，部分严格解析器遇到BOM会报错。具体用哪种，问一下数据接收方的习惯就行。
6. 我踩过的几个坑与收尾提醒
6.1 二进制与文本模式的坑
我第一次写读文件函数时用了"r"模式，结果JSON字符串里的\n全被转成了\r\n，文件里是1个字符，读出来变成2个字符，jsoncpp解析时在报告"line breaks"的错误。定位了很久才意识到是文件模式的问题。所以统一原则：处理文本文件，只要涉及JSON解析，一律用二进制模式，自己做编码和换行处理，别让CRT库替你做决定。
6.2 空节点和默认值
有一回排查线上问题，发现上报的数据里多了很多"null"字段。查了半天，是代码里用operator[]读取某个配置项时键名写错了，jsoncpp自动在Value里插入了空节点，后续把这个Value整体序列化，多余的null就跟着出去了。从那之后我定了规矩：读操作全部用isMember配合get，写操作才用operator[]。
6.3 StyledWriter与FastWriter的取舍
jsoncpp 0.5.0的两个Writer各有用途。StyledWriter输出带缩进和换行，调试的时候一目了然；FastWriter把整个JSON压成一行，体积小、传输快，适合对接Web接口。我现在的习惯是：debug配置用StyledWriter，release配置用FastWriter，封装成宏或者参数开关，省得来回改代码。
6.4 给还在战斗的VC6同行
调试VC6项目还有两个额外经验：VC6的Watch窗口直接看std::string是乱的，需要在Watch里输入(string变量名).c_str()才能真正看到字符串内容；VC6偶尔会出现改了源码不重新编译的情况，Rebuild All能解决大多数灵异现象。
最后提一句源码文件编码问题。VC6的编辑器保存.c/.cpp文件时是ANSI编码，如果文件里有中文注释，千万别用其他编辑器把文件整体存成UTF-8，否则VC6打开时注释会变成乱码，严重时连字符串字面量都跟着错位。我见过不止一个项目因为混用了文件编码，编译时冒出一堆warning，程序里中文界面全乱。保持源码文件ANSI编码，把UTF-8和GBK的转换集中在编码工具类里，这是VC6时代最省心的中文处理方式。
这套VC6.0调用JSONCPP的流程，从版本选型到工程配置，从编码转换到完整读写，我都实测跑通了。老项目维护本身就是戴着镣铐跳舞，把最常用的这几个模块沉淀成固定方案，以后再有新接口对接，直接拷贝这套代码作为起点，省下来的时间足够多陪陪家人。
本文还有配套的精品资源，点击获取
