簡介HexEdit是一款基于VC開發(fā)的十六進(jìn)制編輯控件面向需要直接讀寫、搜索、替換二進(jìn)制文件的Windows桌面開發(fā)者適用于軟件調(diào)試、數(shù)據(jù)恢復(fù)、逆向工程及自定義文件解析等場景?？丶峁╇p視圖編輯界面可同時(shí)展示二進(jìn)制與ASCII字符支持插入、刪除、查找、替換等基礎(chǔ)操作同時(shí)具備高亮顯示、文件解析與文檔/視圖框架便于開發(fā)者理解控件內(nèi)部機(jī)制并進(jìn)行二次擴(kuò)展。壓縮包共53個(gè)文件以h/cpp源碼為主包含演示工程、項(xiàng)目工程文件sln/vcxproj、資源定義文件rc/ico以及htm升級(jí)說明等文檔還附帶編譯生成的exe、obj、pdb等可執(zhí)行與中間文件包體約2.02MB整體目錄結(jié)構(gòu)清晰適合對(duì)照源碼學(xué)習(xí)和調(diào)試。借助完整的示例程序與控制臺(tái)測試對(duì)話框可直接查看HexEditCtrl的接口調(diào)用、高亮設(shè)置、文件讀寫流程和工程組織方式對(duì)評(píng)估十六進(jìn)制編輯能力的開發(fā)者有實(shí)用價(jià)值。目前已有97人學(xué)習(xí)下載適合正在準(zhǔn)備在VC項(xiàng)目中嵌入二進(jìn)制編輯功能的中高級(jí)開發(fā)者參考。1. 把二進(jìn)制編輯器塞進(jìn)自己的界面別從零造輪子用十六進(jìn)制編輯器扒過別人的固件、修過損壞的文件頭、或者對(duì)著通訊報(bào)文找過錯(cuò)位字節(jié)的人應(yīng)該都體會(huì)過這種別扭系統(tǒng)里的十六進(jìn)制工具確實(shí)好用但它永遠(yuǎn)是一個(gè)獨(dú)立窗口沒法嵌進(jìn)你自己正在開發(fā)的調(diào)試器、協(xié)議分析器或者上位機(jī)軟件里。這份資源解決的就是這個(gè)痛點(diǎn)——它是一套可直接編譯進(jìn) VC 工程的 hexedit 十六進(jìn)制編輯控件源碼不是命令行工具也不是獨(dú)立 exe而是能像普通控件一樣放進(jìn)你的對(duì)話框、屬性頁、甚至 SDI 界面里的可編輯組件。適合的人群很明確做嵌入式上位機(jī)、固件分析工具、網(wǎng)絡(luò)報(bào)文解析器以及任何需要在自家軟件里直接查看和修改二進(jìn)制數(shù)據(jù)的一線開發(fā)者。它把地址欄、十六進(jìn)制區(qū)、ASCII 區(qū)、查找、字節(jié)編輯這些基礎(chǔ)能力一次性給你省掉從零寫一個(gè)編輯器的全部工作。2. 控件是拿來用的場景判斷、能力邊界與選型理由2.1 這種東西和獨(dú)立十六進(jìn)制編輯器有什么不一樣理解這個(gè)控件的定位關(guān)鍵是搞清楚它和完整十六進(jìn)制編輯器之間的差別。獨(dú)立工具比如你平時(shí)用的那些綠色小軟件通常把整套功能綁在一起文件關(guān)聯(lián)、大文件映射、磁盤扇區(qū)讀取、腳本批量替換。而這類源碼控件走的是相反的路——它只提供一塊可以交互的區(qū)域渲染十六進(jìn)制字節(jié)流、處理鍵盤鼠標(biāo)事件讓你在對(duì)話框里擺放它就像擺放一個(gè) Edit 控件那樣。它內(nèi)部做的是數(shù)據(jù)管理你自己決定數(shù)據(jù)從哪來、改完之后往哪寫。所以選型之前先做一個(gè)判斷你的需求是“把某個(gè)文件完整地打開讓用戶改”還是“在程序里某一塊數(shù)據(jù)需要可視化和就地修改”如果是前者直接用成熟獨(dú)立工具就行如果是后者這份資源才有價(jià)值。舉個(gè)例子我在做某個(gè)通訊調(diào)試工具時(shí)需要把收到的數(shù)據(jù)幀以十六進(jìn)制展示在界面下方同時(shí)允許手工修改某個(gè)字節(jié)重新組包——這種情況獨(dú)立編輯器根本接不進(jìn)來控件方案是唯一合理的路。資源本身的編輯控件形態(tài)一般會(huì)拆成三層結(jié)構(gòu)最左側(cè)是地址欄顯示偏移量中間是十六進(jìn)制區(qū)每個(gè)字節(jié)占兩字符寬度空白分隔可以光標(biāo)定位最右側(cè)是 ASCII/字符區(qū)。三層聯(lián)動(dòng)滾動(dòng)是這類控件的基本功拿到源碼后先確認(rèn)三層列寬和字體渲染是否固定這決定了后續(xù)定制量。2.2 明確邊界大文件、連續(xù)流和稀疏數(shù)據(jù)誰不適合控件擅長的是中等規(guī)模的塊狀數(shù)據(jù)編輯。我的經(jīng)驗(yàn)是單文件控制在幾十兆字節(jié)以內(nèi)體驗(yàn)最好。超過這個(gè)量級(jí)滾動(dòng)、查找、撤銷三塊的性能會(huì)明顯吃力因?yàn)閮?nèi)存里的數(shù)據(jù)副本和繪制刷新是同步開銷的。還有一個(gè)容易被忽略的邊界連續(xù)字節(jié)流。如果數(shù)據(jù)是實(shí)時(shí)不間斷到達(dá)的比如串口抓包每分鐘幾千幀那它不適合直接當(dāng)監(jiān)控視圖——它本質(zhì)上是“靜態(tài)數(shù)據(jù)編輯器”不適合做流式追加。數(shù)據(jù)到達(dá)后先積累成緩沖區(qū)再一次性加載進(jìn)去或者做成定時(shí)快照刷新這才符合控件的設(shè)計(jì)前提。另外稀疏數(shù)據(jù)和大空洞比如磁盤鏡像里大量 0xFF 填充區(qū)也很考驗(yàn)控件的壓縮策略。有些控件實(shí)現(xiàn)里對(duì)連續(xù)重復(fù)字節(jié)做了折疊顯示有些沒有。拿到這份資源后可以先拿一個(gè)幾十兆的鏡像文件試試滾動(dòng)流暢度再?zèng)Q定是否需要修改數(shù)據(jù)存儲(chǔ)層。2.3 集成路徑選哪種對(duì)話框、屬性頁還是子窗口實(shí)際接入時(shí)一般有三條路可以走挑哪條取決于你的工程框架。第一種也是最常見的一種放進(jìn) MFC 對(duì)話框直接在資源編輯器里畫一個(gè) Custom Control 占位區(qū)域初始化時(shí)把控件位置鋪滿這個(gè)區(qū)域。這條路改動(dòng)最小適合工具類軟件的上位機(jī)界面。第二種放進(jìn)屬性頁P(yáng)ropertySheet的某一頁里適合做“數(shù)據(jù)查看是軟件中一個(gè)標(biāo)簽頁”的產(chǎn)品形態(tài)。屬性頁的字體環(huán)境、背景色和對(duì)話框有些差異需要注意背景刷新的問題。第三種放到普通子窗口里通過 Create 指定父窗口句柄適合非 MFC 框架比如 Win32 SDK WTL或者想在分割窗口里動(dòng)態(tài)布局的場景。這種路徑自由度最高但也需要你這個(gè)控件容器本身支持窗口消息轉(zhuǎn)發(fā)——它的鼠標(biāo)滾輪、鍵盤消息都要正確到達(dá)子窗口。我的建議是只要工程是 MFC 對(duì)話框或文檔視圖結(jié)構(gòu)就走第一種如果是插件形式或有復(fù)雜的動(dòng)態(tài)布局需求走第三種。別上來就選第三種會(huì)多繞一層窗口管理和消息反射的排查工作量。3. 從源碼到裝入你的對(duì)話框編譯、創(chuàng)建與首屏加載3.1 編譯前必須做的三個(gè)確認(rèn)把資源包解壓之后不要急著往工程里拖文件。先花十分鐘確認(rèn)三件事能省掉后面一整個(gè)下午的排查時(shí)間。第一確認(rèn)字符集設(shè)置?，F(xiàn)在的 VS 工程默認(rèn)是 Unicode而這類老控件源碼很可能在 ANSI 時(shí)代寫的或者相反。進(jìn)工程屬性 - 常規(guī) - 字符集看當(dāng)前用的是“使用 Unicode 字符集”還是“使用多字節(jié)字符集”。如果控件源碼里大量使用 CString 和 TCHAR 宏那它多半能兼容兩種如果直接用了 char* 和 LPSTR就必須把工程切到多字節(jié)字符集或者做一層寬窄字符轉(zhuǎn)換的封裝。第二確認(rèn)控件源碼里有沒有依賴 MFC 的特定版本。有些版本用了 CString、CRect 這些 MFC 基礎(chǔ)類有些則盡量自包含以支持純 SDK 工程。如果你只想讓它獨(dú)立工作不想拖整個(gè) MFC 框架進(jìn)工程那就需要選用純 Win32 實(shí)現(xiàn)的那份源碼。第三確認(rèn)編譯警告級(jí)別。這類控件代碼通常比較老在老編譯器上零警告在 VS2019 以上可能產(chǎn)生一堆 C4996比如 strcpy 被標(biāo)記為不安全。直接的做法是把警告級(jí)別調(diào)到 3 而不是 4或者在包含頭文件之前加上警告抑制宏別花時(shí)間去逐條改代碼。一個(gè)很常見的編譯失敗點(diǎn)是源碼里用到的大小寫不敏感的文件名——把 HexEdit.h 寫成了 hexedit.hWindows 文件系統(tǒng)不區(qū)分但一提交到大小寫敏感的倉庫或打包給別人構(gòu)建就立刻報(bào)“無法打開包含文件”。我用這類控件時(shí)會(huì)在第一步就把所有文件名統(tǒng)一并確認(rèn)了一次編譯通過。3.2 控件窗口的創(chuàng)建靜態(tài)占位和動(dòng)態(tài)創(chuàng)建的兩套代碼最穩(wěn)的做法是先在對(duì)話框資源編輯器里放一個(gè) Custom Control 占位控件把它的類名改成控件注冊的窗口類名然后在 OnInitDialog 里把它的位置和大小拉滿。這套流程的好處是對(duì)話框能正常使用 Tab 鍵切換焦點(diǎn)資源編輯器里可以直觀擺位代碼量最小。// 對(duì)話框頭文件里聲明控件句柄或封裝對(duì)象 HWND m_hHexEdit; // OnInitDialog 里綁定占位控件 CWnd* pPlaceHolder GetDlgItem(IDC_HEXEDIT_PLACEHOLDER); CRect rc; pPlaceHolder-GetWindowRect(rc); ScreenToClient(rc); pPlaceHolder-DestroyWindow(); // 動(dòng)態(tài)創(chuàng)建真正的控件實(shí)例 m_hHexEdit CreateHexEditWindow(WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL, rc, m_hWnd, IDC_HEXEDIT_REAL);這段代碼要拆開理解GetDlgItem 拿到的是資源里的占位控件它的唯一使命是提供一個(gè)矩形區(qū)域DestroyWindow 把占位控件銷毀避免它留在界面上礙事CreateHexEditWindow 才是真正的創(chuàng)建入口第四個(gè)參數(shù)傳入父窗口句柄第五個(gè)參數(shù)是控件 ID后續(xù)所有消息路由和 SetDlgItemText 之類的調(diào)用都要基于這個(gè)新的 ID。如果你不想在資源編輯里放占位控件也可以直接在 OnInitDialog 里算坐標(biāo)然后創(chuàng)建但要注意對(duì)話框的字體、DPI 縮放都會(huì)影響控件實(shí)際尺寸寫死像素坐標(biāo)在 96 DPI 和 150% 縮放下顯示效果差別很大。資源編輯器占位的方式能天然適配 DPI 縮放因?yàn)閷?duì)話框管理器會(huì)幫你處理對(duì)話框單位的換算。創(chuàng)建控件的窗口類注冊一般在控件的 DLL 或靜態(tài)庫初始化函數(shù)里完成。如果資源包是靜態(tài)庫形式記得在對(duì)話框進(jìn)程啟動(dòng)時(shí)顯式調(diào)用一次 InitHexEdit 之類的注冊函數(shù)如果是 DLL 形式通常在 DLL 的 DllMain 里自動(dòng)注冊但有些實(shí)現(xiàn)放在一個(gè)導(dǎo)出初始化函數(shù)里漏調(diào)一次就會(huì)出現(xiàn)“創(chuàng)建窗口失敗找不到十六進(jìn)制窗口類”的報(bào)錯(cuò)。3.3 首屏把數(shù)據(jù)喂進(jìn)去全量加載與緩沖區(qū)有效性控件創(chuàng)建出來是空白的接下來的問題是數(shù)據(jù)從哪來以什么形式進(jìn)來。資源包一般會(huì)提供兩類接口一類是直接讀文件路徑控件內(nèi)部用 CFile 讀整個(gè)文件到內(nèi)存另一類是接收外部緩沖區(qū)指針。// 方式一直接加載文件路徑 BOOL bOK HexEdit_LoadFile(m_hHexEdit, _T(C:\\data\\firmware.bin)); // 方式二外部數(shù)據(jù)緩沖區(qū)加載數(shù)據(jù)已在內(nèi)存中避免重復(fù)IO BYTE* pBuf (BYTE*)malloc(1024 * 1024); GetPacketData(pBuf); // 假設(shè)這是你從網(wǎng)絡(luò)上取到的原始數(shù)據(jù) HexEdit_OpenBuffer(m_hHexEdit, pBuf, 1024 * 1024, TRUE);方式一是最省事的但有幾個(gè)細(xì)節(jié)要留意。LoadFile 內(nèi)部如果實(shí)現(xiàn)不當(dāng)會(huì)把整個(gè)文件讀進(jìn)一個(gè)大緩沖區(qū)遇到幾百兆的文件會(huì)瞬間吃掉幾百兆內(nèi)存而文件長度超過 int 上限2GB時(shí)基本必掛。好一點(diǎn)的實(shí)現(xiàn)會(huì)用文件映射CreateFileMapping MapViewOfFile這樣大數(shù)據(jù)量也不會(huì)內(nèi)存爆炸但代價(jià)是寫入后需要 FlushViewOfFile 才能真正落盤。方式二更靈活本地調(diào)試時(shí)可以先抓包、再塞進(jìn)去展示。BOOL 類型的最后一個(gè)參數(shù)表示“控件是否接管這個(gè)緩沖區(qū)的生命周期”傳 TRUE 表示控件釋放時(shí)會(huì)幫你 free 掉這塊內(nèi)存?zhèn)?FALSE 表示一個(gè)月后由你自己管理釋放。這里是最容易踩坑的地方——生命周期語義不清楚的話輕則內(nèi)存泄漏被工具檢查警告重則二次釋放崩潰。還有一類特殊情況你只想讓用戶查看十六進(jìn)制內(nèi)容禁止任何修改。這通常在控件里會(huì)有一個(gè)只讀模式開關(guān)開戶位置一般叫 EnableReadOnly 或 SetReadOnly 的成員函數(shù)。開啟只讀不意味著查找和跳轉(zhuǎn)被禁用只是限制編輯操作這對(duì)做“報(bào)表型”展示頁面非常實(shí)用。4. 編輯、查找、斷點(diǎn)與對(duì)比四個(gè)核心功能的技術(shù)實(shí)現(xiàn)要點(diǎn)4.1 查找十六進(jìn)制串、ASCII 串和范圍限定查找是使用頻率最高的功能?？丶话闾峁﹥煞N查找模式十六進(jìn)制串輸入“4D 5A 90 00”和文本串輸入“MZ”。底層是同一個(gè)查找算法只是編碼方式不同。// 查找十六進(jìn)制模式輸入字符串忽略空格大小寫不敏感 int nOffset HexEdit_Find(m_hHexEdit, 4D 5A 90 00, FIND_HEX, // 查找模式十六進(jìn)制 0, // 從偏移 0 開始找 -1); // -1 表示搜到文件末尾 // 查找文本模式直接傳 ASCII 字符串 int nTextOffset HexEdit_Find(m_hHexEdit, RIFF, FIND_TEXT, nCurrentPos 1, // 從上次找到的位置之后繼續(xù) -1);返回的 nOffset 是文件內(nèi)的絕對(duì)偏移量找到后通常配合滾動(dòng)函數(shù)讓光標(biāo)跳到那個(gè)位置if (nOffset 0) { HexEdit_SetSelection(m_hHexEdit, nOffset, nOffset 4); HexEdit_EnsureVisible(m_hHexEdit, nOffset); }幾個(gè)參數(shù)的實(shí)際含義要理解對(duì)。起始偏移傳 0 表示從頭找但如果你在循環(huán)查找“下一個(gè)匹配項(xiàng)”需要把起始偏移設(shè)成上一次找到的位置加 1否則會(huì)陷入無限循環(huán)——每次都從文件頭重新找永遠(yuǎn)找到同一個(gè)位置。查找性能方面如果是幾十兆的文件一次次從頭掃每次查找都會(huì)是線性開銷連續(xù)點(diǎn)“下一個(gè)”時(shí)體感會(huì)越來越卡。最好先確認(rèn)控件內(nèi)部是否有索引優(yōu)化沒有的話就自己把查找范圍限制在合理區(qū)間內(nèi)。自動(dòng)跳轉(zhuǎn)到找到的位置是查找功能完整性的重要部分需要控件同時(shí)提供了地址定位和選區(qū)高亮的配合。如果控件實(shí)現(xiàn)良好還會(huì)有額外的狀態(tài)提示比如在狀態(tài)欄顯示“找到偏移 0x12345678”這種信息我在集成時(shí)通常會(huì)把這個(gè)返回值直接接到自己的狀態(tài)欄邏輯上讓用戶獲得反饋。4.2 字節(jié)寫入與撤銷棧直接改內(nèi)存緩沖區(qū)不涉及文件句柄控件對(duì)所編輯數(shù)據(jù)的修改本質(zhì)上就是改那塊外部傳入的緩沖區(qū)或內(nèi)部持有的緩沖對(duì)象。編輯動(dòng)作通過消息、鍵盤輸入或者代碼調(diào)用來完成不限于是用戶手動(dòng)操作。實(shí)際開發(fā)中軟件里還有一類需求是代碼自動(dòng)修改某些字節(jié)——比如把某個(gè)配置字段的 CRC 計(jì)算完寫回去。// 直接寫入一個(gè)字節(jié)到指定偏移 BOOL bOK HexEdit_WriteByte(m_hHexEdit, 0x100, 0x5A); // 寫入多個(gè)字節(jié)從偏移 0x100 開始連續(xù)寫 4 字節(jié) BYTE pNewData[] { 0x5A, 0xA5, 0x00, 0xFF }; HexEdit_WriteBlock(m_hHexEdit, 0x100, pNewData, 4);WriteByte 的第一參數(shù)是控件句柄第二參數(shù)是偏移量第三參數(shù)是新值。它只是更新內(nèi)存數(shù)據(jù)并不會(huì)自動(dòng)替你落盤。保存的動(dòng)作一般單獨(dú)提供常見的是 SaveFile 或?qū)椤盎貙懺募痹O(shè)計(jì)的接口因?yàn)檫@不是每次修改后都會(huì)觸發(fā)的操作。撤銷棧是這類控件最容易實(shí)現(xiàn)出體驗(yàn)差異的功能。實(shí)現(xiàn)得好的控件你連續(xù)改 20 個(gè)字節(jié)按 20 次 CtrlZ 能一步步回退每一部都精確還原。實(shí)現(xiàn)得粗糙的控件要么只支持一層撤銷改錯(cuò)了只能手動(dòng)改回去要么整塊撤銷一下子回到最初狀態(tài)中間的操作全部丟失。拿到資源后先做一遍撤銷壓力測試隨機(jī)改 50 個(gè)字節(jié)連續(xù) Undo 50 次看最后一次是否真的回到初始狀態(tài)。這一步測試能快速判斷控件的編輯核心是否可靠。如果棧深度有限制記得在界面和代碼里控制好用戶可以連續(xù)撤銷的步數(shù)上限。4.3 斷點(diǎn)與跳躍調(diào)試器風(fēng)格的地址定位十六進(jìn)制編輯器里“斷點(diǎn)”的含義比調(diào)試器里寬松得多通常指的是在某個(gè)偏移位置做一個(gè)書簽標(biāo)記方便反復(fù)回來檢查。這類功能在做協(xié)議分析時(shí)非常有用報(bào)文頭、CRC 區(qū)域、負(fù)載起點(diǎn)各打一個(gè)標(biāo)記來回切換不用反復(fù)滾動(dòng)屏幕。斷點(diǎn)相關(guān)接口一般長這樣// 添加一個(gè)斷點(diǎn)標(biāo)記 int nMarkId HexEdit_AddBookmark(m_hHexEdit, 0x2C00, _T(PackHeader)); // 跳轉(zhuǎn)到指定斷點(diǎn) HexEdit_JumpToBookmark(m_hHexEdit, nMarkId);AddBookmark 的第一個(gè)參數(shù)是偏移量第二參數(shù)是給這個(gè)斷點(diǎn)起的名字返回值是這個(gè)斷點(diǎn)的 ID后續(xù)刪除和跳轉(zhuǎn)都用這個(gè) ID 操作。斷點(diǎn)的視覺呈現(xiàn)方式一般是在地址欄左側(cè)畫一個(gè)紅色圓點(diǎn)或在對(duì)應(yīng)行做整行高亮具體形式取決于控件實(shí)現(xiàn)。除了斷點(diǎn)跳躍功能還包括“跳轉(zhuǎn)到指定偏移量”比如在地址輸入框里輸入 0x2A40直接滾到那個(gè)位置。這里有個(gè)體驗(yàn)細(xì)節(jié)要注意跳轉(zhuǎn)到文件末尾或超出文件長度的偏移時(shí)控件應(yīng)當(dāng)做鉗制處理把位置限制在合法范圍內(nèi)而不是產(chǎn)生越界訪問。集成時(shí)要測試一下邊界輸入比如輸入一個(gè)負(fù)數(shù)或超大值看控件是否會(huì)友好地拒絕。斷點(diǎn)列表的量一般維持在一百個(gè)以內(nèi)體驗(yàn)較好太多會(huì)讓繪制層和書簽管理變得繁瑣。如果你的業(yè)務(wù)需要大量標(biāo)記比如解析一份幾萬行的配置文件每個(gè)字段打一個(gè)標(biāo)記建議自己維護(hù)一組 offset 到名稱的映射表而不是依賴控件內(nèi)置的斷點(diǎn)機(jī)制。4.4 文件對(duì)比差異統(tǒng)計(jì)與快速逐跳這個(gè)功能是很多十六進(jìn)制編輯控件的加分項(xiàng)。文件對(duì)比可以輔助排查“兩個(gè)固件版本之間到底改了哪里”這類經(jīng)典問題?？丶峁┑膶?duì)比接口一般按字節(jié)比較兩個(gè)緩沖區(qū)返回差異塊的起始偏移和長度。// 對(duì)比當(dāng)前緩沖區(qū)與文件中的另一個(gè)文件 int nDiffCount HexEdit_CompareFile(m_hHexEdit, _T(C:\\data\\firmware_v2.bin), 0, // 當(dāng)前緩沖區(qū)對(duì)比起點(diǎn) 0, // 外部文件對(duì)比起點(diǎn) 1024 * 1024); // 對(duì)比長度返回值 nDiffCount 是差異塊的數(shù)量注意是“塊”的數(shù)量不是“字節(jié)”數(shù)量。連續(xù)幾個(gè)字節(jié)不同會(huì)被合并成一個(gè)差異塊。對(duì)比完成后通常需要逐跳瀏覽這些差異位置int nFirstDiff HexEdit_GetFirstDiff(m_hHexEdit); HexEdit_SetSelection(m_hHexEdit, nFirstDiff, nFirstDiff 1);對(duì)比性能方面如果控件用 memcmp 按塊比較幾十兆文件通常一兩秒內(nèi)完成如果實(shí)現(xiàn)成逐字節(jié)循環(huán)比對(duì)那同樣的文件可能要十幾秒。做固件分析時(shí)我會(huì)傾向先把對(duì)比區(qū)域縮小到實(shí)際有變化的區(qū)間比如跳過文件尾部的空白填充區(qū)這樣既省時(shí)間也能規(guī)避全文件對(duì)比時(shí)控件內(nèi)部可能出現(xiàn)的效率瓶頸。文件對(duì)比還有一個(gè)實(shí)踐要點(diǎn)外部文件加載失敗時(shí)控件的行為。Reader 打開一個(gè)不存在或權(quán)限不夠的文件控件應(yīng)該返回明確錯(cuò)誤碼而不崩潰。我在接這個(gè)接口時(shí)都會(huì)先把外部文件是否存在校驗(yàn)一遍別指望控件幫你做這個(gè)檢查自己多做一步提前防御后面會(huì)省很多排錯(cuò)力氣。5. 集成 hexedit 的常見坑字符集、緩存刷新、坐標(biāo)換算與滾動(dòng)性能5.1 字符集不匹配導(dǎo)致中文顯示亂碼或編譯失敗現(xiàn)象工程是 Unicode 字符集控件讀到的字節(jié)被解釋成寬字符ASCII 區(qū)里的中文顯示成亂碼或者編譯時(shí)出現(xiàn)一大堆“無法將參數(shù)從‘const char *’轉(zhuǎn)換為‘LPCTSTR’”的錯(cuò)誤。原因老控件源碼里用 char 處理字符串而 Unicode 工程要求寬字符接口。問題出在頂層 API 的字符串參數(shù)傳遞層面不一定是顯示亂碼這一層。解決優(yōu)先把控件工程和宿主工程統(tǒng)一到同一字符集。若控件源碼是大改不動(dòng)就在集成層做一個(gè)轉(zhuǎn)換殼把所有寬字符文件名轉(zhuǎn)換成 UTF-8 或 ANSI 的多字節(jié)字符串再調(diào)用控件內(nèi)部接口。我一般會(huì)寫一個(gè)小工具函數(shù)CStringA WideToAnsi(const CString strWide) { int nLen WideCharToMultiByte(CP_ACP, 0, strWide, -1, NULL, 0, NULL, NULL); CStringA strA; WideCharToMultiByte(CP_ACP, 0, strWide, -1, strA.GetBuffer(nLen), nLen, NULL, NULL); strA.ReleaseBuffer(); return strA; }這個(gè)轉(zhuǎn)換函數(shù)度必須放在集成層而不是改動(dòng)控件源碼因?yàn)椴煌姹镜目丶?nèi)部存儲(chǔ)格式不一樣混改容易引入新的問題。5.2 修改字節(jié)后界面不刷新光標(biāo)雖然移動(dòng)了但顯示還是舊值現(xiàn)象調(diào)用 HexEdit_WriteByte 成功返回 TRUE但控件畫面上顯示的仍然是原來的字節(jié)直到下一次鼠標(biāo)點(diǎn)擊或滾動(dòng)才恢復(fù)正常。原因數(shù)據(jù)緩沖區(qū)的確被更新了但控件沒有發(fā)出刷新指令I(lǐng)nvalidate繪制層不知道自己需要重畫。這類控件常見的問題是寫接口和刷新接口分離寫之后必須主動(dòng)調(diào)用刷新函數(shù)好一點(diǎn)的實(shí)現(xiàn)會(huì)內(nèi)部自動(dòng)觸發(fā)重繪差的則不會(huì)。解決每次調(diào)用 WriteByte 或 WriteBlock 之后強(qiáng)制調(diào)用控件的重繪接口或者向控件窗口發(fā)送 WM_PAINT 消息。HexEdit_WriteByte(m_hHexEdit, 0x100, 0x5A); // 強(qiáng)制刷新視圖區(qū)域 InvalidateRect(m_hHexEdit, NULL, TRUE); UpdateWindow(m_hHexEdit);這個(gè)坑在做“代碼自動(dòng)修改字節(jié)”時(shí)尤其隱蔽——用戶操作有鍵盤事件驅(qū)動(dòng)刷新代碼調(diào)用則容易忘記刷新。我后來養(yǎng)成的習(xí)慣是把“寫字節(jié) 強(qiáng)制刷新”封裝成一個(gè)函數(shù)所有修改都走這一個(gè)入口。5.3 地址越界寫入往文件末尾后面寫數(shù)據(jù)控件行為異?，F(xiàn)象調(diào)用 WriteByte 時(shí)傳入了超過數(shù)據(jù)長度的偏移比如文件只有 4096 字節(jié)卻往偏移 0x5000 寫了一個(gè)字節(jié)。結(jié)果要么返回 FALSE 不生效要么直接破壞內(nèi)部數(shù)據(jù)結(jié)構(gòu)的長度字段導(dǎo)致后續(xù)顯示出現(xiàn)亂碼或崩潰。原因控件內(nèi)部可能存在一個(gè)不嚴(yán)謹(jǐn)?shù)膶懭雽?shí)現(xiàn)沒有對(duì)偏移量做邊界校驗(yàn)就開始了操作。有些實(shí)現(xiàn)會(huì)直接把緩沖區(qū)的長度改掉甚至用越界偏移計(jì)算新長度時(shí)產(chǎn)生負(fù)數(shù)長度。解決編碼層面強(qiáng)制校驗(yàn)寫入前自己檢查偏移量寫入長度是否超過當(dāng)前數(shù)據(jù)緩沖區(qū)大小。if (nOffset nBufSize || nOffset nWriteLen nBufSize) { // 拒絕寫入并提示 return FALSE; }這里有個(gè)細(xì)節(jié)值得注意某些情況下你想實(shí)現(xiàn)“擴(kuò)展文件長度后寫入”比如在文件末尾追加 100 字節(jié)數(shù)據(jù)。這個(gè)需求應(yīng)該走專門的擴(kuò)展接口通常是 ResizeBuffer 或 AppendData而不是直接越界寫。先用擴(kuò)展接口把緩沖區(qū)擴(kuò)大再寫新位置的數(shù)據(jù)。5.4 大文件加載緩慢 拖動(dòng)滾動(dòng)條卡頓鼠標(biāo)滾輪更卡現(xiàn)象加載一個(gè) 200MB 的 bin 文件等了十幾秒才顯示出來顯示之后拖動(dòng)滾動(dòng)條有明顯掉幀鼠標(biāo)滾輪一次滾多行時(shí)界面像幻燈片。原因控件在加載階段就把全部文件讀進(jìn)內(nèi)存并做了逐字節(jié)的界面初始化工作比如把每個(gè)偏移量的坐標(biāo)都預(yù)計(jì)算了一遍。滾動(dòng)時(shí)如果沒做有效緩存只重畫可視區(qū)每一幀都要全量重算字形位置和字符寬度必然卡頓。解決分批加載數(shù)據(jù)并使用更快的滾動(dòng)方式。如果控件實(shí)現(xiàn)了虛擬模式只渲染可視區(qū)域的前后幾行那加載大數(shù)據(jù)應(yīng)該很快如果沒實(shí)現(xiàn)就自己限流不讓大文件直接進(jìn)入到首屏展示或者把數(shù)據(jù)量裁剪到可視范圍內(nèi)再交給控件。相對(duì)來說加載 200MB 文件的預(yù)期時(shí)間應(yīng)該在 12 秒內(nèi)超過這個(gè)數(shù)就該從控件實(shí)現(xiàn)層面找原因。5.5 坐標(biāo)換算問題鼠標(biāo)點(diǎn)擊某行選中的字節(jié)不是預(yù)期的那個(gè)現(xiàn)象點(diǎn)十六進(jìn)制區(qū)第七行中間位置控件選中的卻是一整行或選到了相鄰行的開頭字節(jié)光標(biāo)定位總是差一兩個(gè)字符位。原因源控件可能固定了等寬字體和列寬而宿主對(duì)話框的字體環(huán)境不一樣導(dǎo)致字符寬度計(jì)算錯(cuò)誤?？丶?nèi)部一般采用“字節(jié)偏移 (行號(hào) * 每行字節(jié)數(shù)) (列號(hào) / 每字節(jié)字符寬度)”的計(jì)算模式字體變了列寬就變了命中區(qū)域自然偏移。解決確認(rèn)控件創(chuàng)建時(shí)是否設(shè)置了自己的字體如果沒有在創(chuàng)建后主動(dòng)調(diào)用控件提供的設(shè)置字體接口并傳入一個(gè)等寬字體// 使用等寬字體保證字符寬度一致 LOGFONT lf { 0 }; lf.lfHeight -14; lf.lfPitchAndFamily FIXED_PITCH | FF_MODERN; _tcscpy_s(lf.lfFaceName, _T(Consolas)); HFONT hFont CreateFontIndirect(lf); HexEdit_SetFont(m_hHexEdit, hFont);Consolas、Courier New 這類字體在 Windows 全平臺(tái)上都有用它們可以保證十六進(jìn)制區(qū)列對(duì)齊。如果控件自帶的字體偏好設(shè)置能設(shè)置字符間距也可以順手調(diào)一下但別改間距太狠否則又會(huì)破壞固定列寬的對(duì)齊。6. 定制擴(kuò)展的方向從基礎(chǔ)集成走向深度改造拿到這份資源后很多人問的最多的問題是“這個(gè)控件能不能改成我的風(fēng)格”——比如背景涂黑、字節(jié)顏色區(qū)分、特定地址高亮。答案是可以的但要看清楚擴(kuò)展點(diǎn)在哪兒。第一處可改的是繪制層。大多數(shù)十六進(jìn)制控件在 OnDraw 或類似的地方集中繪制三個(gè)區(qū)域你要做的只是找到繪制 ASCII 區(qū)的那幾行代碼插入一個(gè)判斷如果當(dāng)前字節(jié)值小于 0x20 或者大于 0x7E就換一種顏色畫。比如非打印字符用灰色、控制字符用紅色// 偽代碼示意在 ASCII 區(qū)繪制邏輯中插入特殊配色 COLORREF crColor IsPrintableByte(pData[i]) ? RGB(0,0,0) : RGB(160, 160, 160); pDC-SetTextColor(crColor);第二處可改的是數(shù)據(jù)來源對(duì)接?？丶哪J(rèn)數(shù)據(jù)源是文件或內(nèi)存緩沖區(qū)但你可以把它的數(shù)據(jù)接口重新綁定到一個(gè)自己實(shí)現(xiàn)的數(shù)據(jù)源上——比如從遠(yuǎn)程設(shè)備讀取數(shù)據(jù)塊控件每次請求某段地址時(shí)就從設(shè)備實(shí)時(shí)讀取而不是本地內(nèi)存。這種改造把控件從“文件編輯器”變成“遠(yuǎn)程數(shù)據(jù)查看器”很多遠(yuǎn)程調(diào)試工就是這么做的。第三處可改的是事件通知?？丶谛薷淖止?jié)、移動(dòng)光標(biāo)、執(zhí)行查找后通常會(huì)給父窗口發(fā) WM_NOTIFY 消息你可以在對(duì)話框的消息反射里攔截這些通知把事件轉(zhuǎn)發(fā)給業(yè)務(wù)邏輯。比如用戶修改了某個(gè)關(guān)鍵字段后自動(dòng)觸發(fā)重算校驗(yàn)和。這類攔截屬于標(biāo)準(zhǔn) MFC 反射機(jī)制控件部分的封裝一般已經(jīng)提供了消息類型定義直接查它的頭文件里 WM_NOTIFY 的 code 值即可對(duì)接。我自己的習(xí)慣是做一個(gè)新工具時(shí)把控件修改字節(jié)的動(dòng)作攔截到日志里記錄誰在什么時(shí)間改了什么地址——調(diào)試過程中這個(gè)日志能幫你省下大量定位問題的時(shí)間。每接一個(gè)新項(xiàng)目我都會(huì)先用五分鐘把這個(gè)控件的字體驗(yàn)證、撤銷棧深度、越界寫入防護(hù)這三項(xiàng)跑一遍確認(rèn)無誤才開始做功能開發(fā)。從那以后集成這類控件基本沒有再出過運(yùn)行時(shí)崩潰的意外這份資源里的源碼雖然需要你自己動(dòng)手打磨的地方還不少但把它跑通、改透之后你手里等于多了一把處理二進(jìn)制數(shù)據(jù)的稱手工具省下來的時(shí)間絕對(duì)值得。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取