blocks|key|275496|text|在ASCII字符代表文本块中的大多数字符的情况下，UTF-8具有优势，因为UTF-8将这些字符编码为8位(如ASCII)。这也是有利的，因为只包含ASCII字符的UTF-8文件具有与ASCII文件相同的编码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275497|在ASCII不占主导地位的情况下，UTF-16更好，因为它主要使用每个字符2个字节。对于高位字符，UTF-8将开始使用3个或更多字节，而对于大多数字符，UTF-16仍然只使用2个字节。|275498|UTF-32将在4个字节中覆盖所有可能的字符。这使得它变得相当臃肿。我想不出使用它有什么好处。|275499|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

UTF-8 has an advantage in the case where ASCII characters represent the majority of characters in a block of text, because UTF-8 encodes these into 8 bits (like ASCII). It is also advantageous in that a UTF-8 file containing only ASCII characters has the same encoding as an ASCII file.

UTF-16 is better where ASCII is not predominant, since it uses 2 bytes per character, primarily. UTF-8 will start to use 3 or more bytes for the higher order characters where UTF-16 remains at just 2 bytes for most characters.

UTF-32 will cover all possible characters in 4 bytes. This makes it pretty bloated. I can't think of any advantage to using it.

blocks|key|4339769|text|简而言之：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4339770|4339771|UTF-8:可变宽度编码，向后兼容ASCII码。ASCII字符(U%2B0000到U%2B007F)占用1个字节，码点U%2B0080到U%2B07FF占用2个字节，码点U%2B0800到U%2BFFFF占用3个字节，码点U%2B10000到U%2B10FFFF占用4个字节。适用于英文文本，不适合亚洲文本。|unordered-list-item|4339772|UTF-16:可变宽度编码。代码点U%2B0000到U%2BFFFF占用2个字节，码点U%2B10000到U%2B10FFFF占用4个字节。英文文本不好，亚洲文本好。|4339773|UTF-32:固定宽度编码。所有代码点都需要四个字节。这是一个巨大的内存占用，但操作起来很快。很少使用。|4339774|4339775|参见维基百科：UTF-8、UTF-16和UTF-32。|offset|length|4339776|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/UTF-8|1|http://en.wikipedia.org/wiki/UTF-16|2|http://en.wikipedia.org/wiki/UTF-32^0|0|0|0|0|0|0|7|5|0|D|6|1|K|6|2|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|14|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@]|9|@$M|17|N|18|1|19]|$M|1A|N|1B|1|1C]|$M|1D|N|1E|1|1F]]|A|$]]|$1|O|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]|Y|$5|R|S|T|A|$U|Z]]]]

In short:

<ul>
<li>UTF-8: Variable-width encoding, backwards compatible with ASCII. ASCII characters (U+0000 to U+007F) take 1 byte, code points U+0080 to U+07FF take 2 bytes, code points U+0800 to U+FFFF take 3 bytes, code points U+10000 to U+10FFFF take 4 bytes. Good for English text, not so good for Asian text.</li>
<li>UTF-16: Variable-width encoding. Code points U+0000 to U+FFFF take 2 bytes, code points U+10000 to U+10FFFF take 4 bytes. Bad for English text, good for Asian text.</li>
<li>UTF-32: Fixed-width encoding. All code points take four bytes. An enormous memory hog, but fast to operate on. Rarely used.</li>
</ul>

In long: see Wikipedia: <a href="http://en.wikipedia.org/wiki/UTF-8" rel="noreferrer">UTF-8</a>, <a href="http://en.wikipedia.org/wiki/UTF-16" rel="noreferrer">UTF-16</a>, and <a href="http://en.wikipedia.org/wiki/UTF-32" rel="noreferrer">UTF-32</a>.

blocks|key|275375|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275376|UTF-8是可变1到4字节。|unordered-list-item|offset|length|style|BOLD|275377|UTF-16是可变2或4字节。|275378|UTF-32是固定的E110+E1104+E211字节。H212F213|275379|注意:按照最新的约定，UTF-8可以包含1到6个字节：https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html|275380|entityMap|0|LINK|mutability|MUTABLE|url|https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html^0|0|8|3|0|9|3|0|0|R|1U|0|0^^$0|@$1|2|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|W|7|@$D|X|E|Y|F|G]]|8|@]|9|$]]|$1|H|3|I|4|C|6|Z|7|@$D|10|E|11|F|G]]|8|@]|9|$]]|$1|J|3|K|4|5|6|12|7|@]|8|@]|9|$]]|$1|L|3|M|4|5|6|13|7|@]|8|@$D|14|E|15|1|16]]|9|$]]|$1|N|3|-4|4|5|6|17|7|@]|8|@]|9|$]]]|O|$P|$4|Q|R|S|9|$T|U]]]]

<ul>
<li>UTF-8 is variable 1 to 4 bytes.</li>
<li>UTF-16 is variable 2 or 4 bytes.</li>
<li>UTF-32 is fixed 4 bytes.</li>
</ul>

Note: UTF-8 can take 1 to 6 bytes with latest convention: <a href="https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html" rel="noreferrer">https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html</a>

blocks|key|1005026|text|Unicode定义了一个庞大的字符集，为每个图形符号分配一个唯一的整数值(这是一个重大简化，实际上并不是真的，但对于这个问题来说已经足够接近了)。UTF-8/16/32只是不同的编码方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1005027|简而言之，UTF-32对每个字符使用32位值。这使得他们可以对每个字符使用固定宽度的代码。|1005028|默认情况下，UTF-16使用16位，但这只能提供65k个字符，对于完整的Unicode集来说远远不够。因此，一些字符使用成对的16位值。|1005029|默认情况下，UTF-8使用8位值，这意味着127个第一个值是固定宽度的单字节字符(最高有效位用于表示这是多字节序列的开始，留下7位作为实际字符值)。所有其他字符都被编码为最多4个字节的序列(如果内存有效)。|1005030|这就引出了我们的优势。任何ASCII字符都直接与UTF-8兼容，因此对于升级传统应用程序，UTF-8是一个常见且显而易见的选择。在几乎所有的情况下，它也会使用最少的内存。另一方面，你不能保证一个字符的宽度。它可能是1个、2个、3个或4个字符，这使得字符串操作变得困难。|1005031|UTF-32正好相反，它使用了最多的内存(每个字符都是固定的4字节宽)，但另一方面，您知道每个字符都有这个精确的长度，所以字符串操作变得简单得多。您可以简单地根据字符串的字节长度来计算字符串中的字符数。使用UTF-8不能做到这一点。|1005032|UTF-16是一种折衷方案。它允许大多数字符适合固定宽度的16位值。因此，只要没有中文符号、音符或其他符号，就可以假设每个字符都是16位宽。它比UTF-32使用更少的内存。但在某些方面，这是“两个世界中最糟糕的”。它几乎总是比UTF-8使用更多的内存，并且仍然无法避免困扰UTF-8+(可变长度字符)的问题。|1005033|最后，只使用平台支持的内容通常是有帮助的。Windows在内部使用UTF-16，因此在Windows上，这是显而易见的选择。|1005034|Linux略有不同，但它们通常使用UTF-8来处理与Unicode兼容的所有内容。|1005035|所以简而言之:这三种编码都可以编码相同的字符集，但它们将每个字符表示为不同的字节序列。|1005036|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

Unicode defines a single huge character set, assigning one unique integer value to every graphical symbol (that is a major simplification, and isn't actually true, but it's close enough for the purposes of this question). UTF-8/16/32 are simply different ways to encode this.

In brief, UTF-32 uses 32-bit values for each character. That allows them to use a fixed-width code for every character.

UTF-16 uses 16-bit by default, but that only gives you 65k possible characters, which is nowhere near enough for the full Unicode set. So some characters use pairs of 16-bit values.

And UTF-8 uses 8-bit values by default, which means that the 127 first values are fixed-width single-byte characters (the most significant bit is used to signify that this is the start of a multi-byte sequence, leaving 7 bits for the actual character value). All other characters are encoded as sequences of up to 4 bytes (if memory serves).

And that leads us to the advantages. Any ASCII-character is directly compatible with UTF-8, so for upgrading legacy apps, UTF-8 is a common and obvious choice. In almost all cases, it will also use the least memory. On the other hand, you can't make any guarantees about the width of a character. It may be 1, 2, 3 or 4 characters wide, which makes string manipulation difficult.

UTF-32 is opposite, it uses the most memory (each character is a fixed 4 bytes wide), but on the other hand, you know that every character has this precise length, so string manipulation becomes far simpler. You can compute the number of characters in a string simply from the length in bytes of the string. You can't do that with UTF-8.

UTF-16 is a compromise. It lets most characters fit into a fixed-width 16-bit value. So as long as you don't have Chinese symbols, musical notes or some others, you can assume that each character is 16 bits wide. It uses less memory than UTF-32. But it is in some ways "the worst of both worlds". It almost always uses more memory than UTF-8, and it still doesn't avoid the problem that plagues UTF-8 (variable-length characters).

Finally, it's often helpful to just go with what the platform supports. Windows uses UTF-16 internally, so on Windows, that is the obvious choice.

Linux varies a bit, but they generally use UTF-8 for everything that is Unicode-compliant.

So short answer: All three encodings can encode the same character set, but they represent each character as different byte sequences.

blocks|key|3493170|text|Unicode是一种标准，关于UTF-x，您可以将其视为一些实际用途的技术实现：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3493171|3493172|UTF-8+-+"size+optimized"：最适合基于拉丁字符的数据(或ASCII码)，每个字符只需要1个字节，但大小相应地增长符号种类(在最坏的情况下，每个character)|unordered-list-item|offset|length|style|BOLD|3493173|UTF-16可能增长到6个字节-“character)|3493174|UTF-32+balance”：每个字符最少需要2个字节，这对于具有固定大小的现有主流语言集已经足够了，以简化字符处理(但大小仍然是可变的，每个"performance"：可以增长到4个字节)允许使用简单的算法，例如固定大小字符(4字节)的结果，但带有内存disadvantage|3493175|3493176|entityMap^0|0|0|0|5|9|E|0|0|6|0|0|6|21|B|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@$F|T|G|U|H|I]|$F|V|G|W|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|X|8|@$F|Y|G|Z|H|I]]|9|@]|A|$]]|$1|L|3|M|5|E|7|10|8|@$F|11|G|12|H|I]|$F|13|G|14|H|I]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|P|$]]

Unicode is a standard and about UTF-x you can think as a technical implementation for some practical purposes:

<ul>
<li>UTF-8 - "size optimized": best suited for Latin character based data (or ASCII), it takes only 1 byte per character but the size grows accordingly symbol variety (and in worst case could grow up to 6 bytes per character)</li>
<li>UTF-16 - "balance": it takes minimum 2 bytes per character which is enough for existing set of the mainstream languages with having fixed size on it to ease character handling (but size is still variable and can grow up to 4 bytes per character)</li>
<li>UTF-32 - "performance": allows using of simple algorithms as result of fixed size characters (4 bytes) but with memory disadvantage</li>
</ul>

blocks|key|3493296|text|我试着在我的blogpost中给出一个简单的解释。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3493297|UTF-32|3493298|需要32位(4字节)来对任何字符进行编码。例如，为了使用此方案表示"A“字符代码点，您需要将65写成32位二进制数：|3493299|00000000+00000000+00000000+01000001+(Big+Endian)|code-block|syntax|javascript|3493300|如果仔细观察，您会注意到使用ASCII方案时，最右边的7位实际上是相同的位。但由于UTF-32是固定宽度方案，我们必须附加三个额外的字节。这意味着如果我们有两个只包含"A“字符的文件，一个是ASCII编码的，另一个是UTF-32编码的，那么它们的大小将分别为1字节和4字节。|3493301|UTF-16|3493302|许多人认为，由于UTF-32使用固定宽度的32位来表示码点，所以UTF-16是固定宽度的16位。不对!|3493303|在UTF-16中，码点可以用16比特或32比特表示。因此，该方案是一种变长编码系统。与UTF-32相比有什么优势？至少对于ASCII，文件的大小不会是原始文件的4倍(但仍然是原来的两倍)，所以我们仍然不能向后兼容ASCII。|3493304|由于7位足以表示"A“字符，我们现在可以使用2个字节而不是像UTF-32那样使用4个字节。它看起来像这样：|3493305|00000000+01000001|3493306|UTF-8|3493307|你猜对了..在UTF-8中，码点可以用32位、16位、24位或8位来表示，并且作为UTF-16系统，该码点也是可变长度编码系统。|3493308|最后，我们可以用与使用ASCII编码系统表示A相同的方式来表示"A“：|3493309|01001101|3493310|一个UTF-16实际上比UTF-8更好的小示例：|3493311|以中文字母"語“为例，它的UTF8编码是：|3493312|11101000+10101010+10011110|3493313|而它的UTF-16编码更短：|3493314|10001010+10011110|3493315|为了理解它的表现以及它是如何被解释的，请访问原始帖子。|3493316|entityMap|0|LINK|mutability|MUTABLE|url|https://dev.to/marounmaroun/unicode-and-character-sets-2p86^0|6|8|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@$A|1R|B|1S|1|1T]]|C|$]]|$1|D|3|E|5|6|7|1U|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1V|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1W|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1X|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|20|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|21|8|@]|9|@]|C|$]]|$1|W|3|X|5|J|7|22|8|@]|9|@]|C|$K|L]]|$1|Y|3|Z|5|6|7|23|8|@]|9|@]|C|$]]|$1|10|3|11|5|6|7|24|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|25|8|@]|9|@]|C|$]]|$1|14|3|15|5|J|7|26|8|@]|9|@]|C|$K|L]]|$1|16|3|17|5|6|7|27|8|@]|9|@]|C|$]]|$1|18|3|19|5|6|7|28|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|J|7|29|8|@]|9|@]|C|$K|L]]|$1|1C|3|1D|5|6|7|2A|8|@]|9|@]|C|$]]|$1|1E|3|1F|5|J|7|2B|8|@]|9|@]|C|$K|L]]|$1|1G|3|1H|5|6|7|2C|8|@]|9|@]|C|$]]|$1|1I|3|-4|5|6|7|2D|8|@]|9|@]|C|$]]]|1J|$1K|$5|1L|1M|1N|C|$1O|1P]]]]

I tried to give a simple explanation in my <a href="https://dev.to/marounmaroun/unicode-and-character-sets-2p86" rel="noreferrer">blogpost</a>. 

<h1>UTF-32</h1>

requires 32 bits (4 bytes) to encode any character. For example, in order to represent the "A" character code-point using this scheme, you'll need to write 65 in 32-bit binary number:

<pre><code>00000000 00000000 00000000 01000001 (Big Endian)
</code></pre>

If you take a closer look, you'll note that the most-right seven bits are actually the same bits when using the ASCII scheme. But since UTF-32 is fixed width scheme, we must attach three additional bytes. Meaning that if we have two files that only contain the "A" character, one is ASCII-encoded and the other is UTF-32 encoded, their size will be 1 byte and 4 bytes correspondingly.

<h1>UTF-16</h1>

Many people think that as UTF-32 uses fixed width 32 bit to represent a code-point, UTF-16 is fixed width 16 bits. WRONG!

In UTF-16 the code point maybe represented either in 16 bits, OR 32 bits. So this scheme is variable length encoding system. What is the advantage over the UTF-32? At least for ASCII, the size of files won't be 4 times the original (but still twice), so we're still not ASCII backward compatible.

Since 7-bits are enough to represent the "A" character, we can now use 2 bytes instead of 4 like the UTF-32. It'll look like:

<pre><code>00000000 01000001
</code></pre>

<h1>UTF-8</h1>

You guessed right.. In UTF-8 the code point maybe represented using either 32, 16, 24 or 8 bits, and as the UTF-16 system, this one is also variable length encoding system.

Finally we can represent "A" in the same way we represent it using ASCII encoding system:

<pre><code>01001101
</code></pre>

<h3>A small example where UTF-16 is actually better than UTF-8:</h3>

Consider the Chinese letter "語" - its UTF-8 encoding is:

<pre><code>11101000 10101010 10011110
</code></pre>

While its UTF-16 encoding is shorter:

<pre><code>10001010 10011110
</code></pre>

In order to understand the representation and how it's interpreted, visit the original post.

blocks|key|3493215|text|UTF-8|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3493216|每个character|3493217|ASCII在1到4个字节之间没有byte-order|unordered-list-item|3493218|
|3493219|uses的概念|3493220|是encoding|3493221|completely自同步的兼容子集，例如，从流中的任何位置丢弃的字节最多会损坏单个character|3493222|pretty大多数所有欧洲语言都以每个字符两个字节或更少的字节进行编码|3493223|3493224|3493225|UTF-16|3493226|必须使用已知的字节顺序或读取字节顺序标记来解析|3493227|3493228|每个字符使用2或4个字节|3493229|3493230|UTF-32|3493231|3493232|每个字符都是4个字节，必须使用已知的字节顺序或读取字节顺序标记来解析|3493233|3493234|3493235|除非大多数字符来自CJK+(中文、日文和韩文)字符空间，否则UTF-8将是最有效的空间。|3493236|UTF-32最适合通过字符偏移量随机访问字节数组。|3493237|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1F|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1G|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|1H|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|1J|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1N|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1O|8|@]|9|@]|A|$]]|$1|W|3|-4|5|F|7|1P|8|@]|9|@]|A|$]]|$1|X|3|Y|5|F|7|1Q|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1S|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|13|3|14|5|F|7|1U|8|@]|9|@]|A|$]]|$1|15|3|-4|5|F|7|1V|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|1X|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1C|$]]

<h3>UTF-8</h3>
<ul>
<li>has no concept of byte-order</li>
<li>uses between 1 and 4 bytes per character</li>
<li>ASCII is a compatible subset of encoding</li>
<li>completely self-synchronizing e.g. a dropped byte from anywhere in a stream will corrupt at most a single character</li>
<li>pretty much all European languages are encoded in two bytes or less per character</li>
</ul>
<h3>UTF-16</h3>
<ul>
<li>must be parsed with known byte-order or reading a byte-order-mark (BOM)</li>
<li>uses either 2 or 4 bytes per character</li>
</ul>
<h3>UTF-32</h3>
<ul>
<li>every character is 4 bytes</li>
<li>must be parsed with known byte-order or reading a byte-order-mark (BOM)</li>
</ul>
UTF-8 is going to be the most space efficient unless a majority of the characters are from the CJK (Chinese, Japanese, and Korean) character space.
UTF-32 is best for random access by character offset into a byte-array.

blocks|key|275726|text|在UTF-32中，所有字符都是用32位编码的。优点是你可以很容易的计算出字符串的长度。缺点是，对于每个ASCII字符，您会浪费额外的三个字节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275727|在UTF-8字符中，长度可变，ASCII字符编码在一个字节(8位)中，大多数西方特殊字符编码在两个字节或三个字节中(例如，four是三个字节)，更多的外来字符可以占用多达四个字节。明显的缺点是，你不能预先计算字符串的长度。但是与UTF-32相比，对拉丁语(英语)字母表文本进行编码所需的字节数要少得多。|275728|UTF-16也是可变长度的。字符以两个字节或四个字节进行编码。我真的不明白这一点。它的缺点是可变长度，但没有像UTF-8那样节省空间的优点。|275729|在这三种格式中，UTF-8显然是传播最广泛的。|275730|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In UTF-32 all of characters are coded with 32 bits. The advantage is that you can easily calculate the length of the string. The disadvantage is that for each ASCII characters you waste an extra three bytes.

In UTF-8 characters have variable length, ASCII characters are coded in one byte (eight bits), most western special characters are coded either in two bytes or three bytes (for example € is three bytes), and more exotic characters can take up to four bytes. Clear disadvantage is, that a priori you cannot calculate string's length. But it's takes lot less bytes to code Latin (English) alphabet text, compared to UTF-32.

UTF-16 is also variable length. Characters are coded either in two bytes or four bytes. I really don't see the point. It has disadvantage of being variable length, but hasn't got the advantage of saving as much space as UTF-8.

Of those three, clearly UTF-8 is the most widely spread.

blocks|key|4340440|text|我在MySQL中做了一些测试来比较UTF-8和UTF-16的数据库性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4340441|更新速度|4340442|UTF-8|4340443|​|4340444|📷|atomic|offset|length|4340445|4340446|UTF-16|4340447|4340448|4340449|4340450|插入速度|4340451|4340452|4340453|4340454|4340455|4340456|4340457|删除速度|4340458|4340459|4340460|4340461|4340462|4340463|4340464|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/4c1503ccb78e35f3cc54771995b4ee2a.png|imageAlt|1|https://ask.qcloudimg.com/http-save/yehe-900000/e2dffa740a3ad625d2cd70a9eba749b7.png|2|https://ask.qcloudimg.com/http-save/yehe-900000/2750fb77cf4e99877d78d9783034683f.png|3|https://ask.qcloudimg.com/http-save/yehe-900000/e3923b0449a4a4c7fbc33eba93bbb57a.png|4|https://ask.qcloudimg.com/http-save/yehe-900000/0f92503d03dfd00f9c4929a7b3d3739c.png|5|https://ask.qcloudimg.com/http-save/yehe-900000/ecf69ed95dd816d9dfe992dbf7d7fb9b.png^0|0|0|0|0|0|1|0|0|0|0|0|0|1|1|0|0|0|0|0|1|2|0|0|0|0|1|3|0|0|0|0|0|1|4|0|0|0|0|1|5|0|0^^$0|@$1|2|3|4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1U|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1V|8|@]|9|@$K|1W|L|1X|1|1Y]]|A|$]]|$1|M|3|G|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|20|8|@]|9|@]|A|$]]|$1|P|3|G|5|6|7|21|8|@]|9|@]|A|$]]|$1|Q|3|I|5|J|7|22|8|@]|9|@$K|23|L|24|1|25]]|A|$]]|$1|R|3|G|5|6|7|26|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|27|8|@]|9|@]|A|$]]|$1|U|3|G|5|6|7|28|8|@]|9|@]|A|$]]|$1|V|3|I|5|J|7|29|8|@]|9|@$K|2A|L|2B|1|2C]]|A|$]]|$1|W|3|G|5|6|7|2D|8|@]|9|@]|A|$]]|$1|X|3|G|5|6|7|2E|8|@]|9|@]|A|$]]|$1|Y|3|I|5|J|7|2F|8|@]|9|@$K|2G|L|2H|1|2I]]|A|$]]|$1|Z|3|G|5|6|7|2J|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2K|8|@]|9|@]|A|$]]|$1|12|3|G|5|6|7|2L|8|@]|9|@]|A|$]]|$1|13|3|I|5|J|7|2M|8|@]|9|@$K|2N|L|2O|1|2P]]|A|$]]|$1|14|3|G|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|15|3|G|5|6|7|2R|8|@]|9|@]|A|$]]|$1|16|3|I|5|J|7|2S|8|@]|9|@$K|2T|L|2U|1|2V]]|A|$]]|$1|17|3|G|5|6|7|2W|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|2X|8|@]|9|@]|A|$]]]|19|$1A|$5|1B|1C|1D|A|$1E|1F|1G|-4]]|1H|$5|1B|1C|1D|A|$1E|1I|1G|-4]]|1J|$5|1B|1C|1D|A|$1E|1K|1G|-4]]|1L|$5|1B|1C|1D|A|$1E|1M|1G|-4]]|1N|$5|1B|1C|1D|A|$1E|1O|1G|-4]]|1P|$5|1B|1C|1D|A|$1E|1Q|1G|-4]]]]

I made some tests to compare database performance between UTF-8 and UTF-16 in MySQL.
<h2>Update Speeds</h2>
<h3>UTF-8</h3>
<img src="https://i.stack.imgur.com/AK6CK.png" alt="Enter image description here" />
<h3>UTF-16</h3>
<img src="https://i.stack.imgur.com/FwSHZ.png" alt="Enter image description here" />
<h2>Insert Speeds</h2>
<img src="https://i.stack.imgur.com/3HYaA.png" alt="Enter image description here" />
<img src="https://i.stack.imgur.com/3cUGV.png" alt="Enter image description here" />
<h2>Delete Speeds</h2>
<img src="https://i.stack.imgur.com/3QcMo.png" alt="Enter image description here" />
<img src="https://i.stack.imgur.com/corSh.png" alt="Enter image description here" />

blocks|key|4340182|text|根据开发环境的不同，您甚至可能无法选择字符串数据类型将在内部使用的编码方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4340183|但是对于存储和交换数据，我总是使用UTF-8，如果可以选择的话。如果你有大多数ASCII数据，这将给你最少的数据量传输，同时仍然能够编码一切。对最少的I/O进行优化是在现代机器上进行的方法。|4340184|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Depending on your development environment you may not even have the choice what encoding your string data type will use internally.

But for storing and exchanging data I would always use UTF-8, if you have the choice. If you have mostly ASCII data this will give you the smallest amount of data to transfer, while still being able to encode everything. Optimizing for the least I/O is the way to go on modern machines.

blocks|key|3492692|text|正如前面提到的，区别主要在于底层变量的大小，在每种情况下，这些变量都会变得更大，以允许表示更多的字符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3492693|然而，字体，编码和事情都非常复杂(不必要？)，所以需要一个大的链接来填充更多的细节：|3492694|http://www.cs.tut.fi/~jkorpela/chars.html#ascii|offset|length|3492695|不要期望理解所有的东西，但是如果你不想以后遇到问题，那么尽可能多地学习是值得的，越早越好(或者只是让别人帮你解决)。|3492696|保罗。|3492697|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|1B|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@$F|V|G|W|1|X]]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|E]]]]

As mentioned, the difference is primarily the size of the underlying variables, which in each case get larger to allow more characters to be represented. 

However, fonts, encoding and things are wickedly complicated (unnecessarily?), so a big link is needed to fill in more detail:

<a href="http://www.cs.tut.fi/~jkorpela/chars.html#ascii" rel="nofollow noreferrer">http://www.cs.tut.fi/~jkorpela/chars.html#ascii</a>

Don't expect to understand it all, but if you don't want to have problems later it's worth learning as much as you can, as early as you can (or just getting someone else to sort it out for you). 

Paul.

blocks|key|276231|text|在通读答案之后，UTF-32需要一些关爱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|276232|C#：|276233|Data1+=+RandomNumberGenerator.GetBytes(500_000_000);

sw+=+Stopwatch.StartNew();
int+l+=+Encoding.UTF8.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($"UTF-8:+Elapsed+-+{sw.ElapsedMilliseconds+*+.001:0.000s}+++Size+-+{l:###,###,###}");

sw+=+Stopwatch.StartNew();
l+=+Encoding.Unicode.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($"Unicode:+Elapsed+-+{sw.ElapsedMilliseconds+*+.001:0.000s}+++Size+-+{l:###,###,###}");

sw+=+Stopwatch.StartNew();
l+=+Encoding.UTF32.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($"UTF-32:+Elapsed+-+{sw.ElapsedMilliseconds+*+.001:0.000s}+++Size+-+{l:###,###,###}");

sw+=+Stopwatch.StartNew();
l+=+Encoding.ASCII.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($"ASCII:+Elapsed+-+{sw.ElapsedMilliseconds+*+.001:0.000s}+++Size+-+{l:###,###,###}");|code-block|syntax|javascript|276234|UTF-8+--已用9.939s+-大小473,752,800|276235|Unicode+--已用0.853s+-大小250,000,000|276236|UTF-32+--已用3.143秒-大小为125,030,570|276237|ASCII+--已用2.362秒-大小为500,000,000|276238|UTF-32+--+MIC+DROP|276239|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

After reading through the answers, UTF-32 needs some loving.
C#:
<pre><code>Data1 = RandomNumberGenerator.GetBytes(500_000_000);

sw = Stopwatch.StartNew();
int l = Encoding.UTF8.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($&quot;UTF-8: Elapsed - {sw.ElapsedMilliseconds * .001:0.000s} Size - {l:###,###,###}&quot;);

sw = Stopwatch.StartNew();
l = Encoding.Unicode.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($&quot;Unicode: Elapsed - {sw.ElapsedMilliseconds * .001:0.000s} Size - {l:###,###,###}&quot;);

sw = Stopwatch.StartNew();
l = Encoding.UTF32.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($&quot;UTF-32: Elapsed - {sw.ElapsedMilliseconds * .001:0.000s} Size - {l:###,###,###}&quot;);

sw = Stopwatch.StartNew();
l = Encoding.ASCII.GetString(Data1).Length;
sw.Stop();
Console.WriteLine($&quot;ASCII: Elapsed - {sw.ElapsedMilliseconds * .001:0.000s} Size - {l:###,###,###}&quot;);
</code></pre>
UTF-8 -- Elapsed 9.939s - Size 473,752,800
Unicode -- Elapsed 0.853s - Size 250,000,000
UTF-32 -- Elapsed 3.143s - Size 125,030,570
ASCII -- Elapsed 2.362s - Size 500,000,000
UTF-32 -- MIC DROP

blocks|key|1000725|text|简而言之，使用UTF-16或UTF-32的唯一原因是分别支持非英语和古老的脚本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1000726|我想知道为什么有人会选择使用非UTF-8编码，而对于web/编程目的来说，这种编码显然更有效。|1000727|一个常见的误解--带后缀的数字并不代表它的能力。它们都支持完整的Unicode，只是UTF-8可以处理单字节的ASCII，所以对CPU和互联网来说更有效/更不容易损坏。|1000728|一些好的读物：http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html和http://utf8everywhere.org|offset|length|1000729|entityMap|0|LINK|mutability|MUTABLE|url|http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html|1|http://utf8everywhere.org/^0|0|0|0|7|2A|0|2I|P|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$H|X|I|Y|1|Z]|$H|10|I|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

In short, the only reason to use UTF-16 or UTF-32 is to support non-English and ancient scripts respectively.

I was wondering why anyone would chose to have non-UTF-8 encoding when it is obviously more efficient for web/programming purposes.

A common misconception - the suffixed number is NOT an indication of its capability. They all support the complete Unicode, just that UTF-8 can handle ASCII with a single byte, so is MORE efficient/less corruptible to the CPU and over the internet.

Some good reading: <a href="http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html" rel="nofollow">http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html</a>
and <a href="http://utf8everywhere.org" rel="nofollow">http://utf8everywhere.org</a>

What are the differences between UTF-8, UTF-16, and UTF-32?

I understand that they will all store Unicode, and that each uses a different number of bytes to represent a character. Is there an advantage to choosing one over the other?

UTF-8, UTF-16, and UTF-32

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

UTF-8、UTF-16和UTF-32之间有什么区别？我知道它们都将存储Unicode，并且每个都使用不同的字节数来表示一个字符。选择其中一个有优势吗？

问UTF-8、UTF-16和UTF-32
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问UTF-8、UTF-16和UTF-32EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问UTF-8、UTF-16和UTF-32
EN