本文经 J-Compass 编辑流程调研与事实核查;编辑团队在发布前审核信息来源及准确性。 了解我们的编辑方法 →
本译文仅供参考,以方便阅读。内容以英文版本为准。 阅读英文原文 →
如何查找不认识的汉字:悬浮取词、手写输入、OCR识别与部首查字
查找一个陌生汉字本质上是一个“分流路由”问题,而非单一工具的选择。最合适的方法取决于目标字符是可被选中的文本、纸面上的图像像素,还是仅仅浮现在你的脑海中。12如果你只死记某一种工作流,在面对其他载体时就会浪费大量时间。真正高效的习惯是:先判定文本来源渠道,再选择与之精准匹配的检索路径。
概述
汉字检索方式根据你所阅读的载体来源呈现清晰的分野。不同的载体为计算机提供了截然不同的读取界面。将“汉字检索方法”简单当作一份平铺直叙的工具菜单,正是本文旨在纠正的误区。
查词决策树包含三大主分支,每个分支都配备了自己的梯级备用方案。一旦选错分支,原本一秒钟的悬浮取词就会演变成长达二十分钟的痛苦部首翻找。
为什么“查汉字”实际上包含三个截然不同的问题
查字工具按来源划分,是因为不同的载体呈现给计算机的读取表面截然不同。屏幕上的电子文本已经由 Unicode 编码构成,查词本质上只是把该字符传递给字典的过程。12
纸面上的手写或印刷字迹只是像素而非字符,必须先经过 OCR 步骤,字典才可能识别。34而局部记忆检索意味着你能在脑海中勾勒出字形轮廓,但手头既无文本也无图像可供 OCR 扫描。此时必须依靠结构化索引系统:部首网格、多部件组合检索或 SKIP 编码。256
这三大分支不可互相替代。面对本可一键悬浮取词的文本去翻部首网格,纯属浪费精力;而想对一本纸质书悬浮取词,若不先通过摄像头拍照也是不可能实现的。
决策树一览
该决策树首先按载体来源分流,再按该载体上最高效的手段推进。每条路径都配备了备用方案,因此形成了一个完整的树状图而非孤立列表。
路径 1(电子文本)最迅捷:优先使用悬浮弹窗插件,遇阻时复制粘贴至 Jisho 兜底。172路径 2(纸面或图像)在字典识别前必须先经过抓取捕获。8934路径 3(局部记忆)虽然耗时最长,但无论何时均百分之百有效,哪怕完全断网断电。21056
本文不涉及的内容
针对各个浏览器插件、OCR 应用以及漫画阅读器的深度评测,均收录在各自的专属页面中,本文不作赘述。部首理论在汉字分类下同样有独立专篇;本文仅根据构件的直观外形进行指称,而不陷入讨论哪一个是“官方权威”《康熙字典》部首的学术考证。
手写输入的具体笔顺规则亦不在本文讨论范围之内。下文手写输入部分侧重于输入法如何运作,而非笔画顺序本身;该部分的完整阐述请参阅笔顺专题文章。
路径 1:屏幕上的电子文本
当汉字显示在屏幕上且文本可以被鼠标或光标选中时,最佳选择几乎永远是悬浮取词插件。“可选中”意味着光标能够高亮单独的文字;已被栅格化渲染为纯图片的文本,或被 DRM 保护阅读器锁定选择功能的文字则不在此列。
使用 Yomitan 或 10ten Japanese Reader 进行悬浮取词(首选)
Yomitan 自称是一款“用于语言学习的浏览器弹窗词典插件”,是著名工具 Yomichan 的正统继承者。它基于 GPL-3.0 协议为 Chrome、Firefox 和 Microsoft Edge 提供安装包。111弹窗不仅可以展示匹配词汇的释义、汉字笔顺图解、真人发音音频,还能通过 AnkiConnect 一键制卡导出至 Anki。用户本地导入的各类辞书(包括 EPWING 格式)为检索提供强劲支持。1
10ten Japanese Reader(前身为 Rikaichamp)是另一款“通过悬停鼠标翻译日文的浏览器扩展”。它支持 Firefox、Chrome、Edge、Safari(App Store)以及 Thunderbird,同样遵循 GPL-3.0 协议。7与 Yomitan 相比,其主要特色在于声调(音调核)直观标示、日本人名地名字典自动关联比对、年代与度量衡单位自动换算,并且原生提供了简体中文和日文本地化界面。7
两款插件均能自动还原词形变化:将鼠标悬停在屈折变形后的动词上,弹窗会自动还原并显示其辞书形。17这正是为什么在连贯阅读时悬浮取词速度远超复制粘贴的原因所在——你完全不需要手动剥离送假名再去查原形。
两款工具均为社区开源项目而非商业软件。建议直接从官方应用商店或项目 GitHub 仓库下载,切勿使用第三方镜像站点。17
当悬浮取词受阻时复制粘贴至 Jisho
Jisho.org 支持直接输入汉字、假名以及罗马音;将单个汉字粘贴到搜索框中,即可返回该字的完整条目,包括音训读音、字义、JLPT 对应等级、常用学年、笔画数以及 SKIP 编码。21213文档列出了可用于缩小搜索范围的操作符:#strokes:N(笔画数)、#grade:N(学年)、#jlpt-nN(JLPT等级)、#skip:P-S1-S2(SKIP编码)以及 KANJIDIC2 编号均完全支持。2
每当源网页屏蔽扩展插件时,复制粘贴就是最稳妥的备选方案。常见受限场景包括:受 DRM 保护的电子书阅读器、锁定了文本选择的 PDF 查看器、禁用文字选中的网页应用,以及直接作为背景图渲染的文本。
实战范例:新闻文章中的汉字
以汉字“鬱”(utsu,意为“忧郁、茂密、阴沉”;JLPT N1,29画,SKIP 编码 4a25.1,初中常用汉字)为例。14该字结构复杂,即使是高阶学习者也可能一时遗忘读音;同时因笔画极为密集,部首查字异常痛苦,而这正是悬浮取词大显身手之处。
鬱蒼とした森の中を歩いた。15
“漫步在郁郁葱葱的茂密森林中。”
在 Yomitan 或 10ten 中将鼠标悬停在“鬱蒼”上,弹窗立即解析出 鬱蒼【うっそう】“郁郁葱葱、茂密”,汉字信息面板直接呈现“鬱”的读音、画数以及 SKIP 编码。1714若退回到 Jisho 复制粘贴,同样能检索出该字词条:读音 ウツ / うっ.する・ふさ.ぐ・しげ.る,JLPT N1,SKIP 4a25.1,画数29。14
悬浮路径只需单次悬停便能顺畅解析复合词“鬱蒼”;而复制粘贴路径则需要你先肉眼分辨出“鬱”是生词、将其从上下文中单独选中剥离、再单独粘贴。虽然二者最终抵达同一份字典数据,但悬浮路径丝毫不会打断你的沉浸式阅读流。
路径 2:纸面上的手写或印刷字迹
当载体为纸张、室外标牌、屏幕截图或任何字典无法直接抓取文本的图像时,必须引入图像捕获环节。选用何种捕获工具,取决于文本属于普通印刷体(如标识牌、书籍、菜单),还是特定漫画排版(如对话气泡中的艺术字体)。
针对印刷文字的摄像头 OCR:Google Lens 与 Apple 实况文本
苹果的 iOS 功能可用性页面将日语明确列为实况文本(Live Text)支持的语言。该名单还包含粤语、中文(简繁体)、韩语、泰语、越南语以及欧洲各主要语言。3苹果官方关于实况文本的支持文档指出,由于日语支持是在 iOS 15 / iPadOS 15.1 / macOS 12 Monterey 初版发布后陆续推送的,因此应以功能可用性页面为准。16
实况文本能够直接在相机取景框内以及“照片”中的任何图片上即时读取文字。长按选中的文字,即可弹出拷贝、查询、翻译和共享操作,轻点一下即可将抓取到的汉字无缝发送给词典 App。16谷歌翻译文档也为 Android 提供了对等的工作流:将摄像头对准文字,应用会原地覆盖显示译文,亦可从相册导入已有照片。4
Google Lens(智能镜头)已深度整合入谷歌翻译、Google 相册以及桌面版 Chrome 的侧边栏中。它能出色地处理横排与竖排日语文本、广告路牌乃至手写字迹。识别出的文字可以复制并粘贴至 Jisho 或其他辞书中。4在实际操作中,iPhone 上使用实况文本最为流畅,因为无需额外打开第三方应用;而在 Android 端和跨平台场景下,Google Lens 或谷歌翻译则是当仁不让的首选。34
漫画专用 OCR:KanjiTomo 与 Mokuro
KanjiTomo 能够“从图像中识别日文字符”,并实现“将鼠标对准屏幕上的任意图像一键查词”。它对横排和竖排日文均能提供支持。9这是一款免费的 Java 桌面应用。开发者说明其“已在 Windows 10 系统上通过测试,其他系统可能可用但不提供官方支持”,并要求安装日文字体。这让它稳稳立足于桌面端漫画阅读与游戏截图取词的专业利基市场。9
Mokuro 则“专为希望结合 Yomitan 这类弹窗词典来阅读日文原版漫画的日语学习者打造”。8它能够对漫画单行本进行离线批量预处理,并在漫画页面图像上方生成一层可自由选中的文本遮罩。处理好的结果直接在浏览器中打开,此时 Yomitan 或 10ten 便可像对待常规网页一样悬浮取词。178其处理管线由两个专用模型驱动:利用 comic-text-detector 定位对话气泡与文本区域,利用 manga-ocr 识别其中的日文字符。输出为 .mokuro 配置文件与原始图像,通过 Web 阅读器平滑浏览。8
Google Lens 和 Apple 实况文本等通用 OCR 主要是基于平整的横排印刷文本进行训练的。而漫画中的对白气泡通常是竖排排版、行间距不拘一格、常常使用极度风格化的夸张字体,周围还环绕着各种方向角度的拟声拟态字。Mokuro 的文本检测器针对这种复杂的漫画布局作了深度专项优化。这正是漫画专用工具能在通用 Lens 丢字漏字的地方精准命中的原因。8
KanjiTomo 与 Mokuro 均为基于 GPL 协议的免费社区工具。它们输出可供字典直接查询的原始文本,但本身并不包揽整句翻译——留给你亲自阅读日文原文,而这正是语言学习的核心真谛。89
手机与桌面端的手写输入
iOS 日语键盘在“设置 → 通用 → 键盘 → 添加新键盘 → 日语(假名)”中提供了手写(手書き)模式(可选择罗马字 / 假名 / 手写)。在 Android 与桌面端,谷歌日文输入法(Google Japanese Input)提供了内置汉字手写输入板。在 Android 上通常表现为 Gboard,而在 Windows、macOS 和 Linux 上则是独立的 Google 日文输入法应用。
Jisho 的手写画板则是网页原生环境下的免配置替代方案:“通过手写输入汉字,直接落笔绘制即可!”它带有清除与退格控制按钮,无需安装任何客户端软件。2在陌生的电脑或朋友的设备上临时应急时,这是环境搭建成本最低的选择。
当你能看清或回想起汉字的大致轮廓、却完全敲不出读音时,手写输入就是最佳武器。尤其是当遇到笔画数数不准、字形美术化严重导致 OCR 失效、或者无法使用摄像头的场合,手写输入尤为救急。其制约在于:识别的精准度很大程度上取决于书写时的笔顺是否大体符合规范,而这也是另一个重要专题。
实战范例:路牌上看到的汉字
设想你在药房外的招牌上看到了繁复的汉字“鬱”(29画),旁边紧挨着大字注明的“うつ病”。14
在 iPhone 上的操作步骤为:打开相机,取景框对准招牌,点击右下角出现的实况文本图标(方括号中带三条横线的指示符),长按“鬱”字,在弹出菜单中选择“查询”或“拷贝”,然后粘贴至 Jisho 或任何汉字辞书应用中。316
在 Android 上的步骤为:打开谷歌翻译,轻点相机,对准标牌,在取景悬浮覆盖中轻点要识别的汉字。“全选”后将识别出来的文字拷贝至剪贴板,随后粘贴至 Jisho。4无论通过哪台手机,将 鬱 粘贴到 jisho.org 后,均能获得标准释义:鬱【ウツ】“忧郁、抑郁、茂密”,29画,SKIP 编码 4a25.1,JLPT N1,初中常用汉字。14
两个手机平台的路径最终通向完全一致的字典条目。选择哪种方式完全取决于你手头拿着哪部手机,在查询效果上并无实质差异。
路径 3:局部记忆,且无任何源图像可供 OCR
保底分支专门用于处理汉字仅存在于你的记忆残片中、或者纸质书籍印刷受损无法被摄像头有效捕获的场景。这也是唯一不需要电源或网络的查字手段:一本 Halpern 纸质字典加一个笔画数,便已足够。
Jisho 部首筛选网格:挑选你能辨析出的构件
Jisho 的部首检索界面可点击搜索框旁边的部首图标进入,官方说明为:“通过构件查找汉字。点击可重置部首选择。”网格按照1至17画将部首分类排列。2其交互过程为渐进式收敛:每当你选中一个部首,候选结果集便会成倍收窄。持续追加选中的部首,直到目标汉字浮现在剩余的候选列表中。2
部首网格检索并不强求你必须知道该汉字的“主部首”——即传统纸质字典中归档字头所用的《康熙字典》权威部首。只要网格中存在该汉字所包含的任何一个可见构件(部件),都可以作为检索条件录入。这种宽容性让你在叫不出确切部首名称时也能查到目标字。2
多部首交叉检索:组合两个或更多部件
部署在 kanji.sljfaq.org/mr.html 的 sci.lang.japan 多部首检索工具是久经考验的免费实用经典。其帮助页面建议:“先识别汉字的一个部分。如果可能的话,通常最好从该汉字的上方或左侧起笔识别”,然后再添加另一个构件,或者在候选列表中进行浏览。6
候选列表“按总笔画数排序”,如果你能大体估算出汉字的总画数,就能以极快的速度锁定目标。6Jim Breen 的 WWWJDIC 同样提供了“Multi-radical selection”(多部首选择)功能,基于与 Jisho 相同的 KANJIDIC2 数据库驱动。6
即使是习惯了悬浮插件的用户,在一种特定场景下依然离不开多部首检索:汉字印在脑海中,或呈现在物理纸张上,却尚未被任何 OCR 设备数字化录入。多部首检索是在“我能看清它”与“我能在键盘上打出它”之间搭建的一座坚实桥梁。
Halpern 词典中的 SKIP 编码(纸质词典终极保底)
SKIP 是“汉字格局索引系统”(System of Kanji Indexing by Patterns)的缩写。它由 Jack Halpern 创立,并作为《讲谈社日英汉字学习者词典》(The Kodansha Kanji Learner's Dictionary,讲谈社国际,1999)及其前身《新日英汉字词典》(研究社1990;NTC 1993)的核心编排索引机制。101718SKIP 为每个汉字分配一个三段式代码 P-S1-S2,其中 P 为格局形态类别(1至4),S1 与 S2 分别为汉字被拆分后的两部分各自的笔画数。175
四种基本格局分类汇总如下:
| 格局 | 结构特征 | 范例 | SKIP 编码 |
|---|---|---|---|
| 1, 左右结构 | 纵向切分为左侧与右侧两部分 | 明 (左侧 日 4画,右侧 月 4画) | 1-4-4135 |
| 2, 上下结构 | 横向切分为上方与下方两部分 | 男 (上方 田 5画,下方 力 2画) | 2-5-2125 |
| 3, 包围结构 | 一个部件包围或部分环抱另一个部件 | 道, 国, 風, 区, 囲 | 3-S1-S25 |
| 4, 整体独体 | 无法归入前三种格局的独体或杂合形态 | 详见下方次级特征代码 | 4-S1-S25 |
格局4需要补充一个关键细节:它的第三位数字不是笔画数,而是次级特征代码:1 = 顶部有明显横画(如“雨”);2 = 底部有明显横画(如“白”);3 = 中间有纵向分割竖线(如“虫”);4 = 不具备上述特征(如“丼”)。5
Jisho 的 #skip: 操作符直接支持 SKIP 代码检索。例如输入 #skip:2-5-2 即可直接返回符合该结构格局的所有汉字,这是在没有纸质字典在手时使用 SKIP 最便捷的途径。212SKIP 作为纸质查词工具的最大魅力在于:它所要求的唯一技能就是数准汉字肉眼可见的两个半部各自的笔画数。完全不需要电,不需要网络,更不需要知道哪个部首才是官方认定的“正统部首”。1017
SKIP 系统受版权保护;Halpern 明确要求批量重新分发这些编码必须获得书面许可,但个人学习参考不受限制。17自用查字完全合规;但二次开发并公开发布转录其编码数据库则属于侵权行为。
基于读音推测与画数的保底筛选
当既记不清具体构件、又无法确定 SKIP 结构时,两类颗粒度较粗的过滤器依然可以收窄范围。Jisho 的 #strokes:N 操作符能够筛选出指定笔画数的所有汉字。你可以将其与其他检索条件组合,这在你对总画数有十足把握、却叫不出任何构件名称时尤为管用。2
基于读音的合理推测是第二种保底途径。如果你能从已知的声旁(表音部件)中推测出其大概的音读,Jisho 的纯文本搜索可以直接列出匹配汉字。例如在搜索框直接输入 かん,就能列出包含该读音的所有汉字与词条。2其背后的底层原理是:大量汉字从声旁家族中继承了稳定的音读,这正是形声造字法在文字体系中建立起的规律。
实战范例:脑海中有印象却打不出来的汉字
以词汇“薔薇”(bara,意为“玫瑰”)中的“薔”字为例:JLPT 未收录,16至17画,SKIP 编码 2-4-13,属于常用汉字表外字。19这是一个极具现实代表性的案例:你在花店遮阳棚上看到了“薔薇”二字并明白其含义,但在键盘上却敲不出这个复杂的字符。
在 Jisho 上通过部首网格查找:打开部首搜索,由于字形顶端为草字头,首先勾选 艹(草字头,3画)。结果列表迅速收窄至草字头汉字。紧接着添加字形中可见的第二个内部构件,例如“土”或“回”(均包含在“薔”中),候选列表瞬间骤减,直到“薔”清晰显现。26
通过 SKIP 编码路径同样能通过外形直达该字。“薔”属于上下结构(格局2),上方为草字头(4画,在康熙部首传统算4画),下方为“嗇”(13画),得到 SKIP 编码 2-4-13。在 Jisho 中检索 #skip:2-4-13,候选列表中立刻出现“薔”。两条路径在同一个字符上殊途同归。2195
手前のガラス張りの建物は薔薇園なんです。20
“眼前这座玻璃建筑正是玫瑰园。”
这种条条大路通罗马的重合正是关键所在。只要你能准确指认出两个肉眼可见的构件,路径 3 下的所有分支手段——无论是部首网格、多部首检索还是 SKIP 编码——本质上都只是同一份底层 KANJIDIC2 数据库的不同查询语言而已。
补充知识
为什么即使两者均可用,悬浮取词依然优于复制粘贴
Yomitan 和 10ten 均能自动将变形后的动词和い形容词还原为辞书形。而复制粘贴到 Jisho 则必须由你手动甄别并剔除送假名,否则很可能遭遇“查无此词”的尴尬局面。172悬浮弹窗还展示了复制粘贴所没有的丰富外延信息,包括音频发音、汉字拆解构件、词频排名以及一键制卡导入 Anki 功能。复制粘贴每次只能反馈一整屏静态数据,而悬浮取词能让你的阅读思绪保持行云流水。17
手写输入在极度形似的近形字前容易失灵
手写识别对字形具有很强的容错能力,但在面对肉眼极度形似的近形字时(如 末 vs 未、土 vs 士、戌 vs 戍 vs 戊),如果笔顺写错,识别引擎便极难给出正确判断。学习者的反馈显示,错误的笔顺往往会导致引擎将完全错误的候选字排在列表最前端。如果你字形写得完全对称端正但笔画顺序颠倒,很可能会误选错误的字。笔顺为何具备这种决定性影响的机理,在笔顺专题中有系统剖析。
在轻信释义前先识别出 OCR 的“视觉陷阱”
实况文本与 Google Lens 主要是针对采光良好、端正平整的机打印刷体进行训练的。其高发失误场景包括:低对比度标牌、书法体或极度艺术化的招牌字体、缺乏清晰分栏的竖排文本、连笔手写字迹,以及复杂背景衬托下的细小字符。3164
容易诱导 OCR 误判的“视觉陷阱”通常是那些仅差一笔或一点的汉字:力 vs 刀 vs 刃、王 vs 玉、大 vs 太 vs 犬。当你查出的字典释义与上下文风马牛不相及时,立刻停止迷信 OCR 结果,转用下一个分支路径(部首网格或 SKIP)来核实。
Yomichan 并未消失,它进化为了 Yomitan
Yomichan 原作者已于2023年2月26日正式归档项目。代码随后被 The Moe Way 社区分支并更名为 Yomitan 持续维护。111那些涉及 Yomichan 的老旧教程、截图和论坛帖子在概念原理上依然适用,但其中的安装链接均已失效。请直接从各浏览器的官方扩展商店安装 Yomitan,不要再费心寻找旧链接。111