HTML与javascript常碰到的编码问题

2023-12-30    分类: 网站建设

在日常的前端开发工作中,我们会经常的与HTML、javascript、css等语言打交道,和一门真正的语言一样,计算机语言也有它的字母表、语法、词法、编码方式等,在这里我简单的谈一下前端HTML与javascript日常工作中常碰到的编码问题。

在计算机中,我们储存的信息都是用二进制码表示的。我们认识的、屏幕上显示的英文、汉字等符号和储存用的二进制代码的互相转换,就是编码。

有两个基本概念需要说明,charset 和 character encoding:

charset ,字符集,也就是某个符号和某个数字映射关系的一个表,也就是它决定了107 是koubei 的 ‘a’,21475 是口碑的“口”,不同的表有不同的映射关系,如 ascii,gb2312,Unicode. 通过这个数字和字符的映射表,我们可以把一个二进制表示的数字转换成某个字符。 chracter encoding ,编码方式。例如,同是对于应“口”的 21475 这个数,我们是用 \u5k3e3 表示呢,还是用 %E5%8F%A3 来表示呢?这就是由 character encoding 来决定的。

对于 ‘koubei.com’ 这样的 字符串来说,是美国人的常用字符,他们就制定了一个 叫做ASCII 的字符集,全称是 american standard code of information interchange 美国标准信息交换码,用0–127这128个数字,(2的7次方,0×00-0×7f) 代表了123abc这样的常用的128个字符。一共是 7 bits,再加上第一个是符号位,要用来去补码反码表示负数什么的,一共8 bits 构成一个 byte。当年美国人就是小气了点,要是一开始就设计成一个 byte 是16 bits、32 bits,世界上会少很多问题,不过当时,估计他们觉得 8 bits 就够了,可以表示128个不同的字符呢!

介于计算机这玩意儿是美国人搞出来的,所以他们自己省事,把自家用的符号都编码好了,用的挺爽的。但当计算机开始国际化的时候,问题出来了,拿中国举例吧,汉字就好几万,怎么办?

现有的 8 bits 一个 byte 的系统是基础,不能破坏,不能去改到 16 bits之类的,否则改动太大了,只能走另一条路:用多个 ascii 的字符去表示一个其他字符,也就是 MBCS ( Multi-Byte Character System,多字节字符系统)。 有了这个 MBCS 的概念,我们可以表示更多个字符了,比如我们用 2 个 ascii 字符,就有 16 bits, 理论上有 2 的 16 次方 65536 个字符。但这些编码怎么分配到字符上呢?比如口碑的”口”的 Unicode 编码就是 21475,谁决定的呢?字符集,也就是刚刚介绍的charset。ascii就是最基础的一个字符集,在此之上,我们有类似于 gb2312, big5这样针对简体中文和繁体中文的MBCS的字符集等等。终于有个叫 Unicode Consortium 的机构,决定做一个囊括所有字符在内的字符集(UCS, Universal Character Set)和对应编码方式的标准,即 Unicode。从1991年开始,它发布了第一版 Unicode 国际标准,ISBN 0-321-18578-1 ,国际标准化组织 ISO 也参与了这个的定制,ISO/IEC 10646 : the Universal Character Set。总之,Unicode 是个基本覆盖了所有已经存在的地球上的符号的字符标准了,现在正在被越来越广泛的使用,ECMA 标准也规定,javascript语言的内部字符使用 Unicode 标准(这意味着,javascript的变量名、函数名等是允许中文的!)。

对于身在中国的开发者来说,可能碰到比较多的问题就是 gbk,  gb2312, utf-8 之间转换之类的问题了。严格的说这个说法不是很准确,gbk,gb2312是字符集 (charset),而 utf-8 是一种编码方式 (character encoding) ,是 Unicode 标准中 UCS 字符集的一种编码方式,因为使用 Unicode 字符集的网页主要用UTF-8编码,所以大家常常就把它们并列了,其实是不准确的。

有了 Unicode 后,至少人类文明没有碰到外星人之前,这是一把万能钥匙了,都用它吧。而现在使用最广泛 Unicode 的编码方式就是 UTF-8 (8-bit UCS/Unicode Transformation Format) 了,它有几个特别好的地方:
  1. 编码 UCS 字符集,全世界通用
  2. 是一种变长编码方式(variable-length character encoding),兼容 ascii
第二点是个很大的优点,它使得以前使用纯 ascii 编码的系统兼容,而且不会增加额外的存储量(假设定长的编码方式,规定每个字符由2个 bytes 组成,那么这时候 ascii 字符占用的存储空间将增大一倍)。

要把 UTF-8 说清楚,引入一个表会更方便了:

U-00000000 – U-0000007F:    0xxxxxxx U-00000080 – U-000007FF:    110xxxxx 10xxxxxx U-00000800 – U-0000FFFF:    1110xxxx 10xxxxxx 10xxxxxx U-00010000 – U-001FFFFF:    11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U-00200000 – U-03FFFFFF:    111110xx 10xxxxxx 10xxxxxx 10xxxxxx  10xxxxxx U-04000000 – U-7FFFFFFF:    1111110x 10xxxxxx 10xxxxxx 10xxxxxx  10xxxxxx 10xxxxxx

要看懂这个表呢,我们看前两行就够了

U-00000000 – U-0000007F: 0xxxxxxx 第一行是这样的,意思是说,如果你发现一个utf-8编码的 byte 的二进制码是0xxxxxxx,是0开头的, 即十进制的0-127之间,那么他就是单独的这一 byte 代表一个字符,而且是拥有和 ascii 码完全一样的含义。其他所有的 utf8 编码的二进制值都是用1开头的1xxxxxxx,大于127的,而且都需要至少2 bytes才能代表一个符号。所以一个字节的第一位是一个开关,代表这个字符是不是一个 ascii 码。这个就是刚才谈到的兼容性,从英文定义上看,就是utf8编码的两个属性:

UCS characters U+0000 to U+007F (ASCII) are encoded simply as bytes 0×00 to 0×7F (ASCII compatibility). This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8. All UCS characters >U+007F are encoded as a sequence of several bytes, each of which has the most significant bit set. Therefore, no ASCII byte (0×00-0×7F) can appear as part of any other character.

然后我们看看第二行:

U-00000080 – U-000007FF:    110xxxxx 10xxxxxx 先看第一个字节:110xxxxx,它的含义是,我不是一个 ascii 码(因为第一位不为0),我是一个多 bytes 字符的第一个 byte (第二位为1),我参与表示的这个字符是由2个 bytes 组成的(第三位为0),从第四位开始,就是字符的信息储存的位置。 再看第二个字节:10xxxxxx,它的含义是:我不是一个 ascii 码(因为第一位不为0),我不是一个多 bytes 字符的第一个 byte (第二位为0),第三位开始是字符的信息储存的位置。

从这个例子中可以总结出来,utf-8编码方式中,在一长串连续的二进制 byte 码中,可能由2个至6个 bytes 来表示一个符号,那么相比较于用一个 byte 表示符号的 ascii 码,我们需要空间来储存两个额外信息: 一,这个符号开始位置,一个“starter”的位置,用生物学上的话来说,就是蛋白质翻译时候起始密码子AUG的位置了;二,这个符号使用的 bytes 数(其实如果每个符号都有 starter,这个长度是可以不提供的,但是提供长度信息增加了在部分 bytes 丢失时的容错能力)。解决方案是:用一个 byte 的第二位是否是1来代表这一 byte 是否是一个字符的起始 byte (因为一个 byte 里面的第一位刚才已经被使用了,0表示ascii码,1表示非ascii ),即,一个多字节符号的第一 个bytes一定是 11xxxxxx,一个192到255之间的二进制数。接下来,从第三位开始,提供长度信息,第三位是0表示这个符号是2字节的,第三位开始每多一个1,字符占用的 bytes 数加一。utf-8 最多定义到了 6 字节字符,需要比 110xxxxx 这样的表示2字节的starter多 4 个 1,所以这个starter就是 1111110x,如上表所示。 再看看英文定义的标准吧,表达的同样的意思:

The first byte of a multibyte sequence that represents a non-ASCII character is always in the range 0xC0 to 0xFD and it indicates how many bytes follow for this character. All further bytes in a multibyte sequence are in the range 0×80 to 0xBF. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.

真正的信息位(即,真正的charset字符集中的数字信息),是直接用二进制的方式,依顺序放在上面这个表的’x'上的。用我们中国程序员接触最多的汉字来说吧,它们的编码区间是在 U-00000800 – U-0000FFFF 之间的,从上面的表中可以查到,这个区间的 utf-8 编码是用三个字节来表示的(这就是 utf-8 编码的汉字会比每个字符占用2 bytes的 EUC-CN 编码的 gb2312 字符集的汉字使用更多储存空间的原因),还是用 口碑的”口”字举例吧,口字在 Unicode 中的编号是这样的: 口: 21475 == 0×53e3 ==  二进制 101001111100011

在 javascript 中,run这段代码(使用 firebug 的 console,或者编辑一个HTML将下列代码插入一对 script 标签之间):

alert(’\u53e3′);  //get ‘口’ alert(escape(’口’));  // get ‘%u53E3′ alert(String.fromCharCode(’21475′));  // get ‘口’ alert(’口’.charCodeAt(0));  // get ’21475‘ alert(encodeURI(’口’));  //get ‘%E5%8F%A3′

可以看到,string直接量可以用\u+十六进制 Unicode 码的形式得到字符 ‘口’,而fromCharCode 方法接受 10 进制的 Unicode 码,得到字符 ‘口’。

其中第二个alert得到的是 ‘%u7545′ , 这是一种不标准的Unicode编码,是属于 URI 的 Percent encoding 一部分,但这种使用方法已经正式被 W3C 拒绝了,任何一个 RFC中都没有这个标准,ECMA-262 标准中规定了 escape 的这种行为,估计也是暂时的。 比较有意思的是第五次alert得到的 ‘%E5%8F%A3′ 这是什么呢?怎么得到的呢?

这就是在URI上用的比较多的 Percent encoding,百分号编码,RFC 3986 标准中规定的

本文来源于成都网站建设公司与成都网站设计制作公司-创新互联成都公司!

分享标题:HTML与javascript常碰到的编码问题
URL分享:https://www.cdcxhl.com/news42/311192.html

成都网站建设公司_创新互联,为您提供外贸网站建设微信公众号电子商务标签优化云服务器网站收录

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

成都做网站