选择ASCII编码而不是UTF-8有什么好处？

91

可以使用UTF-8对ASCII中的所有字符进行编码，而无需增加存储量（两者都需要存储一个字节）。

UTF-8除了“ ASCII字符”之外，还具有字符支持的优点。如果是这样的话，为什么我们会永远选择了UTF-8 ASCII编码？

当我们选择ASCII而不是UTF-8时，是否存在用例？

character-encoding utf-8 ascii

— 起搏器
source

9

为了支持传统的东西...

— fretje

9

我的意思是UTF8 也合法支持ASCII。因此，即使您必须支持旧版产品，UTF8也可以正常工作，而无需其他任何更改。

— Pacerier，2011年

3

也许您需要与将8个ASCII字符压缩为7个字节的系统进行互操作？人们做疯狂的东西，以适应的东西。

— 多纳尔研究员

4

叫我疯了，但我会说安全性和稳定性。没有多字节序列的字符集很难破解。不要误会我的意思，当人类语言支持很重要时，ASCII不会减少它。但是，如果您只是在进行一些基本的编程，并且可以将自己挤进编写编译器和操作系统所用的本机语言中，为什么还要增加复杂性？@同胞们最后我检查了一下... ASCII 是 7个字节。（任何多余的东西都不是ASCII并要求麻烦）

— ebyrob

2

@ebyrob我认为Donal Fellows意味着将8个ascii符号打包为7个字节，因为每个符号每个都使用7位... 8 * 7 = 56位= 7个字节。这将意味着一个特殊的编码和解码功能，只是为了节省存储1个字节每8

— dodgy_coder

83

在某些情况下，它可以加快对单个字符的访问。想象一下str='ABC'以UTF8和ASCII编码的字符串（并假设语言/编译器/数据库知道编码）

要C使用数组访问操作符访问此字符串的第三个（）字符（许多编程语言均提供该功能），您可以执行c = str[2]。

现在，如果字符串是ASCII编码的，我们要做的就是从字符串中提取第三个字节。

但是，如果字符串是UTF-8编码的，则必须首先检查第一个字符是一个还是两个字节的字符，然后我们需要对第二个字符执行相同的检查，然后才能访问第三个字符。性能差异越大，字符串越长。

例如，在某些数据库引擎中，这是一个问题，在其中查找位于UTF-8编码的VARCHAR之后的列的开头，数据库不仅需要检查VARCHAR字段中有多少个字符，还需要检查它们每个使用许多字节。

— 麦克尔
source

3

如果数据库不同时存储“字符数” 和 “字节数”，那么我会说这有一些问题...

— Dean Harding

1

TBH，我不知道有哪个数据库可以存储……

— Mchl 2011年

@Mchl：您如何想象数据库知道何时到达字符串末尾？

— 凯文·克莱恩

1

通常通过到达0x00或0x0000

— Mchl 2013年

4

@DeanHarding字符计数如何告诉您第二个字符的起始位置？还是数据库也应该为每个字符偏移量保留一个索引？注意：它不仅是2个字符，而且最多可以是4个字符（除非是6个字符）stackoverflow.com/questions/9533258/…。（我认为只有utf-16具有非常长的可憎性，可能会破坏您的系统）

— ebyrob 2014年

7

如果只使用UTF-8的US-ASCII（或ISO 646）子集，那么另一个就没有真正的优势。实际上，所有内容都被相同地编码。

如果您不打算使用US-ASCII字符集，而是使用（例如）带有典型西欧语言中的重音符号，变音符号等字符，则有区别-大多数仍然可以在ISO 8859中使用单个字节编码，但是在UTF-8中编码时将需要两个或更多字节。当然也有缺点：ISO 8859要求您使用一些带外方法来指定所使用的编码，并且它仅支持一种一次使用这些语言。例如，您可以仅使用一个字节来对西里尔字母（俄语，白俄罗斯语等）的所有字符进行编码，但是如果您需要/想要将它们与法语或西班牙语字符混合（除了US-ASCII中的字符） / ISO 646子集），您几乎是不走运的-您必须完全更改字符集才能做到这一点。

ISO 8859实际上仅对欧洲字母有用。为了支持大多数中文，日文，韩文，阿拉伯文等字母中使用的大多数字母，您必须使用一些完全不同的编码。其中一些（例如，日语的Shift JIS）是绝对难以处理的。如果您有机会支持它们，我认为使用Unicode是值得的，以防万一。

— 杰里·科芬
source

5

ANSI可以是很多东西，在这方面大多数是8位字符集（例如Windows下的代码页1252）。

也许您在考虑ASCII，它是7位并且是UTF-8的适当子集。即，任何有效的ASCII流也都是有效的UTF-8流。

如果您考虑使用8位字符集，那么一个非常重要的优点是，所有可表示的字符都恰好是8位，而在UTF-8中，它们最多可以是24位。

是的，我正在谈论7位ASCII集。您能想到1个优势吗，我们将需要保存ascii而不是utf-8？（因为7位无论如何都将另存为8位，因此文件大小将完全相同）

— Pacerier 2011年

1

如果您的字符大于Unicode值127，则不能将其保存为ASCII。

1

@Pacerier：任何ASCII字符串都是UTF-8字符串，因此没有区别。编码例程的速度可能会更快，具体取决于所使用平台的字符串表示形式，尽管我并不期望会大幅度提高速度，但是会大大降低灵活性。

— back2dos

@Thor这就是为什么我要问，如果保存为ASCII在所有具有任何优势

— Pacerier

5

@Pacerier，如果将XML保存为ASCII，则需要使用＆＃160; 牢不可破的空间这样可以更充实，但是使您的数据更能抵抗ISO-Latin-1和UTF-8编码错误。这是我们的工作，因为我们的基础平台在角色上扮演了许多隐形魔术。保持ASCII格式可使我们的数据更强大。

3

是的，在某些情况下，ASCII是有意义的：文件格式和网络协议。特别是用于以下场合：

您拥有由计算机程序生成和使用的数据，而从未提供给最终用户；
但这对于程序员能够阅读，简化开发和调试很有用。

通过使用ASCII作为编码，您可以避免多字节编码的复杂性，同时至少保留了一些人类可读性。

几个例子：

HTTP是根据八位位组的序列定义的网络协议，但是（至少对于英语编程者而言）HTTP对应于诸如“ GET”，“ POST”，“ Accept-Language”和“以此类推。
PNG图像格式的块类型由四个八位位组组成，但是如果您要对PNG编码器或解码器进行编程，则IDAT意味着“图像数据”和PLTE“调色板”是很方便的。

当然，您需要注意，确实不会将数据呈现给最终用户，因为如果最终看不到数据（例如在URL的情况下），那么用户理所当然会期望该数据能够被显示出来。他们可以阅读的语言。

— 加雷斯·里斯
source

说得好。具有讽刺意味的是，HTTP是地球上传输最多Unicode的协议，仅需要支持ASCII。（实际上，我认为TCP和IP，二进制支持，ASCII支持也是如此……这就是您在该级别堆栈上所需要的全部）

— ebyrob

2

首先：标题使用/ 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。这样就没关系，您不必担心用户使用哪个代码页设置了系统。

— 马里安·韦内玛（Marjan Venema）
source

如果我不需要支持超过128个字符，那么选择ACSII编码而不是UTF8编码有什么好处？

— Pacerier，2011年

除了将自己限制在那些128个字符之外？不多。UTF-8专为满足ASCII和“仅”需要ANSI的大多数西方语言而设计。您会发现，UTF-8仅会编码相对较少数量的带有一个以上字节的较高ANSI字符。有一个原因，大多数HTML页面使用UTF-8作为默认值...

— Marjan Venema

1

@Pacerier，如果您不需要高于127的编码，则在使用某些API进行编码/解码时，选择ASCII可能是值得的，因为UTF需要额外的位验证才能将其他字节视为同一字符，因此可能需要进行额外的计算而不是纯ASCII，无需验证即可读取8位。但是，我只建议您在确实需要进行大型（大型）计算的高级优化并且您知道该优化的工作时使用ASCII。如果没有，请使用UTF-8。

— 卢西亚诺