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