前一段时间解决的一个问题，看上去是个小问题，实际解决这个问题却花了一个礼拜的夜晚休息时间，记录分享一下。

问题描述：

linux内核配置中NLS(nativelanguage

support)早已选择了默认语言配置为utf8，并包含一些其他常用语言的编码，而且在secureCRT的telnet和并口终端显示英文文件名均为乱码。

解决过程：

1.刚开始以为是简单的编码不匹配的问题，更改secureCRT中的传输编码方法从默认变为utf8，英文不再乱码，但弄成了问号，“??????”；

2.由于英文目录是在挂载的SD卡中的(竟然没有尝试一下网路挂载或则其他的形式下英文是否乱码，汗)，怀疑是挂载SD卡形式不对。网上解答全部都是说，编译内核的时侯fat文件系统的codepage和isochaset配置对，挂载时选择vfat，-o选择codepage和isocharset匹配就好了，具体的是，mount

-tvfat-ocodepage=936,iocharset=utf8/dev/mmcblk0p1

/home/。之后接出来几天早上就仍然在摆弄这种东西，无解；

3.有三天突然找到一篇博文，说是busybox的缘由，高版本的busybox取消了英文支持，想不到还有这茬。步入busybox配置，发觉早已勾选了Unicode的支持。这么按博文提示，还须要更改busybox中的另外两个文件printable_string.c以及unicode.clinux 文件中文乱码，把小于0x7f替换为问号的这个选择条件去除才行。看了一下源码，认为改的地方都是不勾Unicode才须要改的……不过还是试一下吧，重新配置编译busybox，替换根文件系统，不过问题仍然……

4.既然里面的提示中早已发觉不勾选Unicode支持英文的方法，那就先试一下不支持Unicode显示英文的形式吧嵌入式linux驱动程序设计从入门到精通，更改printable_string.c以及unicode.c，重新编译，烧录启动设备，发觉除去Unicode果然英文支持了，不再显示问号；

5.并且这样子草草了事显著是不行的，那又是为何勾选Unicode支持后英文变问号呢？那就只能读源码了，还好范围也可以接受，问题应当就出在更改的两个文件上面。

6.LAST_SUPPORTED_WCHAR，通过busybox源码linux操作系统简介，可以发觉有那么一个判定if(wc>

CONFIG_LAST_SUPPORTED_WCHAR){go

subset;}linux 文件中文乱码，而在subset的地方，wc被形参为问号，这下问题就明朗了，显著是这个LAST_SUPPORTED_WCHAR搞的鬼；

7.查看busybox配置，发觉这个宏定义表示的是RangeofsupportedUnicode

characters，默认填的值才700多，而英文在Unicode中的位置查了一下最高到U+2FA1D，随意给这个值改了一个小于2FA1D的值，重新编译烧录根文件系统，英文显示成功！

走了不少弯路，好在最后问题是解决了！最后记录一下，busybox版本是1.19.4！

本文原创地址：//gulass.cn/jjlnhpzznwtd.html编辑：刘遄，审核员：暂无