简介livla 是一套面向 Lojban 语言学习与开发的组合工具集整合了解析器、搜索接口、词典软件及 HTML 前端模块适合语言爱好者、初学者以及希望定制工具的开发者。压缩包内共 2000 个文件其中以 1613 个 mp3 发音音频为主体便于听音学习同时包含 C/Perl 解析脚本、JavaScript 逻辑、JSON 词库数据、SVG 示意图、OTF 字体以及多个配置文件可支撑词汇查询、语法解析、数据交换与界面展示等场景。整体大小约 44.38MB体积虽紧凑但覆盖了从底层数据到用户界面的完整链路。已有 167 人浏览/学习对希望获得离线词库与发音材料的学习者尤其友好。其中还提供 Docker 部署所需的配置示例和 IRC 机器人相关脚本能够帮助快速搭建实验环境借助其中的词源、形态分析等辅助文件开发者可深入探究 Lojban 的词典结构与解析逻辑为后续扩展工具链提供代码与数据基础。1. livla一组把 Lojban 文本解析、形态标注和词典搜索装进同一个页面的工具组合如果你接触过 Lojban应该会经历这样一个时刻拿到一句话单词都认识但不知道哪个是 cmavo功能词、哪个是 brivla谓词、哪个是合成词 lujvo想去查词典又不知道该查哪一段。livla 就是把这堆事打包在一起的纯前端工具集——它内置了一个用于 Lojban 形态分析的分词 parser、一份离线词表驱动的词典数据以及一个带搜索框的 search interface所有功能都跑在本地 HTML 页面里不用起服务、不用装依赖、不用联网。这套东西特别适合三类人刚开始系统学 Lojban 的爱好者、做人工语言文本处理想找个现成形态分析器的开发者以及想研究「无歧义语法语言该怎么用代码切词」的人。它的实现方式也很值得拆一拆。整个项目没有后端所有逻辑都堆在几个 JavaScript 模块里词表以 JSON 形式放在本地浏览器加载完数据之后parser 和词典模块各干各的活。接下来我会从架构、核心代码、运行方式和改造思路四个角度把它拆开既能让你照着跑起来也方便你把里面的 parser 抠出来用。2. 整体架构与技术选型纯前端 数据驱动的模块化设计2.1 为什么选纯 HTML/JavaScript 而不是后端框架livla 没有选择 Node.js 后端加数据库的方案而是把所有能力都收敛到浏览器端这个取舍和 Lojban 语言学工具的实际使用场景直接相关。做语言处理工具时最烦的事情是环境不一致——换台电脑、换个系统Python 依赖装不上、Java 版本不对项目就瘫了一半。纯前端项目把运行时收敛到浏览器只要你能打开网页工具就能用。配合上关键词里的 HTML 定位项目基本上就是「一个静态页面 若干脚本模块」的组合。词典数据被整理成 JSON 快照放在本地搜索时直接在前端内存里做过滤匹配避免了跨域请求、接口鉴权这些和语言学本身完全无关的复杂度。我一般会怎么理解这种选型呢如果一个语言工具的目标是「查词、分词、标注」而不是「给几十万人提供在线服务」纯前端方案实际上是最省事、最不容易翻车的路线。它牺牲了实时更新词库的能力换来了零部署、零运维的绝对便利。livla 的处理方式是让词表文件独立于代码后续要更新词典数据直接替换 JSON 文件就行。2.2 目录结构与模块职责项目的文件结构不长但模块边界划分得比较清楚拿到手之后应该长这样livla/ ├── index.html # 页面入口集成词典查询与解析展示 ├── css/ │ └── main.css # 单页样式兼顾解析结果与搜索列表 ├── js/ │ ├── parser.js # Lojban 文本分词与形态标注核心 │ ├── morphology.js # brivla / lujvo / cmevla 形态规则库 │ ├── dictionary.js # 词典索引构建与查询逻辑 │ ├── search.js # 搜索接口前缀模糊匹配与结果排序 │ └── app.js # 页面 UI 联动入口启动逻辑 └── data/ ├── cmavo.json # 结构词表含词性标注 ├── gismu.json # 基本谓词根词表 └── lujvo.json # 合成词表含组成 rafsiparser.js 负责把一段 Lojban 文本切成 tokenmorphology.js 根据形态规则给每个 token 归类dictionary.js 在页面加载时把三个 JSON 词表组合成一个索引结构search.js 则在这个索引上做查询。app.js 做最后的粘合输入框拿到文本调用 parser 做标注同时把结果里的每一个词交给 search.js 去词典里查释义最后渲染到同一个页面上。这个结构最大的好处是各模块可以单独替换。你想换掉搜索算法只需要动 search.js你想把 parser 用到别的项目里把 parser.js 和 morphology.js 拎出来就行完全不需要关心 UI 层。2.3 数据层词表 JSON 的组织方式词表数据是整个项目的燃料。cmavo.json 维护的是 Lojban 的结构词清单格式大概是这样的一组条目每个词条包含词本身value、词性类别selmaho也就是 cmavo 所属的语法类别比如 KOhA 代系词、BAI 介词、以及一段简短的英文或中文注释。gismu.json 记录的是约 1300 个基础词根每个词条额外带 rafsi 字段也就是这个词根的缩略形后面 lujvo 拆解要靠它。lujvo.json 存的是社区维护过的合成词每个词条核心字段是 rafsi 序列记录这个词由哪几个部件拼出来。数据驱动这块有个细节值得提项目把词表独立成 JSON 而不是硬编码进 JavaScript意味着二次开发者可以往里面加自己的词条。比如你是一个某个特定领域的 Lojban 使用者想加入领域术语的 lujvo直接往 lujvo.json 里追加条目就行parser 和搜索逻辑都不用改。这就是我前面说「数据与代码分离」的实际收益。3. 核心模块拆解从字符流到带完整标注的词序列3.1 分词链路不能只用空格切很多人第一次写 Lojban 分词器想的是「按空格 split 一下不就行了」实际做下去才发现这想法太天真。Lojban 文本里大量存在标点符号和词黏在一起的情况最典型的就是音位分隔符「.」——它在文本里紧贴词的边缘出现比如「.i mi klama.」里的 .i 和 klama.。如果直接按空格切得到的 klama. 会因为带个点号而无法匹配任何词表。livla 的处理方式是先在字符层做一次清洗把文本里的句读符号按规则和相邻词分离再做切分。核心逻辑在 parser.js 里典型的实现长这样// parser.js - 文本预处理与 token 切分 export function tokenize(text) { // 先统一处理音位分隔符. 与相邻字符之间补空格但不拆 .i 这类独立 cmavo const cleaned text .replace(/([.,?!])/g, $1 ) .replace(/\s/g, ) .trim(); return cleaned.split( ).filter(Boolean); }第一步先做标点隔离把逗号、句点、问号和感叹号从词的边缘拆开第二步再做空白规整最后 split 成 token 数组。注意第一行正则里的点号处理——普通句子里的英语句号会被切走但像 .i 这种本身就是一个词的情况切完之后还是会作为独立 token 留下来不会影响后续匹配。实际跑起来你会发现参数字段的取舍也很关键。如果你在清洗阶段把「.」从文本里彻底删掉而不是隔离那 .i 这个高频 cmavo 就永远不可能被识别出来。所以我一般建议标点一律隔离而不删除至于哪些 token 是有效词交给形态判断阶段去决定而不是在分词阶段就武断丢弃。3.2 形态判断cmavo、brivla、cmevla 的三分类逻辑切出 token 之后真正有技术含量的是形态判断。Lojban 的词可以粗分为三大类cmavo 是结构词数量有限直接查表brivla 是谓词可细分为 gismu根词、lujvo合成词、fuivla外来词cmevla 是名字。livla 的 morphology.js 按这个框架做了一层分类函数// morphology.js - 单 token 形态分类 export function classifyToken(token) { if (cmavoSet.has(token)) { return { type: cmavo, selmaho: cmavoMap[token] }; } if (isCmevla(token)) { return { type: cmevla }; } if (gismuSet.has(token)) { return { type: gismu }; } if (isValidLujvo(token)) { return { type: lujvo, rafsiList: splitLujvo(token) }; } return { type: unknown }; }分类的顺序是有讲究的先查 cmavo 词表因为它是封闭集合、命中率最高接着判断 cmevla名字的形态特征非常明显——要么以大写字母开头要么以辅音结尾最后才轮到 brivla 家族。这个顺序能避免一个经典误判大小写混合的名字可能长得像 lujvo如果先跑 lujvo 规则可能被错误拆分。cmevla 的具体判断规则是这个形态库里的核心逻辑// morphology.js - cmevla 形态规则 function isCmevla(token) { const hasCapital /[A-Z]/.test(token); const endsWithConsonant /[bcdfgjklmnprstvxz]$/.test(token.toLowerCase()); const containsVowel /[aeiouy]/.test(token.toLowerCase()); return containsVowel (hasCapital || endsWithConsonant); }参数说明hasCapital 判断是否包含大写字母Lojban 里非开头位置的大写字母是名字的标志endsWithConsonant 判断是否以辅音结尾所有 brivla 都强制元音结尾所以辅音结尾的词只可能是名字或外来语containsVowel 排除纯辅音串。这个函数当年让我栽过跟头因为 Lojban 文本里「J.」这种缩写会被上面的标点隔离逻辑切成 J 和 .J 没有元音被直接归为 unknown后来我加了一层白名单才解决——但这属于数据层问题不是形态逻辑的问题。3.3 lujvo 复合词拆解从黑匣子到可追溯的 rafsi 序列lujvo 的拆解是整个 parser 里最像「黑匣子」的部分。一个 lujvo 是多个 gismu 的 rafsi 缩略形拼接而成比如某个词由「bradi敌人」和「kacma相机」拼成实际呈现的字符串可能已经看不出原词。livla 的拆分策略不是用机器学习而是基于分词表做贪心匹配。// morphology.js - lujvo 贪心 rafsi 匹配 export function splitLujvo(token, rafsiIndex) { const results []; let remaining token; while (remaining.length 0) { let matched null; for (let len 5; len 2; len--) { const part remaining.slice(0, len); if (rafsiIndex.has(part)) { matched part; break; } } if (!matched) { return null; // 无法完全匹配放弃拆解判定 } results.push(matched); remaining remaining.slice(matched.length); } return results; }这段代码的思路是从左到右尽可能长地匹配 rafsi优先尝试五字母的长形 rafsi然后是四字母、三字母最短到双字母。匹配不到就返回 null外层 classifyToken 就会把这个 token 归为 unknown。rafsiIndex 是页面启动时由所有 gismu 的 rafsi 字段构建的哈希索引把几万条候选词预先映射好匹配时是 O(1) 查表。这个实现做对了什么做对了「失败可见」。很多语言工具遇到不认识的词就静默跳过livla 会把拆解失败的 token 标记为 unknown你在页面上能直接看到哪段文本没被理解。对语言学习者来说这反而是优点——它逼着你去查语法而不是让程序假装读懂。我从这个模块里学到的最重要一件事是分词失败的信息别吞掉展示出来本身就是一种功能。4. 词典与搜索接口一个离线可用的 Lojban dictionary front-end4.1 词典索引构建策略livla 的搜索模块没有依赖任何外部词典 API所有词条来自 data 目录下的三个 JSON 文件。dictionary.js 在页面初始化时把三份词表合并成一个统一索引结构上分为「精确索引」和「文本索引」两层。// dictionary.js - 构建内存索引 export function buildIndex({ cmavo, gismu, lujvo }) { const entries {}; for (const [word, def] of Object.entries(cmavo)) { entries[word] { type: cmavo, ...def }; } for (const [word, def] of Object.entries(gismu)) { entries[word] { type: gismu, ...def }; } for (const [word, def] of Object.entries(lujvo)) { entries[word] { type: lujvo, ...def }; } return { entries, words: Object.keys(entries), }; }合并逻辑很直接但值得注意的点在于三个词表存在重复键的情况某些 gismu 的拼写形式和 lujvo 的短形式可能一致。处理策略是让优先级高的词表先写入后面相同的键被覆盖这里优先顺序是 cmavo gismu lujvo。我在改这个项目的时候把覆盖策略调成了反向——先写 lujvo 再写 gismu导致某个词的解释直接从「基本词根」变成了「复合词缩写」语义差很多。所以索引构建时优先级千万别拍脑袋定得先想清楚你的用户查这个词时更可能想要哪一种解释。4.2 前缀搜索与模糊匹配逻辑搜索接口是 livla 作为 dictionary-software 的核心体验所在。普通的「完全匹配 前缀匹配」方案在 Lojban 场景下体验并不好因为用户经常拼错音位或者不清楚自己要查的词属于哪一类。livla 的 search.js 在实现层级上做了扩展前缀匹配之外还支持对词条做编辑距离排序。// search.js - 带容错的前缀搜索 export function search(query, index, maxResults 20) { const q query.toLowerCase().trim(); if (!q) return []; const exact index.words.filter(w w q); const prefix index.words.filter(w w.startsWith(q)); const fuzzy index.words .filter(w levenshtein(w, q) 2) .sort((a, b) levenshtein(a, q) - levenshtein(b, q)); const seen new Set(); return [...exact, ...prefix, ...fuzzy] .filter(w !seen.has(w) seen.add(w)) .slice(0, maxResults) .map(w ({ word: w, ...index.entries[w] })); }这个搜索链路有三个阶段解释一下参数设计。exact 精确匹配命中后用户看到的第一个结果一定是他输入的原词prefix 前缀匹配对 Lojban 尤其重要因为大量 cmavo 是单音节短词输入前两个字母就能查到整个词族fuzzy 用编辑距离做兜底levenshtein 距离阈值设为 2能容忍一个音位的增删或替换。maxResults 控制返回条数避免模糊匹配把整个词表都捞出来。模糊匹配的代价也要说清楚levenshtein 函数是 O(n*m) 的对上万词表做全量过滤会导致搜索响应变慢。livla 的应对办法是只对长度差不超过 2 的词计算编辑距离把真正需要算距离的候选集从上万缩小到几十个。这个优化后来我在自己的项目里也复用了效果很明显。4.3 搜索界面交互与结果渲染UI 层 app.js 承担了把搜索接口和解析结果串联起来的任务。页面上有一个输入框同时承担两个功能输入整句时走 parser 做分词标注输入单个词时走 search 接口做词典查询。这个「一个入口两套逻辑」的交互设计做得好因为它不需要用户先判断自己输入的是词还是句子。结果渲染部分livla 用了纯 DOM 操作来拼 HTMLdiv classsearch-result span classwordtapla/span span classtypegismu/span p classdefinition某本词典中释义的占位文本/p /div每个结果块固定包含三个字段词形、词类徽标、释义文本。词类徽标按类型着色cmavo 蓝色、gismu 绿色、lujvo 橙色、cmevla 灰色扫一眼就能判断这词的性质。这块没有技术难度但对「搜索结果可读性」的影响非常大——大多数用户来查词典就是为了快速确认词的类别颜色区分比让他读注释里的一行文字直观得多。5. 本地运行与常见问题排查跑起来之后最容易踩的 5 个坑5.1 三步本地跑通livla 是纯前端资源理论上不需要构建工具但实际运行还是有几个讲究的步骤# 第一步进入项目根目录 cd livla # 第二步起一个本地静态服务 python3 -m http.server 8000 # 第三步浏览器打开 # http://localhost:8000要注意的是虽然项目用原生 ES Module 编写但它不能被 file:// 协议直接加载原因是模块加载的安全性限制。直接用浏览器双击 index.html 大概率白屏或报 CORS 错误必须走本地服务。如果你机器上没有 Python用 npx serve 或者 VS Code 的 Live Server 扩展效果一样。启动后首页会同时完成三件事加载词表 JSON 并构建索引、初始化 parser 形态库、渲染搜索框。看到页面标题下方的状态从「词表加载中」变成「就绪」就说明整个工具已经可以正常使用了。想验证 parser 是否正常工作在输入框里粘贴一句带音位分隔符的 Lojban 文本看输出区是否把每个 token 的形态类别渲染出来。5.2 坑 1双击 index.html 白屏现象页面打开空白控制台报错和 CORS 有关。原因浏览器安全策略禁止在 file:// 场景下加载本地 JavaScript 模块和 JSON 文件尤其是 export/import 语法在这种模式下会直接被拒绝。解决切到本地 HTTP 服务模式从 terminal 里的 localhost 地址访问。这个坑几乎所有模块化前端项目都会遇到跟 livla 本身无关但最容易劝退新手。5.3 坑 2搜索啥都搜不到但词表明明加载了现象页面显示「就绪」输入词条但没有返回任何结果。原因大概率是大小写问题。Lojban 的 cmevla 是大小写敏感的用户习惯性输入全小写但词表里存的是带大写形式的词条。解决在 search.js 的 query 归一化里同时做 toLowerCase并在索引构建时把所有词条统一成小写键匹配时不区分大小写。如果你二次开发时改动了 search.js这行归一化代码务必保留住。5.4 坑 3形态标注把 cmevla 识别成 brivla现象一个大写开头的名字被标成了 gismu 或 lujvo。原因上述分类顺序中如果先查 brivla 词表再判断 cmevla名字里恰好含有一个根词拼写时就被误判了。解决调整 classifyToken 的顺序把 cmevla 判断挪到 brivla 前面。这也是我前面特别强调分类顺序的原因——形态库本身的规则顺序就是防误判的第一道防线。5.5 坑 4自定义词表不生效现象往 data/lujvo.json 里加了新词条刷新页面后搜不到。原因浏览器的 HTTP 缓存把旧的 JSON 快照缓存住了尤其是用 Live Server 这类工具时文本文件的更新往往不会触发即时刷新。解决强刷CtrlShiftR或者先在浏览器 Network 面板里确认请求返回的是新文件内容。如果你改了词表结构比如给 gismu 增加了新字段还要确认 morphology.js 里对应的字段读取逻辑同步更新否则新字段会被静默丢弃。5.6 坑 5解析超长文本时页面卡死现象一次性粘贴几万字 Lojban 文本时点击解析后浏览器无响应几秒钟。原因lujvo 拆解是贪心匹配token 越多匹配次数越多加上每个 token 都要做词典查询复杂度叠加。解决把解析改为分批处理用 setTimeout 或 requestAnimationFrame 把大文本切块执行每批 200 个 token 就 yield 一次让出主线程。这是纯前端语言处理工具的通病也是你改造时最容易提升体验的一个点。6. 二次开发把 livla 从页面工具改造成可嵌入的语言处理管道如果你不想只在浏览器里用这套工具第二个比较实际的改造方向是把它从页面工具转成一个可以被命令行或后端调用的处理管道。整个改造的核心思路是parser.js 和 morphology.js 本来就是纯函数模块没有依赖 DOM唯一要做的是取消它们的浏览器专用绑定。// cli.js - 基于 livla parser 的命令行分词工具 import { readFileSync } from fs; import { tokenize } from ./js/parser.js; import { classifyToken } from ./js/morphology.js; const filePath process.argv[2]; const rawText readFileSync(filePath, utf-8); for (const token of tokenize(rawText)) { const classified classifyToken(token); console.log(token, , classified.type); }这段代码把整个工具从页面里解放了出来任何程序都可以通过子进程调用它来给 Lojban 文本做词法标注。第二步我建议你在 search.js 里加一个编辑距离的动态阈值参数允许调用方指定匹配宽容度因为词典场景和学术场景的输入错误率完全不同。第三步如果要把 livla 的服务能力开放给外部应用一个可选的封装是用原生 Node http 模块包一层轻接口把 classifyToken 的输出转成 JSON 返回。完成这三个步骤之后livla 就不再是「一个页面」而是一套语言处理基础组件前端页面可以作为查词入口CLI 可以喂给脚本做批处理HTTP 接口可以挂到任何本地工具上。我自己在把某个图像处理 Demo 改成命令行工具时就吃过类似的亏——当时核心逻辑全部写在 UI 回调里花了一晚上才把渲染逻辑和业务逻辑拆开。从那以后我每次接到这种「页面工具库」都会先做一件事把所有不碰 DOM 的函数全部拎成独立模块再决定要不要做二次开发。这个习惯让我后面每次改造都比预期快不少。希望帮到你。本文还有配套的精品资源点击获取