我目前把它放在所有.py文件的顶部：
# -*- coding: utf-8 -*-
多年来，我一直被教导为最佳实践。对我来说，默认情况下强制执行UTF-8的想法是有道理的，特别是我的测试包含许多Unicode字符。它允许我直接在我的代码中编写Unicode文字。
但是，我最近被告知强制源编码为UTF-8可能对跨平台兼容性有害，因为Windows并不默认为UTF-8。我相信它不仅仅是代码编辑器的一个问题，而是处理Unicode的问题在所有地方都是如此。但我并不完全理解这个问题。
这两种方法似乎都有很强的论据。更详细地说，执行/不强制执行源编码有什么好处？有什么问题？
答案 0 :(得分：3)
我不确定我确切地知道您的兼容性问题，但您似乎在混淆两个不同的问题。有一点是：当您在源文件中实际键入字符时，它们使用特定编码进行编码，该编码由文本编辑器和/或操作系统设置决定。另一件事是：当Python读取你的源文件时，根据某种编码解释它找到的内容，这就是你的*-* coding声明告诉它的。
仅仅因为你在文件顶部写# -*- coding: utf-8 -*-并不意味着你的文件实际上是在UTF-8中。该编码声明不会“强制执行”任何内容;它只是告诉Python 假设该文件是UTF-8。
作为一个平行的，想象一下收到一份顶部说的文件“这份文件是用克罗地亚语写的”。阅读本文后，您可能会获得克罗地亚语词典以帮助您理解该文档。然而，仅仅因为它说顶部并不意味着该文件实际上是克罗地亚语;任何人都可以拿一份用阿尔巴尼亚语或其他语言写成的文件，并在顶部写上“这份文件是用克罗地亚文撰写的” - 事实上，他们可能会这样做，如果他们不熟悉这两种语言而且不知道如何分辨出来。
类似地，如果您使用不支持Unicode的文本编辑器，即使您在顶部写了“coding：utf-8”，它也可能会轻易地将非UTF8字符插入到文件中。如果你以后尝试运行该文件，这将导致问题，因为Python会认为它是UTF-8，即使它确实不是。
UTF-8仍然是最好的编码。唯一的问题是你应该确保你的编辑器已经设置好了，所以它真的是用UTF-8编码你的文件。
如果其他人获取您的代码并进行修改，也可能使用不使用UTF-8的编辑器，如果他们的编辑器将非UTF-8内容放入文件中，这同样会导致问题。这意味着如果您与其他人共享代码（例如，您是开发软件的团队的一员），您应该同意编码并始终如一地使用它。可以想象，您可以成为组织的一部分，其策略是使用除UTF-8之外的某些编码（例如，Latin-1），在这种情况下，您必须将编辑器设置为使用该编码。然而，越来越多的组织大到可以在不同的人之间广泛地共享代码，他们意识到每个人都应该一直使用UTF-8。
（从互联网上下载代码并尝试修改代码的人也会遇到相同的编码问题，但如果你的文件是UTF-8并且有UTF-8编码声明，那么它就是自我记录。如果别人用另一种编码搞砸了，这是他们自己的错，因为你没有注意。你只需要担心这些问题，只要你真正关心与他人合作;你不能也不应该担心那些无数的错误。如果他们遇到您的代码，互联网上的随机人员可能会这样做。）
答案 1 :(得分：1)
许多代码编辑都不会理解您的编码声明。而且，在Windows上，其中许多将默认使用您配置的代码页而不是UTF-8。更糟糕的是，如果您编辑mojibake代码并将其保存，它将会出现双重误导，并且会产生可怕的误导性 - 您将拥有CP1252文本声称是UTF-8。
所以，这很糟糕。
但是，不用编码声明会让事情变得更糟。然后，即使是更好的编辑器（读取编码声明）也会使您的代码出错。更糟糕的是，Python解释器会让你的代码出错！
当然，您可以使用Unicode转义序列在必要时使用Unicode编写所有代码（包括任何字符串文字）。好处是你可以避免与源代码的所有编码相关的问题（好吧，只要你坚持ASCII兼容的编码，但因为当前版本的Python甚至不能在任何EBCDIC机器或ZX81上运行或无论如何，你可以忽略它。缺点是对于某些类型的代码来说它的可读性要低得多（例如，主要工作是用捷克语中的邮件合并模板构建文本的代码，如果这些模板被写成字符串文字，那就很好了使用Unicode转义）。
无论如何，如果你坚持所有的ASCII，那么是的，添加一个编码声明可能是一个坏主意（因为它可能误导你或其他维护者认为他们可以安全地插入非ASCII字符，你故意避免这样做）。但除此之外，它绝对必要。