簡介面向 VC6.0 開發(fā)者的 JSONCPP 集成資源針對在 Visual C 6.0 環(huán)境下解析、生成 JSON 時常見的中文亂碼問題提供了完整的案例工程與可直接運(yùn)行的程序。壓縮包共 72 個文件整體 3.77MB以頭文件h、源碼cpp、內(nèi)聯(lián)模板inl為核心附帶工程文件dsp/dsw、界面資源rc/ico以及編譯輔助文件obj/sbr并包含一份【重要】使用說明文檔和必讀文本。已有 590 人學(xué)習(xí)下載資源內(nèi)置 jsoncpp-src-0.5.0 源碼無需另行編譯庫文件加入工程即可使用。具體內(nèi)容包括完整的 VC6.0 對話框/控制臺測試案例、中文 UTF-8 編碼處理配置、JSON 解析與序列化的可運(yùn)行演示以及排錯思路。通過使用說明文檔可快速掌握在 VC6.0 中規(guī)避中文亂碼、穩(wěn)定處理 JSON 數(shù)據(jù)的方法對維護(hù)舊系統(tǒng)或?qū)W習(xí)早期 C 項(xiàng)目集成的開發(fā)者尤為實(shí)用。1. 給 VC6.0 補(bǔ)上 JSON 解析能力為什么首選 jsoncpp早該被淘汰的 VC6.0 依然在工控、教學(xué)和存量維護(hù)項(xiàng)目里大量存在而 JSON 已經(jīng)成為設(shè)備接口和配置文件的默認(rèn)交換格式。在 VC6.0 上解析 JSON 有個天然痛點(diǎn)這個古董編譯器只支持 C98 的早期子集很多現(xiàn)代 C 庫根本編不過更不用說 STL 的 wchar_t 支持和編碼處理在 VC6 上表現(xiàn)得極其別扭。jsoncpp 是少有的、能在這個環(huán)境下穩(wěn)定編譯的 C JSON 庫而且它開源、單包可移植、API 足夠直觀適合嵌入式設(shè)備調(diào)試工具和 Windows 老項(xiàng)目里做配置讀寫。這份資源的價值在于把 jsoncpp 的源碼包、工程配置、各種解析和生成案例全部打包好并且專門對中文亂碼做了預(yù)處理拿到手不用再去網(wǎng)上東拼西湊找兼容補(bǔ)丁適合做設(shè)備聯(lián)調(diào)、寫上位機(jī)工具、維護(hù)老系統(tǒng)的從業(yè)者。2. 搭建 VC6.0 的 jsoncpp 環(huán)境頭文件、靜態(tài)庫與工程選項(xiàng)2.1 編譯前的準(zhǔn)備源碼里挑對文件別一股腦全編進(jìn)工程jsoncpp 的源碼從 GitHub 上下下來是一整個倉庫但 VC6.0 的工程不需要那么多文件。我一般只挑src/lib_json目錄下的json_reader.cpp、json_writer.cpp、json_value.cpp三個實(shí)現(xiàn)文件以及include目錄下的json/頭文件目錄。其他如json_tool.h、json_batchallocator.h是這三個文件內(nèi)部依賴的輔助頭不需要額外加入工程編譯時自動帶上。很多人在這一步翻車的原因是直接把整個src目錄拉進(jìn)工程結(jié)果json_reader.cpp里引用了json_batchallocator.h而 VC6 的預(yù)處理器對當(dāng)前文件所在目錄的搜索順序和現(xiàn)代 IDE 不一樣經(jīng)常報“無法打開包含文件”的錯誤。解決辦法是把include目錄在“工具 - 選項(xiàng) - 目錄 - Include files”里加到最前面同時把src/lib_json目錄也加進(jìn)包含路徑這樣三個 cpp 文件無論放在工程的哪個子目錄都能正確找到頭文件。// 在工程設(shè)置里添加包含路徑后頭文件這樣引用即可 #include json/json.h #include iostream #include fstream這段代碼的頭文件引用方式?jīng)Q定了你的工程目錄結(jié)構(gòu)json/json.h意味著你的包含路徑必須指向include目錄這樣編譯器會去include/json/下找json.h。我見過有人把json.h直接拷到工程根目錄再改成#include json.h也能編過但后續(xù)升級源碼包時容易漏掉其他頭文件不建議這么干。如果用的是源碼包里的json/json.h那json/value.h、json/reader.h、json/writer.h、json/features.h這些也會被自動遞歸包含不需要手動逐個添加。2.2 編譯選項(xiàng)的四個關(guān)鍵點(diǎn)C 語言標(biāo)準(zhǔn)、warning 級別和預(yù)處理指令VC6.0 對 C 標(biāo)準(zhǔn)的支持停留在 1998 年之前的水準(zhǔn)比 C98 還要老。jsoncpp 官方源碼為了兼容舊編譯器在json/config.h里做了一些預(yù)處理判斷但 VC6 的_MSC_VER值對應(yīng)的是 1200新版 jsoncpp 的某些分支沒有覆蓋到這個老版本所以需要在工程里強(qiáng)制定義兩個宏來解決。// 在工程設(shè)置 - C/C - Preprocessor definitions 里添加 // _WIN32 // _MSC_VER1200 // JSON_NO_INT64 (如果不需要 64 位整數(shù)解析)第一個宏_WIN32是確認(rèn) Windows 平臺jsoncpp 內(nèi)部有一些平臺相關(guān)的分支沒有這個宏會走 Linux 分支導(dǎo)致std::string的迭代器類型不匹配。_MSC_VER1200是讓編譯器報告自己的版本號jsoncpp 的config.h里有針對_MSC_VER的#if _MSC_VER 1400之類的判斷會啟用一些舊代碼路徑比如禁用long long的格式化輸出。JSON_NO_INT64是可選宏老工程不需要解析超過 32 位整數(shù)的 JSON 時建議加上防止Json::Value內(nèi)部使用json_int_t類型在 VC6 下出現(xiàn)__int64與long long混用問題。Warning 級別我建議設(shè)置在Level 1也就是只顯示嚴(yán)重警告。jsoncpp 的源碼本身能通過 Level 1 編譯但如果有第三方庫一起編譯Level 4 的警告可能刷屏。最煩人的是 VC6 對某些for循環(huán)作用域的處理和標(biāo)準(zhǔn)不一致jsoncpp 源碼里已經(jīng)盡量避免但你真的遇到for loop initial declaration used outside C99 mode之類的提示需要在編譯選項(xiàng)里把Disable Language Extensions關(guān)掉也就是不要勾選“禁用語言擴(kuò)展”。2.3 編譯成靜態(tài)庫還是直接用源碼兩種方式的效率對比在 VC6.0 里使用 jsoncpp 有兩種姿勢把三個 cpp 文件直接加進(jìn)自己的工程一起編譯或者先編譯一個json_lib.lib靜態(tài)庫再用。直接加源碼的方式最簡單但每次編譯整個工程都要重新編譯 jsoncpp 的三個文件工程稍微大一點(diǎn)就浪費(fèi)時間。編靜態(tài)庫的方式一勞永逸但初次配置稍微繁瑣。靜態(tài)庫工程的配置要點(diǎn)新建一個 Win32 Static Library 工程把三個 cpp 文件加進(jìn)去編譯選項(xiàng)和 2.2 節(jié)完全一致然后編譯生成.lib文件。在使用端工程的“鏈接器 - 輸入 - 附加依賴項(xiàng)”里填入這個 lib 的名字和路徑。需要注意VC6 的靜態(tài)庫有單線程版和多線程版之分如果你的使用端工程用的是 Debug Multithreaded那靜態(tài)庫也必須用相同的運(yùn)行時庫選項(xiàng)編譯否則鏈接時會報LNK2005或LNK4098這種符號沖突錯誤。# 鏈接器報錯示例LNK2005 _malloc already defined in LIBCMT.lib # 原因靜態(tài)庫用單線程 CRT(/ML) 編譯而使用端用多線程 CRT(/MT) # 解決在靜態(tài)庫工程設(shè)置里把 Runtime library 改成和使用端一致的選項(xiàng)我一般習(xí)慣直接編靜態(tài)庫特別是在維護(hù)多個老項(xiàng)目的時候一份編譯好的 lib 可以給三四個工程共用。但如果你是第一次調(diào)通 jsoncpp我建議先用直接加源碼的方式跑通代碼邏輯等確認(rèn)沒問題再抽成靜態(tài)庫否則一次出現(xiàn)環(huán)境問題和代碼問題疊加在一起排錯會非常痛苦。3. 基礎(chǔ)解析案例從單層對象到嵌套數(shù)組的實(shí)際用法3.1 讀一個簡單 JSON 對象parse 的三種方式與返回值處理jsoncpp 的Reader類提供三種 parse 重載形式接收 C 字符串、接收std::string、接收std::istream。在 VC6.0 里std::istream重載形式用得最多因?yàn)樵O(shè)備接口經(jīng)常把 JSON 數(shù)據(jù)放在文件流或串口數(shù)據(jù)流里。無論哪種重載第一個參數(shù)是 JSON 數(shù)據(jù)源第二個參數(shù)是接收結(jié)果的Json::Value引用返回bool表示解析是否成功。#include json/json.h #include iostream #include fstream bool parseJsonFile(const char* filePath, Json::Value root) { std::ifstream fin(filePath); if (!fin.is_open()) { std::cerr Cannot open file: filePath std::endl; return false; } Json::Reader reader; bool success reader.parse(fin, root, false); if (!success) { // 用 collectErrors 拿到具體錯誤信息 std::string errMsg reader.getFormatedErrorMessages(); std::cerr Parse error: errMsg std::endl; } fin.close(); return success; }這段代碼演示了標(biāo)準(zhǔn)的三步流程打開文件流、調(diào)用 parse、失敗時取錯誤信息。第三個參數(shù)false表示不收集所有錯誤信息只保留第一條錯誤這樣出錯時能快速定位。getFormatedErrorMessages()在解析失敗時返回包含行列號的錯誤描述這個信息在調(diào)試設(shè)備返回的半截 JSON 數(shù)據(jù)時特別實(shí)用能直接告訴你 JSON 在哪一行哪個位置斷了。有一個容易被忽略的點(diǎn)parse 成功后Json::Value對象里的數(shù)據(jù)如果不及時提取會隨root的生命周期失效。所以解析函數(shù)盡量不要把Json::Value以值方式返回而是用引用參數(shù)傳入或者用智能指針管理。VC6 沒有std::shared_ptr一般用auto_ptr或者直接傳引用的方式我習(xí)慣傳引用代碼更直白也不會在對象拷貝時觸發(fā) jsoncpp 內(nèi)部引用計(jì)數(shù)的隱患。3.2 取字段值的類型判斷isValidMember 與 type 檢查配合設(shè)備返回的 JSON 字段經(jīng)常缺失或者類型不對有些人直接root[temperature].asDouble()取完之后才發(fā)現(xiàn)數(shù)據(jù)是字符串類型的23.5asDouble 返回 0排查半天。jsoncpp 的Value::isMember()方法只判斷字段是否存在不判斷類型對不對。更穩(wěn)妥的寫法是先判斷類型再決定怎么取值。bool readTemperature(const Json::Value root, double temp) { const char* fieldName temperature; if (!root.isMember(fieldName)) { std::cerr Field missing: fieldName std::endl; return false; } const Json::Value field root[fieldName]; if (field.isDouble() || field.isInt()) { temp field.asDouble(); return true; } else if (field.isString()) { temp atof(field.asCString()); return true; } std::cerr Field type mismatch: fieldName type field.type() std::endl; return false; }這段代碼體現(xiàn)的是防御式解析思路先檢查字段存在性再檢查類型字符串?dāng)?shù)字也用atof兜底轉(zhuǎn)換。field.type()返回一個枚舉值Json::intValue為 0、uintValue為 1、realValue為 2、stringValue為 3 等等把這些值打印出來排查非常直觀。另外注意field.isInt()在 VC6 下對 32 位整數(shù)有效如果你開啟了JSON_NO_INT64宏那isInt64()方法根本不存在不要去調(diào)用否則編譯直接報錯。3.3 解析嵌套數(shù)組數(shù)組遍歷與對象數(shù)組的混合使用解析數(shù)組的核心是size()方法和operator[]的整數(shù)重載。jsoncpp 的數(shù)組可以用for (Json::Value::const_iterator it arr.begin(); it ! arr.end(); it)這種迭代器方式遍歷但在 VC6.0 下迭代器的operator*返回Value的引用類型類型推斷不如現(xiàn)代 C 靈活容易在賦值時多一次拷貝所以直接用索引遍歷更省心。struct SensorPoint { int id; double value; char name[32]; }; bool parseSensorArray(const Json::Value root, SensorPoint* points, int maxCount, int outCount) { if (!root.isMember(sensors) || !root[sensors].isArray()) { std::cerr sensors is not array std::endl; return false; } const Json::Value sensors root[sensors]; outCount 0; int n sensors.size(); if (n maxCount) { std::cerr Array too large: n maxCount std::endl; return false; } for (int i 0; i n; i) { const Json::Value item sensors[i]; if (!item.isObject()) continue; points[i].id item.get(id, -1).asInt(); points[i].value item.get(value, 0.0).asDouble(); strncpy(points[i].name, item.get(name, ).asCString(), 31); points[i].name[31] \0; outCount; } return true; }這里的item.get(id, -1)是 jsoncpp 提供的一個很有價值的方法第二個參數(shù)是默認(rèn)值字段不存在時直接返回默認(rèn)值不需要像 3.2 節(jié)那樣先isMember再取。但默認(rèn)值只保證字段缺失時不崩字段存在但類型不對時get返回的Value還是錯的值所以對可靠性要求高的字段建議先用isMember檢查。數(shù)組遍歷的邊界條件值得注意sensors.size()返回Json::ArrayIndex類型在 VC6 下是unsigned int和int比較時注意符號問題我寫int n sensors.size()時編譯器會提示符號轉(zhuǎn)換警告直接強(qiáng)轉(zhuǎn)即可。4. 生成 JSON 數(shù)據(jù)對象構(gòu)造、寫入文件與格式化控制4.1 用 Value 對象構(gòu)造嵌套結(jié)構(gòu)Value 的鏈?zhǔn)劫x值原理構(gòu)造 JSON 輸出比解析要友善得多。jsoncpp 的Json::Value重載了operator[]對不存在的字段名會自動創(chuàng)建對應(yīng)類型的 Value 對象所以可以一層一層地往里塞數(shù)據(jù)。核心邏輯是先創(chuàng)建Value對象然后用[key]的方式賦值數(shù)組用append方法添加元素。Json::Value buildStatusReport() { Json::Value root; root[device_id] DEV-2024-001; root[status] online; root[uptime] 3600; // 嵌套對象直接鏈?zhǔn)皆L問子節(jié)點(diǎn) root[network][ip] 192.168.1.100; root[network][mac] AA:BB:CC:DD:EE:FF; // 數(shù)組先創(chuàng)建空數(shù)組再 append Json::Value sensorList; for (int i 0; i 3; i) { Json::Value item; item[index] i; item[value] i * 1.5; sensorList.append(item); } root[sensors] sensorList; return root; }這里的鏈?zhǔn)劫x值root[network][ip] 192.168.1.100看起來像簡單嵌套實(shí)際上內(nèi)部執(zhí)行了兩個步驟第一步root[network]創(chuàng)建一個空的 Value 對象并返回引用第二步在這個引用上再取[ip]并賦值。這種寫法的潛在風(fēng)險是如果你拼錯了中間層鍵名不會報錯而是自動創(chuàng)建一個新的空對象最終生成的 JSON 里會出現(xiàn)多余的層級。所以寫完構(gòu)造代碼后最好跑一遍流程把生成的 JSON 打印出來人工確認(rèn)結(jié)構(gòu)。4.2 縮進(jìn)與換行設(shè)置StyledWriter 還是 FastWriterjsoncpp 提供兩個 Writer 類FastWriter輸出緊湊格式不帶多余空格和換行StyledWriter輸出帶縮進(jìn)的格式化文本便于人讀。設(shè)備對接時我一般用FastWriter因?yàn)槭×髁慷液芏嗲度胧皆O(shè)備解析器對空白字符處理比較弱。寫配置文件時用StyledWriter方便人工修改。std::string valueToStyledString(const Json::Value value) { Json::StyledWriter writer; return writer.write(value); } std::string valueToFastString(const Json::Value value) { Json::FastWriter writer; return writer.write(value); }兩個 Writer 的write方法都返回std::string而且是拷貝返回不是引用所以函數(shù)返回值直接賦給外部字符串沒問題。有一個隱蔽坑FastWriter默認(rèn)會在輸出末尾加一個換行符\n這是為了讓輸出適合寫入文件。如果你要把 JSON 拼進(jìn)網(wǎng)絡(luò)協(xié)議幀里需要手動pop_back()或者用字符串裁剪去掉末尾換行。同理StyledWriter輸出末尾也有換行但它的末尾換行是縮進(jìn)格式的一部分保留比較合理。4.3 中文內(nèi)容的輸出編碼統(tǒng)一std::string 與 UTF-8 的約定這是 jsoncpp 在 VC6.0 場景下最容易出問題的章節(jié)。jsoncpp 內(nèi)部的所有字符串處理都按 UTF-8 字節(jié)流理解它不會做編碼轉(zhuǎn)換。你的程序里如果直接寫中文字符串字面量比如value[name] 溫度傳感器那這個字符串在 VC6 的源碼里是按本地代碼頁中文系統(tǒng)下是 GBK存儲的字節(jié)序列jsoncpp 會把它原樣寫入 JSON 字符串值里不做任何轉(zhuǎn)譯。把這個 JSON 輸出到任何一個按 UTF-8 解析的設(shè)備或網(wǎng)頁時中文就亂碼了。// 錯誤示范直接賦值中文字面量 value[name] 溫度傳感器; // 字符串內(nèi)是 GBK 字節(jié) // 正確示范先轉(zhuǎn)成 UTF-8 字節(jié)序列再賦值 value[name] gbkToUtf8(溫度傳感器);這段代碼的gbkToUtf8函數(shù)在資源包里有獨(dú)立的實(shí)現(xiàn)核心原理是先用MultiByteToWideChar把 GBK 字節(jié)轉(zhuǎn)成 UTF-16 的寬字符再用WideCharToMultiByte把寬字符轉(zhuǎn)成 UTF-8 字節(jié)。VC6 的源碼文件默認(rèn)是 GBK 編碼所以字符串字面量天然是 GBK 字節(jié)流。資源里給的做法是所有中文輸入統(tǒng)一經(jīng)過這個轉(zhuǎn)換函數(shù)所有從 JSON 里讀出來的中文字符串如果要顯示到 Windows 窗口也要反向轉(zhuǎn)成 GBK。5. 解析中文內(nèi)容實(shí)例GBK 與 UTF-8 的字節(jié)層面換算5.1 中文亂碼的根本原因源碼編碼、執(zhí)行編碼與 JSON 編碼的三方不一致解決中文亂碼的關(guān)鍵不在于 jsoncpp而在于把三個環(huán)節(jié)的編碼理順。第一個環(huán)節(jié)是 VC6 源碼文件里的字符串字面量編碼中文 Windows 系統(tǒng)上默認(rèn)是 GBK第二個環(huán)節(jié)是程序運(yùn)行時字符串在內(nèi)存里的編碼字面量是什么字節(jié)存進(jìn)去就是什么字節(jié)第三個環(huán)節(jié)是 jsoncpp 解析和生成的 JSON 數(shù)據(jù)要求是 UTF-8。這三個環(huán)節(jié)只要有兩個不一致就會出現(xiàn)亂碼。我遇到過的典型場景是設(shè)備端上報的 JSON 數(shù)據(jù)是 UTF-8 編碼的設(shè)備名稱:溫度計(jì)解析到Value對象里是正常的 UTF-8 字節(jié)然后用 StyledWriter 打印到屏幕上調(diào)試控制臺按 GBK 顯示亂碼。這不是 jsoncpp 的問題是調(diào)試輸出環(huán)節(jié)的編碼沒轉(zhuǎn)換。反過來程序里硬編碼的中文寫入 JSON 再發(fā)給設(shè)備設(shè)備按 UTF-8 解碼同樣亂碼。所以整個數(shù)據(jù)處理鏈路里任何涉及外部接口的字符串都必須明確標(biāo)注是 UTF-8 還是 GBK。5.2 源頭修復(fù)用 UTF-8 編碼保存源文件直接從編譯期統(tǒng)一一個能根治部分問題的土辦法在 VC6 里把包含中文字面量的源文件保存成 UTF-8 with BOM 編碼。VC6 的編譯器對 UTF-8 with BOM 的源代碼文件會把字符串字面量按 UTF-8 字節(jié)存入目標(biāo)文件也就是說運(yùn)行時內(nèi)存里的字節(jié)已經(jīng)和 JSON 要求的 UTF-8 一致了。這樣代碼里直接寫value[name] 溫度傳感器也不會亂碼。但這個做法有三個副作用需要注意。第一VC6 的編輯器對 UTF-8 with BOM 的支持不完整打開文件時可能亂碼顯示但不影響編譯結(jié)果。第二如果代碼里同時有 GBK 編碼的源文件和 UTF-8 編碼的源文件字符串拼接時會出現(xiàn)半個中文的奇怪字節(jié)排查很困難。第三資源包里自帶的示例代碼有些是 GBK 編碼保存的你如果混用需要在工程設(shè)置里區(qū)分不能一刀切。// 用 UTF-8 with BOM 保存源文件后字面量本身已是 UTF-8 // 可以直接賦值不需要運(yùn)行時轉(zhuǎn)換 value[device_name] 溫度傳感器; // 但控制臺輸出仍需轉(zhuǎn)換UTF-8 - GBK std::string name value[device_name].asString(); std::string displayName utf8ToGbk(name.c_str()); printf(%s\n, displayName.c_str());注意這段代碼里的utf8ToGbk是資源包提供的反向轉(zhuǎn)換函數(shù)和 4.3 節(jié)的gbkToUtf8正好是互逆操作。采用 UTF-8 源文件方案時控制臺輸出前需要做utf8ToGbk轉(zhuǎn)換否則調(diào)試窗口還是亂碼。這個方案的好處是省掉了寫入 JSON 前的轉(zhuǎn)換步驟缺點(diǎn)是所有的調(diào)試輸出都要帶轉(zhuǎn)換沒有哪種方案是絕對省事的關(guān)鍵是統(tǒng)一。5.3 運(yùn)行時動態(tài)轉(zhuǎn)換的完整案例解析設(shè)備上報的 UTF-8 中文 JSON大多數(shù)智能設(shè)備的 JSON 都是 UTF-8 編碼所以解析端需要把 UTF-8 轉(zhuǎn)成 GBK 才能正常顯示或?qū)懭氡镜財(cái)?shù)據(jù)庫。下面這個函數(shù)讀取設(shè)備返回的文件解析后把中文內(nèi)容轉(zhuǎn)成 GBK 再打印完整的處理鏈路如下。std::wstring utf8ToUnicode(const char* utf8Str) { int len MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, NULL, 0); wchar_t* buffer new wchar_t[len]; MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, buffer, len); std::wstring result(buffer); delete[] buffer; return result; } std::string unicodeToGbk(const wchar_t* wideStr) { int len WideCharToMultiByte(CP_ACP, 0, wideStr, -1, NULL, 0, NULL, NULL); char* buffer new char[len]; WideCharToMultiByte(CP_ACP, 0, wideStr, -1, buffer, len, NULL, NULL); std::string result(buffer); delete[] buffer; return result; } std::string utf8ToGbk(const char* utf8Str) { std::wstring unicodeStr utf8ToUnicode(utf8Str); return unicodeToGbk(unicodeStr.c_str()); }這三個函數(shù)形成了完整的轉(zhuǎn)換鏈路UTF-8 字節(jié)先轉(zhuǎn)成 UTF-16 寬字符再由寬字符轉(zhuǎn)成系統(tǒng) ANSI 編碼即 GBK。MultiByteToWideChar和WideCharToMultiByte是 Windows APIVC6 完全支持不需要額外鏈接庫kernel32 默認(rèn)已導(dǎo)入。每次轉(zhuǎn)換都要先調(diào)用一次函數(shù)拿緩沖區(qū)長度再分配內(nèi)存做第二次調(diào)用這是 Windows 編碼轉(zhuǎn)換的標(biāo)準(zhǔn)套路。注意返回值里的-1表示輸入字符串以 null 結(jié)尾函數(shù)會處理結(jié)尾字符你不需要手動截?cái)唷?. 避坑實(shí)測記錄VC6 jsoncpp 的編譯期與運(yùn)行期暗礁6.1 鏈接錯誤 LNK2005CRT 庫版本沖突現(xiàn)象工程編譯通過鏈接時報LNK2005 _malloc already defined in LIBCMT.lib有時還會伴隨LNK4098警告。原因jsoncpp 編譯成靜態(tài)庫時用的運(yùn)行庫選項(xiàng)和使用端工程不一致。VC6 的 C 運(yùn)行時庫有單線程/ML、多線程/MT、多線程調(diào)試/MTd、動態(tài)鏈接/MD等模式靜態(tài)庫如果用了 /ML符號定義在 LIBCMT.lib 和 LIBCD.lib 里各有一份鏈接時就會沖突。解決在 jsoncpp 靜態(tài)庫工程和使用端工程里把Project - Settings - C/C - Code Generation - Use run-time library改成完全相同的選項(xiàng)。我一般統(tǒng)一用Debug Multithreaded做調(diào)試版Release Multithreaded做發(fā)布版。改完重新編譯兩個工程問題消失。6.2 解析返回 false 且錯誤信息指向第一行BOM 頭作怪現(xiàn)象用reader.parse解析從文件讀入的 JSON 時返回falsegetFormatedErrorMessages報line 1, column 1附近有非法字符但用文本編輯器查看 JSON 文件完全正常。原因JSON 文件被 Windows 記事本或其他編輯器保存成了帶 UTF-8 BOM 的格式文件頭部多出 3 個字節(jié)EF BB BFjsoncpp 解析器不認(rèn) BOM把它當(dāng)成非法字符。解決解析前對文件流做 BOM 檢測和剝離。讀文件后檢查前三個字節(jié)是否是0xEF 0xBB 0xBF是則跳過。或者用std::ifstream打開文件后先fin std::ws不能跳過 BOM BOM 不是空白符需要手動處理。資源包里的讀文件函數(shù)已經(jīng)內(nèi)置了 BOM 剝離邏輯但如果你自己寫解析函數(shù)記得加上。6.3 解析大文件時程序崩潰遞歸深度與內(nèi)存分配現(xiàn)象解析一個幾十層嵌套的 JSON 文件或者數(shù)組長度超過幾千時程序直接崩潰沒有異常信息。原因jsoncpp 在舊版本里解析嵌套層級過深的對象時遞歸調(diào)用會導(dǎo)致棧溢出數(shù)組過大時append操作頻繁重新分配內(nèi)存VC6 的默認(rèn)堆管理器效率低而且容易產(chǎn)生內(nèi)存碎片。jsoncpp 對解析深度沒有硬限制但運(yùn)行時棧只有 1MB。解決一是限制 JSON 的嵌套層級設(shè)備協(xié)議里明確約定不超過 10 層二是解析前用Json::Reader::getFeatures()里的strictRoot選項(xiàng)把根節(jié)點(diǎn)必須是對象或數(shù)組這一約束打開防止根節(jié)點(diǎn)是數(shù)字或字符串這種非法 JSON 被解析三是如果 JSON 體量很大改用Json::CharReader新版接口配合std::istream流式解析不要一次把整個文件讀入內(nèi)存。6.4 中文轉(zhuǎn)出來的 JSON 在設(shè)備端顯示成 UTF-8 亂碼現(xiàn)象本機(jī)解析和生成 JSON 一切正常但把 JSON 發(fā)到設(shè)備或上傳到 Web 服務(wù)端后中文變成一堆亂碼而且不是\uXXXX形式。原因數(shù)據(jù)在電腦和服務(wù)端之間傳輸時代碼用的是 GBK 字節(jié)串但沒聲明編碼服務(wù)端默認(rèn)按 UTF-8 解碼或者反過來。jsoncpp 在生成 JSON 時不會做轉(zhuǎn)義中文字符如果以原始 UTF-8 字節(jié)寫入字符串值傳輸層再用 GBK 讀就亂碼。解決在 HTTP 或 TCP 協(xié)議頭里明確charsetutf-8并確保發(fā)送前字符串是 UTF-8 字節(jié)。排查時用一個十六進(jìn)制查看器看字符串的第一個字節(jié)0xE4開頭是 UTF-8中文通常以 E4-E9 開頭0xC4或0xD6開頭是 GBK。資源包里的案例工程自帶這個排查工具函數(shù)打印每個中文字符的十六進(jìn)制值。6.5 用 StyledWriter 輸出后字符串被截?cái)嗷騼?nèi)容偏移現(xiàn)象StyledWriter寫出的 JSON 字符串復(fù)制到別的編輯器里偶爾出現(xiàn)內(nèi)容偏移字符串值的末尾少了一個字符或者轉(zhuǎn)義符號被吞掉。原因VC6 的std::string和 C 字符串 API 混用。StyledWriter::write返回的std::string在寫入文件時用了fwrite(str.c_str(), 1, str.length(), fp)但 c_str() 返回的指針可能在后續(xù)字符串對象析構(gòu)時失效如果你先保存了指針再用就等于野指針。解決凡是 Writer 的輸出一律立即用std::string的值拷貝到自己的變量里不要長期持有const char*。寫入文件的長度用str.length()而不是strlen(str.c_str())因?yàn)?JSON 字符串內(nèi)可能包含\0轉(zhuǎn)義序列的存儲形式strlen會提前截?cái)?。這些細(xì)節(jié)在 VC6 的老標(biāo)準(zhǔn)下特別容易踩現(xiàn)代 C 里 std::string 的優(yōu)化策略反而讓這些問題不容易暴露。7. 最后的技巧把中文轉(zhuǎn)換封裝成工程級的全局工具收尾要落地一個能直接抄走的東西。資源包里已經(jīng)附帶了一個獨(dú)立的工具模塊叫encoding_util.cpp把 5.3 節(jié)里的 UTF-8 與 GBK 互轉(zhuǎn)函數(shù)封裝成了CEncodingUtil靜態(tài)類并且加了一個自動識別函數(shù)傳入一個std::string先看字節(jié)特征判斷是否為 UTF-8是則轉(zhuǎn) GBK否則原樣返回。這個函數(shù)在調(diào)試串口設(shè)備數(shù)據(jù)時特別實(shí)用因?yàn)橛行┰O(shè)備的固件版本不同輸出的 JSON 編碼不統(tǒng)一用自動識別可以少寫很多分支判斷。std::string CEncodingUtil::AutoToGbk(const std::string input) { // 判斷是否為 UTF-8 編碼 bool isUtf8 true; const unsigned char* data (const unsigned char*)input.c_str(); int len (int)input.length(); int i 0; while (i len) { if (data[i] 0x80) { i; // ASCII 范圍直接跳過 } else if ((data[i] 0xE0) 0xC0 i 1 len) { if ((data[i1] 0xC0) ! 0x80) { isUtf8 false; break; } i 2; } else if ((data[i] 0xF0) 0xE0 i 2 len) { if ((data[i1] 0xC0) ! 0x80 || (data[i2] 0xC0) ! 0x80) { isUtf8 false; break; } i 3; } else { isUtf8 false; break; } } if (isUtf8 len 0) { return utf8ToGbk(input.c_str()); } return input; }這個自動識別函數(shù)不算百分之百準(zhǔn)確但對于常見的中文場景足夠。UTF-8 的多字節(jié)序列有嚴(yán)格的比特位模式GBK 的編碼空間和它有部分重疊極少數(shù)情況下會有誤判但概率極低。把這個函數(shù)放在公共模塊里所有項(xiàng)目共用一份比每個 cpp 文件里各寫各的轉(zhuǎn)換函數(shù)要靠譜得多。驗(yàn)證轉(zhuǎn)換是否正確的方法也很簡單調(diào)用Json::StyledWriter把生成的 JSON 打印出來在 VC6 的 Output 窗口里如果中文顯示正常說明內(nèi)存中的字節(jié)已經(jīng)是 GBK如果在 Output 窗口亂碼但文件內(nèi)容正常說明是 UTF-8。也可以用資源里帶的一個小工具函數(shù)PrintHex把字符串每個字節(jié)的十六進(jìn)制打出來對照 ASCII 表查看E4 B8 AD是“中”的 UTF-8 編碼D6 D0是“中”的 GBK 編碼一眼就能分辨當(dāng)前串是什么編碼。資源包里所有的示例工程默認(rèn)已經(jīng)做了三件事源文件統(tǒng)一保存為 UTF-8 with BOM、工程編譯選項(xiàng)預(yù)置了_MSC_VER1200和JSON_NO_INT64、所有讀取 JSON 文件的入口都做了 BOM 剝離。你拿到手以后第一件事不是改代碼而是先跑通自帶的 Demo 工程確認(rèn)你的 VC6 環(huán)境和資源包配置一致再往自己的工程里遷移。從那以后我每次在 VC6 里接入 jsoncpp都強(qiáng)制自己先跑一遍編碼自檢函數(shù)再動業(yè)務(wù)代碼這么多年再沒因?yàn)閬y碼翻過車。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取