简介VC 6.0 环境下可用的 jsoncpp 类库项目源代码专为解决 jsoncpp 官方包不含 VC6 工程文件、集成困难而整理。作者补全 .dsw/.dsp 等工程配置在 VC 6.0 中编译通过并实际投入使用适合需要在老旧 VC6 环境解析 JSON 的 C 开发者参考。资源包共 57 个文件约 2.76MB以 20 个 .h 头文件、6 个 .cpp 实现文件、6 个 .inl 内联模板为主体附带 .dsw/.dsp 工程文件、编译生成的 .obj/.sbr 中间文件以及 .opt/.ncb/.plg 等辅助配置打开工程即可对照编译。目前已有 376 人学习浏览。通过该资源可免去自行移植 jsoncpp 的繁琐步骤直接获得可在 VC6 编译并运行的类库源代码保留了解析、写入等核心能力方便后续维护与扩展。1. 为什么还要在VC6上编译jsoncpp老代码维护者的现实痛点如果你的工具链还停留在vc6偏偏又要让项目接收一串JSON格式的配置或接口数据那么vc6 jsoncpp 编译这个组合几乎是所有C老兵都会撞上的问题。jsoncpp是成熟稳定的C JSON解析库但它在现代编译器上编译很顺放到VC6.0这个1998年的编译器上就完全是另一回事模板语法、STL头文件、异常和处理宽字符的方式处处受限制。很多人在编译第一步就翻车随后被一个个报错劝退。这篇文章讲的就是一套在VC6.0中能真正编译通过并正常工作的jsoncpp类库源代码以及把它集成进老工程时我踩过的、看得见的和看不见的坑。适合那些维护着十几年老系统、没法换编译器也没法换业务的开发者它解决的是老瓶子装新酒时最尴尬的一公里。2. JSON解析的理论选型与jsoncpp源码结构2.1 从JSON解析说到jsoncpp的类设计JSONJavaScript Object Notation本质是一棵由对象、数组、字符串、数字、布尔和空值组成的树。任何JSON解析库的工作只有两件事把这段文本反序列化成一棵内存树以及把这棵树按照指定格式序列化回文本。jsoncpp的特点是它把这棵树做成了一个叫Json::Value的变体类。Json::Value可以自动表示int、double、string、bool、null、array和object底层用C的std::map和std::vector存放子节点。使用时你不需要关心节点的具体类型赋值和读取都会自动转换这给维护老代码带来了极大的便利。jsoncpp的作者设计了一套简单清晰的API。核心是这两个类型Json::Reader解析文本字符串填充Json::Value对象。在老版本中它的parse()方法接收const std::string或者std::istream。Json::Writer把Json::Value对象序列化成字符串。老版本中常用Json::StyledWriter带缩进的人类可读格式和Json::FastWriter紧凑格式。我曾经接手过一个模拟项目X里面所有配置都是这种{host:127.0.0.1,ports:[8080,8443]}形式的文本文件。用jsoncpp解析后直接通过Value[host].asString()取值替代了过去一长串字符串切割和strstr查找的代码维护成本立刻降了下来。下面是一个用jsoncpp读取内容的典型用法现代版本依然兼容#include json/json.h #include string std::string raw {\name\:\Tester\,\count\:42}; Json::Value root; Json::Reader reader; bool ok reader.parse(raw, root); if (ok) { std::string name root[name].asString(); int count root[count].asInt(); }这段代码的逻辑很简单先用Json::Reader把字符串raw解析到root中解析成功后再从root里取出键值。这里要注意reader.parse()的第一个参数是const std::string如果你从文件读出来的是char*要先用std::string包一层。第二个参数是输出用的Json::Value对象引用传递解析失败时root会被清空而不是保留旧值。old版本里parse()还接受std::istream所以也可以直接喂给std::ifstream。asString()和asInt()是带类型转换的如果节点不是对应类型它们会返回默认值而不是抛异常这一点是好事也是坏事——好事是不会崩坏事是你可能默默拿到一个空串或0。2.2 与cJSON和RapidJSON对比在老编译器下为什么选它在VC6这个环境下能交互的JSON库其实不多。cJSON是纯C写的只有两个文件cJSON.c和cJSON.h编译毫无压力但它是基于函数指针和结构体的C风格API每个节点要手动cJSON_Delete()释放嵌套和修改节点时容易漏掉内存。RapidJSON则号称高性能但它大量使用C11的移动语义、可变参数模板和constexpr在VC6下根本编译不过除非你把代码改写一遍又一遍这比重新实现一个JSON解析器还累。jsoncpp的优势在于它只用了C98规范里的基本特性类设计抽象程度高读写都直接映射到STL容器上。虽然它的性能稍有折扣毕竟每次访问节点都可能触发std::map查找但在老业务系统里配置文件的解析频率通常以秒级计这点开销完全可以忽略。回头看jsoncpp是在VC6里能编译、能工作、可维护三者之间平衡得最好的一个。从工程角度看这个类库源码资源通常包含以下几部分这是老版本中常见的标准布局目录/文件作用include/json/公共头文件如json.h、value.h、reader.h、writer.h、forwards.hsrc/lib_json/实现文件json_value.cpp、json_reader.cpp、json_writer.cpp等src/lib_json/CMakeLists.txt现代构建用VC6环境可忽略额外的.dsp/.dsw有的资源包会附带VC6的工程文件打开即用如果你的资源包不带工程文件也不要紧后面我会给出手工创建VC6工程和直接用命令行编译的两种方式。关键在于理解这些源文件的依赖关系json_reader.cpp依赖json_value.cpp中Value内部结构的实现json_writer.cpp也依赖Value它们三个必须一起编译进同一个lib或dll不能只挑其中一个加入工程。3. 在VC6.0中配置jsoncpp从源码到静态库的完整步骤3.1 检查文件结构与预处理器定义拿到一份声称VC6编译通过的jsoncpp源码第一件事不是双击打开工程而是先检查头文件里的条件编译。老版本jsoncpp的头文件里有大量类似这样的片段#if defined(_MSC_VER) _MSC_VER 1500 // 针对 VS2005 及更老编译器的补丁 #endif在VC6中_MSC_VER的值是1200因此你需要确认这些条件分支没有进入错误的方向。另一个关键宏是JSONCPP_DLL。如果你打算做成静态库lib那么不要定义JSONCPP_DLL否则类声明前会加上__declspec(dllexport)或__declspec(dllimport)导致符号导出异常。如果打算做动态库则必须定义并且json_value.h里的类声明会套上条件导出宏JSON_API。我一般会先打开json/config.h查看里面关于JSONCPP_DLL、JSON_NOEXCEPT、JSON_USE_OLD_RVREF这些宏的默认值。在VC6下最安全的做法是把不支持的C11特性宏全部关掉例如#define JSON_NOEXCEPT #define JSON_HAS_RVALUE_REFERENCES 0注意这要放在json/config.h的最前面且在所有源文件包含头文件之前生效。如果资源包已经配置好这一步可以跳过但如果遇到编译报错说noexcept、std::move找不到基本就是这个没关干净。3.2 创建VC6静态库工程从菜单到编译选项下面是以VC6.0 IDE创建静态库工程的步骤新手可以照抄打开VC6选择 File - New - Projects - Win32 Static Library。为工程取名假设叫jsoncpp_so点击 OK 完成向导。在工程的左侧目录树里右键点击Source Files选择 Add Files To Folder把资源包里的json_value.cpp、json_reader.cpp、json_writer.cpp全部加入。右键点击Header Files加入资源包里的json/json.h所在的头文件路径或者直接把include目录加入头部搜索路径。确认工程设置Project - Settings - C/C 选项卡。在Category下拉框里选择Preprocessor把JSON_NOEXCEPT加入 Preprocessor definitions。在同一选项卡的 Code Generation 分类里把 Use run-time library 设置为Multithreaded也就是libcmt.lib而不是带DLL后缀的版本。这一步直接决定后续主程序链接时有没有符号冲突。把 Exception handling 设为 Yes因为 jsoncpp 源码内部用了try/catch。注意这里不要开预编译头。jsoncpp 源文件里没有#include stdafx.h如果工程默认开启了预编译头每个cpp文件都会报stdafx.h not found。解决办法是在 C/C 选项卡的 Precompiled Headers 里选择 Not using precompiled headers。完成这些设置后Build - Build jsoncpp_so.dllVC6会生成一个jsoncpp_so.lib文件。如果你在这一步遇到了编译错误不用急着改源码先去检查是不是预编译器宏或头文件路径的问题绝大多数失败都出在这两个环节。3.3 命令行编译不依赖IDE的裸编译方式有些机器上的VC6环境已经退化到只装了命令行工具IDE打不开这时可以用cl.exe直接编译。首先要配置环境变量在命令行里执行VC6安装目录下的vcvars32.batC:\Program Files\Microsoft Visual Studio\VC98\bin\vcvars32.bat注意这是老VC6的默认路径如果你的机器装在其他盘请相应修改。此文件会设置INCLUDE和LIB路径让cl.exe能找到标准库。然后进入源码目录执行cl /c /nologo /O2 /MT /EHsc /D JSON_NOEXCEPT /I include src\lib_json\json_value.cpp src\lib_json\json_reader.cpp src\lib_json\json_writer.cpp link /lib json_value.obj json_reader.obj json_writer.obj /OUT:json_static.lib参数说明/c表示只编译不链接生成三个目标文件。/O2是速度优化也可以改成/Od方便调试。/MT对应静态运行时库和IDE里设置的效果一致。/EHsc是C异常处理模型VC6默认是/GX但/EHsc更明确。/I include指定头文件搜索路径。最后一步用link /lib把三个obj打包成静态库json_static.lib。这样生成库文件后主程序包含头文件时链接器添加json_static.lib即可。如果你希望得到导入库加dll则把/c编译后的每个obj再链接成dlllink /DLL json_value.obj json_reader.obj json_writer.obj /OUT:jsoncpp.dll不过动态库方案要处理__declspec(dllexport)源码里必须定义JSONCPP_DLL否则导不出类符号所以我更推荐静态库。VC6时代的运行环境静态库反而省心。3.4 在调用方工程中的头文件与库文件配置库编译好了接下来要让老工程认得它。以VC6的MFC对话框工程为例你要做三件事在调用工程的 Project Settings - C/C - Preprocessor - Additional include directories 里加入jsoncpp源码的include目录。在 Link - Object/library modules 尾部追加json_static.lib。在工程的 precompiled header通常叫stdafx.h里添加#include json/json.h。注意头文件包含顺序有讲究。jsoncpp的头文件依赖于cstdio和cstdlib如果你在stdafx.h中过早包含它可能引发宏冲突。一个常见做法是先包含标准库头再包含json头#include afxwin.h #include string #include fstream #include json/json.h这能最大限度减少顺序性编译错误。如果调用方是纯Win32控制台程序同样适用只是不需要afxwin.h。4. 避坑手册VC6编译jsoncpp的常见问题与排查4.1 编译错误 C2061: 语法错误标识符string现象在json_reader.cpp里报错提示string不是类或命名空间。原因VC6的STL头文件在std命名空间中但旧标准头文件string并没有把basic_string重导出到全局。jsoncpp老版本有些头文件内部在#include string后用了std::string但如果某个源文件先包含了windows.h而windows.h也定义了一个typedef混淆了名字空间或者恰好因为预编译头导致了头文件包含顺序被破坏就可能在解析std::string前先碰到一个不完整的类型声明。另一个原因是工程中无意定义了宏string比如和Windows的某些类型重名。解决在工程预处理器定义中确认没有string、value这类宏。更稳妥的做法是在json/config.h的最顶部强制包含#include string和#include vector保证在任何干扰之前标准头先读进来。我在一次集成时发现是项目自身的resource.h里定义了#define string LPSTR真是血泪经验排查了一下午。4.2 编译错误 C2143: 语法错误缺少;在之前现象错误定位到json_value.h的某个template typename T声明上VC6提示在前少了分号。原因VC6对模板语法的支持是半生不熟的尤其是当模板声明前有一条未以分号结束的宏或者结构体定义时它会把模板的下一个符号当作上一行的拼写。最常见的是某些头文件在#define JSON_CPP_API __declspec(dllimport)后紧跟着没有空格或换行导致预处理器把__declspec(dllimport)和template粘连了。解决检查所有涉及JSON_API的宏定义确保它们是JSON_CPP_API并且后面没有多余的分号。在VC6下把JSON_CPP_API直接定义成空字符串禁用导入导出修饰是绕开这个问题的快速方案#define JSON_CPP_API再编译基本不会再出现这个玄学语法错误。另外确保在包含json/json.h之前不要包含任何自定义的combase.h这类头文件会引发template歧义。4.3 链接错误 LNK2001: 无法解析的外部符号 private: static class ...现象主工程明明链接了json_static.lib但点击编译后链接器提示某个Json::Value类的成员函数符号无法解析。原因json_static.lib是在没有定义JSON_CPP_API的情况下编译的而调用工程在头文件中却因为某个宏改变了类声明使它期待的是__declspec(dllimport)版本的导入符号。两者符号修饰不一致VC6就会把函数符号视作外部可导入的实际需要的却是内部的__thiscall调用方式于是无法匹配。解决统一所有工程对JSON_CPP_API、JSON_NOEXCEPT等宏的定义。最省事的办法是在所有涉及jsoncpp的工程属性里把它们设置为完全相同的内容。还有一个低级坑把json_static.lib和某个动态库导入库jsoncpp.lib混在一起链接器会挑错的版本。删掉多余的库引用只保留一份即可。4.4 内存崩溃运行库/MD与/MT混用现象程序运行到Json::Value析构时崩溃或者在delete处访问野指针。原因jsoncpp静态库是用/MT多线程静态运行时编译的主程序却用的/MD多线程DLL运行时。两者各自维护一套堆内存指针当Json::Value对象在一个运行时环境里分配内存在另一个运行时环境里释放时堆句柄不匹配直接引发heap corruption。解决把主工程的C/C - Code Generation - Use run-time library改成与jsoncpp库一致的选项。如果库使用/MT主程序也要/MT如果是Debug版本都用/MTd。这个错误不会在编译期发现只会在运行时随机崩极其阴险。我一般会在项目文档里醒目标注jsoncpp库必须匹配运行库模式避免后续接手的人踩坑。4.5 中文乱码与宽字符问题现象从文件读入含中文的JSON字符串解析后asString()得到的不是乱码就是空。原因VC6的char默认是单字节std::string只负责存储字节流不关心编码。jsoncpp对UTF-8的处理是字节级复制因此如果源文件是GBK编码JSON内容会原样转成GBK字节但JSON标准里要求\uXXXX转义可以解析而中文字符直接出现在字符串里jsoncpp会认为是非法字符。很多老工程里文件保存为GBK读取后JSON解析就报了unterminated string。解决在读取文件后、parse之前把字节流转成UTF-8格式或者强制源代码中所有中文条件用\uXXXX转义。还有一招更贴合老系统修改json_reader.cpp的skipComment逻辑允许GBK扩展字节区域绕过合法性检查。但那样会破坏JSON兼容性我不推荐。实际我处理那个模拟项目时是写了一个GBK转UTF-8的包装函数先转再解析出参再转回GBK整个世界就清净了。VC6下没有MultiByteToWideChar的对应简化用法用的时候要格外注意对字节长度的判断。5. jsoncpp实战读写JSON配置的完整代码与要点5.1 从一个配置文件装载全部参数假设你手头有个老系统配置文件config.txt内容是{server:{host:192.168.1.10,port:8088},enable_log:true}下面是我在VC6下经常写的一段代码用于加载并读取配置#include json/json.h #include fstream #include iostream bool LoadConfig(const char* filePath, Json::Value outCfg) { std::ifstream fin(filePath); if (fin.fail()) { return false; } Json::Reader reader; bool ok reader.parse(fin, outCfg, false); fin.close(); return ok; }这里有几个关键点reader.parse的第三个参数是collectComments设为false可以丢弃注释老版本里如果遇到带//的配置文件会默认跳过注释true表示收集注释到Value里反而浪费空间。std::ifstream在VC6下打开文件时如果文件路径含中文可能会失败这是VC6的fstream早就存在的坑建议用std::ifstream::open之前先MultiByteToWideChar转成宽字符路径再用ifstream::open(const wchar_t*)。不过VC6的标准库其实也接受宽字符路径只是它的ifstream实现里没有对应的重载所以更常见的是用FILE*加fopen然后传给reader.parse。5.2 修改节点并序列化输出读取之后往往要改里面某些键。下面这段代码演示怎么改端口号和增加一个新键然后写成带缩进的文本Json::Value cfg; if (LoadConfig(config.txt, cfg)) { cfg[server][port] 9090; cfg[enable_log] false; cfg[max_conns] 256; // 新增键 Json::StyledWriter writer; std::string out writer.write(cfg); std::ofstream fout(config_new.txt); fout out; fout.close(); }逻辑说明cfg[server][port] 9090;这行会自动在server对象下创建port键如果server原本不存在jsoncpp也会自动创建一个object节点。Json::StyledWriter::write()返回std::string序列化后的字符串末尾带一个换行符这在你拼接日志时要注意去掉否则多打一个空行。FastWriter的类型空间更紧凑但输出时不会格式化适合网络传输。参数要点StyledWriter的缩进是固定两空格没有参数可调。如果想要自定义格式那就得用更高版本的StreamWriterBuilder但VC6不支持那个新接口。老版本中如果不想有null节点需要在写之前用cfg.removeMember(enable_log2)移除直接赋Json::nullValue也只能让它序列化成null文本。这个行为很容易被忽略。5.3 在老系统中集成线程安全边界与内存释放jsoncpp的Json::Value内部使用引用计数管理内存这意味当你把某个子节点复制给另一个Value时两个对象共享同一份数据只有当引用计数归零时才释放内存。这在多线程环境下是隐患如果两个线程同时操作同一个Value内部的引用计数操作没有加锁就会产生数据竞争。老系统里如果多个线程同时读取配置建议每个线程各自parse一份独立的Json::Value不要共享。关于内存释放Json::Value对象本身会递归释放所有子节点你不必手动delete。但要注意循环引用——jsoncpp设计上没有处理环的能力如果真的构造出一个自包含的节点会导致内存泄漏。好在我们平时读写JSON并不会遇到环除非有人像写链表一样不断value[child] value那纯属自找麻烦。下面是一个典型的“解析一次多次只读”模式class CConfigHelper { public: // 加载成功后不再修改 root bool Initialize(const char* path) { return LoadConfig(path, m_Root); } std::string GetHost() const { return m_Root[server][host].asString(); } int GetPort() const { return m_Root[server][port].asInt(); } private: Json::Value m_Root; };这种封装让调用方根本感觉不到jsoncpp的存在后续替换成其他解析库时只需要改这一个类内部外部代码零改动。6. 用最小测试用例锁定VC6编译器的怪癖每次拿到一份新的VC6 jsoncpp源码我都会写一个只有十几行的smoke.cpp专门验证最基础的编解码路径。它不测业务逻辑只测编译器对库的态度// smoke.cpp #include json/json.h #include string int main() { Json::Value v; v[name] testing; v[count] 123; Json::FastWriter w; std::string s w.write(v); Json::Value v2; Json::Reader r; if (r.parse(s, v2)) { return (v2[name].asString() testing) ? 0 : 1; } return 2; }这个用例故意绕开了文件读写直接在内存里完成赋值、序列化、再解析。它能一次性暴露编译器在模板实例化、字符串字面量处理、运行时库匹配上的问题。如果smoke.cpp编译后返回0我再开始集成到实际工程如果返回非0说明这个库的拷贝或编译配置仍有没对齐的漏洞省得在大型模块里反复排错。从那以后我每次搭VC6环境都会强制走一遍这个smoke测试再顺手把编译参数抄到一个build_notes.txt里。说玄学也好说笨办法也罢这确实让我躲过了很多次无头绪的链接错误。希望你在这份jsoncpp源码上编译时也能少踩几个坑——哪怕踩了至少知道该去哪儿修。本文还有配套的精品资源点击获取