简介这份资源面向仍在使用 Visual C 6.0 的开发者聚焦于在 VC6.0 工程中集成 JSONCPP 库并完成 JSON 解析与生成重点解决中文字符读写时的乱码问题。资源以 jsoncpp-src-0.5.0 源码为基础演示了将 json_value.cpp、json_reader.cpp、json_writer.cpp 等源文件直接加入控制台或对话框项目的完整流程并配套一份测试通过的源码类使用说明文档帮助读者避开常见配置陷阱。压缩包共 72 个文件以 h 头文件、cpp 源文件、inl 内联实现为主另含 obj、sbr 等编译中间文件及 dsp、dsw 工程文件整体约 3.77MB目录结构保留了可直接编译运行的工程形态。目前已有 590 人学习。读者可据此获得一套可复用的 VC6.0 调用 JSONCPP 范例理解 UTF-8 编码处理与中文防乱码的配置思路并借助说明文档快速排查集成与序列化环节的问题。1. VC6.0 调用 JSONCPP 解析中文变问号这个坑我踩了整整两天在 VC6.0 里调 JSONCPP 解析带中文的 JSON结果std::string里拿到的全是?或者乱码方块——这个报错我见过太多次也自己踩过。表面看是 JSONCPP 的问题实际上十有八九是 VC6.0 那套老掉牙的编译环境、字符集设置和 JSONCPP 版本三者打架。更折腾人的是它不给你任何异常解析不报错isMember返回 trueasString也能返回内容就是中文全烂掉属于典型的“静默翻车”。这篇笔记面向还在维护 VC6.0 老工程、又不得不接 JSON 接口的开发者把从编译报错到中文乱码的几类故障按现象、根因、解决顺序拆开讲照着命令和配置改就能跑通。2. 编译就过不去JSONCPP 在 VC6.0 下的三类报错VC6.0 用的是 VC6 编译器cl.exe 12.x对 C 标准的支持停留在很早期的阶段而 JSONCPP 从 0.x 到 1.x 的演进过程中大量使用了模板偏特化、std::string的新成员、long long、std::auto_ptr等特性。直接拿新版源码丢进 VC6 工程第一步就卡在编译。这一章把最常见的三类编译报错拆开每一类给出可落地的改法。2.1error C2039: XXX : is not a member of std的根因与改法这个报错是 VC6 调用 JSONCPP 时出现频率最高的一个。典型输出长这样json_value.cpp(123) : error C2039: strtoll : is not a member of std json_reader.cpp(45) : error C2065: int64_t : undeclared identifier根因有两层。第一层VC6 的string和cstdlib是 1998 年之前的实现std::strtoll、std::strtoull这些 C99 才进标准库的函数根本没有第二层JSONCPP 内部用int64_t、uint64_t表示整数而 VC6 没有cstdint也没有long long的完整支持。新版 JSONCPP 还依赖std::auto_ptr的移动语义写法VC6 的 STL 实现同样对不上。常见做法是不要硬啃最新版源码而是选一个明确标注支持老编译器的分支版本再对少数几处做兼容补丁。我一般会先确认工程里 JSONCPP 的版本然后在json/config.h里做条件编译// json/config.h 片段为 VC6 补齐缺失的整型定义 #if defined(_MSC_VER) (_MSC_VER 1300) // VC6 的 _MSC_VER 是 1200 # ifndef JSONCPP_HAS_INT64 # define JSONCPP_HAS_INT64 0 // 关掉 int64 支持避免 int64_t 未定义 # endif typedef __int64 int64_t; // VC6 认 __int64不认 long long typedef unsigned __int64 uint64_t; #endif这段配置的逻辑是用_MSC_VER判断编译器代际VC6 对应 1200低于 1300 就进入兼容分支。JSONCPP_HAS_INT64置 0 后JSONCPP 内部会退回到用double或long表示大整数牺牲一点精度换取能编译。__int64是微软编译器从 VC6 起就支持的扩展类型用它替代long long是这一步的关键。参数上要注意如果你的 JSON 里确实有大整数比如超过 2^53 的 ID关掉 int64 后精度会丢这种情况得单独用字符串字段承载别指望数值类型。改完头文件还不够std::strtoll这类调用要替换成_strtoi64这是 VC6 运行库自带的// 把 JSONCPP 源码里对 std::strtoll 的调用替换为 VC6 可用的版本 #if defined(_MSC_VER) (_MSC_VER 1300) # define json_strtoll _strtoi64 # define json_strtoull _strtoui64 #else # define json_strtoll std::strtoll # define json_strtoull std::strtoull #endif用宏做一层间接好处是同一份源码在新旧编译器上都能编不用维护两套。_strtoi64的签名和strtoll一致返回__int64第二个参数是结束指针第三个参数是进制直接替换即可。失败时它会返回 0 并设置errno排查时可以在调用后检查errno ERANGE判断是否溢出。2.2fatal error C1083: Cannot open include file: stdint.h怎么绕这个报错说明 JSONCPP 源码里#include stdint.h找不到。VC6 的 include 目录里确实没有这个头它是 C99 的产物。有人会去网上找一个stdint.h塞进工程目录能编过但容易和别的库冲突。更稳的做法是自己写一个最小的兼容头只在 VC6 下生效// compat/stdint_vc6.h仅在 VC6 下提供最小可用的整型定义 #ifndef COMPAT_STDINT_VC6_H #define COMPAT_STDINT_VC6_H #if defined(_MSC_VER) (_MSC_VER 1300) typedef signed char int8_t; typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned short uint16_t; typedef int int32_t; typedef unsigned int uint32_t; typedef __int64 int64_t; typedef unsigned __int64 uint64_t; #endif #endif然后在工程设置里把compat目录加到 Additional include directories或者在json/config.h顶部用#include compat/stdint_vc6.h引入。逻辑说明这些 typedef 的宽度必须和标准一致int32_t用int是因为 VC6 下int就是 32 位int64_t用__int64是 64 位宽度对上了JSONCPP 内部的位运算和序列化才不会错位。参数上唯一要盯的是char的符号性VC6 默认char是 signed所以int8_t用signed char显式声明避免不同编译选项下行为漂移。提示不要把这个兼容头加进全局 include 路径给所有工程用只在 JSONCPP 相关源文件里包含否则老工程里其他代码可能因为int64_t重定义报 C2371。2.3 链接期unresolved external symbol的排查顺序编译过了链接又挂报错形如json_reader.obj : error LNK2001: unresolved external symbol public: __thiscall std::_String_base::_Xran(void)const 这类符号多半来自 STL 版本不一致。VC6 的工程如果混用了不同 Service Pack 的 STL或者 JSONCPP 编译时用的运行库设置单线程/多线程、静态/动态和主工程不一致就会出现这种“函数明明有却链不上”的情况。排查顺序我一般固定走三步先看工程设置里 C/C 的 Code Generation 页确认 Runtime Library 两边都是 Multithreaded DLL 或都是 Multithreaded不能一边 Debug 一边 Release再看 JSONCPP 的 .lib 是不是用和主工程相同的配置重新编过最后检查是否重复包含了不同版本的string头。# 用 dumpbin 检查 lib 里的符号和运行库依赖在 VS 命令行里执行 dumpbin /symbols jsoncpp.lib | findstr _String_base dumpbin /directives jsoncpp.lib | findstr DEFAULTLIB第一条命令看 lib 里到底有没有那个缺失的符号有就说明是主工程没链上没有就是 lib 编错了版本。第二条看 lib 声明的默认运行库DEFAULTLIB:LIBCMT表示静态多线程MSVCRT表示动态和主工程对不上就重编。参数上findstr只是过滤实际排查时把输出重定向到文件慢慢看更清楚。这一步的根因几乎都是“配置不一致”不是代码问题所以别急着改源码。3. 解析中文变问号字符集与编码的三层错位编译链接都通了程序跑起来JSON 里的name:张三解析出来变成name:??或者一串方块。这是 VC6 调 JSONCPP 最经典的故障也是标题里“防乱码”要解决的核心。根因不是单点而是源文件编码、编译器字符集、JSONCPP 内部std::string处理三层错位叠加。这一章按层拆开每层给出验证方法和改法。3.1 源文件是 UTF-8 还是 GBK先确认字节流中文乱码排查的第一步永远是确认字节。JSONCPP 的Json::Reader::parse接收的是std::string它不关心编码只按字节搬运。如果你的 JSON 文本是 UTF-8 编码而 VC6 的源文件是 GBK字符串字面量在编译时就已经被转成了 GBK 字节再交给 JSONCPP 解析出来的自然是错的。验证方法很直接把解析前后的字节打出来看十六进制// 打印字符串的十六进制字节确认编码是否符合预期 #include stdio.h #include string void dumpHex(const std::string s) { for (size_t i 0; i s.size(); i) { printf(%02X , (unsigned char)s[i]); } printf(\n); } // 调用示例dumpHex(value.asString());逻辑说明UTF-8 的“张”是E5 BC A0三个字节GBK 的“张”是D5 C5两个字节。打印出来一对比就知道当前字符串到底是什么编码。参数上(unsigned char)强转不能省否则char为负值时%02X会打出FFFFFFxx这种错误结果。这一步是后面所有改法的判断依据别跳过。确认了字节之后如果 JSON 来源是外部接口UTF-8而你的工程内部用 GBK就需要在解析后做一次转码。VC6 下没有现成的std::codecvt可用常见做法是调 Windows API// UTF-8 转 GBK用于 VC6 工程内部显示 #include windows.h #include string std::string utf8ToGbk(const std::string utf8) { int wlen MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, NULL, 0); if (wlen 0) return std::string(); wchar_t* wbuf new wchar_t[wlen]; MultiByteToWideChar(CP_UTF8, 0, utf8.c_str(), -1, wbuf, wlen); int glen WideCharToMultiByte(CP_ACP, 0, wbuf, -1, NULL, 0, NULL, NULL); if (glen 0) { delete[] wbuf; return std::string(); } char* gbuf new char[glen]; WideCharToMultiByte(CP_ACP, 0, wbuf, -1, gbuf, glen, NULL, NULL); std::string result(gbuf); delete[] wbuf; delete[] gbuf; return result; }这段代码走的是“UTF-8 → UTF-16 → 本地代码页”两段转换。CP_UTF8指定源编码CP_ACP指定目标为系统默认代码页中文系统下就是 GBK。-1表示输入以\0结尾函数会自动算长度。两次调用的模式是先传 NULL 拿所需缓冲区大小再分配再转换这是 Windows API 的标准用法。失败时返回空串调用方要判断别直接拿去显示。注意CP_ACP依赖系统区域设置如果程序要跑在不同语言的系统上这里得改成显式的936。3.2 VC6 工程字符集设置_MBCS与_UNICODE的取舍VC6 工程设置里 Preprocessor definitions 常见_MBCS和_UNICODE两个宏它们决定了TCHAR、LPCTSTR这些类型展开成单字节还是宽字符。JSONCPP 内部统一用std::string单字节所以工程里如果定义了_UNICODE你从 JSONCPP 拿到的std::string再往CString、TCHAR里塞就会触发隐式转换中文在这一步丢字节。判断方法看工程设置 Project → Settings → C/C → Preprocessor如果定义了_UNICODE和UNICODE而你又用CString接 JSONCPP 的结果那基本就是这里出的问题。改法有两条路选一条走到底别混。第一条路工程保持_MBCSJSONCPP 的std::string直接转CString// _MBCS 工程下std::string 转 CString 是安全的 std::string name root[name].asString(); CString csName(name.c_str()); // 单字节到单字节不丢字节第二条路工程是_UNICODE那就必须显式转宽字符不能靠隐式转换// _UNICODE 工程下先转宽字符再赋给 CString std::string name root[name].asString(); int wlen MultiByteToWideChar(CP_ACP, 0, name.c_str(), -1, NULL, 0); wchar_t* wbuf new wchar_t[wlen]; MultiByteToWideChar(CP_ACP, 0, name.c_str(), -1, wbuf, wlen); CString csName(wbuf); delete[] wbuf;逻辑说明CP_ACP这里是因为 JSONCPP 出来的std::string已经是 GBK 字节假设你按 3.1 做了转码从 GBK 转宽字符用CP_ACP正确。如果 JSONCPP 出来的是 UTF-8这里要换成CP_UTF8。参数-1同样表示以\0结尾。这一步最容易翻车的地方是“以为CString会自动转”VC6 的CString在_UNICODE下确实有从const char*构造的重载但它内部按CP_ACP转如果字节流不是 GBK转出来就是乱码而且不报错。注意_MBCS和_UNICODE的取舍要在工程级别统一JSONCPP 的 .lib 和主工程必须一致否则链接期还会冒出_T相关的符号冲突。3.3 JSONCPP 内部std::string与CString互转的坑即便字符集设置对了std::string和CString互转仍有细节。CString的GetBuffer返回的是可写缓冲区用完必须ReleaseBuffer否则引用计数错乱std::string的c_str()返回的指针在字符串对象销毁后失效不能长期持有。// CString 转 std::string 的安全写法 CString csText _T(张三); std::string sText; #ifdef _UNICODE int len WideCharToMultiByte(CP_ACP, 0, csText, -1, NULL, 0, NULL, NULL); char* buf new char[len]; WideCharToMultiByte(CP_ACP, 0, csText, -1, buf, len, NULL, NULL); sText buf; delete[] buf; #else sText (LPCTSTR)csText; // _MBCS 下直接取指针 #endif逻辑说明_UNICODE分支走宽字符到 GBK 的转换CP_ACP是目标代码页_MBCS分支直接赋值因为CString内部就是单字节。参数-1表示CString以\0结尾函数自动算长度。这里没有用GetBuffer是因为只读场景下(LPCTSTR)强转更轻量GetBuffer适合需要修改内容的场景。失败时WideCharToMultiByte返回 0要判断len再分配否则new char[0]虽然合法但后续赋值会得到空串掩盖问题。4. 解析成功但取值异常类型判断与空值处理的常见误用中文问题解决后还有一类故障更隐蔽parse返回 trueisMember也 true但asString拿到空串或者asInt拿到 0。这类问题不报错靠日志才能发现排查成本高。这一章把类型判断、空值、数组越界三类误用拆开每类给出可复现的代码和改法。4.1isMember为 true 但asString返回空类型不匹配JSONCPP 的Value是弱类型的asString对非字符串类型会做转换但转换规则和你想的不一样。比如 JSON 里是age: 25数字你调asString()JSONCPP 会返回25这个没问题但如果 JSON 里是name: nullasString()返回空串isString()返回 false而isMember(name)仍然是 true因为键存在。// 取值前先判断类型避免 null 和类型不匹配 Json::Value root; Json::Reader reader; if (!reader.parse(jsonText, root)) { // 解析失败reader.getFormattedErrorMessages() 拿详细错误 return; } if (root.isMember(name) root[name].isString()) { std::string name root[name].asString(); } else { // 键不存在或类型不对走默认值 std::string name ; }逻辑说明isMember只判断键在不在不判断值的类型isString才判断值是不是字符串。两个条件都要缺一个就可能拿到空串或异常转换结果。参数上reader.parse的第二个参数是输出第三个参数可选collectComments老版本默认 true会额外解析注释性能敏感场景可以关掉。失败时getFormattedErrorMessages返回带行号的错误描述比只看返回值有用得多。4.2 数组下标越界与size()的边界判断JSONCPP 的数组用Json::Value的size()拿长度用[i]访问。越界访问不会抛异常而是返回一个 null 值后续asString得到空串问题被吞掉。常见翻车场景是遍历时用而不是// 正确的数组遍历边界用 而不是 const Json::Value items root[items]; for (Json::ArrayIndex i 0; i items.size(); i) { std::string id items[i][id].asString(); // 处理每个元素 }逻辑说明Json::ArrayIndex是 JSONCPP 定义的无符号整型用int在超大数组时可能溢出虽然实际场景少见但类型对齐能避免警告。size()返回元素个数下标范围是0到size()-1用会多访问一个拿到 null。参数上items[i]返回的是引用别对它取地址长期持有root销毁后引用失效。如果数组元素本身可能是 null还要在循环内加items[i].isObject()判断。4.3 大整数精度丢失asInt与asDouble的选择JSON 里的数字没有整数和浮点之分JSONCPP 内部用double存超过 2^53 的整数会丢精度。如果你的 JSON 里有订单号、时间戳这类大整数用asInt拿到的可能是错的。// 大整数用字符串字段承载避免 double 精度丢失 // JSON: {orderId: 1234567890123456789} std::string orderId root[orderId].asString(); // 按字符串取不丢精度 // 如果 JSON 里是数字类型只能接受精度损失或用 int64 分支 #if JSONCPP_HAS_INT64 Json::Int64 bigId root[orderId].asInt64(); #endif逻辑说明asString对数字类型会做格式化转换但double本身已经丢了精度转出来也是错的所以根本办法是让接口方把大整数用字符串传。asInt64只在JSONCPP_HAS_INT64为 1 时可用VC6 下按第 2 章的改法通常是 0所以这条路走不通。参数上asInt返回int32 位超过范围会截断asDouble返回double53 位有效位。选哪个取决于字段语义ID 类一律字符串计数类用asInt够用。5. 避坑清单VC6 调 JSONCPP 的五个血泪教训这一章是踩坑记录每条按“现象 → 原因 → 解决”写都是我在实际工程里遇到过的不是理论推演。VC6 这套环境太老很多问题在新编译器上根本不会出现但老工程维护绕不开记下来能省时间。第一条Debug 能跑 Release 崩链接期符号对不上。现象是 Debug 配置下解析正常切到 Release 一运行就崩在Json::Value的析构。原因是 JSONCPP 的 .lib 用 Debug 运行库编的主工程 Release 用另一套std::string的内存布局在两种运行库下不一致析构时释放了错误的堆。解决是把 JSONCPP 源码直接加进主工程一起编不单独出 .lib让运行库设置强制一致如果必须用 .lib就编两份Debug 配 DebugRelease 配 Release工程设置里 Runtime Library 逐项核对。第二条中文在日志里正常写进文件变乱码。现象是界面上显示“张三”没问题fwrite到文件再用记事本打开是乱码。原因是界面走的是CString的宽字符渲染文件写入用的是std::string的 GBK 字节而记事本默认按 UTF-8 猜编码。解决是写文件前统一转 UTF-8或者写完后用支持 GBK 的编辑器验证。根因是“显示正常”不等于“字节正确”第 3.1 节的十六进制打印要养成习惯。第三条parse返回 false 但错误信息是空的。现象是解析失败getFormattedErrorMessages返回空串不知道错在哪。原因是 JSONCPP 老版本的Reader在构造时如果没开collectComments某些错误路径不记录详细信息。解决是构造Json::Reader reader(Json::Features::all())或者升级到带getFormattedErrorMessages完整实现的版本再不行就在parse前把jsonText的前 200 字节打进日志人工看结构。第四条多线程下解析偶发崩溃。现象是单线程跑一万次没事多线程跑几百次崩一次崩的位置不固定。原因是 JSONCPP 的Json::Value引用计数不是线程安全的多个线程共享同一个Value做读写会竞争。解决是每个线程用自己的Reader和Value解析完再合并如果必须共享外面加锁锁的粒度覆盖整个解析和取值过程别只锁parse。第五条工程能编过换台机器就报C1083。现象是本机编译正常拷到另一台开发机报找不到json/json.h。原因是 include 路径用了绝对路径或者依赖了本机某个目录下的兼容头。解决是把 JSONCPP 源码目录放进工程相对路径Additional include directories 用..\thirdparty\jsoncpp\include这种相对写法兼容头跟着源码走别放系统目录。提示这五条里前两条出现频率最高建议新接手的工程先按这两条自查一遍能排掉大半“玄学”问题。6. 快速定位从报错到根因的排查路径与验证习惯故障排查到最后拼的不是知道多少改法而是能不能在十分钟内把范围缩到一层。VC6 调 JSONCPP 的问题我一般按“编译期 → 链接期 → 运行期 → 编码层”四段走每段有固定的验证动作不靠猜。编译期看第一个报错别被后面的连带错误带偏。VC6 的报错经常一个头文件缺失引发几十条C2065真正的根因只有第一条C1083。把输出重定向到文件从第一条开始改改一条编一次别一次改十处。链接期用dumpbin对符号前面 2.3 节给过命令。核心判断是“符号在不在 lib 里”和“运行库设置一致不一致”两个问题分开查别混在一起改配置。运行期先确认parse的返回值和错误信息再确认取值的类型判断。我习惯在解析入口加一段固定日志// 解析入口的固定日志出问题先看这里 Json::Reader reader; Json::Value root; bool ok reader.parse(jsonText, root); if (!ok) { printf([JSON] parse failed: %s\n, reader.getFormattedErrorMessages().c_str()); printf([JSON] raw head: %.200s\n, jsonText.c_str()); return; } printf([JSON] parse ok, keys%d\n, root.size());这段日志的价值在于失败时给出错误详情和原始文本头部成功时给出顶层键数量。键数量对不上说明 JSON 结构和预期不符问题在数据源不在解析代码。参数上%.200s限制打印长度避免大 JSON 刷屏root.size()对 object 返回键数对 array 返回元素数对基本类型返回 0看日志时要注意区分。编码层用十六进制打印3.1 节的dumpHex是标配。判断标准就两条UTF-8 的中文是三字节且首字节 E0GBK 的中文是两字节且首字节 81。对不上就往上追是源文件编码问题还是转码函数用错了代码页。故障阶段典型报错第一动作判断依据编译期C2039 / C2065看第一条报错缺类型还是缺函数链接期LNK2001dumpbin 查符号lib 里有没有、运行库是否一致运行期parse 返回 false打错误信息和原文头部结构问题还是语法问题编码层中文变问号dumpHex 看字节三字节 UTF-8 还是两字节 GBK这张表我贴在工位上用了很久每次卡住先对一遍比翻文档快。从那以后我每次接 VC6 老工程都强制先跑一遍“编译 → 链接 → 解析 → 十六进制”四步验证再动业务代码省下来的时间远比这套流程本身多。希望帮到你。本文还有配套的精品资源点击获取
