ftp测试分析
形成乱码的原因:
ftp交互时候协商所使用的编码方式:通常是utf-8,协商主要有客户端决定自己使用何种编码。
麒麟(文件管理器)客户端必须使用utf8,协商ok,如果server不支持utf8则乱码。
Windows客户端(资源管理器)理论上支持gbk和utf8, 默认协商用utf8,但是windows客户端按照utf8上传文件时候出问题了
Windows资源管理器上传时候出错便立即执行删除命令删除的时候却传来的正确的编码。
比较下:
为什么会出错:第一行是正确的,utf8 3个字节一个汉字,第二行当成了gbk两个字节一个汉字,那么最后的87 2E被当成一个汉字 由于不能识别就用3F(?)代替了
重要的是:这发生在客户端,就是说还没有上传到服务器就发生了字节损耗(丢失)。所以服务端如何解码都无济于事。
结论:windows 资源管理器的ftp功能自己主动使用utf8,自己却不能良好的支持,可笑的是stor的时候错误,发现错误后(自动)执行dele的时候却又正确了。
限制:windows必须使用资源管理器,linux必须使用文件管理器,不能使用其他客户端,服务端解码无济于事。要求同时兼容这两种客户端,尽量少的干扰客户(客户:操作尽量简单)。
思路:分析windows 资源管理器的ftp的行为特征,强制ftp server协商不允许utf8 OK 粗略测试可行,没有大规模测试