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