关于字符编码你应当晓得的事变

2024年4月3日 129次阅读 来源: shoyuf

读完本文你将相识的知识点

  1. 为何 Windows 上运用 Notepad 会涌现乱码
  2. 为何 Emoji 脸色在有些手机上显现不准确
  3. 为何 Emoji 在没有做过迥殊优化的数据库中存储失利
  4. 为何运用 Linux 开辟的代码别人运用 Windows 开辟后换行符全变了
  5. 为何在 JS 中 [...'👨‍👨‍👦‍👦'] => ["👨", "‍", "👨", "‍", "👦", "‍", "👦"]
  6. 新版本 ECMAScript 针对 JavaScript 编码题目做了哪些革新
  7. 为何运用 Google Chrome 翻开 JS 文件，文件中的中笔墨符会变成乱码

比特、字节

  1. 比特 ( Bit / Binary digit )
    缩写为 b，计算机最小的存储单元，以 0/1 来示意值
  2. 字节 ( Byte )
    缩写为 B，8 个比特示意一个字节

    在计算机内部，一切的信息终究都示意为一个二进制的序列。每一个二进制位 ( Bit ) 有 0 和 1 两种状况，因而八个二进制位就能够组合出 256 种状况，这被称为一个字节 ( Byte ) ，也就是说，一个字节一共能够用来示意 256 种差别的状况或许标记。假如我们制造一张对应表格，关于每一个 8 位二进制序列，都对应唯一的一个标记。每一个状况对应一个标记，就是 256 个标记，从 0000 0000 到 1111 1111 。

ASCII 与 EASCII

  1. ASCII (American Standard Code for Information Interchange，美国信息交流范例代码)

    1967 年宣告，末了更新于 1986 年，共定义了 128 ( 2⁷ ) 个字符( 0x00 – 0x7F ) ，个中 33 个字符为不可打印字符 ( 0x00 – 0x1F & 0x7F )，95 个可打印字符 ( 0x20 – 0x7E )

    可打印字符为范例键盘中可输入的字符，以下所示：

    10 个数字 (
    0-9 )，26×2 个大小写字母 (
    a-z A-Z ) ，32 个标点标记 1 个空格 (
    ,./;'[]\-=~!@#$%^&*()_+{}|:"<>? )

    ASCII 的局限在于只能显现 26 个基础拉丁字母、阿拉伯数目字和英式标点标记，因而只能用于显现当代美国英语，而其他照顾类似于重音标记的字母没法显现 ( naïve、café )

  2. EASCII ( Extended ASCII，延长美国范例信息交流码 )

    由于 ASCII 的自然不足，它的变种体敏捷涌现，兼容字符集对ASCII的处置惩罚

  • ISO/IEC 646 1972年

    该范例来自数个国度范例，最主要的是美国的 ASCII 范例，ISO 646 为了示意欧洲种种言语的带附加标记（ diacritical mark ）的变音字母，由于没有码位空间去直接编码这些变音字母，所以用几个标点标记来兼作变音字母的附加标记

  • ISO/IEC 8859

    扩大字符：0xA0 ( 160 ) – 0xFF ( 255 )
    镌汰了 ISO 646 编码范例

    ISO 8859 一致了此前列国各言语的零丁编码的杂沓局势；烧毁了 ISO 646 运用的退格键最早的转义序列来示意变音字母的要领，而是在 G1 地区直接编码示意变音字母。

    ISO 8859 有 15 个子版本（ 1-11，13-16 ），个中席卷了大部份欧州言语，英语由于没有重音字母，一切能够运用个中任何一个子版本示意

    Microsoft Codepage 1252 为 ISO 8859-1 的超集，扩大了 0x80 – 0x9F 来编码一些可打印字符 ( € ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ Ž ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ )

    比方在中国 GB/T 1988-80 范例中： $ u+0024 替换为 ¥ u+00A5 ，~ u+007E 替换为 ‾ u+203E

  1. ANSI

    Windows 操作体系上的 ANSI 编码并不是指的是美国国度范例学会 ( ANSI )，而是用来指称多个差别的代码页，比如在简体中文编码操作体系中，ANSI 实际运用 GB 系字符编码

中文

  • GB2312 ( 1981 ) 6763 个汉字，最初版本，双字节编码
  • GB12345 ( 1993 ) 6866 个汉字，为了顺应繁体汉字信息处置惩罚而制订的范例
  • GBK ( 1995 ) 21886个汉字和图形标记，不属于国度范例
  • GB18030 ( 2000 )，70244 个字符，基于 GBK，现行版本

国际通用范例

  • Unicode ( 万国码、国际码、一致码、单一码 )

    最初版本：1.0.0 宣告，1991 年 10 月宣告，7161 个字符
    当前正式版本 Unicode 11.0 ( 2018 年 6 月 ) 具有 137374 个字符
    当前最新版本：Emoji 12.0 Beta

    示意要领：

    • 基础平面：一般会用 “U+” 然后紧接着 4 个 16 进制的数字来示意这一个字，可示意 6 万余个字符
    • 其他平面运用 “U-” 然后接着 8 个 16 进制数字示意
  • ISO/IEC 10646 ( UCS / 通用字符集 )

    该字符集包含了其他一切字符集，保证了与其他字符集的双向兼容，ISO 10646 有三种完成级别，差别的完成级别能支撑的字符数目差别

    与 Unicode 的关联：

  • 一切字符在雷同位置且有雷同名字
  • Unicode 范例里有细致申明某些言语和笔墨的表达算法等
  • ISO 许诺，ISO 10646 将不会替超越 U+10FFFF（ Unicode 编码以 U+ 开首） 的 UCS-4 编码赋值

UTF ( Unicode Transformation Format )

Unicode 是一个字符集，其完成体式格局称为 Unicode 转换花样，即 UTF

  • UTF-32

    Unicode 与 UCS 兼并之前已产生了 UCS-4 编码体式格局，UCS-4 运用了 32 位来示意每一个编码，为了兼容 Unicode 产生了 UTF-32 范例，编码空间限定在了 0x000000 – 0x10FFFF 之间，因而能够说 UTF-32 是 UCS-4 的子集。由于 UTF-32 的编码空间占用过大，因而在 HTML5 范例中明白规定不能运用 UTF-32 举行编码

  • UTF-16

    UTF-16 编码具有定长和变长两个编码特性，关于 Unicode 基础平面的字符，UTF-16 占用两个字节，关于辅佐平面的字符，UTF-16 编码占用四个字节

    Unicode 范例定义，每一个文件的最前面离别到场一个示意编码递次的字符，这个字符的名字叫做 “零宽度非换行空格 ( zero width no-break space )”，用 FE FF 示意。但在差别计算机体系中对字节递次的明白是不一致的，即涌现了大端序 ( UTF-16 BE ) 与小端序 ( UTF-16 LE ) 两种状况。文本头部运用 FE FF 与 FF FE 举行辨别,此辨别符称为“字节递次标记 ( BOM ) ”

    怎样肯定双字节和四字节：

    在基础平面内，从 U+D800 到 U+DFFF 是一个空段，不对应任何码点，这个空段用来映照辅佐平面的字符，即一个辅佐平面的字符，被拆成两个基础平面的字符示意。

    比方： 👨 能够示意为 U+D83D U+DC68

  • UTF-8

    由于前两种编码体式格局的编码划定规矩对与英语国度来讲异常糟蹋（2-4 字节编码）

    UTF-8 当前运用 1-6 个字节为每一个字符编码

  1. 关于单字节的标记，字节的第一位设为 0 ，背面 7 位为这个标记的 Unicode 码。因而关于英语字母，UTF-8 编码和 ASCII 码是雷同的。
  2. 关于n字节的标记（ n > 1 ），第一个字节的前n位都设为 1，第 n + 1 位设为0，背面字节的前两位一概设为 10。剩下的没有说起的二进制位，悉数为这个标记的 Unicode 码。
  3. 带有附加标记的拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母则须要两个字节编码 ( Unicode 局限由 U+0080 至 U+07FF )。
  4. 其他基础多文种平面 ( BMP ) 中的字符（这包含了大部份常用字，如大部份的汉字）运用三个字节编码 ( Unicode局限由U+0800至U+FFFF )。
  5. 其他少少运用的 Unicode 辅佐平面的字符运用 4-6 字节编码
  • UCS-2

    JavaScript 采纳了 Unicode 字符集。然则只支撑一种编码体式格局。JS 最早采纳的编码既不是 UTF-16 也不是 UTF-32 或 UTF-8 ，而是 UCS-2 。UTF-16 明白宣告是 UCS-2 的超集。UTF-16 中基础平面字符延用 UCS-2 编码。辅佐平面字符定义了 4 个字节的示意要领。

    JS 只能处置惩罚 UCS-2 编码，形成一切字符在这门言语中都是两个字节，假如是四个字节的字符。会被当作两个双字节的字符处置惩罚。

    二者的关联简单说，就是 UTF-16 庖代了 UCS-2，或许说 UCS-2 整合进了 UTF-16。所以，如今只要 UTF-16，没有 UCS-2。

码点和平面

字符会从 0 最早为每一个字符指定一个编码， 这个编码叫做码点

举例
Unicode 中给字符举行分区定义，每一个区称为一个面，Unicode 具有 0-16 共 17 个平面，每一个平面 16⁴ 个字符

平面字符值形貌
0号平面U+0000 – U+FFFF基础多文种平面
1号平面U+10000 – U+1FFFF多文种补充平面
2号平面U+20000 – U+2FFFF表意笔墨补充平面
3号平面U+30000 – U+3FFFF表意笔墨第三平面（未正式运用）
4 – 13号平面U+40000 – U+DFFFF（还没有运用）
14号平面U+E0000 – U+EFFFF迥殊用处补充平面
15号平面U+F0000 – U+FFFFF保留作为私家运用区（A区）
16号平面U+100000 – U+10FFFF保留作为私家运用区（B区）

题首题目

  • 为何 Windows 上运用 Notepad 会涌现乱码

    Windows 上的 Notepad 软件在保留文件时默许运用的是 ANSI 编码保留，而在翻开的时刻须要猜想 txt 文件的编码体式格局，假如文档中涌现了 ANSI 编码之外的字符，则在翻开时刻能够会涌现编码辨认毛病的状况，由于 txt 文件为纯文本文件，没有保留文档编码信息的地区，则此题目能够一向存在。

    处理该题目可在保留文件的时刻运用 UTF-8 编码保留，但须要注重的是：

    Windows 的 Notepad 运用运用 UTF-8 保留的时刻实际运用的为 UTF-8 BOM 体式格局，其表现为在文本最开首增加 EF BB BF ，这部份称为
    UTF-8 字节递次标记 ，该体式格局并不是强迫范例，假如在代码文件中运用该体式格局保留则有能够涌现运转毛病。

  • 为何 Emoji 脸色在有些手机上显现不准确

    当前 iOS 12 运用的 Unicode 版本为 11，而群众运用比较的 Android 8.0 运用的Unicode 版本为 9，假如在 Android 体系中涌现了新版本的字符，则会涌现没法显现或显现毛病的状况。

    比方在 Unicode 8.0 中到场了 5 个菲茨帕特里克修饰符，用来调治人形脸色的肤色，假如在低于此版本的 Unicode 中显现的字符为两个字符，离别是色彩加人偶。

    别的 Unicode 新版本中运用 U+200D 零宽连字 ( ZWJ ) 将多个 Emoji 连起来，比方 👨‍👨‍👦‍👦 => 👨👨👦👦

  • 为何 Emoji 在没有做过迥殊优化的数据库中存储失利

    Emoji 脸色占用 4 个字节，然则 MySQL 数据库运用的 utf-8 默许编码最多只能存储 3 个字节 ( UTF-8 范例支撑最长编码为 6 字节 )，就会致使存储不进去，在读取的时刻读取不完整，致使乱码

    修复要领为：修正数据库字符集为 uft8mb4，假如数据库衔接池中对字符集作出了设置须要在链接中去掉 characterEncoding 参数

  • 为何运用 Linux 开辟的代码别人运用 Windows 开辟后换行符全变了

    Windows 系列体系运用的换行标志为 CRLF，该换行标志与 Unix/Linux 的 LF 换行及 macOS 的 CR 换行不雷同。
    假如在代码工程中运用了 Code Lint 东西自动花样化，能够会使代码中的 LF 换行自动转换为 CRLF 换行，Git 中也能捕捉或疏忽这个变化。
    别的，从 Windows 10 1803 最早，支撑 Unix/Linux 的 LF 换行及 macOS 的 CR 换行。

  • 为何在 JS 中 [...'👨‍👨‍👦‍👦'] => ["👨", "‍", "👨", "‍", "👦", "‍", "👦"]

    👨‍👨‍👦‍👦 是 2015 年增加到 Emoji 2.0 中的新字符，运用 U+200D 零宽连字 (ZWJ) 将4个 Emoji 连起来，可运用以下代码检测

    […’👨‍👨‍👦‍👦’].forEach(e=>{console.log(e.codePointAt().toString(16))})

  • 新版本 ECMAScript 针对 JavaScript 编码题目做了哪些革新

    由于 JavaScript 运用的是只支撑双字节编码的 USC-2 编码体式格局，所以一切凌驾二字节编码的 Unicode 字符都没法在 JavaScript 中处置惩罚

    比方 '👨'.charCodeAt().toString(16) 输出的效果为 d83d ，而👨的Unicode 码点却不是 d83d，形成如许的原由于 JavaScript 只处置惩罚了该字符的前两个字节

    为相识决这些题目，ECMAScript 6 种增强了对新版本 Unicode 的支撑。
    比方：

    1. for of 循环中对双字节以上字符能辨认准确长度
    2. Array.from 等要领能准确分别字符串
    3. 支撑直接运用码点示意字符，比方'\ud83d\udc68' === '👨' === '\u{1F468}'
    4. String.fromCodePoint() 和 String.prototype.codePointAt() 等要领替代 String.fromCharCode() 和String.prototype.charCodeAt() 等要领，以用于支撑 UTF-16 编码字符
    5. 正则表达式供应了 u 修饰符，对正则表达式增加4字节码点的支撑
    6. 供应了normalize要领，许可”Unicode正规化” ，比方：'\u01D1'.normalize() === '\u004F\u030C'.normalize()

  • 为何运用 Google Chrome 翻开 JS 文件，文件中的中笔墨符会变成乱码

    由于 2017 年更新的某版本 Chrome 中，去除了对 JS 文件默许编码 UTF-8 的支撑，运用了体系默许编码（比方中文操作体系运用 GB18030 ）对 JS 文件的解码，所以致使 JS 文件中的中笔墨符变成乱码。

    处理要领有两种：

    1. 在文件服务器中对返转头的 Content-Type 设置加上 charset=UTF-8
    2. 浏览器中运用插件转变网页编码体式格局，比方运用 FEHelper 东西

参考资料：

本文首发地点

blog.shoyuf.top

第二次在 segmentfault 上发文章，迎接列位批评区中吐槽斧正

    原文作者：shoyuf
    原文地址: https://segmentfault.com/a/1190000018202684
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞