ChromeOS 的中文输入法支持和现状(含 Linux 子系统)

in Technology with 0 comment

众所周知,ChromeOS 长期以来对 CJK 用户的支持程度都十分一言难尽。
博主对 ChromeOS 可能将被 Android 替代表示:好死。

本文讲述部分现状,和部分的 Workaround 解决方案。

主系统内

ChromeOS 一直有附带一个自带的中文输入法,看起来是这样的:
2025-03-10T08:59:34.png
且不说这个纯粹就是 Copy-Paste 日语输入法的远古 UI,灾难的词库也使其十分难以使用。
好在凑合还不是不能用,而且 Android 子系统里面它也是没什么大问题的。
不过对于很多人来说的一个巨大问题是——完全没有内置双拼输入法。我本人不用双拼,但如果你是双拼用户,这想必会成为一个很大的问题。

解决方案:真文韵输入法(fydeRhythm)

2025-03-10T09:39:13.png
真文韵输入法是 FydeOS 团队基于 Rime,使用 WebAssembly 在 ChromiumOS 系 OS 上实现的一个输入法引擎,较原版输入法体验优秀不少,且内置很多的输入方案的支持(包括雾凇拼音、双拼)。
https://chromewebstore.google.com/detail/fyderhythm-input-method/ppgpjbgimfloenilfemmcejiiokelkni?hl=en
说起这东西在 ChromeOS 上的运行,倒也有一个曲折的故事。本来 FydeOS 基于 Google 的 chrome.input.ime API 整得好好的,Google 突然一篇公告发出来就说这个 API 要没了,也没有给出任何现实的替代方案。

然后就真被删了一阵子,这一阵子 ChromeOS 用户就真的没有第三方输入法可用。

但过了一段时间 Google 又悄咪咪给它加回来了,也没发公告,世间鬼才。

Linux 开发环境(子系统) 内

众所周知,Linux Development Environment 的本质是一个 KVM 套一层 LXC (虚拟机套容器)的扭曲东西,使用 Google 自己整出来的一个叫 Sommelier 的东西提供图形化 App 的支持。

根据官方文档,Sommelier 自己承担类似于一个 Wayland Compositor 的任务,把 GUI 程序的合成工作转发给 ChromeOS 自己的 Wayland 服务器实现。它也会自己开启一个 XWayland 服务器,来支持 X11 应用程序。

顺带一提,对于显卡加速的支持,默认是基于 swrast 的纯软件渲染,但可以在 flag 里打开一个基于 virgl (属于 VirtIO 项目) 的硬件加速支持(因为仍然属于虚拟化,显然有性能损耗)。

好的,这一切都很好,然后问题在于哪里呢?

  1. 首先,整个 Sommelier 在 Wayland 输入法协议的支持的这一块,只支持 text-input-v1。
    Wayland 的 text-input-v* 的具体区别可参照 Fcitx5 的 Wiki

    简单来说,Google 非常奇怪地似乎十分鄙视 text-input-v3,不仅 Linux 版的 Chrome 不予支持 text-input-v3,Sommelier 也仅仅实现了 text-input-v1。

    如果单纯只是只支持这个的话,倒不算是一个特别大到影响使用的问题。

    • Qt:本来就只实现了 text-input-v2/v4,而这两个协议基本只有 KWin 支持了。所以除了 KDE 用户,大家用的都是 Qt IM Module,which 其实不是个太大的问题,毕竟也不是不能用。
    • Gtk:只实现了 text-input-v3。没有问题,这个协议作为正统合并进 wayland-protocols 里的协议,基本上每一个正经 Compositor 都是支持的——吧?鬼哦。Weston(被 Windows 的 WSL2 使用)和我们的主角 ChromeOS Sommelier 都不支持。but still,只要这个程序不整别的花活老老实实用的是 Gtk3/4,我们直接继续用 Gtk IM Module 就好了。而 Gtk2 的话本来就不支持 Wayland,所以也是一样的继续 XWayland + Gtk IM Module。
    • 其他程序:大不了就用 XWayland。
  2. Sommelier 的快捷键支持很诡异,切换输入法的快捷键经常不好使。
  3. Sommelier 的 Wayland 实现其实根本不咋样,导致崩溃的小问题挺多的。

然而显然问题不止这么简单。最大的根本问题在于:

Linux 环境里它很长一段时间内根本就没有输入法啊

所以前人们大部分是自己安装配置 Fcitx 用。

那么现在,what changed?

Google 在 M108 版本正式带来了 crosim 的支持,这就是 ChromeOS 输入法在 Linux 环境中的正式实现。
2025-03-10T09:38:38.png
原文要点:

从 M108 开始,有限的 IME 支持已可用于测试。
确保在输入设置中禁用自动更正和拼写/语法检查功能,这些功能尚未完工,且已知会导致问题。
当前支持仅限于 GTK 应用,这包括了 Electron 应用(例如 VS Code、Discord)、Firefox、LibreOffice(需安装 libreoffice-gtk)等。Qt 支持目前正在开发中但尚未可用。通过 XIM 服务器支持其他(非 GTK/Qt)应用(例如 Android Studio)的工作尚未开始。
目前我们主要针对语言支持,即中文、日文、韩文、阿拉伯文等。虚拟键盘、自动更正、拼写/语法检查等功能支持尚未就绪。
如果您经常使用多个 IME,可能已注意到 Ctrl+Space 在 Crostini 中无效。我们正在研究解决方案,在此期间此 Reddit 帖子详细说明了如何通过该快捷键从 Crostini 切换 IME。
如果您已手动在 Crostini 内安装 Linux IMF(例如 fcitx 或 ibus),可能设置了会与 cros-im 冲突的环境变量。要为 GTK 应用使用 ChromeOS IME 集成,需确保未手动设置 GTK_IM_MODULE。

那么,我们翻译成人话,要点就是:

这对我们意味着,基于 Chromium 的 App 现在就会可以调用 ChromeOS 原生的输入法了,但是对于其他的第三方应用,我们依然还是需要自己安装 Fcitx 等输入法。

tl;dr:那我到底怎么配置,才能有最接近完美的体验?

当然是,对于能支持 ChromeOS 原生输入法的应用用原生输入法,而不行的用 Fcitx。
以后可能我会详细写如何这么做的办法,在此之前先给一点参考链接:
https://blog.skihome.xyz/archives/5/
https://chromium.googlesource.com/chromiumos/platform2/+/355b615d5987b442e82e1445da7e8d35bbc71cae/vm_tools/cros_im/README.md

最后的吐槽

Google 对 ChromeOS 的「投入」真是让人哭笑不得——你说它不上心吧,它确实花了大力气搞了个 Linux 子系统和 Android 容器;你说它上心吧,这系统里随便一个功能都像是实习生用周末加班赶出来的半成品。输入法这种 CJK 用户刚需级别的功能,居然能靠「复制日语输入法 UI + 石器时代词库」硬撑十年,最后还得靠第三方团队用 WebAssembly 擦屁股,实在是魔幻现实主义。

更离谱的是,每当开发者试图在生态里做点正经事,Google 就突然掏出祖传艺能:发一篇公告把关键 API 扬了,留下一堆第三方应用在风中凌乱。等大家骂够了再偷偷把 API 塞回来,整个过程行云流水,仿佛在玩「API 生死开关模拟器」。这种薛定谔式的技术支持,连开发者都分不清到底是技术路线调整,还是单纯的产品经理喝高了。

至于 Linux 子系统的输入法支持,简直可以入选「人类迷惑技术行为大赏」——号称「开发者友好」的 Crostini 从诞生至今多少年了,连个正经的输入法协议支持都缝不明白。好不容易等来官方解决方案,结果发现只支持一部分 GTK 应用,还要和 Wayland 协议版本斗智斗勇?这就好比造了辆跑车,最后告诉你发动机只能烧花生油。更讽刺的是,当用户不得不同时启用原生输入法和 Fcitx 时,恍惚间仿佛回到了 2008 年用 Wine 跑 QQ 的黑暗岁月。

最让人绝望的是,当全世界都在拥抱现代化输入法框架时,ChromeOS 的 Linux 环境还在为「如何让 Ctrl+Space 正常切换输入法」这种搞笑问题挣扎。这哪里是什么操作系统?分明是数字时代的鲁滨逊漂流记——用户得学会钻木取火(改环境变量)、搭建茅屋(配置输入法框架)、与野生动物搏斗(解决 Wayland/X11 兼容问题),才能勉强生存下去。

或许有一天,当 ChromeOS 终于被 Android 彻底取代时,我们该为它刻一块墓志铭:「这里躺着一个缝合时代的残影,它教会我们,操作系统可以既像浏览器,又像虚拟机,唯独不像一个能好好打字的工具。」

好死,开香槟咯!🍾

Written by Deepseek,不代表博主立场(可能)。

Comments