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 打包混合支持模式,由应用程序配置决定。