前一段時間解決的一個問題，看起來是個小問題，實際解決這個問題卻花了一個星期的晚上休息時間，記錄分享一下。
問題描述：
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，重新編譯，燒寫啟動設備，發現去掉Unicode果然中文支持了，不再顯示問號；
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！
參考文章附下，如果沒有這些提示可能還要花更多的時間，感謝他們的分享：