利用建站系统wordpress建设网站网站注销备案查询

当前位置： 首页 > news >正文

利用建站系统wordpress建设网站,网站注销备案查询,优秀企业,河南专业网站建设公司UTF-8 出现的时间及目的 UTF-8#xff08;8-bit Unicode Transformation Format#xff09;于1992年由Ken Thompson和Rob Pike在Plan 9操作系统开发过程中首次提出#xff0c;并于1993年正式标准化。它是为了解决以下问题而设计的#xff1a; 兼容ASCII#xff1a;早期计…UTF-8 出现的时间及目的 UTF-88-bit Unicode Transformation Format于1992年由Ken Thompson和Rob Pike在Plan 9操作系统开发过程中首次提出并于1993年正式标准化。它是为了解决以下问题而设计的 兼容ASCII早期计算机系统广泛使用ASCII7位编码仅支持128个字符主要是英文字符。UTF-8设计为前128个字符与ASCII完全兼容确保现有ASCII文本无需转换即可使用。 支持多语言随着全球化的发展计算机需要处理多种语言的字符如中文、日文、阿拉伯文等。Unicode旨在为所有字符分配统一编码但需要一种高效的编码方式来存储和传输。UTF-8通过变长编码1到4字节支持Unicode字符集既节省空间又能表示全球字符。 效率与灵活性相比固定长度的编码如UCS-2使用2字节UTF-8在存储英文字符时更节省空间同时能扩展到支持超过100万个字符。
UTF-8的修订历史 UTF-8自诞生以来经过了几次修订主要是为了与Unicode标准同步并解决边缘问题 1993年初始标准UTF-8首次定义支持Unicode 1.0最大编码范围为31位5或6字节编码理论上可表示2^31个字符。 1996年Unicode 2.0修订以支持 surrogate pairs代理对引入4字节编码限制最大编码到U10FFFF21位与UTF-16保持一致。废弃了5字节和6字节编码因为Unicode字符集被限制在17个平面0到16。 2003年RFC 3629进一步规范化明确禁止非最短编码形式non-shortest form以防止恶意编码如用多字节表示单字节字符导致的安全漏洞。最大编码范围固定为4字节U0000到U10FFFF。 后续微调随Unicode版本更新如Unicode 15.02022年UTF-8的编码规则未变但支持的字符集随Unicode扩展而增加。修订主要集中在字符分配和规范化而非编码方式本身。
UTF-8与UTF-16的差别 UTF-8和UTF-16是Unicode的两种编码方式主要区别如下 编码方式 UTF-8变长编码字符用1到4字节表示。ASCII字符U0000到U007F用1字节中文等常用字符用3字节罕见字符用4字节。 UTF-16变长编码主要用2字节表示基本多文种平面BMPU0000到UFFFF的字符超出BMP的字符如部分emoji或罕见汉字用4字节surrogate pairs。 空间效率 UTF-8对英文文本效率高1字节/字符但中文等字符占用3字节空间效率低于UTF-16。 UTF-16对东亚语言如中文、日文效率较高通常2字节/字符但对英文文本效率低于UTF-8且需要处理代理对增加复杂性。 兼容性 UTF-8完全兼容ASCII广泛用于互联网网页、邮件、JSON等和文件系统。现代软件默认使用UTF-8。 UTF-16不兼容ASCII需字节序标记BOM区分大端/小端编码。常用于Windows系统和某些遗留应用如Java、.NET早期版本。 错误处理 UTF-8字节序列严格错误检测容易如无效字节或非最短编码。解析中断后易恢复。 UTF-16代理对错误如孤立代理码点可能导致解析困难错误恢复较复杂。 应用场景 UTF-8主导互联网和跨平台应用适合文本传输和存储占全球网页编码的95%以上2023年数据。 UTF-16在某些内部处理如Windows API、Java字符串中使用但逐渐被UTF-8取代。
UTF-8MB4 是什么 UTF-8MB4MB4表示“4-byte UTF-8”是 MySQL 数据库中对标准 UTF-8 编码的一种实现用于支持完整的 Unicode 字符集包括需要 4 字节编码的字符如部分 emoji 和罕见汉字。它本质上是标准 UTF-8 的子集但专为 MySQL 设计以解决早期 MySQL 中 UTF-8 编码的局限性。 背景与问题 MySQL 早期5.5 版本之前的所谓“UTF-8”编码实际上只支持最多 3 字节的 Unicode 字符范围为 U0000 到 UFFFF即基本多文种平面BMP。这意味着 无法存储 4 字节的字符如许多 emoji如 U1F60A或某些罕见汉字如 U30EDD。 导致插入此类字符时出错如“Incorrect string value”或数据被截断。
为了解决这一问题MySQL 引入了 UTF-8MB4它完全支持 Unicode 的整个字符集U0000 到 U10FFFF包括需要 4 字节编码的补充平面字符。 UTF-8MB4 的特点 编码范围 支持标准 UTF-8 的所有字符包括 1 到 4 字节编码。 特别针对补充平面Supplementary Planes如 emoji、罕见字符优化。 与标准 UTF-8 的关系 UTF-8MB4 与标准 UTF-8 在编码规则上相同只是 MySQL 内部的命名区分。 MySQL 的“UTF-8”实现旧版是阉割版仅限 3 字节UTF-8MB4 则是完整版。 存储需求 与标准 UTF-8 一样ASCII 字符占 1 字节中文占 3 字节emoji 等占 4 字节。 相比 UTF-8MB3MySQL 内部对 3 字节 UTF-8 的称呼UTF-8MB4 对 4 字节字符的支持增加了一些存储开销。 兼容性 UTF-8MB4 完全兼容标准 UTF-8任何有效的 UTF-8 数据都可以无缝迁移到 UTF-8MB4。 需要注意客户端、连接和服务器字符集配置一致如 utf8mb4_unicode_ci否则可能出现乱码。
修订与发展 引入时间MySQL 5.5.32010 年正式引入 UTF-8MB4。 改进 校对规则CollationMySQL 提供了多种 UTF-8MB4 校对规则如 utf8mb4_unicode_ci基于 Unicode 标准通用、utf8mb4_bin二进制排序等优化排序和比较。 性能优化MySQL 8.02018 年后UTF-8MB4 性能进一步提升成为默认字符集取代 Latin1。 现状从 MySQL 8.0 开始UTF-8MB4 是推荐和默认的字符集广泛用于支持现代应用的国际化需求。
UTF-8MB4 与 UTF-16 的对比 与 UTF-16 的对比类似于标准 UTF-8见前述回答但在 MySQL 上下文中 UTF-8MB4MySQL 的首选适合互联网应用支持所有 Unicode 字符存储效率对英文高传输兼容性好。 UTF-16MySQL 支持 UTF-16通过 ucs2 或 utf16 字符集但不常用因其存储效率较低固定 2 或 4 字节且不兼容 ASCII。
应用场景 Web 应用支持 emoji 和多语言的社交媒体、聊天应用如微信、Twitter广泛使用 UTF-8MB4。 数据库迁移从旧版 MySQL 的“UTF-8”3 字节迁移到 UTF-8MB4以支持现代字符需求。 配置建议在 MySQL 中建议设置数据库、表、列、客户端连接均为 utf8mb4校对规则选 utf8mb4_unicode_520_ci基于 Unicode 5.2或更高版本。
为什么在 UTF-8 之后创造 UTF-16 UTF-8 和 UTF-16 都是 Unicode 的编码方式UTF-16 的出现并不是因为 UTF-8 不足以支持上百万字符而是由于历史、技术和应用场景的特定需求。以下是 UTF-16 诞生的背景、原因及其特别意义

1. 历史背景与时间线 Unicode 的早期发展 Unicode 项目始于 1980 年代末旨在为全球所有字符提供统一编码。最初Unicode 计划使用固定 2 字节16 位编码称为 UCS-2Universal Character Set, 2-byte可表示 65,536 个字符U0000 到 UFFFF足以覆盖当时已知的大多数常用字符基本多文种平面BMP。 UTF-16 作为 UCS-2 的扩展诞生于 1996 年Unicode 2.0引入了代理对surrogate pairs机制将编码范围扩展到 U10FFFF约 110 万字符与 UTF-8 的覆盖范围一致。 UTF-8 则在 1992-1993 年由 Ken Thompson 和 Rob Pike 提出强调 ASCII 兼容性和变长编码1-4 字节。 时间线对比 UTF-8 和 UTF-16 几乎同时发展UTF-16 的前身 UCS-2 甚至早于 UTF-8 的广泛应用。两者是为不同需求设计的平行方案而非 UTF-16 是 UTF-8 的“替代品”。
   
2. 创造 UTF-16 的原因 UTF-16 的创造主要基于以下需求和技术考量 固定长度编码的吸引力早期 在 Unicode 早期1991 年Unicode 1.0认为 65,536 个字符足以覆盖所有语言的字符需求。UCS-2UTF-16 的前身使用固定 2 字节编码简单且易于实现适合当时的内存和处理能力有限的系统。 相比之下UTF-8 是变长编码1-4 字节需要更复杂的解析逻辑在 1990 年代的硬件上处理效率稍低。 意义UCS-2/UTF-16 提供了简单、统一的编码方式适合早期软件如 Windows NT、Java处理多语言文本。 东亚语言的优化 东亚语言如中文、日文、韩文的字符主要集中在 Unicode 的 BMPU4E00 到 U9FFF 等每个字符在 UCS-2/UTF-16 中正好占用 2 字节存储效率高且对齐整齐。 UTF-8 对这些字符需要 3 字节空间效率稍逊例如中文文本在 UTF-8 中比 UTF-16 多占约 50% 空间。 意义对于日本、韩国、中国等东亚地区UTF-16或其前身 UCS-2在早期更适合处理本地化文本尤其在内存敏感的环境中。 与现有系统的兼容性 1990 年代许多系统如 IBM、Microsoft已使用 2 字节编码如 Shift-JIS、Big5处理本地字符集。UCS-2/UTF-16 作为 2 字节编码的 Unicode 实现易于与这些系统迁移和集成。 例如Windows NT1993 年发布采用 UCS-2 作为内部编码后来升级支持 UTF-16。 意义UTF-16 降低了从传统编码如 Shift-JIS到 Unicode 的迁移成本适合企业级系统如 Windows、SQL Server。 代理对扩展的需求 当 Unicode 扩展到超过 65,536 个字符1996 年Unicode 2.0 引入补充平面时UCS-2 已不足以表示所有字符。UTF-16 通过代理对机制使用 4 字节表示 U10000 以上字符扩展了编码范围保持了与 UCS-2 的部分兼容性。 意义UTF-16 作为 UCS-2 的自然演进允许现有系统平滑过渡到支持完整的 Unicode 字符集。
   
3. UTF-16 的特别意义 尽管 UTF-8 现已成为主流UTF-16 在当时和某些场景中有其独特意义 历史过渡作用 UTF-16及其前身 UCS-2是 Unicode 早期推广的关键。1990 年代固定 2 字节编码被认为是一种简单直观的解决方案得到 Microsoft、IBM、Apple 等公司的支持推动了 Unicode 的普及。 例如Windows NT 和 Java 的早期采用奠定了 UTF-16 在企业级软件中的基础。 特定领域的效率 对于东亚语言如中文、日文、韩文UTF-16 在 BMP 字符上的固定 2 字节编码比 UTF-83 字节更节省空间尤其在内存和存储成本较高的时代。 在某些内存敏感的嵌入式系统或早期数据库如 SQL Server中UTF-16 更易于处理。 生态系统锁定 Microsoft 的 Windows 生态API、文件格式、Java字符串处理、JavaScriptECMAScript 标准等选择 UTF-16 作为默认编码形成了技术锁定效应。这些系统的影响力使 UTF-16 在特定领域持续使用。 意义UTF-16 的存在反映了技术生态的路径依赖特别是在 Windows 和 Java 主导的 1990-2000 年代。
   
4. 为何 UTF-16 使用减少 尽管 UTF-16 有其历史意义但其局限性导致使用场景减少 不兼容 ASCIIUTF-16 无法直接兼容 ASCII需要 2 字节表示英文字符而 UTF-8 完全兼容适合互联网和文件系统。 复杂性代理对4 字节字符增加了解析难度错误处理如孤立代理码点更复杂。 存储效率对英文文本UTF-162 字节/字符比 UTF-81 字节/字符浪费空间对补充平面字符UTF-16 和 UTF-8 均需 4 字节无明显优势。 互联网主导UTF-8 因其在 WebHTML、JSON、Linux、macOS 和数据库MySQL UTF-8MB4中的广泛采用成为事实标准占网页编码 95% 以上2023 数据。 为什么 UTF-8 比 UTF-16 多一个字节 你的问题可能指的是 UTF-8 在某些情况下如存储东亚字符或补充平面字符比 UTF-16 使用更多字节的情况因为 UTF-8 是变长编码1-4 字节而 UTF-16 主要是 2 字节或 4 字节用于代理对。下面详细解释 UTF-8 和 UTF-16 的字节使用差异以及 UTF-8 “多出的字节”存了什么。
5. UTF-8 和 UTF-16 的编码方式 UTF-8 变长编码使用 1 到 4 字节表示 Unicode 字符U0000 到 U10FFFF。 字节分配 1 字节U0000 到 U007FASCII 字符如英文。 2 字节U0080 到 U07FF拉丁文、希腊文等。 3 字节U0800 到 UFFFF包括东亚字符如中文、日文、韩文位于基本多文种平面BMP。 4 字节U10000 到 U10FFFF补充平面如 emoji、罕见汉字。 每个字节的最高位用于标记 单字节0xxxxxxxASCII。 多字节首字节以 110xxxxx2 字节、1110xxxx3 字节、11110xxx4 字节开头后续字节以 10xxxxxx延续字节开头。 这些标记位确保解码器能识别字节序列的开始和长度。 UTF-16 变长编码主要使用 2 字节部分字符用 4 字节代理对。 字节分配 2 字节U0000 到 UFFFFBMP覆盖大多数常用字符包括东亚字符。 4 字节U10000 到 U10FFFF补充平面使用代理对高代理 UD800 到 UDBFF 低代理 UDC00 到 UDFFF。 UTF-16 不需要像 UTF-8 那样的复杂标记位因为 BMP 字符固定 2 字节补充平面字符通过代理对的固定范围识别。
   
6. 为何 UTF-8 比 UTF-16 多一个字节 你提到的“多一个字节”可能主要针对 东亚字符如中文、日文、韩文U0800 到 UFFFF。以下是具体分析 东亚字符的存储 UTF-8中文等东亚字符例如“汉” U6C49需要 3 字节。 编码示例“汉” (U6C49) 的 UTF-8 编码为 E6 B1 89 首字节1110xxxx表示 3 字节序列。 后续字节10xxxxxx 10xxxxxx存储字符的位。 UTF-16同一字符只需要 2 字节。 编码示例“汉” (U6C49) 的 UTF-16 编码为 6C 49小端。 直接存储 Unicode 码点无需额外标记。 多出的 1 字节存了什么 UTF-8 的第 3 字节主要用于 标记位每个字节的最高位1110 或 10用于标识字节序列的结构帮助解码器区分首字节和延续字节。 数据位UTF-8 将 Unicode 码点例如 U6C49 的二进制01101100 01001001拆分到多个字节中。3 字节编码提供 16 位数据空间3 × 6 位有效数据首字节 4 位 两个延续字节各 6 位足以覆盖 U0800 到 UFFFF。 具体来说“汉” 的 UTF-8 编码 E6 B1 89 E611100110前 4 位 1110 表示 3 字节序列后 4 位存储码点高位。 B110110001前 2 位 10 表示延续字节后 6 位存储码点中位。 8910001001前 2 位 10 表示延续字节后 6 位存储码点低位。 标记位1110 和 10占用额外空间确保解码器能正确解析变长序列。 相比之下UTF-16 的 2 字节直接存储码点6C 49无需标记位因此更紧凑。 为什么 UTF-8 需要 3 字节而非 2 字节 UTF-8 设计时优先考虑 ASCII 兼容性 1 字节编码0xxxxxxx留给 ASCIIU0000 到 U007F确保英文字符与 ASCII 一致。 这导致非 ASCII 字符U0080 以上必须从 2 字节起步而 2 字节110xxxxx 10xxxxxx只能表示 U0080 到 U07FF11 位数据。 东亚字符U0800 到 UFFFF需要 16 位数据因此必须用 3 字节1110xxxx 10xxxxxx 10xxxxxx。 UTF-16 没有 ASCII 兼容性要求直接用 2 字节表示 BMP 字符因此对东亚字符更节省空间。
   
7. 补充平面字符的对比 对于补充平面字符U10000 到 U10FFFF如 emoji U1F60A两者都用 4 字节 UTF-84 字节编码例如 的编码为 F0 9F 98 8A。 首字节 11110xxx 表示 4 字节序列后续字节 10xxxxxx 存储码点数据。 UTF-164 字节代理对例如 的编码为 D83D DE0A。 高代理D83D和低代理DE0A各占 2 字节。 差异两者字节数相同但 UTF-8 的 4 字节包含标记位11110 和 10而 UTF-16 的代理对范围UD800 到 UDFFF本身起到类似标记作用。
   
8. UTF-8 多字节的权衡 UTF-8 的变长设计包括多出的字节是为了以下目标 ASCII 兼容性 UTF-8 确保 ASCII 字符只用 1 字节这对英文文本和互联网协议如 HTTP、JSON至关重要。 UTF-16 用 2 字节表示 ASCII 字符效率低且不兼容 ASCII。 自同步性 UTF-8 的标记位0、110、1110、11110、10使字节序列自同步解码器可轻松定位序列起点即使数据损坏也能快速恢复。 UTF-16 依赖代理对范围错误如孤立代理码点更难检测。 扩展性 UTF-8 的 4 字节设计支持 U10FFFF足以覆盖 Unicode 所有字符未来扩展空间充足。
   
9. 为何 UTF-16 对东亚字符更节省字节 UTF-16 的前身 UCS-2固定 2 字节设计时假设 65,536 个字符BMP足够覆盖所有语言尤其优化了东亚字符中文、日文、韩文多在 BMP。 UTF-16 继承了这一优势对 BMP 字符直接用 2 字节无需标记位。 UTF-8 为了 ASCII 兼容性和变长编码的通用性牺牲了东亚字符的存储效率3 字节。 GB2312、GBK 与 UTF 的出现时间及比较 出现时间 GB2312 发布时间1980年。 正式实施1981年5月1日。 全称“信息交换用汉字编码字符集 基本集”是中国大陆制定的第一个汉字编码国家标准。 GBK 发布时间1995年12月。 全称“汉字内码扩展规范”是对 GB2312 的扩展由中国电子工业部和微软合作开发。 UTF-8 和 UTF-16 UTF-8 提出时间1992年由 Ken Thompson 和 Rob Pike 在 Plan 9 系统中设计。 标准化1993年纳入 Unicode 标准和 RFC 2279。 UTF-16及其前身 UCS-2 UCS-2固定 2 字节编码1991年Unicode 1.0 发布时。 UTF-16扩展到代理对1996年Unicode 2.0 引入补充平面。 Unicode 项目本身始于1988年1991年发布 Unicode 1.0。 时间线对比 GB23121980 Unicode/UCS-21991 UTF-81992-1993 GBK1995 UTF-161996。 GB2312 比 UTF-8 和 UTF-16 早约 10-15 年GBK 晚于 UTF-8 但早于 UTF-16 的最终形式。
   
10. GB2312 和 GBK 出现的原因 GB2312 和 GBK 是为满足中国大陆的汉字处理需求而开发的编码标准其出现与当时的技术环境、语言需求和国际化背景密切相关。 GB2312 的出现原因 汉字处理需求 1970年代中国计算机技术开始发展但受限于硬件能力和软件生态英文字符的 ASCII7 位128 个字符无法表示汉字。 汉字数量庞大常用字约 3000-7000全部字超过数万需要专门的编码方案来支持中文输入、存储和显示。 国家标准化需求 为规范信息交换如政府、出版、电信中国需要统一的汉字编码标准。 1970年代末中国启动了汉字编码研究目标是制定一个覆盖常用汉字的字符集。 技术背景 GB2312 基于双字节编码2 字节每个字符用 94x94 的编码空间区位码共收录 6763 个汉字一级 3755二级 3008及 682 个非汉字符号如拉丁字母、标点。 编码范围A1A1 到 FEFE高字节和低字节均避开 ASCII 的 0x00-0x7F兼容 ASCII单字节表示英文。 设计简单适合当时的计算机如 8 位或 16 位系统和终端设备。 意义 GB2312 是中国大陆第一个汉字编码国家标准广泛用于早期计算机、打字机和信息系统如 DOS 时代的中文软件。 推动了中文信息化如电子出版、数据库奠定了后续编码的基础。
    GBK 的出现原因 GB2312 的局限性 GB2312 只收录 6763 个汉字覆盖常用汉字但无法满足专业领域如古籍、地名、人名的需求。例如许多罕见汉字如“镕”不在 GB2312 中。 随着计算机普及用户需要更全面的字符集来支持复杂文本处理。 微软与 Windows 的推动 1990年代初微软进入中国市场Windows 95 的中文版需要支持更丰富的汉字集。 GB2312 字符集不足以支持 Windows 的字体库如宋体、黑体和应用程序需求微软推动扩展编码以支持更多汉字。 兼容性和扩展需求 GBKK 代表“扩展”在 GB2312 基础上扩展收录约 21,003 个汉字包括 CJK 统一汉字及更多符号总字符数约 21,886。 编码方式 仍用双字节编码扩展到 81-FE高字节x 40-FE低字节。 兼容 GB2312GB2312 的字符编码在 GBK 中不变。 新增字符填充 GB2312 未用的编码空间。 GBK 还部分兼容 Unicode 的 CJK 统一汉字试图与国际标准接轨。 市场驱动 GBK 成为 Windows ⁹⁵⁄₉₈ 中文版的默认编码CP936 代码页广泛应用于软件、游戏和早期互联网如 BBS。 它填补了 GB2312 和 Unicode 之间的过渡需求尤其在 Unicode 尚未普及的 1990年代中期。 意义 GBK 解决了 GB2312 的字符覆盖不足问题成为 1990-2000 年代中国大陆的主流编码。 作为 GB2312 和 Unicode 的桥梁GBK 在中文信息化中起到关键作用。
    
11. 为何出现 GB2312 和 GBK而非直接用 UTF-8/UTF-16 GB2312 和 GBK 的出现早于或与 UTF-8/UTF-16 同时期主要是因为以下原因 时间和技术限制 GB23121980 1980年Unicode 项目尚未启动1988年才开始国际统一的字符编码不存在。 计算机硬件8 位 CPU、有限内存难以支持复杂的多语言编码GB2312 的双字节设计更适合当时的系统。 中国急需本地化编码来支持中文信息化GB2312 是为特定语言汉语定制的解决方案。 GBK1995 1995年Unicode 和 UTF-8 刚起步UTF-8 1993年标准化但尚未成熟或普及。 软件生态如 DOS、Windows仍以本地编码为主UTF-8 的变长编码1-4 字节在解析效率和兼容性上不占优势。 GBK 提供了快速、兼容的解决方案适应 Windows 和本地软件需求。 本地化需求 GB2312 和 GBK 专为中文设计针对汉字的编码空间和使用习惯优化 GB2312 覆盖常用汉字适合政府、公文、出版等场景。 GBK 扩展到罕见汉字满足专业和个人需求。 UTF-8/UTF-16 旨在支持全球所有语言编码范围庞大U10FFFF对中文场景显得“过于通用”早期实现成本高。 生态和市场驱动 GB2312由中国政府主导强制实施于信息交换系统如电信、银行形成国家标准。 GBK微软的商业推动使 GBK 成为 Windows 中文版的默认编码迅速普及于个人电脑和软件开发。 UTF-8/UTF-16 由国际组织Unicode 联盟推动初期缺乏本地生态支持推广较慢。 Unicode 的早期局限 1991年的 Unicode 1.0 只收录约 7000 个汉字远少于 GBK 的 21,000无法满足中文需求。 UTF-8 的变长编码需要 3 字节表示汉字在早期硬件上解析效率低于 GB2312/GBK 的固定 2 字节。 UTF-16UCS-2虽与 GB2312/GBK 同为 2 字节但不兼容 ASCII且代理对机制1996年尚未成熟。
    
12. GB2312、GBK 与 UTF 的对比 字符覆盖 GB23126763 个汉字 682 个符号覆盖常用中文。 GBK约 21,886 个字符覆盖常用和部分罕见汉字。 UTF-8/UTF-16支持 U10FFFF约 110 万字符覆盖全球语言。 编码方式 GB2312/GBK固定 2 字节汉字单字节ASCII简单高效。 UTF-8变长 1-4 字节ASCII 兼容汉字用 3 字节。 UTF-16变长 2-4 字节汉字用 2 字节BMP不兼容 ASCII。 应用场景 GB23121980-1990 年代的中文系统如 DOS、出版。 GBK1995-2000 年代的 Windows 软件、早期互联网。 UTF-82000 年代后主导互联网网页、JSON、数据库。 UTF-16Windows API、Java、JavaScript 内部。 现状 GB2312 和 GBK 逐渐被 UTF-8 取代但仍用于遗留系统和部分本地软件。 UTF-8 占全球网页编码 95% 以上2023 数据是现代标准。