VS2019 静态集成 jsoncpp 与 json-rpc：配置、调用与避坑指南

简介本资源提供在 Windows 平台使用 VS2019 静态编译完成的 libjsoncpp 与 libjson-rpc-cpp 库面向需要在 C 项目中集成 JSON 解析与 JSON-RPC 通信能力的开发者。相比网络上流传的同类静态编译包此版本补齐了缺失的 libjsoncpp 文件并采用 X64 架构解决了 x86 版本无法直接使用的问题。压缩包共 355 个文件约 20.82MB包含 4 个 lib 静态库、3 个 sln 解决方案、4 个 vcxproj 工程文件以及大量 cpp、h、inl 源码与 obj、pdb、tlog 等编译中间产物另附 json、expected 测试数据与 py、sh 辅助脚本便于直接链接使用或按需二次编译为 X64 或 x86。已有 474 人学习下载。拿到后可直接将 lib 与头文件引入工程省去自行编译依赖的繁琐过程同时保留完整工程结构方便排查编译问题、调整运行库配置或裁剪模块适合中高级 C 开发者快速搭建 JSON-RPC 通信环境。1. 拿到 libjsoncpp 和 libjson-rpc 静态库先搞清楚它能省掉你多少事在 Windows 上用 VS2019 做 C 项目只要涉及 JSON 解析或 RPC 通信大概率绕不开 jsoncpp 和 json-rpc-cpp 这两个库。问题是这两个库在 Windows 上的编译体验并不友好jsoncpp 需要 CMake 生成 VS 工程再编译json-rpc-cpp 还依赖 libmicrohttpd、libcurl、jsoncpp 本身一套下来光是环境配置就能耗掉半天。如果你手上已经有一份 VS2019 静态编译好的 libjsoncpp 和 libjson-rpc那意味着链接阶段直接引用.lib文件即可不需要再折腾 CMake、vcpkg 或第三方依赖的源码编译。这篇文章面向的是需要在 VS2019 工程里快速集成 JSON 解析和 RPC 通信能力的 C 开发者尤其是那些不想在构建系统上花太多时间、只想把库拉进项目就跑起来的人。接下来我会把静态库的目录结构、VS2019 工程配置、编译参数、链接顺序以及实际调用时容易翻车的地方逐一讲清楚。2. 静态库目录结构与 VS2019 工程配置从零到编译通过2.1 拿到静态库后先确认的三件事一份 VS2019 静态编译好的 jsoncpp json-rpc 库通常包含以下内容头文件目录include、静态库文件.lib、可能的调试版和发布版各一套。在动手配置工程之前先确认三件事。第一确认编译平台。VS2019 默认工具集是 v142静态库必须是用相同工具集编译的。如果库是 v140 或 v141 编译的链接时会出现LNK2038不匹配警告严重时直接报错。检查方法是看库文件所在目录名是否带v142或MSVC2019标识或者用dumpbin /headers xxx.lib查看编译信息。第二确认运行库模式。静态库编译时用的运行库是/MT静态链接 CRT还是/MD动态链接 CRT必须和你的工程设置一致。不一致的典型症状是链接时报LNK2005符号重复定义或者运行时堆损坏。在 VS2019 里查看方式是项目属性 → C/C → 代码生成 → 运行库看当前设置是多线程 (/MT)还是多线程 DLL (/MD)。第三确认字符集。jsoncpp 默认使用 UTF-8 编码处理字符串但 Windows 工程可能设置为 Unicode 字符集。这本身不冲突但如果你在代码里混用std::string和std::wstring需要自己做转换。建议统一用std::string配合 UTF-8避免不必要的编码转换开销。2.2 VS2019 工程属性页的逐项配置假设静态库目录结构如下jsoncpp-static/ ├── include/ │ └── json/ │ ├── json.h │ ├── reader.h │ ├── writer.h │ └── value.h ├── lib/ │ ├── x64/ │ │ ├── Debug/ │ │ │ └── jsoncpp.lib │ │ └── Release/ │ │ └── jsoncpp.lib │ └── x86/ │ └── ... jsonrpc-static/ ├── include/ │ └── jsonrpccpp/ │ ├── server/ │ ├── client/ │ └── common/ └── lib/ └── x64/ ├── Debug/ │ ├── jsonrpc.lib │ └── jsonrpccpp.lib └── Release/ └── ...在 VS2019 中新建一个空 C 项目后按以下步骤配置第一步设置包含目录。项目属性 → C/C → 常规 → 附加包含目录添加$(ProjectDir)..\jsoncpp-static\include $(ProjectDir)..\jsonrpc-static\include第二步设置库目录。项目属性 → 链接器 → 常规 → 附加库目录添加$(ProjectDir)..\jsoncpp-static\lib\x64\$(Configuration) $(ProjectDir)..\jsonrpc-static\lib\x64\$(Configuration)这里用$(Configuration)宏自动区分 Debug 和 Release前提是库目录下确实按 Debug/Release 分好了。第三步添加附加依赖项。项目属性 → 链接器 → 输入 → 附加依赖项添加jsoncpp.lib jsonrpc.lib jsonrpccpp.lib链接顺序有讲究json-rpc 依赖 jsoncpp所以 jsoncpp.lib 应该放在 json-rpc 相关库的后面或至少同级。如果出现LNK2019未解析的外部符号先检查顺序。第四步确认运行库设置。项目属性 → C/C → 代码生成 → 运行库确保与静态库编译时一致。如果不确定可以先用/MT试因为大多数静态编译场景默认用/MT。第五步预处理器定义。如果 json-rpc 库编译时启用了JSONRPC_CPP_STATIC或类似宏你的工程也需要加上。查看库附带的说明文件或头文件中的#ifdef判断。配置完成后写一个最小测试代码验证#include json/json.h #include jsonrpccpp/server.h #include iostream int main() { // 测试 jsoncpp 基本解析 Json::Value root; Json::Reader reader; std::string jsonStr R({name:test,version:1}); if (!reader.parse(jsonStr, root)) { std::cerr JSON parse failed: reader.getFormattedErrorMessages() std::endl; return -1; } std::cout name: root[name].asString() std::endl; std::cout version: root[version].asInt() std::endl; // 测试 jsoncpp 序列化 Json::Value output; output[status] ok; output[code] 200; Json::FastWriter writer; std::cout writer.write(output) std::endl; return 0; }这段代码做了两件事用Json::Reader解析一个 JSON 字符串并读取字段用Json::FastWriter把Json::Value序列化成字符串。如果编译链接通过且运行输出正确说明静态库配置基本没问题。注意Json::Reader在新版 jsoncpp 中已被标记为废弃但静态库版本可能仍包含它如果编译报错说找不到Reader改用Json::CharReaderBuilder和parseFromStream。2.3 编译参数与运行库匹配的细节静态库链接最容易出问题的地方就是运行库不匹配。VS2019 中/MT和/MD的区别在于 CRT 是静态嵌入还是动态引用。如果静态库用/MT编译你的工程也必须用/MT否则会出现符号冲突。判断方法用dumpbin /directives jsoncpp.lib | findstr DEFAULTLIB查看库依赖的 CRT 版本。另一个参数是_ITERATOR_DEBUG_LEVEL。Debug 模式下 VS 默认设为 2Release 模式为 0。如果静态库是 Release 版但你的工程是 Debug 模式链接时会报LNK2038关于_ITERATOR_DEBUG_LEVEL不匹配。解决办法是 Debug 工程链接 Debug 库Release 工程链接 Release 库不要混用。如果确实需要在 Debug 工程中使用 Release 库可以在项目属性 → C/C → 预处理器中把_ITERATOR_DEBUG_LEVEL设为 0但这会失去迭代器调试检查不推荐长期这样做。3. jsoncpp 静态库的实际调用解析、序列化与中文处理3.1 解析 JSON 的三种方式与选型jsoncpp 提供了多种解析接口静态库版本通常包含以下三种第一种是Json::Reader::parse()这是最老式的接口用法简单但性能一般且在新版中已废弃。如果你的静态库版本较老可能只有这个接口。第二种是Json::CharReaderBuilder配合parseFromStream()这是推荐方式支持配置解析选项比如是否允许注释、是否允许尾随逗号等。第三种是Json::parseFromStream()的自由函数形式内部也是调用CharReader。实际使用中我一般用第二种因为可以控制解析行为。示例#include json/json.h #include sstream #include iostream bool parseJson(const std::string input, Json::Value output) { Json::CharReaderBuilder builder; // 允许注释方便解析配置文件 builder[allowComments] true; // 不允许尾随逗号保持严格模式 builder[allowTrailingCommas] false; std::istringstream iss(input); std::string errs; bool ok Json::parseFromStream(builder, iss, output, errs); if (!ok) { std::cerr Parse error: errs std::endl; } return ok; } int main() { std::string jsonStr R({ // 这是注释 server: 127.0.0.1, port: 8080, timeout: 30.5, enabled: true, tags: [cpp, json, rpc] }); Json::Value root; if (parseJson(jsonStr, root)) { std::cout server: root[server].asString() std::endl; std::cout port: root[port].asInt() std::endl; std::cout timeout: root[timeout].asDouble() std::endl; std::cout enabled: root[enabled].asBool() std::endl; for (const auto tag : root[tags]) { std::cout tag: tag.asString() std::endl; } } return 0; }CharReaderBuilder的allowComments设为true后可以解析带//或/* */注释的 JSON这在读配置文件时很实用。allowTrailingCommas控制是否允许数组或对象最后一个元素后有多余逗号建议保持false以符合标准 JSON 规范。3.2 序列化时的格式控制与中文编码jsoncpp 的序列化输出有两种常用方式Json::FastWriter和Json::StyledWriter。前者输出紧凑格式后者输出带缩进的可读格式。但在较新版本中推荐用Json::StreamWriterBuilder。#include json/json.h #include iostream int main() { Json::Value root; root[name] 张三; root[city] 北京; root[age] 28; // 紧凑输出 Json::StreamWriterBuilder compactBuilder; compactBuilder[indentation] ; std::string compact Json::writeString(compactBuilder, root); std::cout Compact: compact std::endl; // 美化输出 Json::StreamWriterBuilder prettyBuilder; prettyBuilder[indentation] ; std::string pretty Json::writeString(prettyBuilder, root); std::cout Pretty:\n pretty std::endl; return 0; }这里有一个中文处理的坑jsoncpp 默认输出 UTF-8 编码的字符串但不会做 Unicode 转义。也就是说张三会原样输出为 UTF-8 字节序列而不是\u5f20\u4e09。这在大多数场景下没问题但如果你的接收端期望 ASCII 安全的 JSON就需要自己转义。反过来如果输入是\u5f20\u4e09这样的转义序列jsoncpp 解析后asString()返回的是 UTF-8 编码的中文可以直接用。在 Windows 控制台输出中文时如果出现乱码需要设置控制台代码页为 UTF-8#include windows.h // 在 main 函数开头调用 SetConsoleOutputCP(CP_UTF8);或者在 VS2019 项目属性 → C/C → 命令行中添加/utf-8编译选项确保源码中的中文字符串字面量以 UTF-8 编码存入二进制。3.3 静态库版本差异与 API 兼容性不同时间编译的 jsoncpp 静态库可能对应不同的上游版本API 有差异。比如 1.9.x 之前Json::Reader是主流1.9.x 之后推荐CharReaderBuilder。如果你拿到的静态库头文件中没有CharReaderBuilder说明版本较老只能用Reader。判断方法打开include/json/reader.h搜索class CharReaderBuilder。如果存在说明支持新接口。另一个判断点是Json::Value::asInt64()是否存在老版本只有asInt()和asUInt()。如果静态库版本较老且你不想换库用Reader也能完成工作只是错误信息不如新接口详细。Reader::getFormattedErrorMessages()可以拿到格式化的错误位置信息调试时够用。4. json-rpc 静态库集成服务端与客户端的最小实现4.1 json-rpc 的服务端抽象类与注册流程json-rpc-cpp 在 Windows 上的静态库通常包含服务端和客户端两部分。服务端基于AbstractServer抽象类你需要继承它并实现具体的 RPC 方法。常见做法是先用 json-rpc 提供的代码生成工具根据 JSON 接口描述文件生成桩代码但如果只有静态库没有生成工具也可以手写。手写服务端的基本流程是继承AbstractServer在构造函数中注册方法名和对应的回调然后启动监听。以下是一个最小示例#include jsonrpccpp/server.h #include jsonrpccpp/server/connectors/httpserver.h #include json/json.h #include iostream class MyRpcServer : public jsonrpc::AbstractServerMyRpcServer { public: MyRpcServer(jsonrpc::AbstractServerConnector connector) : jsonrpc::AbstractServerMyRpcServer(connector) { // 注册方法方法名、参数类型、回调函数 this-bindAndAddMethod( jsonrpc::Procedure(add, jsonrpc::PARAMS_BY_POSITION, jsonrpc::JSON_INTEGER, param1, jsonrpc::JSON_INTEGER, param2, jsonrpc::JSON_INTEGER, NULL), MyRpcServer::add); this-bindAndAddMethod( jsonrpc::Procedure(echo, jsonrpc::PARAMS_BY_POSITION, jsonrpc::JSON_STRING, message, jsonrpc::JSON_STRING, NULL), MyRpcServer::echo); } // add 方法的实现 void add(const Json::Value request, Json::Value response) { int a request[param1].asInt(); int b request[param2].asInt(); response a b; } // echo 方法的实现 void echo(const Json::Value request, Json::Value response) { std::string msg request[message].asString(); response echo: msg; } }; int main() { // 监听 8383 端口 jsonrpc::HttpServer httpServer(8383); MyRpcServer server(httpServer); if (!server.StartListening()) { std::cerr Failed to start server std::endl; return -1; } std::cout Server listening on port 8383... std::endl; std::cout Press Enter to stop. std::endl; std::cin.get(); server.StopListening(); return 0; }bindAndAddMethod的第一个参数是Procedure对象描述了方法名、参数传递方式按位置或按名称、返回值类型以及参数列表。第二个参数是成员函数指针签名固定为void(const Json::Value, Json::Value)。HttpServer构造函数接收端口号StartListening()返回bool表示是否成功。注意HttpServer在 Windows 上依赖libmicrohttpd如果静态库没有把libmicrohttpd静态链接进去你可能还需要额外链接microhttpd.lib或对应的静态库。检查方法是看链接时是否报LNK2019关于MHD_开头的符号。4.2 客户端调用与连接管理客户端使用Client类通过HttpClient连接器与服务端通信#include jsonrpccpp/client.h #include jsonrpccpp/client/connectors/httpclient.h #include json/json.h #include iostream int main() { jsonrpc::HttpClient httpClient(http://127.0.0.1:8383); jsonrpc::Client client(httpClient); try { // 调用 add 方法 Json::Value params; params[param1] 10; params[param2] 32; Json::Value result client.CallMethod(add, params); std::cout add result: result.asInt() std::endl; // 调用 echo 方法 Json::Value echoParams; echoParams[message] hello rpc; Json::Value echoResult client.CallMethod(echo, echoParams); std::cout echo result: echoResult.asString() std::endl; } catch (jsonrpc::JsonRpcException e) { std::cerr RPC error: e.what() std::endl; return -1; } return 0; }CallMethod的第一个参数是方法名第二个是参数对象。参数可以按位置传递用数组或按名称传递用对象取决于服务端注册时的PARAMS_BY_POSITION或PARAMS_BY_NAME。上面服务端用的是PARAMS_BY_POSITION但客户端传的是对象json-rpc 内部会按名称匹配所以能正常工作。如果服务端严格按位置解析客户端传数组更稳妥。HttpClient在 Windows 上依赖libcurl同样需要确认静态库是否已包含 curl 的静态链接。如果链接报LNK2019关于curl_easy_的符号需要额外链接libcurl.lib及其依赖项如ws2_32.lib、wldap32.lib、crypt32.lib。4.3 静态链接下的线程安全与超时设置json-rpc 的HttpServer在 Windows 上默认使用多线程处理请求libmicrohttpd会为每个连接创建线程。如果你的静态库编译时没有启用线程支持或者libmicrohttpd是单线程版本高并发下会出现请求阻塞。检查方法是看HttpServer构造函数是否有threading参数或者查看libmicrohttpd的编译选项。超时设置方面HttpClient默认没有超时限制网络异常时可能长时间挂起。可以在HttpClient构造后设置jsonrpc::HttpClient httpClient(http://127.0.0.1:8383); // 设置连接超时和传输超时单位秒 httpClient.SetTimeout(5);如果静态库版本不支持SetTimeout可以通过libcurl的底层选项设置但需要拿到HttpClient内部的CURL*句柄这通常不暴露。更实际的做法是在服务端保证响应速度或者用异步调用模式。5. 避坑与排查静态库链接和运行时的五个血泪教训5.1 链接报 LNK2038 运行库不匹配现象编译通过链接时报LNK2038: 检测到“RuntimeLibrary”的不匹配项: 值“MT_StaticRelease”不匹配值“MD_DynamicRelease”。原因静态库编译时用的运行库是/MT而你的工程用的是/MD或反过来。VS2019 默认新建工程用/MD但很多第三方静态库默认用/MT。解决项目属性 → C/C → 代码生成 → 运行库改成与静态库一致。如果不确定库用的是哪个用dumpbin /directives xxx.lib | findstr DEFAULTLIB查看输出中带LIBCMT的是/MT带MSVCRT的是/MD。5.2 解析中文 JSON 时抛出异常或乱码现象解析包含中文的 JSON 字符串时parseFromStream返回false错误信息提示* Line 1, Column 1 Syntax error: value, object or array expected或者解析成功但asString()返回乱码。原因源码文件编码与 JSON 字符串编码不一致。VS2019 默认用 GBK 保存源文件而 jsoncpp 期望 UTF-8。如果源码里写张三编译器按 GBK 编码存入二进制jsoncpp 按 UTF-8 解析就会失败。解决在项目属性 → C/C → 命令行中添加/utf-8强制编译器把源码当 UTF-8 处理。或者用u8张三前缀明确指定 UTF-8 字面量。如果 JSON 来自文件或网络确保读取时不做编码转换直接以二进制模式读入std::string。5.3 json-rpc 服务端启动失败但无错误信息现象StartListening()返回false但没有异常抛出也没有日志输出。原因端口被占用或者libmicrohttpd初始化失败。Windows 上 8383 端口可能被其他进程占用或者防火墙阻止了监听。解决先用netstat -ano | findstr 8383检查端口占用。如果端口被占换一个端口。如果是防火墙问题在 Windows 防火墙中为可执行文件添加 inbound 规则。另外HttpServer构造函数可以传入MHD_USE_DEBUG标志如果静态库支持开启调试输出。5.4 客户端调用超时或返回空结果现象CallMethod长时间不返回或者返回的Json::Value是null。原因服务端没有启动、网络不通、或者libcurl静态链接时缺少 SSL 支持导致 HTTPS 请求失败。如果服务端返回了错误CallMethod会抛JsonRpcException但如果没有异常且返回null说明响应体为空。解决先用浏览器或curl命令测试服务端是否可达。如果服务端正常检查客户端HttpClient的 URL 是否拼写正确。对于 HTTPS确认静态库编译时启用了libcurl的 SSL 后端如 OpenSSL 或 Schannel否则只能走 HTTP。5.5 Debug 工程链接 Release 库导致运行时崩溃现象编译链接都通过但程序运行时在 jsoncpp 内部崩溃调用栈显示std::_Container_base12::_Orphan_all或类似符号。原因Debug 工程的_ITERATOR_DEBUG_LEVEL为 2Release 库为 0混用后迭代器结构体大小不一致内存布局错乱。解决严格区分 Debug 和 Release 配置Debug 工程链接 Debug 库Release 工程链接 Release 库。如果只有 Release 库把 Debug 工程的_ITERATOR_DEBUG_LEVEL设为 0项目属性 → C/C → 预处理器 → 预处理器定义添加_ITERATOR_DEBUG_LEVEL0但这会关闭迭代器调试检查仅作为临时方案。6. 进阶技巧用静态库做配置热加载与 RPC 批量调用静态库集成稳定之后可以做一些更实用的扩展。一个常见需求是配置热加载程序运行期间检测 JSON 配置文件变化自动重新解析并应用新配置。用 jsoncpp 静态库实现这个功能不需要额外依赖核心思路是记录文件最后修改时间定时检查变化时重新解析。#include json/json.h #include fstream #include chrono #include thread #include atomic #include iostream class ConfigWatcher { public: ConfigWatcher(const std::string path) : path_(path), running_(false) {} void start() { running_ true; lastWriteTime_ getLastWriteTime(); worker_ std::thread([this]() { while (running_) { auto current getLastWriteTime(); if (current ! lastWriteTime_) { lastWriteTime_ current; reload(); } std::this_thread::sleep_for(std::chrono::seconds(2)); } }); } void stop() { running_ false; if (worker_.joinable()) worker_.join(); } Json::Value getConfig() { std::lock_guardstd::mutex lock(mutex_); return config_; } private: void reload() { std::ifstream ifs(path_); if (!ifs.is_open()) return; Json::CharReaderBuilder builder; Json::Value newConfig; std::string errs; if (Json::parseFromStream(builder, ifs, newConfig, errs)) { std::lock_guardstd::mutex lock(mutex_); config_ newConfig; std::cout Config reloaded. std::endl; } else { std::cerr Config reload failed: errs std::endl; } } std::filesystem::file_time_type getLastWriteTime() { // 需要 C17 的 filesystem std::error_code ec; auto t std::filesystem::last_write_time(path_, ec); return ec ? std::filesystem::file_time_type{} : t; } std::string path_; std::atomicbool running_; std::thread worker_; std::mutex mutex_; Json::Value config_; std::filesystem::file_time_type lastWriteTime_; };这个类每 2 秒检查一次文件修改时间变化时重新解析。getConfig()返回当前配置的副本加锁保证线程安全。注意std::filesystem需要 C17VS2019 默认支持但需要在项目属性中把 C 语言标准设为/std:c17。另一个进阶用法是 RPC 批量调用。json-rpc 支持批量请求一次发送多个方法调用服务端返回结果数组。客户端侧可以这样构造Json::Value batch; batch.append(Json::Value()); // 占位实际用 jsonrpc 的批量接口 // 更实际的做法是直接用 jsonrpc::Client::CallProcedures std::vectorjsonrpc::Procedure procedures; // 填充 procedures... // auto results client.CallProcedures(procedures);不过CallProcedures在部分静态库版本中可能不存在需要确认头文件。如果不存在可以手动构造 JSON-RPC 批量请求体用HttpClient直接 POST然后解析响应数组。这种方式更灵活但需要自己处理 id 匹配和错误。最后说一个我自己的习惯拿到任何静态库先写一个最小可运行示例确认编译、链接、运行三步都通过再往正式工程里集成。这一步花 10 分钟能省掉后面几小时的排查。静态库的坑大多集中在链接阶段运行起来之后反而问题少。希望帮到你。本文还有配套的精品资源点击获取