Kodokon kodokon.com

重音字符、UTF-8 与换行符

弄明白为什么重音字符有时会变成乱码,以及看不见的换行符里藏着什么。

7 分钟 · 3 题

在 Kodokon 中打开本课

机器根本不知道字母 A 是什么。它只会处理数字。所以要写出文本,大家必须先就一张对照表达成一致:数字 65 表示 A,66 表示 B,依此类推。这个约定就叫编码。最古老的一个是 ASCII,它可以追溯到 1960 年代,只覆盖了英文字母:没有 é,没有 ç,没有 ü,一个汉字也没有。

后来每个国家都发明了自己的对照表,混乱随之而来:一个法语文件用俄语的对照表打开,就成了一堆乱码。现代的解决方案叫 Unicode,一份统一的字符总表,给所有语言的每一个字符都分配了一个编号,emoji 也包括在内。而 UTF-8 则是把这些编号写进文件的标准方式。今天的规则很简单,而且没有例外:始终把你的文件保存为 UTF-8

TEXT
用 UTF-8 写入,按 UTF-8 读取    ->  Creme brulee(重音正常)
用 UTF-8 写入,按 Latin-1 读取  ->  Crème brûlée
用 Latin-1 写入,按 UTF-8 读取  ->  Cr?me br?l?e
同一个文件用错误的对照表读取,就变成了乱码。

第二个看不见的东西:换行符。当你按下回车时,文件里并不会画出一条线。被加进去的是一到两个看不见的字符,而在这件事上,各个系统同样从未达成一致。macOS 和 Linux 用一个字符,LFline feed,换行),写作 \n。Windows 连用两个,CRLFcarriage return 回车,再加 line feed 换行),写作 \r\n。这直接来自打字机:当年需要两个分开的动作,先把字车推回去,再把纸卷下一行。

TEXT
你在屏幕上看到的:

Hello
Hi there

文件里真正存着的:

macOS / Linux (LF)     Hello\nHi there
Windows (CRLF)         Hello\r\nHi there
两个在屏幕上一模一样的文件,实际内容却不同。

知识检测

确认你已牢记本课的重点内容。

  1. é 显示成 é 时,发生了什么?
    • 读取文件用的编码和写入时用的不一样
    • 文件已经损坏,必须重新创建
    • 重音符号被系统删掉了
    • 字体缺失了
  2. Windows 历史上使用哪种换行符?
    • CRLF
    • LF
    • 单独的 CR
  3. 在代码编辑器里应该选哪些设置?
    • 编码用 UTF-8,换行符用 LF
    • 编码用 ASCII,换行符用 CRLF
    • 编码用 Latin-1,换行符用 CR