简介面向需要在VS2013环境下用C解析JSON的开发者一份可直接运行的jsoncpp示例工程已整合第三方jsoncpp库的完整配置。压缩包共33个文件包含11个头文件、1个cpp源文件、预编译lib库以及编译生成的exe可执行文件另有sln工程文件、pdb调试信息和tlog等构建日志方便对照工程配置快速上手。已有1580人学习下载。资源以json_demo示例项目为主体演示了从读取data.json、构建CharReader解析器、解析到Json::Value对象再到遍历输出键值对的过程同时附带了VS2013所需的include头文件路径和lib链接配置可直接打开调试或修改扩展。对初学者理解jsoncpp库的接入步骤和常用API调用很有帮助也可作为后续处理数组、嵌套对象等复杂JSON结构的起点。1. VS2013 里解析 JSON 文件为什么我把 jsoncpp 源码直接编进项目如果你现在还需要在 vs2013 的 c 工程里解析 json 文件jsoncpp 基本是老代码里最顺手的库没有之一。我最近在维护一套 2015 年遗留的工控上位机程序界面和业务逻辑都很旧唯独配置文件从 INI 换成了 JSON而工程里没有任何现成的解析手段。用的还是 VS2013连 C11 都是半支持状态硬上了好几个库之后最后全删了规规矩矩地把 jsoncpp 源码直接编进了项目。这篇笔记就是按我当时搭的方案来的哪些版本能用、代码怎么贴、编译和运行时会撞到哪些坑全部是实操结果不是理论推演。适合正在维护 VS2013 老工程、或者被迫在旧编译器上做新功能的人直接抄作业。2. jsoncpp 引入方式与版本选型源码直编、NuGet 与预编译库的区别2.1 版本选型为什么 jsoncpp 1.8.4 是 VS2013 的甜点位jsoncpp 的版本演进跟 VS2013 的兼容性关系非常大这个坑我建议先避开。jsoncpp 从 1.9.0 开始官方把最低编译要求提到了完整的 C11 支持。VS2013 对应的 _MSC_VER 是 1800它对 C11 的支持停留在早期阶段变量模板、通用 constexpr 这些要么缺失要么实现不完整STL 里不少算法也还是残缺的。所以你在 VS2013 里直接下载最新的 jsoncpp 1.9.x编译报错会非常难看而且报错位置往往不在 jsoncpp 本身而是在标准库头文件的深层模板展开里定位起来非常劝退。我最终锁定了 jsoncpp 1.8.4。这个版本是 1.8 系列的最后一个发布版代码风格还照顾老编译器默认不启用 C11 特性在 VS2013 里编起来基本不费劲。如果你手头工程里本来就有旧版 jsoncpp先看一眼版本#include json/version.h #if JSONCPP_VERSION_MAJOR ! 1 || JSONCPP_VERSION_MINOR ! 8 #error this project expects jsoncpp 1.8.x, check your include path #endif逻辑说明header 里用宏做编译期检查是接手老工程时最快的版本指纹确认方式。JSONCPP_VERSION_MAJOR、JSONCPP_VERSION_MINOR 和 JSONCPP_VERSION_PATCH 在 jsoncpp 的 version.h 里有定义不会失效。如果你工程里混入了别的 jsoncpp 版本编译直接停在第一行比运行到一半崩掉好处理得多。参数说明这段代码不要写在 stdafx.h 里应该放在真正包含 json/json.h 的源文件顶部确保 include 路径确定之后再检查。版本兼容情况可以参考这个表我实测过 VS2013 的结论是jsoncpp 版本最低编译器要求VS2013 实测1.8.4 及之前C03 为主直接编译无报错1.9.0 ~ 1.9.5完整 C11编译报错集中在模板和头文件1.9.6C11 / 部分 C14不建议尝试2.2 三种引入方式源码直编、amalgamated 单文件和 NuGet把 jsoncpp 弄进 VS2013 工程常见的有三种姿势差别在文件数和踩坑面积。第一种是完整源码直编把 jsoncpp 仓库里的 include/json 目录和 src/lib_json 目录原样拿进来工程里加三个 cpp 文件json_reader.cpp、json_value.cpp、json_writer.cpp编译时一起编。优点是调试时能跟进 jsoncpp 内部缺点是文件多新手容易漏文件。第二种是官方提供的 amalgamated 打包用仓库里的 python 脚本把 jsoncpp 打成单个 jsoncpp.cpp 和单个 json/json.h两个文件丢进工程就完事。我一般建议老工程用这种方式因为引入一个第三方库的开销最小出问题排查面也最小。脚本在 jsoncpp 源码根目录下叫 amalgamate.py运行后产物在 dist 目录里。VS2013 只要把这个 dist/jsoncpp.cpp 加进工程把 dist 目录配成附加包含目录即可。第三种是 NuGet 或者用预编译好的 lib/dll。NuGet 上默认拉下来的是新版 jsoncpp坑在 2.1 已经说明了另一个坑是预编译库的平台和运行库不一定跟你的工程一致Debug 和 Release、Win32 和 x64 混着用链接期直接爆炸。这个我在避坑清单里单独写。三种方式对比下来引入方式文件数配置难度踩坑点完整源码直编头文件 3 个 cpp中容易漏 cpp 文件amalgamated 单文件2 个文件低基本无NuGet / 预编译库1 个包低版本和运行库匹配问题多2.3 VS2013 工程配置四步走配置步骤说细一点。第一步下载 jsoncpp 1.8.4 源码跑 amalgamate.py 生成 dist 目录。第二步VS2013 里打开项目属性C/C - 常规 - 附加包含目录把 dist 目录加进去。第三步把 dist/jsoncpp.cpp 加入工程 Source Files。第四步确认预处理器里没有定义 JSON_USE_CXX11也不要定义 JSON_DLL。// 在 jsoncpp 1.8.4 的 json/config.h 里默认会这样判断编译器 #if defined(_MSC_VER) _MSC_VER 1800 // 老 VC 编译器走 C03 分支 #else // 新编译器才考虑 C11 特性 #endif逻辑说明jsoncpp 源码内部自己会判断编译器版本不需要我们干预。如果你在工程预处理器里手贱加了 JSON_USE_CXX11反而会让 jsoncpp 启用一些 VS2013 支持不好的特性。参数说明JSON_DLL 是动态库导出宏静态编译时不要定义如果看到 Json::Value 的链接报错提示 JSON_API 相关多半是这里配错了。还有一个容易被忽略的点VS2013 工程默认有预编译头如果 jsoncpp.cpp 也参与了预编译头编译可能产生 C1854 之类的警告。我的做法是右键 jsoncpp.cpp - 属性 - 预编译头 - 不使用预编译头其他文件保持默认。这一步不配后面大概率要回来补。3. 从文件到 Json::Value读取、解析与遍历的完整可抄代码3.1 完整代码二进制读取、剥离 BOM、解析配置好工程之后落地代码其实不长。我先给出一个可以直接抄进 VS2013 工程的完整 demo后面再拆开讲参数。这个 demo 做的事读取一个 config.json 文件剥掉 UTF-8 BOM用 jsoncpp 解析成 Json::Value然后取出嵌套字段打印。#include fstream #include iostream #include string #include memory #include json/json.h static std::string ReadFileUtf8(const std::string utf8Path) { std::ifstream in(utf8Path.c_str(), std::ios::binary); if (!in.is_open()) { throw std::runtime_error(cannot open utf8Path); } std::string content((std::istreambuf_iteratorchar(in)), std::istreambuf_iteratorchar()); // 去掉 UTF-8 BOM否则 jsoncpp 解析会失败 if (content.size() 3 (unsigned char)content[0] 0xEF (unsigned char)content[1] 0xBB (unsigned char)content[2] 0xBF) { content.erase(0, 3); } return content; } int main() { try { std::string text ReadFileUtf8(config.json); Json::Value root; Json::CharReaderBuilder builder; builder[collectComments] false; std::unique_ptrJson::CharReader reader(builder.newCharReader()); std::string errs; bool ok reader-parse(text.c_str(), text.c_str() text.size(), root, errs); if (!ok) { std::cerr parse error: errs std::endl; return 1; } std::string host root[server][host].asString(); int port root[server][port].asInt(); std::cout host host , port port std::endl; } catch (const std::exception ex) { std::cerr ex.what() std::endl; } return 0; }逻辑说明读取文件用的是 ifstream 的 binary 模式配合 istreambuf_iterator 一次性把整个文件装进 std::string。这里必须用 binary 模式否则 Windows 下文本模式会把\r\n转换成\n解析结果不会错但如果是二进制字段会有问题。参数说明parse 接口是 CharReaderBuilder 生成 CharReader 后调用的四个参数分别是文本起始指针、文本结束指针、输出的 Value 指针和错误信息字符串。这里没有用老的 Json::Reader因为 CharReaderBuilder 有配置项可以透出比如 collectComments。关于 collectComments这个配置控制 jsoncpp 是否保留 JSON 里的注释。严格 JSON 标准不允许注释但很多老项目的配置文件里确实写了//注释。默认值是 truejsoncpp 会容忍并跳过注释把它设成 false遇到注释直接 parse 失败。老工程我建议保持默认 true降低改造阻力。3.2 遍历 Json::Value成员遍历和数组遍历解析出 root 之后业务逻辑里最常干的事是遍历。Json::Value 内部是变体类型底层可能是 object、array、string、int、double、bool 或 null。遍历 object 成员和遍历 array 的写法不一样很多新人在 array 上用了成员遍历结果迭代器返回的是空 key拿不到值。// 遍历 object 成员 Json::Value::const_iterator it; for (it root.begin(); it ! root.end(); it) { std::string key it.key().asString(); Json::Value val *it; std::cout key - val.toStyledString() std::endl; } // 遍历 array 元素 Json::Value arr root[users]; for (Json::ArrayIndex i 0; i arr.size(); i) { std::cout user i : arr[i].asString() std::endl; }逻辑说明Json::Value 的 begin()/end() 在 object 和 array 上都可用但 object 的迭代器通过 it.key() 拿字段名array 的迭代器没有这个概念。判断当前 Value 是哪种类型用 isObject() 和 isArray() 提前分流。参数说明Json::ArrayIndex 在 jsoncpp 内部是 unsigned int 的别名旧版 VS2013 上不要用 size_t 直接跟 arr.size() 比较类型不一致在某些警告等级下会炸 warning 甚至报错。还有一种很常见但是容易踩坑的写怪直接把root[users]当数组遍历如果这个字段缺失jsoncpp 会返回一个 null Valuenull Value 的 size() 是 0循环体一次都不执行看起来没毛病。但如果这个字段类型是 objectsize() 返回成员数量循环就会把 object 当数组取越界读取有的版本直接断言崩溃。所以遍历前加类型判断是必要的下面第 4 章会专门讲容错。3.3 递归遍历一次摸清整个 JSON 里有哪些字段接手老工程时最痛苦的是不知道配置文件里到底有哪些字段、什么类型。与其一个 key 一个 key 去猜不如写个递归遍历把整棵 JSON 树打出来。这个函数我一直在工程里留着排障时特别好用。static void WalkJson(const Json::Value v, const std::string path) { if (v.isObject()) { Json::Value::const_iterator it; for (it v.begin(); it ! v.end(); it) { std::string child path . it.key().asString(); WalkJson(*it, child); } } else if (v.isArray()) { for (Json::ArrayIndex i 0; i v.size(); i) { char buf[32]; sprintf_s(buf, [%u], i); WalkJson(v[i], path buf); } } else { std::cout path : type v.type() std::endl; } }逻辑说明递归的思路很简单object 就进子节点拼 keyarray 就按下标拼[i]叶子节点打印完整路径。这里注意区分 isObject 和 isArray 的判断顺序jsoncpp 的 Value 类型是互斥的一个 Value 不可能同时是 object 和 array所以顺序无所谓但先判断 object 更符合阅读习惯。参数说明v.type() 返回 Json::ValueType 枚举可以直接转成 int 打印sprintf_s 是 VS2013 下 MSVC 提供的安全版本不能直接用 sprintf否则 C4996 警告满天飞。4. 查询与容错三板斧isMember、get 缺省值和类型检查4.1 isMember 预检为什么 operator[] 不能乱用jsoncpp 的root[key]这个操作很多人用得顺手但它有个隐蔽行为如果你用非 const 的 root 去访问不存在的 keyjsoncpp 会在 root 里插入一个 null Value然后返回这个新插入的引用。这带来两个后果一是整个 Json::Value 的成员数量变了后面再遍历会多出脏字段二是如果把这种操作放在读取配置的逻辑里等于在往配置对象里写垃圾数据。Json::Value cfg; bool hasServer cfg.isMember(server); if (hasServer cfg[server].isObject()) { // 这里才能放心用 operator[] }逻辑说明isMember 只做存在性检查不修改对象本身。加上 isObject 是防止字段存在但类型不对的情况比如配置文件里把 server 写成了字符串你不加这个判断下一步 cfg[server][host] 的行为就是未定义的轻则返回 null Value重则崩溃。参数说明isMember 的入参是 const char* 或 std::string都可以对老工程的建议是统一用 std::string避免隐式转换带来的临时对象开销。还有一种典型误用是把查询结果存起来供后续判断。正确姿势是查出一次后面复用if (cfg.isMember(server)) { Json::Value server cfg[server]; // 拷贝一份后面不再查根对象 if (server.isObject() server.isMember(host)) { host_ server[host].asString(); } }4.2 get 缺省值一行代码搞定可选配置配置文件里的字段不是每个都必须存在的。常见做法是先用 isMember 判断不存在就用默认值。jsoncpp 提供了 get 接口能做到一行代码完成而且不会往 Value 里插入脏数据。int timeout cfg.get(timeout, Json::Value(3000)).asInt(); bool enable cfg.get(enable_log, Json::Value(true)).asBool(); std::string name cfg.get(name, Json::Value(demo)).asString();逻辑说明get 的第一个参数是 key第二个参数是默认值返回一个 Json::Value。如果 key 不存在返回默认值如果 key 存在但类型不匹配比如 timeout 在 JSON 里写成了字符串 3000返回的是实际存在的值不是默认值。所以 get 只解决存在性问题不解决类型问题。参数说明Json::Value(3000) 这种构造方式直接创建整数型 ValueJson::Value(true) 创建布尔型Json::Value(demo) 创建字符串型注意字符串走的是 const char* 重载如果你想用 std::string 变量作为默认值要写成 Json::Value(std::string(demo))避免歧义。get 用在嵌套字段上同样有效配合第 3 章的遍历代码可以把配置读取简化成一套无脑取值int port cfg.get(server, Json::Value(Json::objectValue)) .get(port, Json::Value(8080)).asInt();4.3 类型检查asInt 的截断坑和 isString 的判真jsoncpp 的类型判断在边界条件下容易翻车这里列三个我实际踩过的行为。第一个asInt 对浮点数会直接截断JSON 里写 3.99asInt 返回 3不报错也不警告。第二个isInt 对 3.99 返回 false但 asInt 仍然能调出 3。第三个isString 对字符串数字返回 true所以先判断 isString 再去 asInt 是很危险的。Json::Value v cfg[port]; if (v.isInt()) { int port v.asInt(); } else if (v.isDouble()) { int port static_castint(v.asDouble()); // 显式转换自己负责精度 }逻辑说明这段代码先显式判断类型再决定怎么取数。isDouble 的情况用 static_cast 把 double 转 int精度取舍自己心里有数不会让 jsoncpp 悄悄截断。参数说明语音识别如果 JSON 里 port 是字符串 8080上面的代码两个分支都进不去正确的容错是再加一个 isString 分支手动解析或者干脆在配置规范层面约定端口必须是数字把脏数据挡在源头。类型判断再往深走一步是对 Value 做递归校验检查整个配置树的字段类型是否符合预期。思路跟 3.3 的递归遍历一样把类型判断加在叶子节点上记录所有不匹配的路径。老项目上这个函数能把漏配的字段一次性揪出来调试效率提升很多。static void ValidateType(const Json::Value v, const std::string path, Json::ValueType expect) { if (v.isObject() || v.isArray()) { Json::Value::const_iterator it; for (it v.begin(); it ! v.end(); it) { std::string child path . it.key().asString(); ValidateType(*it, child, expect); } } else if (v.type() ! expect) { std::cerr type mismatch at path : expect expect , got v.type() std::endl; } }5. 避坑清单编码、平台与运行库三座大山5.1 新版 jsoncpp 在 VS2013 编译不过现象工程里通过 NuGet 装 jsoncpp或者直接把 GitHub 上的最新源码放进 VS2013编译时报成片模板错误报错定位在标准库头文件里完全看不出跟 jsoncpp 有关。原因jsoncpp 1.9.0 起要求完整 C11 支持VS2013 的 _MSC_VER 1800 对部分 C11 特性支持不完整标准库算法和容器实现也偏老两者在一起触发模板深层展开失败。解决换用 jsoncpp 1.8.4或者直接使用 1.8.4 的 amalgamated 单文件。如果工程结构允许也可以考虑用第三方的旧版分支但没必要1.8.4 在 VS2013 上实测可用功能和 1.9 的差异对大多数业务无所谓。5.2 链接报 LNK2019Json::Value 相关符号找不到现象编译全部通过链接时报一堆 unresolved external symbol符号名里全是 Json::Value::Json::Value、Json::Value::~Json::Value 之类。原因只把 include/json 目录配进了附加包含目录却忘了把 json_reader.cpp、json_value.cpp、json_writer.cpp 加进工程。头文件让编译器认识了这个类链接器找不到实现。另一个常见原因是工程里同时引入了两个版本的 jsoncpp符号冲突或者被错误版本抢先解析。解决要么把三个 cpp 加进工程要么直接用 amalgamated 的 jsoncpp.cpp。加完 cpp 之后把 jsoncpp 的源文件设置成不使用预编译头这个细节前面 2.3 提过如果不设置某些配置下会报 C1854。检查是否混入了多个版本在工程里搜索 json_value.cpp确认只有一个。5.3 控制台打印中文乱码现象JSON 文件里明明是中文字符串asString() 取出来之后用 std::cout 打印控制台显示成???或者乱码。原因VS2013 源码文件默认保存为 GBK控制台代码页通常是 936而 JSON 文件里的中文是 UTF-8 编码。jsoncpp 原样把 UTF-8 字节解析成 std::string打印到控制台时被按 GBK 解释自然乱码。这不是 jsoncpp 的问题是编码链路问题。解决读取阶段以 UTF-8 为标准打印阶段再转成 ANSI即 GBK。用一个转码函数封装不污染业务代码#include Windows.h static std::string Utf8ToAnsi(const std::string utf8) { if (utf8.empty()) return utf8; int wlen MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, NULL, 0); std::wstring wstr(wlen, L\0); MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, wstr[0], wlen); int alen WideCharToMultiByte(CP_ACP, 0, wstr.c_str(), -1, NULL, 0, NULL, NULL); std::string astr(alen, \0); WideCharToMultiByte(CP_ACP, 0, wstr.c_str(), -1, astr[0], alen, NULL, NULL); return astr; }逻辑说明先通过 MultiByteToWideChar 把 UTF-8 转成宽字符再用 WideCharToMultiByte 转成系统 ANSI 代码页。参数说明CP_UTF8 和 CP_ACP 是 Windows 下两个关键代码页常量前者是 UTF-8后者是系统 ANSI中文系统上是 936。打印时std::cout Utf8ToAnsi(host) std::endl;即可内部解析逻辑保持 UTF-8 不动。5.4 Debug 和 Release、Win32 和 x64 混配导致崩溃现象程序在 Debug 下运行正常切 Release 后启动即崩或者用 Release 编译的 lib 放到 Debug 工程里链接运行时会堆损坏。原因jsoncpp 的 cpp 文件和调用方工程如果运行时库不一致比如一边 /MDd 一边 /MT两边对 new/delete 和内存管理的实现不同跨模块分配释放直接崩。另外 Debug 默认开启迭代器调试_ITERATOR_DEBUG_LEVEL 不同会导致 std::string 等容器内存布局不同jsoncpp 内部用了 std::vector 等容器就会踩到。解决最省心的方式是把 jsoncpp 源码直接编进目标工程跟随工程的平台和运行库设置走。如果非要用预编译 lib必须保证 Debug/Release、Win32/x64、运行时库三个维度全部一致。检查方法项目属性 - C/C - 代码生成 - 运行时库两边都选 /MD 或都选 /MDd。5.5 JSON 文件路径含中文时 ifstream 打不开现象配置文件放在中文路径下程序启动时抛 cannot open日志里路径看着没问题但就是打不开。Windows 资源管理器里文件明明存在。原因std::ifstream 的 const char* 构造在 MSVC 下走的是 ANSI 字符串入口而程序中路径是 UTF-8 编码Windows API 收到 UTF-8 字节后把它当 ANSI 解释路径就不对了。这是 VS2013 时代非常典型的路径编码问题。解决先把路径转成宽字符再用 ifstream 的宽字符重载构造std::wifstream in(Lconfig.json, std::ios::binary); // 或者先用 MultiByteToWideChar 把 UTF-8 路径转成 std::wstring说明MSVC 的 fstream 提供了接受 const wchar_t* 的扩展构造这是老版本里绕开 ANSI 解析的唯一便捷通道。如果工程里大量使用 std::string 路径推荐封装一个 OpenFile 函数统一把 UTF-8 转成宽字符再打开避免每个调用点都写一遍转码。6. 用 writer 回写做双端验证把 jsoncpp 变成格式化与校验工具jsoncpp 不仅会解析sequence 化也是它最容易被低估的能力。我常说 jsoncpp 的 writer 是个天然的 JSON 格式化器和合法性验证器把一段 JSON 读进来再写出去如果全程无异常说明结构能被 jsoncpp 完整理解写出去的文本用别的工具再解析一遍如果也通过说明没有产生无效 JSON。这个方法在接手老工程时价值很大因为老配置文件往往手改过很多次缩进混乱不说还夹着注释、尾逗号之类的东西。Json::StreamWriterBuilder wb; wb[indentation] ; std::string formatted Json::writeString(wb, root); std::ofstream out(config.formatted.json, std::ios::binary); out formatted; out.close();逻辑说明StreamWriterBuilder 是 jsoncpp 推荐的新 writer 入口indentation 配置项控制缩进字符这里设为两个空格。writeString 把 Value 序列化成字符串。参数说明除了缩进还能配置注释样式、特殊浮点数处理等但对老工程最关键是缩进因为很多配置文件是要给运维看的不是给人看的缩进统一了diff 才能看出来谁改了哪里。序列化成功后在 VS2013 外部用 Python 做交叉验证。Windows 上装个 Python命令行执行python -m json.tool config.formatted.json verified.json逻辑说明python -m json.tool 会解析文件并重新格式化输出解析失败时返回非零退出码并打印错误。这个命令是双端验证里最省事的一环因为 Python 的 json 模块和 jsoncpp 对 JSON 标准的解释基本一致如果它能通过说明 jsoncpp 写出来的内容没有语法层面问题。对比 config.formatted.json 和 verified.json 的内容差异就能看出 jsoncpp 和 Python 两边对某些边界值的处理差异比如浮点精度、整数上下界。从那以后我每次接手老工程第一件事就是跑一遍「读入 - writer 回写 - json.tool 校验」的流程先把配置结构摸清楚再谈改字段。这个习惯帮我挡掉过好几次因为配置文件里有脏数据导致的运行时崩溃。也希望这套流程能帮到你少走弯路。本文还有配套的精品资源点击获取