亂碼重新編譯
❶ 如何解決嵌入式軟體開發過程中的亂碼問題
解決過程：
剛開始是簡單的編碼不匹配情況，修改secureCRT中的傳輸編碼方式從默認變為utf8，中文不再亂碼，但變成了問號，「??????」；
因為中文目錄是在掛載的SD卡中的（居然沒有嘗試一下網路掛載或者其他的方式下中文是否亂碼，）。，編譯內核的時候fat文件系統的codepage和isochaset配置對，掛載時選擇vfat，-o命令選擇codepage和isocharset匹配就好了，具體的命令是，mount -t vfat -o codepage=936,iocharset=utf8 /dev/mmcblk0p1 /home/。然後接下來幾天晚上就一直在鼓搗這些東西，無解；
高版本的busybox取消了中文支持，進入busybox配置，發現已經勾選了Unicode的支持。還需要修改busybox中的另外兩個文件printable_string.c以及unicode.c，把大於0x7f替換為問號的這個選擇條件去掉才行。看了一下源碼，覺得改的地方都是不勾Unicode才需要改，重新配置編譯busybox，替換根文件系統，如果問題還在進行下一步。
既然上面的提示中已經發現不勾選Unicode支持中文的方式，那就先試一下不支持Unicode顯示中文的方式吧，修改printable_string.c以及unicode.c，重新編譯，燒寫啟動設備，發現去掉Unicode果然中文支持了，不再顯示問號；到這一步還出現問題再進行下一步。
LAST_SUPPORTED_WCHAR，通過busybox源碼，可以發現有這么一個判斷if (wc > CONFIG_LAST_SUPPORTED_WCHAR){go subset;}，而在subset的地方，wc被賦值為問號，明顯是這個LAST_SUPPORTED_WCHAR的原因；
查看busybox配置，發現定義表示的是Range of supported Unicode characters，默認填的值才700多，而中文在Unicode中的位置查了一下最高到U+2FA1D，隨便給這個值改了一個大於2FA1D的值，重新編譯燒寫根文件系統，中文顯示成功！
❷ c語言編譯運行亂碼是什麼原因
這種情況多數是由於操作系統的語言選項不正確引起的。建議你查看一下控制面板中的區域和語言選項，特別是有關「非Unicode程序的語言」，一定要選擇成「中文（簡體，中國）」。然後重啟電腦。
❸ 在CMD里編譯java文件是出亂碼
出現亂碼可能是因為：
JDK沒有安裝好或是用了不完整的（損壞的）安裝包。
環境變數未設置或設置錯誤。
JDK沒有安裝好或是用了不完整的（損壞的）安裝包的解決方法：
用可信軟體（大數字，企鵝等）或控制面板里刪除之前下載的所有java，
到java官網下載最新版JDK
安裝（需記住目錄）
重新配置環境變數
環境變數未設置或設置錯誤的解決方法：
右鍵我的電腦，屬性，高級設置，環境變數
新建，變數名：JAVA_HOME
變數值：C:Program FilesJavajdk1.7.0（你安裝java的目錄）
新建變數名：CLASSPATH
變數值：.;%JAVA_HOME%libdt.jar;%JAVA_HOME%lib ools.jar;（輸入法切換到英文，開頭的【.;】和末尾的【;】不要漏掉）
在系統變數列表裡找到Path變數，雙擊
變數名：Path（不變）
變數值：%JAVA_HOME%in;%JAVA_HOME%jrein;
點擊確定完成環境變數的配置，打開cmd輸入java和javac測試
彈出下圖所示的東西就表明環境變數編輯成功
java：
❹ Linux中unzip解壓時中文亂碼如何解決
更改源碼解決亂碼
調試發現問題出現在MultiByteToWideChar方法里，
如 MultiByteToWideChar(CP_ACP,0,fn,-1,tfn,MAX_PATH); 到這里時fn中的name屬性值還是正常的，在這個方法內部執行完tfn就亂了。
解決方法：
打開unzip.cpp源文件，找到函數
ZRESULT TUnzip::Get(int index,ZIPENTRY *ze)
{ // ......
// ......} 12345
這個函數里有
#ifdef UNICODE
MultiByteToWideChar(CP_UTF8,0,fn,-1,tfn,MAX_PATH);#else
strcpy(tfn,fn);#endif12345
把 CP_UTF8 改為CP_ACP， （ CP_ACP 指示要使用當前設置的 API 默認 Windows ANSI 代碼頁）
重新編譯後
這樣就解決了解壓中文文件名稱亂碼的問題
編譯時解決源碼問題（無需更改源碼）
上面的情況，我們我觀察到unzip源代碼這段開始的地方有判斷
#ifndef Ext_ASCII_TO_Native 1
這樣問題似乎更簡單了，不用改源代碼，只需在make時定義 Ext_ASCII_TO_Native 即可，這樣 Ext_ASCII_TO_Native 實際為一個空的宏，不進行任何轉換操作。
比如，使用下面的方法編譯
make -DExt_ASCII_TO_Native 1
或者在bash執行下面兩行
export LOCAL_UNZIP=-DExt_ASCII_TO_Native
make12
unzip解壓縮含中文文件名zip包是出現亂碼的問題解決！
如果您的系統已經安裝了unzip
方法一 unzip行命令解壓，指定字元集
通過unzip行命令解壓，指定字元集
unzip -O CP936 xxx.zip (用GBK, GB18030也可以)1
方法二 在環境變數中，指定unzip參數
在環境變數中，指定unzip參數，總是以指定的字元集顯示和解壓文件
/etc/environment中加入2行
UNZIP=」-O CP936″
ZIPINFO=」-O CP936″12
方法三 利用pyton來處理
復制以下內容（python）保存未myuzip.py文件腳本，並修改運行許可權為可運行(chmod +x uzip)
#!/usr/bin/env python# -*- coding: utf-8 -*-# uzip.pyimport osimport sysimport zipfileprint "Processing File " + sys.argv[1]
file=zipfile.ZipFile(sys.argv[1],"r");for name in file.namelist():
utf8name=name.decode('gbk') print "Extracting " + utf8name
pathname = os.path.dirname(utf8name) if not os.path.exists(pathname) and pathname!= "":
os.makedirs(pathname)
data = file.read(name) if not os.path.exists(utf8name):
fo = open(utf8name, "w")
fo.write(data)
fo.close
file.close()
這樣以後我們解壓縮時只需要運行此文件即可
./myuzip.py xxxx.zip