强制Python源编码为UTF-8
我现在在所有的 .py 文件顶部都加上这个：
# -*- coding: utf-8 -*-
我从很多年前就被教导这样做是最佳实践。对我来说，默认使用 UTF-8 编码是有道理的，特别是我的测试中包含很多 Unicode 字符。这样我就可以直接在代码中写 Unicode 字面量。
不过，最近有人告诉我，强制使用 UTF-8 编码可能会对跨平台兼容性造成问题，因为 Windows 默认不是 UTF-8。我觉得这不仅仅是代码编辑器的问题，更是如何在不同地方处理 Unicode 的问题。但我对这个问题还不是很明白。
这两种做法似乎都有很强的理由。更详细地说，强制或不强制使用源编码有什么好处？会有什么问题呢？
2 个回答
很多代码编辑器可能不理解你的编码声明。而且在Windows系统上，很多编辑器会默认使用你设置的代码页，而不是UTF-8。更糟糕的是，如果你编辑了那些乱码的代码并保存，它会变成双重乱码，这样就会非常混淆——你会得到声称是UTF-8的CP1252文本。
所以，这样做是很糟糕的。
而且如果不写编码声明，情况会变得更糟。即使是那些比较好的编辑器（能读取编码声明的）也会把你的代码搞错。更糟的是，Python解释器也会把你的代码搞错！
当然，你可以把所有代码（包括字符串）都写成ASCII格式，必要时使用Unicode转义序列。这样做的好处是可以避免源代码中所有与编码相关的问题（只要你坚持使用与ASCII兼容的编码，不过现在的Python版本根本不在EBCDIC机器或ZX81上运行，所以这点你可以忽略）。坏处是，对于某些类型的代码来说，这样可能会让代码变得不太易读（比如，如果你的代码主要是用捷克语的邮件合并模板构建文本，而这些模板是用Unicode转义的字符串字面量写的，那就会显得很难看）。
总之，如果你坚持使用ASCII，那么是的，添加编码声明可能不是个好主意（因为这可能会误导你或其他维护者，以为可以安全地插入非ASCII字符，而你其实是故意避免这样做的）。但如果不是这样，添加编码声明绝对是必要的。
我不太确定你说的兼容性问题具体指什么，但你似乎把两个不同的问题搞混了。首先，当你在源文件中输入字符时，这些字符会根据你的文本编辑器和/或操作系统的设置，使用某种编码方式进行编码。其次，当Python读取你的源文件时，它会根据某种编码方式来“解释”它所找到的内容，而这就是你在文件顶部写的*-* coding声明所告诉它的内容。
仅仅因为你在文件顶部写了# -*- coding: utf-8 -*-，并不意味着你的文件实际上就是UTF-8编码的。这个编码声明并不会“强制”什么，它只是告诉Python假设这个文件是UTF-8编码的。
举个例子，想象一下你收到了一份文件，文件顶部写着“这份文件是用克罗地亚语写的”。看到这句话，你可能会去找一本克罗地亚语的词典来帮助理解这份文件。然而，仅仅因为文件上写了这句话，并不意味着文件真的就是用克罗地亚语写的；任何人都可以拿一份用阿尔巴尼亚语写的文件，在顶部写上“这份文件是用克罗地亚语写的”——实际上，他们可能就是这样做的，如果他们对这两种语言都不熟悉，根本分不清楚。
同样，如果你使用的文本编辑器不支持Unicode，它可能会随意在文件中插入非UTF-8的字符，即使你在顶部写了“coding: utf-8”。如果你后来尝试运行这个文件，就会出现问题，因为Python会认为它是UTF-8编码的，实际上却不是。
UTF-8仍然是最好的编码方式。唯一需要注意的是，你应该确保你的编辑器设置正确，确实是以UTF-8编码你的文件。
还有一种可能性是，如果其他人获取了你的代码并进行了修改，他们可能使用的编辑器并不是UTF-8编码，这同样会导致问题，因为他们的编辑器可能会在文件中插入非UTF-8的内容。这意味着如果你和其他人分享代码（例如，你是一个软件开发团队的一部分），你们应该达成一致，使用相同的编码方式。可以想象，你可能在一个有政策要求使用其他编码（比如Latin-1）的组织中，在这种情况下，你需要将你的编辑器设置为使用那个编码。然而，越来越多的大型组织意识到，大家应该始终使用UTF-8编码。
（如果有人从网上下载你的代码并尝试修改，也可能会遇到同样的编码问题，但如果你的文件是UTF-8编码并且有UTF-8的编码声明，那么它就是自我说明的。如果其他人用其他编码搞乱了文件，那是他们自己不注意的错。你只需要担心这些问题，前提是你真的关心与他人合作；你不需要担心那些在网上随机遇到你代码的人可能犯的各种错误。）