Pac*_*ier 4 unicode ansi utf-8 overhead character-encoding
在某处我读过(改述):
如果我们比较UTF-8编码文件VS UTF-16编码文件,有时,UTF-8文件可能会使文件大小增加50%到100%
我是否正确地说这篇文章是错误的,因为在任何时候,以UTF-8编码的文本永远不会给我们提供超过UTF-16编码的相同文本的+ 50%文件大小?
tch*_*ist 26
答案是在UTF-8中,ASCII只有1个字节,但一般来说,包括英语在内的大多数西方语言在这里和那里需要使用2个字节,所以实际百分比会有所不同.当以UTF-8编码时,希腊语和西里尔语在其脚本中每个字符至少需要2个字节.
常见的东方语言要求其字符为UTF-8中的3个字节,而UTF-16中为2个字节.但请注意,"不常见"的东方字符在UTF-8和UTF-16中都需要4个字节.
3确实只比大于2的50%.但这仅适用于单个代码点.它不适用于整个文件.
实际百分比无法准确说明,因为您不知道代码的平衡是指向1字节还是2字节的UTF-8范围,还是4字节的UTF-8范围.如果亚洲文本中有空格,那么这只是UTF-8的字节,但它是一个昂贵的2字节的UTF-16.
这些事情确实有所不同 您只能获得精确文本的精确数字,而不能获得一般文本.亚洲文本中的代码点占用UTF-8的1,2,3或4个字节,而在UTF-16中,它们各自需要2或4个字节.
比较东京各种语言的维基百科页面,看看我的意思.即使在东方语言中,仍然有大量的ASCII.仅这一点就会使你的数字出现波动.考虑:
Paras Lines Words Graphs Chars UTF16 UTF8 8:16 16:8 Language
519 1525 6300 43120 43147 86296 44023 51% 196% English
343 728 1202 8623 8650 17302 9173 53% 189% Welsh
541 1722 9013 57377 57404 114810 59345 52% 193% Spanish
529 1712 9690 63871 63898 127798 67016 52% 191% French
321 837 2442 18999 19026 38054 21148 56% 180% Hungarian
202 464 976 7140 7167 14336 11848 83% 121% Greek
348 937 2938 21439 21467 42936 36585 85% 117% Russian
355 788 613 6439 6466 12934 13754 106% 94% Chinese, simplified
209 419 243 2163 2190 4382 3331 76% 132% Chinese, traditional
461 1127 1030 25341 25368 50738 65636 129% 77% Japanese
410 925 2955 13942 13969 27940 29561 106% 95% Korean
Run Code Online (Sandbox Code Playgroud)
其中每一个都是以文本形式保存 的东京维基百科页面,而不是 HTML.所有文本都在NFC中,而不是在NFD中.每列的含义如下:
我将语言分为西方拉丁语,西方非拉丁语和东方语言.观察:
使用拉丁文字的西方语言在从UTF-8转换为UTF-16后遭受了极大的损失,英语受到的影响最大,增幅为96%,匈牙利语最少,增长率为80%.一切都很大.
不使用拉丁文字的西方语言仍然受到影响,但只有15-20%.
东方语言不会像 UTF-8那样以每个人声称他们的方式来做!看吧:
我希望能回答你的问题.与以UTF-16编码的相同文本相比,使用UTF-8编码时,东方语言的大小不会增加+ 50%到+ 100%.只有在获取单个代码点时,您才会看到类似的数字,这是一个完全不合理的指标.
cha*_*sen 10
是的,你是对的.U + 0800..U + FFFF范围内的代码点大小为+ 50%.
UTF-8 UTF-16
U+0000..U+007F 1 2
U+0080..U+07FF 2 2
U+0800..U+FFFF 3 2
U+010000..U+10FFFF 4 4
Run Code Online (Sandbox Code Playgroud)