WIN10中文亂碼修復合集

最近被中文亂碼害慘了，所以做箇中文修復合集吧！

解決中文亂碼問題

一個清單大概包含了CSDN中所有解決此問題的辦法
無論WIN10還是WIN7
學識淺薄，如有任何意見建議歡迎各位批評指正！

本方案基本解決以下亂碼問題（包括但不限於）

• TXT閱讀亂碼（方法1）
• WINRAR等解壓縮中文文件夾亂碼（方法1）
• 右鍵菜單亂碼←請參閱
• 資源管理器中文件夾亂碼（方法1或方法2）
• 關於系統DOS（CMD）的中文亂碼修復←請參閱
• 英文系統中查閱中文文件出現亂碼←請參閱
• 等等諸多問題

方法一：更改區域設置解決中文亂碼

動圖來自：win10消除亂碼

下面爲詳細操作步驟
————————————————
環境爲：WIN10_1909

設置爲中國（簡體，中國），且取消勾選

beta版本，使用UTF-8提供全球語言支持*

確定後進行重啓

若沒有解決你的問題，請參閱方法二

方法二：修改註冊表解決中文亂碼

方法一爲最基礎的設置解決辦法
　本章節爲最廣的且最有效的解決方法：

運行註冊表regedit
　　打開鍵 計算機\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated Charset
點擊Associated Charset項，在其目錄下新建字符串值，並修改名稱與數據數值：

名稱	類型	數據
ANSI ( 00)	REG_SZ	YES
GB2312(86)	REG_SZ	YES
OEM(FF)	REG_SZ	YES
SYMBOL(02)	REG_SZ	NO
WEM(FF)	REG_SZ	YES

如果沒有則自己創建：（右鍵→新建→字符串值）

在一些版本中，此法可解決一些亂碼問題，
但是仍有部分軟件存在亂碼，
在較新版本中，系統本身都已經把這兩項設置成YES了，
但還是有亂碼。要解決這些，還得做下一步工作

打開註冊表鍵 計算機\HKEY_CURRENT_USER\Control Panel\International
將右側：“Locale”=“00000409″ 改成 ”Locale“=”00000804″。然後再修改完確定之後重新啓動電腦。

系統出現亂碼現象，可能是系統病毒導致，可能是文件錯亂導致，如果用戶在系統下遇到同樣的問題時，試試以上的步驟，把亂碼趕出系統。

轉自：http://www.xitongcheng.cc/xtjc/108.html

在執行了以上所有操作之後如果您還和我一樣右鍵菜單依舊是亂碼！那不妨您耐得住性子，再和我做這一步

注意方法三隻適用於reg文件
例如：您想在系統的右鍵菜單中加入一個**在當前位置打開cmd**這個選項的話出現了亂碼，
或者是使用reg進行註冊導入使用：**取得管理員權限**的右鍵菜單項的話，那您找對了這個方法絕對適合您

方法三：右鍵菜單亂碼（只針對文本文件寫入有效）

請更改您的reg文件的保存類型
例如：以下代碼是爲了獲取win10系統的指定文件夾管理權限的需要複製保存到本地的txt文件中並更改格式爲
.reg進行使用

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\runas]
@="取得管理權限"
"Icon"="cmd.exe"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\*\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
[HKEY_CLASSES_ROOT\exefile\shell\runas2]
@="取得管理權限"
"Icon"="cmd.exe"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\exefile\shell\runas2\command]
@="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" && icacls \"%1\" /grant administrators:F"
[HKEY_CLASSES_ROOT\Directory\shell\runas]
@="取得管理權限"
"Icon"="cmd.exe"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\shell\runas\command]
@="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"
"IsolatedCommand"="cmd.exe /c takeown /f \"%1\" /r /d y && icacls \"%1\" /grant administrators:F /t"

請注意txt進行保存的時候請先執行以下步驟！！！

請另存爲其他編碼的文件如下圖

保存之後再執行就會正常！

UTF-8與GBK的愛恨情仇

以上爲全部的解決問題的步驟
那麼爲什麼會出現這些問題呢？
本篇文章圍繞UTF-8與GBK的差異，來具體瞭解系統會出現亂碼的原因
學識淺薄，如有任何意見建議歡迎各位批評指正！
本節源自:UTF-8和GBK的區別——CSDN

各種編碼詳解

ASCII(ISO-8859-1)是鼻祖，最簡單的方式，字節高位爲0
GB2312、GBK、GB18030，這幾個是中文編碼方式，並向下兼容。
GB2312包含7000多個漢字和字符，GBK包含21000多個，GB18030更厲害，到了27000多個。
他們都是用2個字節來表示一個漢字。跟ascii是怎麼區分的呢？如果高字節的高位爲1（也就是高字節大於127），就表示是漢字，低字節並無明顯特徵。

ASCII

ASCII碼是7位編碼，編碼範圍是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯數字和標點符號等字符。其中0x00-0x20和0x7F共33個控制字符。

只支持ASCII碼的系統會忽略每個字節的最高位，只認爲低7位是有效位。HZ字符編碼就是早期爲了在只支持7位ASCII系統中傳輸中文而設計的編碼。早期很多郵件系統也只支持ASCII編碼，爲了傳輸中文郵件必須使用BASE64或者其他編碼方式。

GB2312

GB2312是基於區位碼設計的，區位碼把編碼表分爲94個區，每個區對應94個位，每個字符的區號和位號組合起來就是該漢字的區位碼。區位碼一般 用10進制數來表示，如1601就表示16區1位，對應的字符是“啊”。在區位碼的區號和位號上分別加上0xA0就得到了GB2312編碼。

區位碼中01-09區是符號、數字區，16-87區是漢字區，10-15和88-94是未定義的空白區。它將收錄的漢字分成兩級：第一級是常用漢字計3755個，置於16-55區，按漢語拼音字母/筆形順序排列；第二級漢字是次常用漢字計3008個，置於56-87區，按部首/筆畫順序排列。一級漢字是按照拼音排序的，這個就可以得到某個拼音在一級漢字區位中的範圍，很多根據漢字可以得到拼音的程序就是根據這個原理編寫的。

GB2312字符集中除常用簡體漢字字符外還包括希臘字母、日文平假名及片假名字母、俄語西裏爾字母等字符，未收錄繁體中文漢字和一些生僻字。可以用繁體漢字測試某些系統是不是隻支持GB2312編碼。

GB2312的編碼範圍是0xA1A1-0x7E7E，去掉未定義的區域之後可以理解爲實際編碼範圍是0xA1A1-0xF7FE。
EUC-CN可以理解爲GB2312的別名，和GB2312完全相同。

區位碼更應該認爲是字符集的定義，定義了所收錄的字符和字符位置，而GB2312及EUC-CN是實際計算機環境中支持這種字符集的編碼。HZ和ISO-2022-CN是對應區位碼字符集的另外兩種編碼，都是用7位編碼空間來支持漢字。區位碼和GB2312編碼的關係有點像 Unicode和UTF-8。

GBK

GBK編碼是GB2312編碼的超集，向下完全兼容GB2312，同時GBK收錄了Unicode基本多文種平面中的所有CJK漢字。同 GB2312一樣，GBK也支持希臘字母、日文假名字母、俄語字母等字符，但不支持韓語中的表音字符（非漢字字符）。GBK還收錄了GB2312不包含的漢字部首符號、豎排標點符號等字符。

GBK的整體編碼範圍是爲0x8140-0xFEFE，不包括低字節是0×7F的組合。高字節範圍是0×81-0xFE，低字節範圍是0x40-7E和0x80-0xFE。

低字節是0x40-0x7E的GBK字符有一定特殊性，因爲這些字符佔用了ASCII碼的位置，這樣會給一些系統帶來麻煩。
有些系統中用0x40-0x7E中的字符（如“|”）做特殊符號，在定位這些符號時又沒有判斷這些符號是不是屬於某個 GBK字符的低字節，這樣就會造成錯誤判斷。在支持GB2312的環境下就不存在這個問題。需要注意的是支持GBK的環境中小於0x80的某個字節未必就是ASCII符號；另外就是最好選用小於0×40的ASCII符號做一些特殊符號，這樣就可以快速定位，且不用擔心是某個漢字的另一半。Big5編碼中也存在相應問題。

CP936和GBK的有些許差別，絕大多數情況下可以把CP936當作GBK的別名。

GB18030

GB18030編碼向下兼容GBK和GB2312，兼容的含義是不僅字符兼容，而且相同字符的編碼也相同。GB18030收錄了所有Unicode3.1中的字符，包括中國少數民族字符，GBK不支持的韓文字符等等，也可以說是世界大多民族的文字符號都被收錄在內。

GBK和GB2312都是雙字節等寬編碼，如果算上和ASCII兼容所支持的單字節，也可以理解爲是單字節和雙字節混合的變長編碼。GB18030編碼是變長編碼，有單字節、雙字節和四字節三種方式。
GB18030的單字節編碼範圍是0x00-0x7F，完全等同與ASCII；雙字節編碼的範圍和GBK相同，高字節是0x81-0xFE，低字節的編碼範圍是0x40-0x7E和0x80-FE；四字節編碼中第一、三字節的編碼範圍是0x81-0xFE，二、四字節是0x30-0x39。

其中：

GBK就是在保存你的帖子的時候，一個漢字佔用兩個字節。。外國人看會出現亂碼，此爲我中華爲自己漢字編碼而形成之解決方案。

UTF8就是在保存你的帖子的時候，一個漢字佔用3個字節。。但是外國人看的話不會亂碼，此爲西人爲了解決多字節字符而形成之解決方案。

UTF-8

首先Unicode是統一編碼，它建立了一個全世界統一的碼錶。
世界上的所有文字，在這張碼錶中都是唯一的。

UTF－8是Unicode的一種存儲、傳輸方式。它將整個Unicode碼錶分爲3部分。
0000 - 007F 這部分是最初的ascii部分，按原始的存儲方式，即0xxxxxxx。
0080 - 07FF 這部分存儲爲110xxxxx 10xxxxxx
0800 - FFFF 這部分存儲爲1110xxxx 10xxxxxx 10xxxxxx
因此，一個漢字究竟被存儲爲什麼，就需要：先查unicode碼錶，然後根據在碼錶的位置進行計算。例如：“電”字，在碼錶中是3575，計算成utf8就是E794B5，而在GB2312的碼錶中爲B5E7
UTF－8的好處：
兼容ASCII，存儲英文文件都是單字節，文件小。
當然，當以存中文爲主時就變成了3字節編碼了，比GB系列還大！
如何標明一個文件是utf-8格式呢？
這個標記是可選的：EF BB BF。
比如：用windows自帶的記事本創建一個utf8格式的文件，就會加上這個標記。
但是，如果用ultraedit創建utf-8文件，並不會加上這個標記。
這個標記有個術語，叫做BOM（Byte Order Mark）。不帶BOM的utf-8文件和GB2312文件怎麼區分呢？我也不知道。唯一能想到的辦法就是：先用一種試，如果出現亂碼，就用另一種再試

至於UTF－8編碼則是用以解決國際上字符的一種多字節編。碼，它對英文使用8位（即一個字節），中文使用24位（三個字節）來編碼。對於英文字符較多的論壇則用UTF－8節省空間。

UTF-8,GBK,ANSI之間的關係和區別

GBK應該是屬於ANSI之中的，在ANSI的國際通用集，GBK是專門來解決中文編碼的，是雙字節的，不論中英文都是雙字節，而UTF-8是才用的另外的一種編碼方式，對英文是用8位，對中文使用24位，是和ANSI和GBK 的編碼方式是有本質區別的。我們記事本默認的保存時方式是ANSI，並且用不同的編碼方式編寫的文件必須用對應的編碼格式來讀取，否則就會出現亂碼。
原文鏈接：https://blog.csdn.net/weixin_42446691/article/details/89639446

---

版權聲明：本文爲CSDN博主「56734M」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。