Web UTF-8编码传给服务器后乱码：中英文支持技术方案

 

1 纯中英文支持技术方案（已开发通过验证）

    优势：

1           该技术方案为真正意义上的中英文支持。

2           可与中文windows与第三方FTP（SSH）客户端的替代使用，它们默认采用GBK字符集。

环境：

1         Linux系统需设置字符集采用GBK编码.

操作方法：编辑/etc/bash.bashrc，在文件结尾加上这样一行：
export LANG=zh_CN.GBK。重新启动

2         服务器端的JAVA虚拟机需要中文环境变量。

操作方法：部署的Linux环境为支持中文字符集。在其上启动即可

3         显示网页编码为UTF-8

不足：

1         需要改变搭载服务器的语言编码，可能会影响在之前安装的其他支持中文的平台。因为某些平台的中文已经是根据原先编码转换后的utf-8编码

2         不支持GBK以外字符集。

3         很多客户端命令行不支持中文。

4         中文不被其他科学计算平台支持。

应用范围：

1         需要支持中文windows与其他中文FTP（SSH）客户端的自由交互与统一。

2         需要支持中文存储功能。

3         中文可以被其他平台直接解读。

测试：

    该技术方法功能测试及运行良好。

 

2 多语言替代支持技术方案（已开发正在使用）

      优势：

1         该技术为替代非ASCII的多语言替代技术，将多语言、空格、符号表述为utf-8编码或者其他规则的编码，统一编码

2         替代实际的多语言将不再受主机环境影响，在存储中为替代语言存储。

  环境：

1         Linux环境语言编码为支持ASCII的任何平台

2         需要客户端与服务端协商解码和转码支持。

不足：

1           替代字符会比原先增加存储空间1/3

2           非英文字符会显示为替代字符，用命令行登录后造成一定程度的阅读困难。

3           转换需要额外开发代码并增加cpu开销，但是都可以转嫁到客户端中完成。

4           不可与其他ftp客户端除英文外的字符文件替代使用。

应用范围：

1           不支持多语言或者空格文件的主机环境

2           需要统一语言的环境

测试：

1         该技术功能测试为可行，可利用Java API中base64和uri编码配置

2 利用url编码技术的测试结果（英文不变，空格用+，其他字符用%和8位16进制编码表示）

1）字符串：测试  eng lish 中文和空     格 _-

转换后:

%E6%B5%8B%E8%AF%95++eng+lish+%E4%B8%AD%E6%96%87%E5%92%8C%E7%A9%BA+++++%E6%A0%BC+_-+

恢复后: 测试  eng lish 中文和空     格 _-

 

2）字符串：newFOLDER

转换后: newFOLDER

恢复后: newFOLDER

 

3）字符串：%+%

转换后: %25%2B%25

恢复后: %+%

 

4）字符串：测试  eng lish 中文和空     格 _-

   转换后: （不转换）

恢复后: 测试  eng lish 中文和空     格 _-

 

3 总结：

1           如果主机环境支持中文，将使用第1种技术方案开发效率最高。

2           如果主机环境不支持中文或空格，将使用第2种技术可以替代支持中文。

3           打包混合支持模式，由应用程序配置决定。