关于你不想知道的所有Python3 unicode特性(3)
这不是最差的版本。不是因为我想让事情更加复杂，它现在就是有这么复杂。例如在例子里没有做的是在读取一个二进制的东西是强制清理文本stdout。在这个例子里没有必要，是因为这里的print调用去了stderr而不是stdout，但如果你想打印一些stdout，你就必须清理。为什么？因为stdout是别的缓冲区之上的缓冲区，如果你不强制清理它，你的输出顺序可能会出错。
不仅仅是我，例如看：twisted's compat module ，会发现相同的麻烦。
跳起编码舞蹈
为了理解shell里的命令行参数，顺便说一些Python3里最糟糕的情况：
- shell把文件名以字节传给脚本
- 字节在命中你的代码前被Python以预期的解码方式解码。因为这是有损好的过程，Python3使用一个特别的错误处理器来处理解码错误。
- Python代码处理一个没有错误的文件，并且需要格式化一个错误信息。因为我们写文本流的时候如果它不是非法的unicode，是不会写替代的。
- 将包含替代的unicode串编码为utf-8，然后告诉它处理替代转义。
- 然后我们从utf-8解码并告诉他忽略错误
- 结果字符串回到只有文本的流里
- 之后终端会解码我们的字符串来进行显示
以下是Python2里的情况：
- shell把文件名作为字节传给脚本
- shell解码字符串来进行显示
因为Python2版本里的字符串处理只是在出错的时候进行纠正，因为shell在显示文件名时能做得更好。
注意这没有让脚本更不对。如果你需要对输入数据进行实际的字符串处理，你就要在2.x和3.x里面切换到unicode处理。但在那种情况，你也想让你的脚本支持一个—charset参数，那么在2.x和3.x上做的工作差不多。只是在3.x上会更加糟糕，你需要构建在2.x上不需要的二进制标准输出。
但你是错误的
很显然我错了，我被人告诉这些：
- 我感到痛苦是因为我不像初学者那样思考，新的unicode系统会对初学者更友好
- 我不考虑windows用户和新的文本模型对windows用户是多么大的改进
- 问题不在于Python，问题在POSIX规范
- Linux发行版需要开始支持C.UTF-8，因为它们被过去一直阻碍着
- 问题是SSH发送了错误的编码。SSH需要修复这个问题。
- Python3里一大堆unicode错误的真正问题是人们不传递明确的编码而假设Python3作出了正确的决定。
- 我与分解代码工作，显然这在Python3里会更难。
- 我应该去改进Python3而不是在twitter和博客上抱怨
- 你在没有问题的地方制造问题。让每个人修复他们的环境和对任何东西进行编码就很好。这是用户的问题。
- Java有这个问题好多年了，这对开发者来说没问题。
你知道吗？我在做HTTP方面的工作的时候就停止了抱怨，因为我接受了这个主意，就是HTTP/WSGI的一大堆问题对人们来说很平常。但你知道什么？在Hello World这样的情况下也有相同的问题。可能我应该放弃获得一个高质量的unicode支持的库，就这么将就了。
我可以对以上观点进行反驳，但最终也没关系了。如果Python3是我唯一使用的Python语言，我会解决所有的问题并且使用它开发。有一个完美的另一个语言叫Python2，它有更大的用户基础，并且用户基础是很牢固的。这时我是非常沮丧的。
Python3可能足够强大，会开始让UNIX走Windows走过的路：在很多地方使用unicode，但我很怀疑这样的做法。
更可能的事情是人们仍旧使用Python2，并且用Python3做一些很烂的东西。或者他们会用Go。这门语言使用了与Python2很相似的模型：任何东西都是字节串。并且假设其编码是UTF-8。到此结束。
