我的源代码应该使用UTF-8吗？

我觉得通常您并不真正选择代码的格式。我的意思是，过去我的大多数工具都为我决定了。或者我甚至都没有真正考虑过。前几天我在Windows上使用TextPad，并且在保存文件时，它提示我有关ASCII，UTF-8 / 16，Unicode等的信息。

我假设几乎所有编写的代码都是ASCII，但是为什么要使用ASCII？我们现在是否应该使用UTF-8文件作为源代码，为什么？我想这可能对多语言团队有用。是否有与多语言团队如何命名变量/函数/等相关的标准？

不能在ASCII和UTF-8之间选择。ASCII是7位编码，而UTF-8取代了它-任何有效的ASCII文本也是有效的UTF-8。当您使用非ASCII字符时会出现问题。对于这些，您必须在UTF-8，UTF-16，UTF-32和各种8位编码（ISO-xxxx等）之间进行选择。

最好的解决方案是坚持使用严格的ASCII字符集，即不要在代码中使用任何非ASCII字符。大多数编程语言都提供了使用ASCII字符表示非ASCII字符的方法，例如"\u1234"，将Unicode代码点指示为1234。尤其是，避免将非ASCII字符用作标识符。即使它们工作正常，使用不同键盘布局的人也会因使他们键入这些字符而受到诅咒。

如果您无法避免使用非ASCII字符，则最好选择UTF-8。与UTF-16和UTF-32不同，它是ASCII的超集，这意味着使用错误编码打开它的任何人至少都会正确地使用它。与8位代码页不同，它可以毫无疑问地编码几乎所有您需要的字符，并且它在每个系统中都可用，而与语言环境无关。

然后，您就可以进行代码处理的编码了。这不必与源文件的编码相同。例如，我可以轻松地用UTF-8编写PHP，但是将其内部多字节编码设置为Latin-1；因为PHP解析器根本不关心编码本身，而只是读取字节序列，所以我的UTF-8字符串文字会被误解为Latin-1。如果我在UTF-8终端上输出这些字符串，则不会看到任何差异，但是字符串长度和其他多字节操作（例如substr）将产生错误的结果。

我的经验法则是对所有内容都使用UTF-8。仅在绝对必须使用其他编码的情况下，请尽早转换为UTF-8，并尽早从UTF-8转换。

大多数IDE将默认使用UTF-8编码进行保存，并且您几乎可以肯定在给定选项的情况下选择UTF-8而不是ASCII。这将确保您不会在国际化代码中遇到奇怪的问题。

能够在源代码中的带引号的字符串或字符中键入纯文本，并且能够看到实际的字符非常好。例如，pi符号'π'或表意符号'𠀊'比pi的等效符号'\ u3c0'和表意符号的L'\ u2000A'更好。

可以像在体面的编辑器中一样将ASCII字符直接键入和/或复制并粘贴到源代码中，就像ASCII字符一样。

我发现一些具体示例有助于概念化和理解单词描述有时似乎无法带回家的事物。概念化输入到源代码中的Unicode字符常量，例如以下简短的示例代码片段：

const unsigned char  ASCII_0X7E      = (unsigned char)  '~';
const unsigned short UNICODE_0X3C0   = (unsigned short) 'π';
const unsigned long  UNICODE_0X2000A = (unsigned long)  '𠀊';
const unsigned long  UNICODE_0X2893D = (unsigned long)  '𨤽';

ASCII代字字符'〜'可以保存在ASCII或UTF-8源文件中，但是Unicode字符不能以ASCII形式存储。PI符号“π”是Unicode代码点0x3c0，可以以UTF-8形式存储为两个字节的值0xcf，0x80。Unicode代码点0x2000a和0x2893d的表意文字需要4字节的UTF-8序列。

为了使这些字符保留其预期值并让编译器按预期解释它们，需要以支持Unicode字符集的格式（例如UTF-8或UTF-16）保存源代码。如果将其保存为UTF-8，则体面的编译器将按预期理解和解释这些值，并且体面的编辑器将正确加载和显示字符。

正如其他人指出的那样，如果您的源代码中根本没有任何字符不在ASCII范围内，则另存为UTF-8将导致文件与保存ASCII文件没有区别，因为UTF- 8被设计为在ASCII字符范围内与ASCII重叠。一旦您在源代码中键入了超出ASCII范围的任何字符，一个体面的编辑器就会通知您，您必须选择一种编码来保存文件。UTF-8是一个不错的选择，因为它可以按原样处理ASCII以及开发环境中几乎支持的所有其他字符。