字符发展历史

单位
- 8位 = 1字节
- 1024字节 = 1kb
- 1024kb = 1m
- 1024m = 1G
- 1024G = 1T
JavaScript中的进制
- 进制表示
```
let a = 0b10100 //二进制
let b = 0o24 //八进制
let c = 20 //十进制
let d = 0x14 // 16进制

console.log(a == b)
console.log(b == c)
console.log(c == d)
```
- 进制转换
```
//10进制转任意进制 10进制数toStrong(目标进制)
console.log((20).toString(2));
//任意进制转十进制 parseInt('字符串', 原始进制)
console.log(parseInt('10100', 2))
```
- ASCII
  - 最开始计算机只在美国用，八位的字节可以组合出256中不同的状态。0-32种状态规定了特殊用途，一旦终端，打印机遇见约定好的这些字节被传过来是，就要做一些约定动作：
  - 遇上0×10, 终端就换行；
  - 遇上0×07, 终端就向人们嘟嘟叫；
  - 又把所有的空格，标点符号，数字，大小写字母分别用俩虚的字节表示，一直编到了127号，这样计算机就可以用不同的字节来存储英语文字了
  - 这128个符号(包括32个不能打印出来的控制符号)，只占用了一个字节后边的7为，最前面的以为统一规定为0
  - 这个方案就叫做ASCII编码
- GB2312
  - 后来西欧一些国家用的不是英文，他们的字母在ASCII里没有位置可以保存他们的文字，他们使用126号后边的空位来保存新的字母一直编到了255位。
  从128到288这一页的字符集被称为扩展字符集
  - 中国为了表示汉字，把127号之后的符号取消了，规定
  - 一个小于127的字符的意义与原来相同，打两个大于127的字符连在一起时，表示一个汉字
  - 千米俺的一个字节（他称之为高字节）从0xA1 用到 0xF7 ，后边的一个字节（第字节），从0xA1 到0xFE
  - 这样我们就可以组合出大约7000多个(247-161)*(254-161) = (7998)简体汉字了
  - 还把数学符号，日文假名和ASCII里原来旧有的数字，标点和字母都编成两个字长的编码，127一下那些就叫做半角字符
  - 把这中汉字方案叫做GB2312。GB2312是对ASCII的中文扩展
- GBK
  
  后来还是不够用，于是干脆不在要求低字节一定是127号之后的内码，
  
  只要第一个字节时大于127就固定表示这是一个汉字的开始，又增加了近20000个新的汉字(包括繁体字)和符号
- GN8030和DBCS
  - 又增加了几千个新的少数名族的字GBK 扩成了GB18030 通称他们叫做DBCS
  - Double Byte Character Set：双字节字符集
  - 在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于一套编码方案里，各个过节都向中国这样搞一套自己的编码标准，结果互相之间谁也不动谁的编码，谁也不支持别人的编码
- Unicode
  
  ISO 的国际组织废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符的编码！ Unicode 当然是一个很大的集合，现在的规模可以容纳100多万个符号。\
  - International Organization for Standardization：国际标准化组织。
  - Universal Multiple-Octet Coded Character Set，简称 UCS，俗称 Unicode
  ISO 就直接规定必须用两个字节，也就是 16 位来统一表示所有的字符，对于 ASCII 里的那些半角字符，Unicode 保持其原编码不变，只是将其长度由原来的 8 位扩展为16 位，而其他文化和语言的字符则全部重新统一编码。从 Unicode 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的一个字符！同时，也都是统一的两个字节
  - 字节是一个8位的物理存贮单元，
  - 而字符则是一个文化相关的符号。
- UTF-8
  
  Unicode在很长的一段时间无法推广，知道互联网的出现，为解决Unicode如何在网络上传输的问题，于是面向传输的众多UTF标准出现了：
  
  Universal Character Set(UCS) Transfer Format
  - UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式
  - UTF-8就是每次以8个位为单位传输数据
  - 而UTF-16就是每次 16 个位
  - UTF-8 最大的一个特点，就是它是一种变长的编码方式
  - Unicode 一个中文字符占 2 个字节，而 UTF-8 一个中文字符占 3 个字节
  - UTF-8 是 Unicode 的实现方式之一
- 编码规则
  - 对于单字节的符号，字节的第一位设为0，后边的7为为这个符号的Unicode码，因此对于英语字母，UTF-8编码和ASCII码时相同。
  - 对于n自己的符号(n > 1),第一个字节的前n为都设为1，第n+1为设为0，后边字节的前两位一律设为10.剩下的没有提及的二进制为，全部为这个符号的Unicode码。
```
Unicode符号范围     |        UTF-8编码方式
(十六进制)        |        （二进制）
----------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
```
- 文本编码
  
  使用NodeJS编写前端工具时，操作得最多的是文本文件，因此也就涉及到了文件编码的处理问题。我们常用的文本编码有UTF8和GBK两种，并且UTF8文件还可能带有BOM。在读取不同编码的文本文件时，需要将文件内容转换为JS使用的UTF8编码字符串后才能正常处理。
- BOM的移除
  
  BOM用于标记一个文本使用Unicode编码，其本身是一个Unicode字符(‘\uFEFF’)，位于文件头部。在不同的Unicode编码下，BOM字符最硬的二进制字节如下：
  
  Bytes Encoding
  
  FE FF UTF16BE
  FF FE UTF16LE
  EF BB BF UTF8
  
  //因此我们可以根据文件头部几个字节来判断文件是否包含BOM，以及使用那种Unicode编码。但是，BOM字符虽然起到了标记文件的作用，其本身却不属于文件的一部分，如果读取文本时不去掉BOM，在某些场景下就会有问题。例如我们把几个JS文件合并为一个文件后，如果文件中间含有BOM字符，就会导致浏览器JS语法错误，因此，一般使用NodeJs读取文件的时候需要去掉BOM

猜你喜欢