数据编码：修订间差异
更多操作
无编辑摘要 |
无编辑摘要 |
||
| 第56行： | 第56行： | ||
字符集回答“是什么字符”，字符编码回答“怎么存储”。 | 字符集回答“是什么字符”，字符编码回答“怎么存储”。 | ||
</blockquote> | </blockquote> | ||
== 进阶 == | |||
本节内容'''超出普通高中信息技术课程要求'''，用于帮助对计算机底层、操作系统或编程感兴趣的读者进一步理解字符编码在实际系统中的应用。 | |||
=== 字节序与 BOM === | |||
在多字节编码方式中，不同系统可能对'''字节顺序'''（Endian）有不同约定： | |||
* '''大端序'''（Big Endian）：高位字节在前 | |||
* '''小端序'''（Little Endian）：低位字节在前 | |||
UTF-16 和 UTF-32 编码由于每个字符占用多个字节，可能会受到字节序影响。 | |||
为了解决这一问题，Unicode 定义了 '''BOM'''（Byte Order Mark，字节顺序标记）： | |||
* UTF-16BE：<code>FE FF</code> | |||
* UTF-16LE：<code>FF FE</code> | |||
* UTF-8 BOM：<code>EF BB BF</code>（可选） | |||
UTF-8 本身不存在字节序问题，因此通常'''不推荐'''使用 BOM，但在某些系统（如部分 Windows 软件）中仍可能出现。 | |||
=== 常见乱码的产生原因 === | |||
乱码通常并非数据本身错误，而是'''编码解释方式不一致'''导致的，常见原因包括： | |||
* 使用 UTF-8 编码的文本被当作 GBK 或 BIG5 解码 | |||
* 文本文件实际编码与编辑器设置不一致 | |||
* 程序读写文件时未明确指定字符编码 | |||
* 网络传输或数据库存储过程中编码信息丢失 | |||
例如，将 UTF-8 编码的“中文”按 GBK 解码，往往会显示为一串无意义的符号。 | |||
=== 操作系统与字符编码 === | |||
现代主流操作系统普遍以 Unicode 作为内部字符表示方式： | |||
* Linux、macOS：默认使用 UTF-8 | |||
* Windows NT 内核：内部使用 UTF-16（Wide Char） | |||
Windows 系统中仍保留“代码页”（Code Page）机制以兼容旧程序，这也是部分 Windows 环境中乱码问题较为常见的原因之一。 | |||
=== 编程语言中的字符编码 === | |||
不同编程语言对字符编码的支持方式有所不同： | |||
* C / C++：字符编码与源文件、编译器和运行环境强相关 | |||
* Java、C#：内部统一使用 Unicode | |||
* Python 3：字符串类型基于 Unicode，文件 I/O 需显式指定编码 | |||
* JavaScript：字符串采用 UTF-16 编码 | |||
在实际开发中，明确约定'''源代码编码、文件编码和数据交换编码'''是避免问题的关键。 | |||
=== 为什么现代系统推荐使用 UTF-8 === | |||
UTF-8 成为事实上的通用编码标准，主要原因包括： | |||
* 向后兼容 ASCII | |||
* 跨平台一致性强 | |||
* 网络传输与存储效率较高 | |||
* 已成为互联网和开源软件的默认选择 | |||
因此，在新系统、新项目中，通常推荐统一使用 UTF-8 作为字符编码。 | |||
[[分类:信息技术]] | [[分类:信息技术]] | ||
2025年12月29日 (一) 06:34的最新版本
方便存储、检索和使用的数据形式
字符编码
美国信息交换标准代码
美国信息交换标准码（American Standard Code for Information Interchange，ASCII）为国际标准 ISO 646。 仅可显示英文字母、数字及英文标点符号。
不同的国家和地区制定了不同的字符集和字符编码标准以显示更多的语言文字。但由于缺乏统一规划，这些字符编码有可能存在冲突，例如：
在常见的 GB 2312（中国大陆的中文字符集）和 BIG5（台湾、香港等地区使用的繁体中文字符集）编码标准中，同一个编码数值 0xA6A1 所代表的字符是不同的：
- 在 GB 2312 编码中，字节 0xA6A1 代表中文符号“丶”（一个点）。
- 在 BIG5 编码中，同一个字节 0xA6A1 却代表符号“﹢”（一个小加号）。
统一字符编码
为了解决不同字符编码之间相互冲突、无法通用的问题，提出了统一字符编码（Unicode）的概念。
Unicode 为世界上几乎所有已知文字和符号分配了唯一的编号，称为码点（Code Point），通常表示为 U+XXXX 的形式。例如：
- 字符 “A” 的 Unicode 码点为
U+0041 - 汉字 “中” 的 Unicode 码点为
U+4E2D
Unicode 本身只规定字符与码点的对应关系，并不规定具体的存储方式。
Unicode 的编码方式
为了在计算机中存储 Unicode 码点，需要将其转换为具体的字节序列，这种转换方式称为 Unicode 编码方式，常见的有：
- UTF-8
- UTF-16
- UTF-32
UTF-8 编码
UTF-8（Unicode Transformation Format – 8-bit）是一种可变长度编码方式，也是目前互联网上使用最广泛的字符编码。
其特点包括：
- 使用 1～4 个字节表示一个字符
- 对 ASCII 字符完全兼容（ASCII 字符仍使用 1 个字节）
- 不同字符使用不同长度编码，节省存储空间
- 不存在字节序问题（无大小端之分）
例如：
- 字符 “A” 在 UTF-8 中编码为
41 - 汉字 “中” 在 UTF-8 中编码为
E4 B8 AD
由于其兼容性好、效率高，UTF-8 成为现代操作系统、网页和程序中最常用的字符编码。
字符集与字符编码的区别
- 字符集：定义“有哪些字符”，以及每个字符对应的编号（如 ASCII、Unicode）。
- 字符编码：定义“字符如何存储”，即如何将字符编号转换为字节序列（如 UTF-8、UTF-16）。
简单来说：
字符集回答“是什么字符”，字符编码回答“怎么存储”。
进阶
本节内容超出普通高中信息技术课程要求，用于帮助对计算机底层、操作系统或编程感兴趣的读者进一步理解字符编码在实际系统中的应用。
字节序与 BOM
在多字节编码方式中，不同系统可能对字节顺序（Endian）有不同约定：
- 大端序（Big Endian）：高位字节在前
- 小端序（Little Endian）：低位字节在前
UTF-16 和 UTF-32 编码由于每个字符占用多个字节，可能会受到字节序影响。 为了解决这一问题，Unicode 定义了 BOM（Byte Order Mark，字节顺序标记）：
- UTF-16BE：
FE FF - UTF-16LE：
FF FE - UTF-8 BOM：
EF BB BF（可选）
UTF-8 本身不存在字节序问题，因此通常不推荐使用 BOM，但在某些系统（如部分 Windows 软件）中仍可能出现。
常见乱码的产生原因
乱码通常并非数据本身错误，而是编码解释方式不一致导致的，常见原因包括：
- 使用 UTF-8 编码的文本被当作 GBK 或 BIG5 解码
- 文本文件实际编码与编辑器设置不一致
- 程序读写文件时未明确指定字符编码
- 网络传输或数据库存储过程中编码信息丢失
例如，将 UTF-8 编码的“中文”按 GBK 解码，往往会显示为一串无意义的符号。
操作系统与字符编码
现代主流操作系统普遍以 Unicode 作为内部字符表示方式：
- Linux、macOS：默认使用 UTF-8
- Windows NT 内核：内部使用 UTF-16（Wide Char）
Windows 系统中仍保留“代码页”（Code Page）机制以兼容旧程序，这也是部分 Windows 环境中乱码问题较为常见的原因之一。
编程语言中的字符编码
不同编程语言对字符编码的支持方式有所不同：
- C / C++：字符编码与源文件、编译器和运行环境强相关
- Java、C#：内部统一使用 Unicode
- Python 3：字符串类型基于 Unicode，文件 I/O 需显式指定编码
- JavaScript：字符串采用 UTF-16 编码
在实际开发中，明确约定源代码编码、文件编码和数据交换编码是避免问题的关键。
为什么现代系统推荐使用 UTF-8
UTF-8 成为事实上的通用编码标准，主要原因包括：
- 向后兼容 ASCII
- 跨平台一致性强
- 网络传输与存储效率较高
- 已成为互联网和开源软件的默认选择
因此，在新系统、新项目中，通常推荐统一使用 UTF-8 作为字符编码。