关于python:sys.setdefaultencoding(‘utf-8’)的危险

Dangers of sys.setdefaultencoding('utf-8')

在python 2中设置sys.setdefaultencoding('utf-8')有一种令人沮丧的趋势。有人能列举出问题的真实例子吗？像it is harmful或it hides bugs这样的论点听起来不太有说服力。

更新：请注意，这个问题只与utf-8有关，而不是"在一般情况下"更改默认编码。

如果可以的话，请用代码给出一些例子。

相关讨论

最初的海报要求提供代码，证明交换机是有害的，只是它"隐藏"了与交换机无关的错误。好的。结论概要

根据我收集到的经验和证据，以下是我得出的结论。好的。

现在将默认编码设置为UTF-8是安全的，除了专门的应用程序，处理来自非Unicode就绪系统的文件。好的。

"官方"拒绝转机是基于不再与绝大多数最终用户(而不是图书馆供应商)相关的原因，因此我们应该停止劝阻用户设置转机。好的。

在默认情况下正确处理Unicode的模型中工作比手动处理Unicode API更适合于系统间通信的应用程序。好的。

实际上，在绝大多数用例中，经常修改默认编码可以避免许多用户头痛。是的，在某些情况下，处理多个编码的程序会无声地出错，但是由于可以逐段启用此开关，所以这在最终用户代码中不是问题。好的。

更重要的是，启用这个标志是用户代码的一个真正优势，既可以减少手工处理Unicode转换的开销，使代码混乱，降低可读性，也可以避免程序员在任何情况下都不能正确执行这一操作时可能出现的错误。好的。

由于这些声明与Python的官方通信线路几乎完全相反，我认为对这些结论的解释是有必要的。好的。在野外成功使用修改过的默认编码的示例

费多拉的戴夫·马尔科姆认为这永远是对的。在调查了风险之后，他建议为所有Fedora用户更改分布范围的def.enc.=utf-8。好的。

尽管我列出的散列行为只是为什么python会崩溃，但在处理用户票据时，核心社区中的任何其他对手都不会因为担心或甚至担心同一个人而采取这种行为。好的。

Fedora的简历：诚然，改变本身被核心开发人员描述为"非常不受欢迎"，并且被指控与以前的版本不一致。好的。

仅OpenHub就有3000个项目在做这件事。他们的前端搜索速度很慢，但我估计98%的人使用的是UTF-8。没有发现令人讨厌的惊喜。好的。

有18000个！！)Github主分支已更改。好的。

虽然这一变化在核心社区"不受欢迎"，但在用户群中却相当流行。尽管可以忽略这一点，但由于用户都知道使用黑客解决方案，我认为这不是一个相关的论点，因为我的下一点。好的。

因此，GitHub上总共只有150个错误报告。以100%的有效率，变化似乎是积极的，而不是消极的。好的。

为了总结人们遇到的现有问题，我已经浏览了前面提到的所有门票。好的。

转换def.enc.to utf-8通常是在问题关闭过程中引入的，但不是删除的，通常作为解决方案。一些大公司把它当作临时修复，考虑到它的"坏媒体"，但更多的bug记者对修复感到高兴。好的。
几个(1-5？)项目修改了他们的代码，手工进行类型转换，这样他们就不再需要更改默认值了。好的。
在两个例子中，我看到有人声称，将def.enc.set设置为utf-8会导致完全没有输出，而没有解释测试设置。我无法证实这一说法，我测试了一个，发现相反的说法是正确的。好的。
有人说他的"系统"可能依赖于不改变它，但我们不知道为什么。好的。
有一个(而且只有一个)有真正的理由避免它：ipython或者使用第三方模块，或者测试运行程序以不受控制的方式修改了它们的过程(没有人怀疑def.enc.change是由它的支持者在解释器设置时倡导的，即当"拥有"这个过程时)。好的。

我发现零迹象表明"_"和"U"的不同散列在现实代码中会导致问题。好的。

python不会"中断"好的。

在将设置更改为utf-8之后，单元测试所涉及的Python的任何特性都不会与不使用开关的情况有任何不同。不过，开关本身根本没有经过测试。好的。

它在bugs.python.org上被建议给受挫的用户。好的。

这里，这里或这里的例子(通常与官方警告线相关)好的。

第一个例子展示了如何在亚洲建立交换机(也与Github的论点进行比较)。好的。

伊恩·比金发表了他的支持，支持人们总是支持这种行为。好的。

I can make my systems and communications consistently UTF-8, things will just get better. I really don't see a downside. But why does Python make it SO DAMN HARD [...] I feel like someone decided they were smarter than me, but I'm not sure I believe them.

Ok.

马蒂金·法森在驳斥伊恩时承认，ASCII一开始可能是错误的。好的。

I believe if, say, Python 2.5, shipped with a default encoding of UTF-8, it wouldn't actually break anything. But if I did it for my Python, I'd have problems soon as I gave my code to someone else.

Ok.

在python3，他们不"实践他们所宣扬的"好的。

尽管反对任何定义enc.change由于环境相关的代码或隐含性而如此严厉，但这里的讨论围绕着python3的"unicode三明治"范式的问题以及相应的所需的隐含假设展开。好的。

此外，他们还创造了编写有效python3代码的可能性，比如：好的。

1
2
3
4

>>> from 褐褑褒褓褔褕褖褗褘 import *
>>> def 空手(合氣道): あいき(ど(合氣道))
>>> 空手(う??('?? ') + ?)
??

Diveintopython推荐。好的。

在这个线程中，guido自己建议专业的最终用户使用特定于流程的环境，并将开关设置为"为每个项目创建自定义的Python环境"。好的。

The fundamental reason the designers of Python's 2.x standard library don't want you to be able to set the default encoding in your app, is that the standard library is written with the assumption that the default encoding is fixed, and no guarantees about the correct workings of the standard library can be made when you change it. There are no tests for this situation. Nobody knows what will fail when. And you (or worse, your users) will come back to us with complaints if the standard library suddenly starts doing things you didn't expect.

Ok.

Jython提供即时更改，甚至在模块中。好的。

Pypy不支持Reload(sys)，但在一天内根据用户的请求恢复了它，并且没有提出任何问题。与塞顿"你做错了"的态度相比，毫无证据地宣称这是"邪恶的根源"。好的。

结束此列表后，我确认可以构建一个模块，该模块由于解释程序配置更改而崩溃，执行如下操作：好的。

1
2
3
4
5
6
7
8
9
10
11

def is_clean_ascii(s):
""" [Stupid] type agnostic checker if only ASCII chars are contained in s"""
try:
unicode(str(s))
# we end here also for NON ascii if the def.enc. was changed
return True
except Exception, ex:
return False

if is_clean_ascii(mystr):
<code relying on mystr to be ASCII>

我不认为这是一个有效的论点，因为编写这个双类型接受模块的人明显知道ASCII和非ASCII字符串，并且知道编码和解码。好的。

我认为，这些证据足以表明，在绝大多数情况下，改变这个设置不会导致现实世界中的代码库出现任何问题。好的。好啊。

相关讨论

难道这不应该是一个你在评论马蒂的答案时链接到的博客条目吗？
感谢您的反馈，我现在提供了我调查的总结。
这个答案实在太长了，而且不必要。大多数支持你的论据，占你大部分的论据，充其量似乎只是一个论据，一个民粹，充其量是一个冗长的证据。此外，关于标准化和编码的整个部分是无关的，属于博客文章，而不是堆栈溢出时的答案。你的答案会更好，如果你只是简单地提炼出你的观点的技术原因，没有更多。
谢谢，亚历克西斯，这是一次精彩的编辑之旅。
一些特定的注释：设置不同的默认值就像使用goto。当然，您可以让它工作，但是在开发应用程序时，您将很难做到这一点。在处理unicode时，你会变得不一致，这会让你很痛苦。大多数使用它的人不理解Unicode，认为这是一个简单的方法。
很多Github代码使用的参数并不能证明它是可以使用的，也可以作为大多数开发人员不理解如何正确使用Unicode的证据。您可以看到同样的问题，即缺乏经验的开发人员如何使用super()。一般来说，它是一种货物崇拜，应用和误用，不知道它是如何工作或如果需要。
你是对的，一个默认值，一般来说应该永远不会改变，仅仅是因为问题神奇地消失了，你不知道为什么。你应该知道你在做什么。但是如果你知道它是干什么的话，那么使用python2就更好了。对我来说比Py3更好-但那是另一回事；-)
我也开始理解，您的主要问题似乎是(同意的)事实，您的代码可能会变得不一致的字符串类型通过，一些Unicode一些字节，而没有开关，它将崩溃。还有，我和你在一起：在写第一个py2 l.o.c之前，应该先决定他的lib或进程是使用unicode还是使用字节——一致。我们更喜欢字节-有充分的理由。
@"你在处理unicode时会变得不一致，这会让你很痛苦。"你能详细说明一下咬我们的问题到底是什么吗？因此，江户十一〔二〕似乎是一个相当安全的出路。如果有什么东西会在很长时间内坏掉，我们现在难道没有听说过吗？这难道不意味着使用另一种默认编码时坏掉的东西需要修复吗？谢谢你的洞察力。在我看来，默认情况下，python 2.x拒绝处理ascii>127的方式相当神秘(尽管我都支持python，否则的话)。
@Miraculixx:python 2.0是2000年10月推出的第一个支持Unicode的python版本。它包括在那里的决定，然后禁用设置默认编码。这意味着现在有15年的遗留代码，它们依赖于当您尝试将非ASCII字节连接到不可解码为ASCII等的字节时能够捕获异常。您可能无法修复所有这些代码。
@Miraculixx：你所说的"奥术"被称为前后兼容，当你的语言被世界上数十亿台计算机使用时，这是一项要求。python 3可以进行切换，因为它没有承诺兼容性。
>这意味着现在有15年的遗留代码依赖于能够捕获异常(…)。实际上，15年的遗留代码依赖于标准lib来使用unicode(即sometext'.decode('whatever')，不支持更改默认编码imho类似于说我们不确定unicode支持是否实际有效[在stdlib中]。不管怎样，我明白你的意思。本质上，这意味着转换默认编码并没有得到官方的支持，但是正如这个答案指出的那样，在某些情况下这样做有好处。谢谢你的POV。
如果早点掌握了这些知识，我们将永远不需要python 3，厌倦了浪费十年的python社区时间而导致缺乏创新。
@尼希米：这几乎把我最初的帖子总结成一行。

因为您并不总是希望字符串自动解码为Unicode，或者为此，您的Unicode对象自动编码为字节。由于您需要一个具体的例子，下面是一个：

以一个wsgi Web应用程序为例；您正在通过在循环中将外部进程的产品添加到列表中来构建响应，并且该外部进程为您提供了utf-8编码字节：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

results = []
content_length = 0

for somevar in some_iterable:
output = some_process_that_produces_utf8(somevar)
content_length += len(output)
results.append(output)

headers = {
'Content-Length': str(content_length),
'Content-Type': 'text/html; charset=utf8',
}
start_response(200, headers)
return results

很好，很好，很有效。但随后，你的同事来了，并添加了一个新功能；你现在也提供了标签，这些都是本地化的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

results = []
content_length = 0

for somevar in some_iterable:
label = translations.get_label(somevar)
output = some_process_that_produces_utf8(somevar)

content_length += len(label) + len(output) + 1
results.append(label + '
')
results.append(output)

headers = {
'Content-Length': str(content_length),
'Content-Type': 'text/html; charset=utf8',
}
start_response(200, headers)
return results

你用英语测试过这个，一切都正常，太好了！

但是，translations.get_label()库实际上返回Unicode值，当您切换区域设置时，标签包含非ASCII字符。

wsgi库将这些结果写入套接字，所有Unicode值都会自动编码，因为您将setdefaultencoding()设置为utf-8，但计算的长度完全错误。它太短了，因为UTF-8用多个字节对ASCII范围之外的所有内容进行编码。

所有这些都忽略了实际使用不同编解码器中的数据的可能性；您可能正在写出Latin-1+Unicode，现在您有了一个不正确的长度头和混合的数据编码。

如果您没有使用sys.setdefaultencoding()，就会出现一个异常，您知道您有一个bug，但现在您的客户抱怨响应不完整；页面末尾缺少字节，您不太清楚是怎么回事。

请注意，此方案甚至不涉及可能依赖或不依赖默认值仍为ASCII的第三方库。sys.setdefaultencoding()设置为全局设置，适用于解释器中运行的所有代码。您如何确定这些库中没有涉及隐式编码或解码的问题？

当您只处理ASCII数据时，python 2隐式地在str和unicode类型之间进行编码和解码是有益和安全的。但是，您真的需要知道什么时候意外地混合了Unicode和字节字符串数据，而不是用全局刷覆盖它，并希望得到最好的结果。

相关讨论

you don't always want to have your strings automatically decoded to Unicode中有一个错误——字符串被解码为UTF-8，而不是Unicode对象。
@techtonik:utf-8是一种编码，所以它们将被编码为utf-8。不过，这就是问题所在，当您混合这两种类型时，会得到unicode对象；如果可以解码str，str + unicode会给您unicode。
@techtonik:在我的示例中，translations.get_label()返回unicode对象。wsgi实现还可以选择只连接所有结果，此时，您将得到一个unicode对象作为输出传递到套接字，或者可能传递到另一个wsgi包装标签。我们不知道，因为我们沉默了通常会抛出的所有Python异常。
我不明白。对我来说，就像你说的那样，使用sys.setdefaultencoding("utf-8")python将开始在以前是str的地方生成unicode对象。对吗？(我仍在阅读示例)
一个关于类型转换和变量内容的表肯定有助于正确理解这一点。
是的，当与unicode对象连接时，python将尝试对str对象进行解码，如果这些字节不能作为ascii进行解码，通常会失败。但是，一旦您更改了默认的编解码器，那么可以作为UTF-8进行解码的字节也将被转换，最终得到的是Unicode对象，而您认为是在生成字节值。
因此，在使用sys.setdefaultencoding("utf-8")时，python不会再使用非ascii字符串崩溃。我看不出这种行为对你的例子有多坏。对于我的应用程序(Roundup)，这接近我试图修复的崩溃-stackoverflow.com/questions/28642781/&hellip；
@技术员：我们正在绕圈子。您不会认为这很糟糕，因为您不会看到隐式转换类型有多糟糕。在隐式转换是例外而非默认的语言中，这是一个巨大的问题，您正在全局级别上更改该转换的规则。如果这是按模块配置的，那么您可以自由地拍摄自己的脚，而不必强制任何第三方库您可能使用的问题。但情况并非如此，如果你没有看到这种行为的问题，我不知道该怎么告诉你。
我看到事情可能很糟糕，但我不认为有一个现实世界的例子表明，改变行为就是期望的行为。在您的示例中，应用程序将在国际符号上崩溃，这在stackoverflow.com/questions/28642781/&hellip；中发生，当我们将unicode模板层添加到roundup时，sys.setdefaultencoding("utf-8")是修复崩溃的唯一推荐方法。我从你那里听到的是车祸是一种理想的行为。对不起，我不能同意。
不过，the length you calculated is entirely wrong是一个很好的论据。pastebin.ubuntu.com/10791721在控制台上给出3和6。但这看起来像是Python中的一个bug，它无法处理多字节编码。
@Techtonik：想要的行为是修复Roundup。如果在第三方产品中有一个bug，唯一的解决方法就是进行全局更改，那么该产品就有问题。
@Techtonik：为什么这是一个关于Python如何处理多字节编码的错误？Unicode字符串的长度应该是代码点的数量，而不是任意编解码器中的字节数。字节字符串的长度应为字节数。内容长度头应包含字节计数，而不是代码点计数。我不明白为什么这是一个多字节与单字节的编码问题。
@techtonik：在您的pastie中，得到了字节字符串的长度，编码为utf-8。在没有sys.setdefaultencoding()调用的情况下，您得到相同的输出。
好啊。因此，如果我们不使用len()进行字符串处理，我们基本上节省了使用sys.setdefaultencoding("utf-8")的费用(这似乎是使用roundup核心的情况，而roundup核心似乎只将utf-8字符串内容从db移到模板层)。
只有当外部libs本身使用非英语字符(badlib)或被输入utf-8字符串进行处理时，才会出现外部libs的问题。这将导致问题stackoverflow.com/questions/29586776/&hellip；-如何跟踪传递到外部libs的utf-8字符串。
上面提到的Roundup的问题是issues.roundup-tracker.org/issue250811-我想知道您打算如何解决它。
@Techtonik:在这里使用jinja2可以发现，roundup并不是在练习unicode三明治方法；使应用程序中的所有文本在入口点尽可能早地进行unicode，并且在出口点尽可能晚地进行字节编码。在本文中，我建议您阅读/查看NedBatchelder的实用Unicode演示。
更精确地说，"但是您计算的字节长度是完全错误的"。假设字符串中的字节数等于字符数通常是一个坏主意，但如果str是ascii，则是安全的。试图用unicode字符在py2中编写代码，并且在任何地方都使用unicode，这看起来更改默认编码是很好的——但我想我真正的问题是在某处引入了一个str。谢谢你的解释。

首先：许多反对更改默认ENC的人认为它是愚蠢的，因为它甚至改变了ASCII比较好的。

我认为，公平地说，按照最初的问题，我认为除了从ASCII到UTF-8之外，没有人主张其他任何东西。好的。

setDefaultEncoding("utf-16")示例似乎总是由那些反对更改它的人提出；-)好的。

使用m='a'：1，：2和文件'out.py'：好的。

1 2	# coding: utf-8 print u'é'

然后：好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[*]：结果假设相同。见下文。好的。

在查看这些操作时，更改程序中的默认编码看起来可能不会太差，这使您的结果"接近"只包含ASCII数据。好的。

关于hashing(in)和len()行为，您将得到相同的结果，然后是ASCII(下面的更多结果)。这些操作还表明Unicode字符串和字节字符串之间存在显著的差异，如果被忽略，这可能会导致逻辑错误。好的。

如前所述：这是一个全过程的选项，所以您只需一次选择它——这就是为什么库开发人员永远不应该这样做，而是要使其内部结构井然有序，这样他们就不需要依赖于Python的隐式转换。他们还需要清楚地记录他们所期望的，并返回和拒绝他们没有为之编写lib的输入(如normalize函数，见下文)。好的。

=>在设置为"开"的情况下编写程序会使其他人在代码中使用程序的模块(至少不过滤输入)带来风险。好的。

注意：一些反对者声称def.enc.甚至是一个系统范围的选项(通过sitecustomize.py)，但软件容器化(docker)的最新时代，每个进程都可以在其完美的环境中启动，而不需要开销。好的。

关于hashing和len()行为：好的。

它告诉您，即使使用修改过的def.enc，您仍然不能忽略程序中处理的字符串类型。u""和""是内存中不同的字节序列-不总是这样，但通常是这样。好的。

因此，在测试时，请确保您的程序在使用非ASCII数据时也能正确运行。好的。

有人说，当数据值发生变化时，哈希值可能会变得不相等，尽管由于隐式转换，"=="操作保持相等，但这是反对更改def.enc的一个参数。好的。

我个人并不认同这一点，因为散列行为与不改变散列行为一样。还没有看到一个令人信服的例子，说明由于我"拥有"的过程中的这种设置而产生的不受欢迎的行为。好的。

总而言之，关于setdefaultencoding("utf-8")：关于其哑与否的答案应该更加平衡。好的。

这要看情况而定。虽然它确实避免了崩溃，例如在一条日志语句中的str()操作，但代价是以后出现意外结果的可能性更高，因为错误的类型会使代码的正确运行时间更长，这取决于某个类型。好的。

在任何情况下，对于您自己的代码，它都不应该是学习字节字符串和Unicode字符串之间区别的替代方法。好的。

最后，将默认编码设置为不使用ASCII不会使普通文本操作(如len()、切片和比较)变得更容易-如果假设(byte)字符串使用utf-8进行所有操作可以解决这里的问题。好的。

不幸的是，事实并非如此——总的来说。好的。

"=="和len()结果比人们想象的要复杂得多，但即使在两边都有相同的类型。好的。

w/o def.enc.changed，"=="对于非ASCII总是失败，如表中所示。有了它，它就工作了——有时：好的。

Unicode确实标准化了世界上大约一百万个符号，并给了它们一个数字——但不幸的是，在输出设备中向用户显示的字形和它们所生成的符号之间没有1:1的双射。好的。

为了激励你研究这一点：有两个文件，j1，j2，用相同的编码用相同的程序编写，包含用户输入：好的。

1 2	>>> u1, u2 = open('j1').read(), open('j2').read() >>> print sys.version.split()[0], u1, u2, u1 == u2

结果：2.7.9 Jos_Jose？假(！)好的。

在py2中使用print作为函数，您可以看到原因：不幸的是，有两种方法可以对同一个字符进行编码，即重音"e"：好的。

1 2	>>> print (sys.version.split()[0], u1, u2, u1 == u2) ('2.7.9', 'Jos\xc3\xa9', 'Jose\xcc\x81', False)

你可能会说一个多么愚蠢的编解码器，但它不是编解码器的错。这是Unicode中的一个问题。好的。

所以即使在PY3中：好的。

1 2	>>> u1, u2 = open('j1').read(), open('j2').read() >>> print sys.version.split()[0], u1, u2, u1 == u2

结果：3.4.2 Jos_Jose？假(！)好的。

=>独立于PY2和PY3，实际上独立于您使用的任何计算语言：要编写高质量的软件，您可能必须"规范化"所有用户输入。Unicode标准确实标准化了标准化。在python 2和3中，unicodedata.normalize函数是您的朋友。好的。好啊。

相关讨论

您假设源代码也被编码为UTF-8。或者所有的字节字符串都是UTF-8编码的。隐式编码从unicode到utf-8，然后使用任意编码将该数据与任何其他字节字符串连接将是一个巨大的错误，您通过设置默认编码来屏蔽它。
另一个问题是，代码可以依靠编码或解码错误来实现信号类型差异。包括第三方图书馆。通过设置除ASCII之外的默认编码，您将无法再检测到要实际使用显式编码的utf-8字节->unicode和unicode->字节隐式编码。
无论如何，我还没有遇到一个用例，在这个用例中设置默认编码比正确处理编码更好。这就像使用全球产品一样，你不会使用它们，因为在实践中，你会显著增加虫子的数量。
因此，如果测试确保您的代码正确地与非ASCII数据一起工作，为什么不执行额外的步骤并正确地处理编码和解码，而不是随意地混合类型呢？为什么要依靠setdefaultencoding()拐杖？
总的来说，我不确定你会怎么回答这个问题；是的，Unicode比较有它们的问题，但你实际上并没有说清楚为什么应该避免使用sys.setdefaultencoding()。
是的-我这篇文章的目的是要说明1.这个问题的答案应该更加平衡。2。def.enc=utf-8并不能减轻开发人员理解字节和Unicode字符串差异的压力——因为他自己的代码3。质量文本处理比新手想象的要复杂得多，即使对于len()和比较这样的原子操作也是如此。
断然拒绝1.在我看来，忽略了人们存在的问题，尤其是大量遗留代码——我敢说，大量PY2代码是由解决文本处理之外的特定问题的人编写的——其中包含大量str()操作……此外，像Go和Rust这样相当流行的语言证明了它可以在"utf-8字节字符串三明治"中工作，并且只在需要时使用Unicode函数，这只是暂时的。
当然，python不是go或rust:-)我可以看到有遗留的项目，但这并不意味着当它们使用unicode处理时，它们应该只设置一个全局配置，这样会产生意想不到的结果。找出这些可能引入的细微错误所需的工作量与对这些部分进行选通以及在这些点将字节解码为Unicode对象所需的工作量相同。例如，这至少是普龙公司正在采取的方法。
imho这是最好的答案，因为它清楚地显示了替代品和后果，而不是危险地带！争论。谢谢您。

实词示例1

它在单元测试中不起作用。

测试运行程序(nose、py.test…)首先初始化sys，然后才发现并导入模块。到那时更改默认编码已经太迟了。

同样的优点是，如果有人将代码作为一个模块运行，它就不起作用了，因为它们的初始化是第一个。

是的，混合使用str和unicode，依靠隐式转换，只会把问题进一步推下去。

相关讨论

单元测试模块导入设置sys.defaultencoding('utf-8')的主模块，为什么不工作？
另外，如果有人将sys.defaultencoding('utf-8')作为一个模块运行，您能提供一个实际的例子吗？
@Techtonik在导入经过测试的模块时，导入了大量其他模块，并且可能已经运行了一些其他测试。此外，stdio已经用系统真默认编码初始化。可以说，在导入时您根本不应该更改默认编码，例如，pydoc将无法正常工作。此外，您应该在测试完成后将系统重置为原始状态。总之，如果只测试代码，而不测试其他任何代码，并且只对自己的数据使用隐式转换，而不使用stdio，那么它可能只对您有用。但只有你。
"stdio已经用系统真正的默认编码进行了初始化"-它不总是ascii吗？
在您的例子中，真正的问题似乎是所有单元测试都共享同一个解释器。如果单元测试干扰全局状态，则应将其隔离并在单独的解释器中运行。但对于应用范围，所有单元测试都是一致的，并且使用相同的sys.defaultencoding('utf-8')。另外，请注意，对于这个问题，I utf-8是至关重要的，它与ASCII向后兼容。
sys.setdefaultencoding()没有设置输入或输出编码；我认为您误解了函数的作用。它将混合类型时隐式编码unicode到str或解码str到unicode时使用的编解码器设置为unicode。
它是否与单元测试一起工作，然后取决于与第三方库相同的因素；如果代码依赖于ASCII作为默认值，那么这些测试可能会失败，因为该默认值已全局更改。
@Techtonik Re：混合模块。其他模块首先加载，它们已经导入sys。当模块运行时，更改编码为时已晚。可用的黑客有sitecustomize.py和reload(sys)。早期版本不适用于单元测试，也不可组合。后者是黑色魔法，你自己动手。
实际上，stdio是基于pythoniocodeding和locale初始化的。谢谢，@martijnpieters。

我们应该知道的一件事是

Python 2 use sys.getdefaultencoding() to decode/encode between str and unicode

conversion between str and unicode

因此，如果我们更改默认编码，就会出现各种不兼容的问题。如：

1
2
3
4
5
6
7
8
9
10
11

# coding: utf-8
import sys

print"你好" == u"你好"
# False

reload(sys)
sys.setdefaultencoding("utf-8")

print"你好" == u"你好"
# True

更多的例子：

https://pythonhosted.org/kitchen/unicode-fruminations.html网站

也就是说，我记得有一些博客建议尽可能使用Unicode，在处理I/O时只使用位字符串。我认为如果你遵循这个惯例，生活会容易得多。可以找到更多解决方案：

https://pythonhosted.org/kitchen/unicode fruminations.html一些解决方案

相关讨论

是否可以为U字符串重载==运算符，以便在发生类似这样的隐式转换时，它们总是出错退出？
不，不能。在Python中，无法更改内置类型的定义。
从我的观察来看，我们必须一直使用sys.setdefaultencoding("utf-8")，以便使"你好" == u"你好"成为True，这是正确的。
@尼希米：没错！！就像3 == 3.0也是True一样。equality是一个关于信息本身的语句，而不是关于它被包装到哪个数据类型的语句。
2018年至今，我仍然觉得它近乎疯狂，那些多年来拒绝允许python使用def.enc utf-8开关的人，拒绝修复这样的破坏行为，因为它将是"危险的"……>>> print"abc" == u"abc" => True>>> print"你bc" == u"你bc" => False是相同的，在他们的unicode三明治思想中，在python3的几乎所有I/O库中接受一个安静的decode('utf-8')。
@尼希米最好不要。仅供参考，我已经更新了我的答案以提供解决方案。
@jiacailiu:utf8everywhere.org——Unicode三明治的概念，即不必要地解码I/O上的所有文本值(并将其留给I/O libs进行静默解码("utf-8")，无论在何处)，与使用Unicode作为API(当您需要值对人类的语义意义时)相比，这是完全不可能的，在计算中很少如此。此外：在微服务无处不在的时代，I/O无处不在，处理管道中的系统关心文本值的存在，而不是它们对人类的语义意义。解码毫无意义，而且容易出错，占99%。
@你说的解决方法是什么？我注意到在python 2中与unicode接口的唯一解决方案是由sys.setdefaultencoding("utf-8")提供。
@nehemiah pythonhosted.org/kitchen/&hellip；
@我同意你的看法，也许我们可以利用一些图书馆来帮助我们解决这个问题。pythonhosted.org/厨房/&hellip；
@家菜柳厨房是一个精心制作的图书馆。尽管如此，在您的链接中处理的许多"沮丧"只是在默认编码为UTF-8交换机时不存在。同时，世界已经同意将UTF-8作为无所不在的文本数据编码——这也是python3工作的原因：检查任何I/O lib(redis、httpie，…)，您将看到.decode("utf-8")无处不在，以便将值传递到它们的"unicode sandwith"。使用py2&dflt.encoding utf8，这一切都是不必要的，理想的世界。在需要的地方可以使用Unicode作为API，并通过语言进行适当的转换。