問題描述

在使用 node-winreg 庫操作 Windows 註冊表時，發現存取中文字符存在亂碼問題：

• 寫入註冊表的中文內容顯示正常
• 從註冊表讀取中文內容時出現亂碼

winreg的版本如下:

問題根源分析

通過源碼分析，發現問題出現在字符編碼的處理環節：

1. 寫入過程：node-winreg 底層使用 spawn 執行 reg 命令，在 Windows 命令行環境中默認使用 GBK 編碼，因此中文內容以 GBK 編碼格式正確寫入註冊表
2. 讀取過程：讀取註冊表時，獲取到的 Buffer 數據使用 buffer.toString() 方法進行解碼，該方法默認使用 UTF-8 編碼
3. 編碼不一致：GBK 編碼寫入，UTF-8 編碼讀取，導致中文字符解碼錯誤，產生亂碼

解決方案

方案一：修改命令行編碼（推薦）

在 spawn 執行 reg 命令前，先執行 chcp 65001 命令將控制枱編碼設置為 UTF-8：

// 修改前執行的命令
reg query "HKEY_CURRENT_USER\Software" /f "中文" /k

// 修改後執行的命令  
chcp 65001 && reg query "HKEY_CURRENT_USER\Software" /f "中文" /k

優點：

• 編碼統一為 UTF-8，符合現代開發標準
• 一勞永逸解決所有字符編碼問題

方案二：使用 iconv-lite 解碼

安裝 iconv-lite 庫，在解碼時明確指定使用 GBK 編碼：

const iconv = require('iconv-lite');

// 修改前
const result = buffer.toString();

// 修改後
const result = iconv.decode(buffer, 'gbk');

優點：

• 精確控制解碼過程
• 不依賴系統環境設置

具體實現

兩種方案都需要修改 node-winreg 的源碼：

方案一實現

在創建子進程執行 reg 命令的代碼處，修改命令拼接邏輯：

// 在 lib/registry.js 中找到 getRegExePath 方法
function getRegExePath() {
    if (process.platform === 'win32') {
        return path.join(process.env.windir, 'system32', 'reg.exe');
    } else {
        return "REG";
    }
}

修改為

function getRegExePath() {
    if (process.platform === 'win32') {
        return "chcp 65001 &&" + path.join(process.env.windir, 'system32', 'reg.exe');
    } else {
        return "chcp 65001 && REG";
    }
}

方案二實現

此方案修改的較大,因為讀取邏輯都封裝在captureOutput方法裏,如下

直接data.toString(),如果字符發送沒有斷開,那麼此處修改為iconv.decode(data,"gbk")即可,如果有斷包的情況,那麼需要使用buffer拼接,在最後的close回調裏使用iconv.decode(buffer,"gbk")即可

注意事項

1. 方案選擇：推薦使用方案一，因為 UTF-8 是更通用的編碼標準
2. 版本兼容：修改源碼後需要記錄，避免在庫更新時丟失修改
3. 測試驗證：修改後務必進行完整的讀寫測試，確保中文字符處理正確

總結

node-winreg 中文亂碼問題的本質是編碼不一致導致的。通過統一編碼標準或使用正確的解碼方式，可以有效解決此問題。建議根據具體項目需求選擇合適的解決方案。