我们都知道如何从键盘输入文字，不是吗？

那么，请允许我挑战你在你最爱的文本编辑器中输入这段文字：

这段文字难以被输入因为它包含着：

• 键盘上没有的印刷符号，
• 平假名日文字符，
• 为符合平文式罗马字标准，日本首都的名字中的两个字母 “o” 头顶带有长音符号，
• 以及最后，用西里尔字母拼写的名字德米特里。

毫无疑问，想要在早期的电脑中输入这样的句子是不可能的。这是因为早期电脑所使用的字符集有限，无法兼容多种书写系统。而如今类似的限制已不复存在，马上我们就能在文中看到。

电脑是如何储存文字的？

计算机将字符作为数字储存。它们再通过表格将这些数字与含有意义的字形一一对应。

在很长一段时间里，计算机将每个字符作为 0 到 255 之间的数字储存（这正好是一个字节的长度）。但这用来代表人类书写所用到的全部字符是远远不够的。而解决这个问题的诀窍在于，取决于你住在地球上的哪一块区域，系统会分别使用不同的对照表。

这里有一张在法国常被广泛使用的对照表 ISO 8859-15：

如果你住在俄罗斯，你的电脑大概会使用 KOI8-R 或是 Windows-1251 来进行编码。现在让我们假设我们在使用后者：

对于 128 之前的数字，两张表格是一样的。这个范围与 US-ASCII 相对应，这是不同字符表格之间的最低兼容性。而对于 128 之后的数字，这两张表格则完全不同了。

比如，依据 Windows-1251，字符串 “said Дмитрий” 会被储存为：

115 97 105 100 32 196 236 232 242 240 232 233

按照计算机科学的常规方法，这十二个数字可被写成更加紧凑的十六进制：

73 61 69 64 20 c4 ec e8 f2 f0 e8 e9

如果德米特里发给我这份文件，我在打开后可能会看到：

said Äìèòðèé

这份文件 看起来 被损坏了，实则不然。这些储存在文件里的数据，即数字，并没有发生改变。被显示出的字符与 另一张表格 中的数据相对应，而非文字最初被写出来时所用的编码表。

让我们来举一个例子，就以字符 “Д” 为例。按照 Windows-1251，“Д” 的数字编码为 196（c4）。储存在文件里的只有数字 196。而正是这同样的数字在 ISO8859-15 中与 “Ä” 相对应。这就是为什么我的电脑错误地认为字形 “Ä” 就是应该被显示的字形。

多提一句，你依然可以时不时地看到一些错误配置的网站展示，或由 用户邮箱代理 发出的对收件人电脑所使用的字符编码做出错误假设的邮件。这样的故障有时被称为乱码（LCTT 译注：原文用词为 mojibake， 源自日语 文字化け）。好在这种情况在今天已经越来越少见了。

Unicode 拯救了世界

我解释了不同国家间交换文件时会遇到的编码问题。但事情还能更糟，同一个国家的不同生产商未必会使用相同的编码。如果你在 80 年代用 Mac 和 PC 互传过文件你就懂我是什么意思了。

也不知道是不是巧合，Unicode 项目始于 1987 年，主导者来自 施乐 Xerox 和…… 苹果 Apple 。

这个项目的目标是定义一套通用字符集来允许同一段文字中 同时 出现人类书写会用到的任何文字。最初的 Unicode 项目被限制在 65536 个不同字符（每个字符用 16 位表示，即每个字符两字节）。这个数字已被证实是远远不够的。

于是，在 1996 年 Unicode 被扩展以支持高达 100 万不同的 代码点 code point 。粗略来说，一个“代码点”可被用来识别字符表中的一个条目。Unicode 项目的一个核心工作就是将世界上正在被使用（或曾被使用）的字母、符号、标点符号以及其他文字仓管起来，并给每一项条目分配一个代码点用以准确分辨对应的字符。

这是一个庞大的项目：为了让你有个大致了解，发布于 2017 年的 Unicode 版本 10 定义了超过 136,000 个字符，覆盖了 139 种现代和历史上的语言文字。

随着如此庞大数量的可能性，一个基本的编码会需要每个字符 32 位（即 4 字节）。但对于主要使用 US-ASCII 范围内字符的文字，每个字符 4 字节意味着 4 倍多的储存需求以及 4 倍多的带宽用以传输这些文字。

所以除了 UTF-32，Unicode 联盟还定义了更加节约空间的 UTF-16 和 UTF-8 编码，分别使用了 16 位和 8 位。但只有 8 位该如何储存超过 100,000 个不同的值呢？事实是，你不能。但这其中窍门在于用一个代码值（UTF-8 中的 8 位以及 UTF-16 中的 16 位）来储存最常用的一些字符。再用几个代码值储存最不常用的一些字符。所以说 UTF-8 和 UTF-16 是 可变长度 编码。尽管这样也有缺陷，但 UTF-8 是空间与时间效率之间一个不错的折中。更不用提 UTF-8 可以向后兼容大部分 Unicode 之前的 1 字节编码，因为 UTF-8 经过了特别设计，任何有效的 US-ASCII 文件都是有效的 UTF-8 文件。你也可以说，UTF-8 是 US-ASCII 的超集。而在今天已经找不到不用 UTF-8 编码的理由了。当然除非你书写主要用的语言需要多字节编码，或是你不得不与一些残留的老旧系统打交道。

在下面两张图中，你可以亲自比较一下同一字符串的 UTF-16 和 UTF-8 编码。特别注意 UTF-8 使用了一字节来储存拉丁字母表中的字符，但它使用了两字节来存储西里尔字母表中的字符。这是 Windows-1251 西里尔编码储存同样字符所需空间的两倍。

而这些对于打字有什么用呢？

啊……知道一些你的电脑的能力与局限以及其底层机制也不是什么坏事嘛。特别是我们马上就要说到 Unicode 和十六进制。现在……让我们再聊点历史。真的就一点，我保证……

……就说从 80 年代起，电脑键盘曾经有过 Compose 键（有时候也被标为 Multi 键）就在 Shift 键的下边。当按下这个键时，你会进入 “ 组合 Compose ” 模式。一旦在这个模式下，你便可以通过输入助记符来输入你键盘上没有的字符。比如说，在组合模式下，输入 RO 便可生成字符 ®（当作是 O 里面有一个 R 就能很容易记住）。

现在很难在现代键盘上看到 Compose 键了。这大概是因为占据主导地位的 PC 不再用它了。但是在 Linux 上（可能还有其他系统）你可以模拟 Compose 键。这项设置可以通过 GUI 开启，在大多数桌面环境下调用“键盘”控制面板：但具体的步骤取决于你的桌面环境以及版本。如果你成功启用了那项设置，不要犹豫，在评论区分享你在你电脑上所采取的具体步骤。

（LCTT 译注：如果有读者想要尝试，建议将 Compose 键设为大写锁定键，或是别的不常用的键，Ctrl 和 Alt 会被大部分 GUI 程序优先识别为功能键。还有一些我自己试验时遇到过的问题，在开启 Compose 键前要确认大写锁定是关闭的，输入法要切换成英文，组合模式下输入大小写敏感。我试验的系统是 Ubuntu 22.04 LTS。）

至于我自己嘛，我现在先假设你用的就是默认的 Shift+AltGr 组合来模拟 Compose 键。（LCTT 校注：AltGr 在欧洲键盘上是指右侧的 Alt 键，在国际键盘上等价于 Ctrl+Alt 组合键。）

那么，作为一个实际例子，尝试输入 “LEFT-POINTING DOUBLE ANGLE QUOTATION MARK（左双角引号）”（LCTT 译注：Guillemet，是法语和一些欧洲语言中的引号，与中文的书名号不同），你可以输入 Shift+AltGr <<（你在敲助记符时不需要一直按着 Shift+AltGr）。如果你成功输入了这个符号，你自己应该也能猜到要怎么输入 “RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK（右双角引号）” 了。

来看看另一个例子，试试 Shift+AltGr --- 来生成一个 “EM DASH（长破折号）”（LCTT 译注：中文输入法的长破折号由两个 “EM DASH” 组成）。要做到这个，你需要按下主键盘上的的 连字符减号 键而非数字键盘上的那个。

值得注意的是 Compose 键在非 GUI 环境下也能工作。但是取决于你使用的是 X11 控制台还是只显示文字的控制台，它们所支持的组合按键顺序并不相同。

在控制台上，你可以通过命令 dumpkeys 来查看支持的组合按键列表（LCTT 译注：可能需要 root 权限）：

dumpkeys --compose-only

在 GUI 下，组合键是在 Gtk/X11 层被实现的。想要知道 Gtk 所支持的助记符，可以查看页面：https://help.ubuntu.com/community/GtkComposeTable

我们可以避免对 Gtk 字符组合的依赖吗？

或许我是个纯粹主义者，但是我为 Gtk 这种对 Compose 键进行硬编码的方式感到悲哀。毕竟，不是所有 GUI 应用都会使用 Gtk 库。而且我如果想要添加我自己的助记符的话就只能重新编译 Gtk 了。

幸好在 X11 层也有对字符组合的支持。在以前则是通过令人尊敬的 X 输入法（XIM）。

这个方法在比起基于 Gtk 的字符组合能够在更加底层的地方工作，同时具备优秀的灵活性并兼容很多 X11 应用。

比如说，假设我只是想要添加 --> 组合来输入字符 → （U+2192，RIGHTWARDS ARROW（朝右箭头）），我只需要新建 ~/.XCompose 文件并写入以下代码：

cat > ~/.XCompose << EOT
# Load default compose table for the current local
include "%L"

# Custom definitions
<Multi_key> <minus> <minus> <greater> : U2192 # RIGHTWARDS ARROW
EOT

然后你就可以启动一个新的 X11 应用，强制函数库使用 XIM 作为输入法，并开始测试：

GTK_IM_MODULE="xim" QT_IM_MODULE="xim" xterm

新的组合排序应该可以在你刚启动的应用里被输入了。我鼓励你通过 man 5 compose 来进一步学习组合文件格式。

在你的 ~/.profile 中加入以下两行来将 XIM 设为你所有应用的默认输入法。这些改动会在下一次你登录电脑时生效：

export GTK_IM_MODULE="xim"
export QT_IM_MODULE="xim"

这挺酷的，不是吗？这样你就可以随意的加入你想要的组合排序。而且在默认的 XIM 设置中已经有几个有意思的组合了。试一下输入组合键 LLAP。

但我不得不提到两个缺陷。XIM 已经比较老了，而且只适合我们这些不太需要多字节输入法的人。其次，当你用 XIM 作为输入法的时候，你就不能利用 Ctrl+Shift+u 加上代码点来输入 Unicode 字符了。什么？等一下？我还没聊过那个？让我们现在来聊一下吧：

如果我需要的字符没有对应的组合键排序该怎么办？

组合键是一个不错的工具，它可以用来输入一些键盘上没有的字符。但默认的组合集有限，而切换 XIM 并为一个你一生仅用一次的字符来定义一个新的组合排序十分麻烦。

但这能阻止你在同一段文字里混用日语、拉丁语，还有西里尔字符吗？显然不能，这多亏了 Unicode。比如说，名字 “あゆみ” 由三个字母组成：

• “HIRAGANA LETTER A（平假名字母 あ）” （U+3042）
• “HIRAGANA LETTER YU（平假名字母 ゆ）” （U+3086）
• 以及 “HIRAGANA LETTER MI（平假名字母 み）” （U+307F）

我在上文提及了 Unicode 字符的正式名称，并遵循了全部用大写拼写的规范。在它们的名字后面，你可以找到它们的 Unicode 代码点，位于括号之间并写作 16 位的十六进制数字。这让你想到什么了吗？

不管怎样，一旦你知道了的一个字符的代码点，你就可以按照以下组合输入：

• Ctrl+Shift+u，然后是 XXXX（你想要的字符的 十六进制 代码点）然后回车。

作为一种简写方式，如果你在输入代码点时不松开 Ctrl+Shift，你就不用敲回车。

不幸的是，这项功能的实现是在软件库层而非 X11 层，所以对其支持在不同应用间并不统一。以 LibreOffice 为例，你必须使用主键盘来输入代码点。而在基于 Gtk 的应用则接受来自数字键盘的输入。

最后，当我和我的 Debian 系统上的控制台打交道时，我发现了一个类似的功能，但它需要你按下 Alt+XXXXX 而 XXXXX 是你想要的字符的 十进制 的代码点。我很好奇这究竟是 Debian 独有的功能，还是因为我使用的语言环境（Locale） 是 en_US.UTF-8。如果你对此有更多信息，我会很愿意在评论区读到它们的！

死键

最后值得一提的是，想要不（必须）依赖 Compose 键来输入键组合还有一个更简单的方法。

你的键盘上的某些键是专门用来创造字符组合的。这些键叫做 死键 Dead Key 。这是因为当你按下它们一次，看起来什么都没有发生，但它们会悄悄地改变你下一次按键所产生的字符。这个行为的灵感来自于机械打字机：在使用机械打字机时，按下一个死键会印下一个字符，但不会移动字盘。于是下一次按键则会在同一个地方印下另一个字符。视觉效果就是两次按键的组合。

我们在法语里经常用到这个。举例来说，想要输入字母 ë 我必须按下死键 ¨ 然后再按下 e 键。同样地，西班牙人的键盘上有着死键 ~。而在北欧语系下的键盘布局，你可以找到 ° 键。我可以念很久这份清单。

显然，不是所有键盘都有所有死键。实际上，你的键盘上是找不到大部分死键的。比如说，我猜在你们当中只有小部分人——如果真的有的话——有死键 ¯ 来输入 Tōkyō 所需要的长音符号（“平变音符”）。

对于那些你键盘上没有的死键，你需要寻找别的解决方案。好消息是，我们已经用过那些技术了。但这一次我们要用它们来模拟死键，而非“普通”键。

那么，我们的第一个选择是利用 Compose - 来生成长音符号（你键盘上有的连字符减号）。按下时屏幕上什么都不会出现，但当你接着按下 o 键你就能看到 ō。

Gtk 在组合模式下可以生成的一系列死键都能在 这里 找到。

另一个解决方法则是利用 Unicode 字符 “COMBINING MACRON（组合长音符号）”（U+0304），然后字母 o。我把细节都留给你。但如果你好奇的话，你会发现你打出的结果有着微妙的不同，你并没有真地打出 “LATIN SMALL LETTER O WITH MACRON（小写拉丁字母 O 带长音符号）”。我在上一句话的结尾用了大写拼写，这就是一个提示，引导你寻找通过 Unicode 组合字符按更少的键输入 ō 的方法……现在我将这些留给你的聪明才智去解决了。

轮到你来练习了！

所以，你都学会了吗？这些在你的电脑上工作吗？现在轮到你来尝试了：根据上面提出的线索，加上一点练习，现在你可以完成文章开头给出的挑战了。挑战一下吧，然后把成果复制到评论区作为你成功的证明。

赢了也没有奖励，或许来自同伴的惊叹能够满足你！

via: https://itsfoss.com/unicode-linux/

作者：Sylvain Leroux 选题：lkxed 译者：yzuowei 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

黑客泄露 GTA 6 测试视频，并出售 GTA 5 的源代码

黑客在论坛上泄露了正在开发之中的侠盗猎车手 6（GTA 6）的数十个测试视频，总长度约 50 分钟，随后这些视频被以侵权为由删除。黑客声称是通过开发商内部 Slack 服务器访问到这些视频的，他们还访问到了游戏源代码，并以 1 万美元的价格出售 GTA 5 的源代码和素材，而其偷到的 GTA 6 测试版暂时不出售。这起事件被认为是游戏史上最大的泄露事件之一，开发商对 GTA 6 的细节以这种方式被分享一事感到“尤为失望”，但表示，“目前我们预计此事不会对现有的游戏进展造成任何干扰。”

消息来源：Bleeping Computer

老王点评：真是防不胜防啊，连游戏公司都成了恶意行为者们的目标。

Adobe-Figma 的 200 亿美元收购不被看好

周四，Adobe 以近乎估值两倍的价格，以 200 亿美元收购了协同设计软件公司 Figma。但二级市场似乎对这次 Adobe 的收购并不看好。消息披露后，Adobe 的股票最高跌幅一度逼近 17%，蒸发了近 300 亿美元市值，而这次的交易总额不过 200 亿美元。一方面，Figma 的一些用户非常沮丧。Figma 是以 Adobe 的竞争对手出现的，其文案宣传也是以 Adobe XD 为目标进行的，现在却被对手收入囊中，令那些逃离 Adobe 的用户情何以堪。另外一方面，Adobe 的收购似乎从没有好下场，比如之前开发了 Flash、Dreamweaver、Firework 网页三剑客的 Micromedia 现在已经没有声音了。

消息来源：CNBC

老王点评：尚未打倒巨龙，就被巨龙收买了——“没办法，他们给的太多了”。

Unicode 15 发布

Unicode 15 增加了 4,489 个字符，总数达到 149,186 个字符。新增字符包括 4193 个 CJK 中日韩表意文字、两种新的语言文字，以及 20 个表情符等等。

消息来源：Unicode

老王点评：Unicode 增加各种语言字符和未收录的少数语种，这没问题，但是我觉得现在收录的各种表情符有点太泛滥了，而且还有些奇奇怪怪的“男人怀孕”字符。