• 从字节理解Unicode(UTF8/UTF16)


    如果你不知道或者不了解什么是Unicode/UTF8/UTF16,请详细阅读这篇文章(这也是这篇博文的先决条件):

    学点编码知识又不会死:Unicode的流言终结者和编码大揭秘

       

    但是如果你看完以上文章后,疑惑为什么一个Unicode:0x4F60(对应汉字是"你")会在UTF8下占用3个字节的存储空间。

    按照排列组合2个字节完全可以存储多数unicode字符,明显字符"你"(0x4F60)是在2个字节最大可能范围内(0xFFFF)。

    但是为什么UTF8却使用3个字节存储字符"你"呢?这样不是明显浪费存储空间吗?

       

    答案不仅是UTF8没有浪费存储空间,而且UTF8还是一个精美的设计,至少在我看来。

       

    Unicode/UTF8/UTF16

    虽然你或许可能知道什么UTF8,但是我还是要简单介绍下什么是UTF8?什么是UTF16?什么是unicode?

       

    看完我开头推荐的那篇详细的博文(学点编码知识又不会死:Unicode的流言终结者和编码大揭秘)。你应该知道unicode是一种索引表,它规定了任何字符的code。比如:字符"你"就是0x4F60,在整个宇宙(你确定是整个宇宙?)的任何地方,只要你用的是unicode,那么"你"的unicode就是"0x4F60"。

       

    所以Unicode并不关心世界上有多少字符,如果你想把一个字符放入Unicode中,那么请告诉我你要放的是什么字符?那么Unicode会给你个索引号码?比如:汉字"你"就是"0x4F60"。也就是假如有一天人类统一了"三体星人"(可惜的是三体星已经被摧毁了。。),我们也可以把三体星文加入到Unicode中。

       

    当然Unicode同样不关心你怎么实现,你怎么把字符编码成字节?所以unicode并不知道字符"你"占用几个字节。这时候就是UTF(Unicode Transformation Formats)来规定unicode字符该如何存储,占用几个字节?

       

    总而言之:

    Unicode定义世界每个字符的索引值。

    UTF8/UTF16实现Unicode的标准,把字符存储到存储介质中。

       

    从字节角度看UTF8

    我们知道存储字节多少只和UTF有关,那么我们先看UTF8一张表.详情请查看wikipedia的介绍 。当然你看百度百科也是可以的。

       

    Bits of

    code point

    First

    code point

    Last

    code point

    Bytes in

    sequence

    Byte 1

    Byte 2

    Byte 3

    Byte 4

    Byte 5

    Byte 6

      7

    U+0000

    U+007F

    1

    0xxxxxxx

      

      

      

      

      

    11

    U+0080

    U+07FF

    2

    110xxxxx

    10xxxxxx

      

      

      

      

    16

    U+0800

    U+FFFF

    3

    1110xxxx

    10xxxxxx

    10xxxxxx

      

      

      

    21

    U+10000

    U+1FFFFF

    4

    11110xxx

    10xxxxxx

    10xxxxxx

    10xxxxxx

      

      

    26

    U+200000

    U+3FFFFFF

    5

    111110xx

    10xxxxxx

    10xxxxxx

    10xxxxxx

    10xxxxxx

      

    31

    U+4000000

    U+7FFFFFFF

    6

    1111110x

    10xxxxxx

    10xxxxxx

    10xxxxxx

    10xxxxxx

    10xxxxxx

    根据这张表,我们可以知道0x4F60(字符"你")是在范围(0x0800-0xFFFF),所以在UF8下需要3个字节来存储。

       

    下面让例子来阐述为什么需要3个字节?首先,先看下这3个字节存放的是什么?

    在windows新建一个txt,写入字符"UTF8你"(加入UTF8是为了有个基准线查看"你"的真实字节值),然后另存为UTF8编码。用notepad++(需要装HEX-editor插件)或者Binary Viewer,查看"你"在UTF8下的16进制值。

       

       

    我们知道字符"UTF8"16进制就是他们的ASNI码"0x55,0x54,0x46,0x38".那么字符"你"在UTF8下3个字节的值是"0xE4/0xBD/0xA0".

       

    "0xE4"-->"11100100".

    "0xBD"-->"10111101".

    "0xA0"-->"10100000".

    查看上面UTF8的表,表给出给出每个字节 的前几个固定的二进制数。

    比如3个字节的Unicode会用到这个格式:"1110xxxx 10xxxxxx 10xxxxxx"来存储字符,对应到字符"你"就是"11100100 /10111101/ 10100000"。

    拿出红色标注的部分"0100 111101 100000",转换成16进制就是"0x4F60"也就对应的是Unicode字符"你"。

       

    现在我们可以知道UTF8固定每个字节的前面几位二进制值,然后用其他的位来表示字符。但是为什么UTF8的设计者们要这样设计呢?

       

    我想这是UTF8为了兼容ASNI所要付出的代价,请查看上表,UTF8下是完全兼容asni,也就是asni标准的下的文档,在UTF8下显示完全不是问题(因为ASNI存储字节值和UTF8是一样的)。字符都是一个一个字节存储的,UTF8肯定是一个一个字节的读取,那么UTF8怎么在完全兼容ASNI前提下,是怎么知道某个字符是需要额外字节信息的?UTF8只有固定前几位二进制来决定这个字符需要以后的几个字节,又因为为了兼容ASNI,所以额外字节也需要固定前2位"10xxxxxx",来决定这个字节值不是代表ASNI字符。ASNI的格式是“0xxxxxxx”。

       

    另外,你也完全可以自己实现一个标准来解释Unicode,比如就叫做UTF9吧,只要你能完全解释Unicode。

    实际上是有UTF7,UTF8,UTF16,UTF32的。

       

    从字节角度看UTF16

    同样的,我们把txt:"UTF8你"另存为UTF16编码(windows下unicode编码就是指UTF16)。

       

    UTF16下的每个字符需要是2个或者4个字节。

    字符"UTF8"在UTF16下就是"0x55/0x0054/0x0045/0x0038",那为什么图片中是0x5500呢?这涉及到高字节序和低字节序。开头的那篇文章也有介绍。字节序仅仅就是先把字符的高位或者低位先放入存储的而已。

    1. 高字节序,高位字节被存在前面
    2. 低字节序,低位字节被存在前面

       

    比如字符"你""0x4F60",第一个字节是"4F"是"高位",第二个字节是"60"是"低位".

    稍微解释下为什么左边是高位,玩笑话就是想想你的银行账户当然是左面数值多才有意义啊。

    那么按照"低字节序" "0x4F60"就被存储为"60 4F"拉。在intel CPU下默认是"低字节序"。

    在UTF16下,存储的字节值和unicode是一一对应的。但是UTF16显示英文(asni)就浪费一个字节。所以英文国家用UTF8的编码比较多。反之其他国家用UTF16的较多。

        

    字节顺序标记(BOM)

    不知道你有没有注意到,在UTF16下的这张图,地址第0,第1位是"FF FE"

     

     

    这就是BOM,通过FF FE或者FE FF来告诉解释器是那种字节序。

    那么你也许会问,为什么UTF8没有字节序呢?那是因为UTF8是以字节为单位,一个一个字节读取。UTF16是以字为单位,一个一个字符(2个字节或者4个字节)读取,这样就会涉及先读取第一个或者第二个字节的情况。

       

    希望这篇文章从存储字节角度看UTF8和UTF16会为给你带来不一样的感觉。

       

       

  • 相关阅读:
    3.2.1 webpack-dev-server的使用
    打印预览及打印
    2.1.8 webpack的环境
    常用docker 启动
    github镜像
    Log解析
    【Bzoj4555】【Luogu P4091】求和(NTT)
    【Bzoj3527】【Luogu3338】[Zjoi2014]力(FFT)
    FFT实现高精度乘法
    Bzoj 2190 仪仗队(莫比乌斯反演)
  • 原文地址:https://www.cnblogs.com/zizifn/p/4716712.html
Copyright © 2020-2023  润新知