@SingeeKing 应该是这个问题了，共享账号的，问题怎样能买到正版？

@leonme 现在遇到的问题不是脚本有什么问题，而是任务根本没有调用到。

@NatsukiKing 我本地和 icloud 里都放同样的脚本了，而且 Qun x 是可以指定存放路径的。放 iloud 时我已经在软件里设置为云端。

@sleepy2koala js 的路径没法指定吧，是它自己去搜索的吧？我在“调试”-“构造请求”里，是可以打开脚本看到源码的。就是没法调起。

@CRVV 关于编码的问题，摸索了一天，再细读你的回复，利益不少。

@also24 真是长见识了，requests 还可以使用 proxies，明天配合 burp 尝试一下。

@luoleng 原方向是需要后者的结果，但现在经 @also24 指点，发现跟字典无关，是 urllib3 低版本的问题。同时我关于字典会转义的指控也是错的，并没有转义，只是__repr__和__str__的区别。

@also24 升级到 1.25.7，可以在测试服务器上看到文件名有数据了，虽然编码还是不对，但距离解决已不远，谢谢你的解答。前期纠结编码，主要是服务器不能管理，无法验证。

@CRVV 的确是开始没搞清楚，跟编码没关系。

@xuboying 是的，确认跟这个没关系，是我搞错方向了。

@also24 自己另外搭了个测试页面来验证，有中文名字的话，服务器端接收完全是空的。

@also24 urllib3 1.23.2
我觉得也是你说的这个问题。

@lc1450 这种方案已经试过来，服务器上是原样出来的，比如 哈哈.txt ，按这样解码，提交上去后服务器显示 %E5%93%88%E5%93%88.txt ，并不是我想要的结果。

@imn1 上传文件，使用 request.post，里面有个参数是 files，传一个字典进去即可，字典有三项，第一是文件名，第二是字节流，第三个是协议格式。如果我文件名是全英文的话没问题，中文则上传成功，但服务器那边解析不出中文文件名，最后结果出错了。

@jyyx 噢，得到了相同的结果。也大概了解了一下__repr__和__str__。第一个解答也是切中要点的。

但更让我迷茫了，看来是搞错了方向，要继续研究解决方案。

@marquina 我提交 iso-8859-1 的值上去，服务器会转换出中文，并非服务器不支持 utf-8，而且无法控制服务器行为。

重点不是编码，是为什么赋值给字典后，字典会进行转义。

@zdnyp 对 python 还是新接触，既然 3.6 结果是一样，那么 3.7 是不是有什么参数，开关可以做到输出一样的结果?

@marquina 将 ‘源代码’提交到服务器是出错的，必须提交'\xe6\xba\x90\xe4\xbb\xa3\xe7\xa0\x81' 才可以。