前一段時間解決的一個問題，看起來是個小問題，實際解決這個問題卻花了一個星期的晚上休息時間，記錄分享一下。

問題描述：

linux核心配置中NLS（native language support）已經選擇了預設語言配置為utf8，幷包含一些其他常用語言的編碼，但是在secureCRT的telnet和串列埠終端顯示中文檔名均為亂碼。

解決過程：

1.剛開始以為是簡單的編碼不匹配的問題，修改secureCRT中的傳輸編碼方式從預設變為utf8，中文不再亂碼，但變成了問號，“??????”；

2.因為中文目錄是在掛載的SD卡中的（居然沒有嘗試一下網路掛載或者其他的方式下中文是否亂碼，汗），懷疑是掛載SD卡方式不對。網上解答全部都是說，編譯核心的時候fat檔案系統的codepage和isochaset配置對，掛載時選擇vfat，-o命令選擇codepage和isocharset匹配就好了，具體的命令是，mount -t vfat -o codepage=936,iocharset=utf8 /dev/mmcblk0p1 /home/。然後接下來幾天晚上就一直在鼓搗這些東西，無解；

3.有一天忽然找到一篇博文，說是busybox的原因，高版本的busybox取消了中文支援，想不到還有這茬。進入busybox配置，發現已經勾選了Unicode的支援。如此按博文提示，還需要修改busybox中的另外兩個檔案printable_string.c以及unicode.c，把大於0x7f替換為問號的這個選擇條件去掉才行。看了一下原始碼，覺得改的地方都是不勾Unicode才需要改的……不過還是試一下吧，重新配置編譯busybox，替換根檔案系統，不過問題依舊……

4.既然上面的提示中已經發現不勾選Unicode支援中文的方式，那就先試一下不支援Unicode顯示中文的方式吧，修改printable_string.c以及unicode.c

5.但是這樣子草草了事明顯是不行的，那又是為什麼勾選Unicode支援後中文變問號呢？那就只能讀原始碼了，還好範圍也可以接受，問題應該就出在修改的兩個檔案裡面。

6.LAST_SUPPORTED_WCHAR，通過busybox原始碼，可以發現有這麼一個判斷if (wc > CONFIG_LAST_SUPPORTED_WCHAR){go subset;}，而在subset的地方，wc被賦值為問號，這下問題就明朗了，明顯是這個LAST_SUPPORTED_WCHAR搞的鬼；

7.檢視busybox配置，發現這個巨集定義表示的是Range of supported Unicode characters，預設填的值才700多，而中文在Unicode中的位置查了一下最高到U+2FA1D，隨便給這個值改了一個大於2FA1D的值，重新編譯燒寫根檔案系統，中文顯示成功！

走了不少彎路，好在最後問題是解決了！最後記錄一下，busybox版本是1.19.4！