当我们选择ASCII而不是UTF-8时是否存在用例？
#1 楼
在某些情况下，它可以加快对单个字符的访问。想象一下用UTF8和ASCII编码的字符串str='ABC'（并假设语言/编译器/数据库知道编码）使用数组访问运算符从字符串中访问第三个（
C）字符，该函数在现在，如果字符串是ASCII编码的，我们要做的就是从字符串中提取第三个字节。 如果字符串是UTF-8编码的，那么我们必须首先检查第一个字符是一个还是两个字节的字符，然后我们需要对第二个字符执行相同的检查，然后才能访问第三个字符。性能差异越大，字符串越长。
这是一个问题，例如在某些数据库引擎中，在其中查找在UTF-8编码之后的列的开头VARCHAR，数据库不仅需要检查VARCHAR字段中有多少个字符，还需要检查每个字符使用多少个字节。
评论
如果数据库不同时存储“字符数”和“字节数”，那么我会说这有一些问题...
–迪恩·哈丁（Dean Harding）
2011年7月31日在22:20
TBH我不知道任何数据库都可以存储...
– Mchl
2011年8月1日17:45
@Mchl：您如何想象数据库知道何时到达字符串末尾？
–kevin cline
13年1月11日在21:25
通常通过达到0x00或0x0000
– Mchl
13年2月27日在10:11
@DeanHarding字符计数如何告诉您第二个字符的起始位置？还是数据库也应该为每个字符偏移量保留一个索引？注意：它不仅是2个字符，而且最多可以是4个字符（除非是6个字符）stackoverflow.com/questions/9533258/…。 （我认为只有utf-16拥有非常长的可憎性，它们可能会破坏您的系统）
– ebyrob
2014年4月1日下午13:44
#2 楼
如果只使用UTF-8的US-ASCII（或ISO 646）子集，那么一个或另一个就没有真正的优势。实际上，所有内容的编码都是相同的。如果您不打算使用US-ASCII字符集，而是使用（例如）带有重音符号，变音符号等字符，然后是典型的西欧语言，那就有所不同-大多数语言仍可以在ISO 8859中用一个字节进行编码，但是在UTF-8中进行编码时将需要两个或更多字节。当然，也有缺点：ISO 8859要求您使用某种带外手段来指定所使用的编码，并且一次仅支持其中一种语言。例如，您可以仅使用一个字节来对西里尔字母（俄语，白俄罗斯语等）的所有字符进行编码，但是如果您需要/想要将其与法语或西班牙语字符混合使用（除了US-ASCII中的字符） / ISO 646子集），您几乎是不走运的-您必须完全更改字符集才能做到这一点。
ISO 8859实际上仅对欧洲字母有用。为了支持大多数中文，日文，韩文，阿拉伯文等字母中使用的大多数字母，您必须使用一些完全不同的编码。其中一些（例如，日语的Shift JIS）绝对难以处理。如果您有机会支持它们，我认为值得使用Unicode，以防万一。
#3 楼
ANSI可以是很多东西，在这方面，大多数是8位字符集（例如Windows下的代码页1252）。也许您在考虑7位ASCII和UTF-的适当子集， 8。即任何有效的ASCII流也都是有效的UTF-8流。
如果您考虑使用8位字符集，则一个非常重要的优点是，所有可表示的字符都恰好是8位，其中UTF-8最多可以使用24位。
评论
是的，我正在谈论7位ASCII集。您能想到1个优势，我们永远需要将ascii而不是utf-8保存吗？ （由于7位无论如何都将另存为8位，因此文件大小将完全相同）
–起搏器
2011年7月30日14:13
如果您的字符大于unicode值127，则不能将其保存为ASCII。
–user1249
2011年7月30日14:47
@Pacerier：任何ASCII字符串都是UTF-8字符串，因此没有区别。编码例程可能会更快，具体取决于您所使用的平台的字符串表示形式，尽管我不希望有明显的提速，但是灵活性却会大大降低。
–back2dos
2011年7月30日在16:04
@Thor这就是为什么我要问是否保存为ASCII完全没有任何优势的原因
–起搏器
11年7月30日在17:06
@Pacerier, if you save XML as ASCII you need to use e.g. for a non-breakable space. This is more filling, but makes your data more resistant against ISO-Latin-1 vs UTF-8 encoding errors. This is what we do as our underlying platform does a lot of invisible magic with characters. Staying in ASCII makes our data more robust.
– user1249
Jul 30 '11 at 17:29
#4 楼
是的，在某些情况下，ASCII是有意义的：文件格式和网络协议。特别是在以下情况下的使用：您拥有由计算机程序生成和使用的数据，从未呈现给最终用户；
但是对于程序员来说，这是有用的。
通过使用ASCII作为编码，可以避免多字节编码的复杂性，同时至少保留一些人类可读性。
A几个示例：
HTTP是根据八位位组的序列定义的网络协议，但是它们对应于八位位组非常有用（至少对于说英语的程序员而言）诸如“ GET”，“ POST”，“ Accept-Language”之类的单词的ASCII编码。
PNG图像格式的块类型由四个八位字节组成，但是如果您要对PNG进行编程则非常方便编码器或解码器，其中
IDAT表示“图像数据”，而PLTE表示“调色板”。当然，您需要注意数据不会真正呈现给最终用户，因为如果它是发现是可见的（例如在URL的情况下），那么用户理所当然地希望数据使用他们可以阅读的语言。
评论
说得好。具有讽刺意味的是，HTTP是地球上传输最多Unicode的协议，仅需要支持ASCII。 （实际上，我想TCP和IP，二进制支持，ASCII支持也是如此……这就是您在该级别堆栈中所需要的全部）
– ebyrob
2014年4月1日在13:58
#5 楼
首先：标题使用/ d ANSI，而在文本中则引用ASCII。请注意，ANSI不等于ASCII。 ANSI包含ASCII集。但是ASCII集仅限于前128个数字值（0-127）。如果所有数据都限于ASCII（7位），则是否使用UTF- 8，ANSI或ASCII，因为ANSI和UTF-8都包含完整的ASCII集。换句话说：0到127之间的数字值表示ASCII，ANSI和UTF-8中的完全相同的字符。
如果需要ASCII集合之外的字符，则需要选择一种编码。您可以使用ANSI，但随后会遇到所有不同代码页的问题。如果将这些机器设置为使用不同的代码页，则在机器A上创建文件并在机器B上读取文件可能会/将产生有趣的文本，这很简单，因为数值nnn表示这些代码页中的不同字符。
此“代码页地狱”是定义Unicode标准的原因。 UTF-8只是该标准的单一编码，还有更多。 UTF-16是最广泛使用的，因为它是Windows的本机编码。
因此，如果您需要支持ASCII集的128个字符以外的任何字符，我的建议是使用UTF- 8。这样就没有关系，您不必担心用户使用哪个代码页设置了系统。
评论
如果我不需要支持超过128个字符，那么选择ACSII编码而不是UTF8编码有什么好处？
–起搏器
2011年7月30日17:16
除了将自己限制在那些128个字符之外？不多。 UTF-8是专门为满足ASCII和“仅”需要ANSI的大多数西方语言而设计的。您会发现，UTF-8将仅对相对较小数量的具有一个以上字节的较高ANSI字符编码。大多数HTML页面使用UTF-8作为默认值是有原因的...
– Marjan Venema
11年7月30日在18:57
@Pacerier，如果您不需要高于127的编码，则当您使用某些API进行编码/解码时，选择ASCII可能是值得的，因为UTF需要额外的位验证才能将其他字节视为同一字符，因此可能需要进行额外的计算，而不是纯ASCII，无需验证即可读取8位数据。但是，我只建议您在确实需要大型（大型）计算中的高级优化并且知道您在该优化中正在做什么的情况下使用ASCII。如果没有，请使用UTF-8。
–卢西亚诺
2012-12-19 13:03
评论
为了支持遗留物...我的意思是UTF8也合法支持ASCII。因此，即使您必须支持旧版内容，UTF8也可以正常工作，而无需进行其他任何更改。
也许您需要与将8个ASCII字符压缩为7个字节的系统进行互操作？人们做了疯狂的事情来适应事物。
叫我疯了，但我会说安全性和稳定性。没有多字节序列的字符集很难破解。不要误会我的意思，当人类语言支持很重要时，ASCII不会削减它。但是，如果您只是在进行一些基本编程，并且可以将自己挤进编写编译器和操作系统所用的本机语言中，为什么还要增加复杂性？ @同胞们最后我检查了一下... ASCII是7个字节。 （任何多余的东西都不是ASCII并引起麻烦）
@ebyrob我认为Donal Fellows意味着将8个ASCII符号打包为7个字节，因为每个符号每个都使用7位... 8 * 7 = 56位= 7个字节。这将意味着特殊的编码和解码功能，只需要每8个保存1个字节的存储空间即可。