WeKnora 繁体转简体字典数据textconv详解OpenCC 词库的移植、实现与 FAQ 归一化应用【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora导读本文围绕 WeKnora 仓库中internal/textconv/data/README.md所描述的「繁体转简体字典数据」展开深入讲解TSPhrases.txt与TSCharacters.txt两份 OpenCC 词库的来源与许可证约束、字典文件格式与 SHA-256 校验、纯 Go 标准库查表转换器的实现原理以及该能力在 FAQ 问题归一化NormalizeQuestion中的实际调用链。读完本文你将掌握 WeKnora 如何在去除 GPL 依赖的前提下保留历史繁体转简体转换行为以及如何安全地审查字典更新对持久化内容哈希的影响。一、背景为什么 WeKnora 需要一份「纯净」的繁转简字典WeKnora 是一个开源 LLM 知识平台其 FAQ 命中能力依赖对用户提问与知识库问题的文本归一化繁体中文问题需要先转换为简体才能与语料库中的简体问题做一致性匹配相关调用见 internal/types/faq.go 中的NormalizeQuestion其中第 4 步即toSimplified→textconv.ToSimplified。历史上这份能力来自第三方 Go 库longbridgeapp/openccOpenCC 的 Go 移植但该库的底层依赖cedar-go采用GPL 许可证对以 Apache-2.0 分发的 WeKnora 构成许可兼容性风险。因此仓库将字典数据与转换实现解耦仅保留 OpenCC 的两份纯数据文件Apache-2.0用 Go 标准库map重写了查表转换器见 internal/textconv/simplified.go不再 vendor 或 importliuzl/da与 GPL 的cedar-go。如 data/README.md 所声明TSPhrases.txt和TSCharacters.txt是longbridgeapp/opencc v0.3.13词典的未修改原样拷贝许可证归属 OpenCC 及 longbridge/opencc 贡献者完整许可证保留在 licenses/OpenCC-Apache-2.0.txt。二、字典文件格式、规模与内容示例2.1 文件格式两份文件均为 UTF-8 纯文本每行一条映射采用TAB 分隔繁体词/字 \t 首选简体转换 [备选1 备选2 ...]以 internal/textconv/data/TSPhrases.txt 为例一目瞭然 一目了然 不瞭解 不了解 乾乾淨淨 干干净净 乾坤 乾坤 乾隆 乾隆注意短语词典中「乾元」「乾卦」「乾坤」等保留了「乾」原形因为它们在简体语境中不应统一变为「干」——这正是 OpenCC 词典将短语优先于单字设计的原因。2.2 文件规模文件词条规模实际行数内容TSCharacters.txt4113 行单字级映射如㑮 TSPhrases.txt277 行多字短语级映射处理一字多义场景单字词典覆盖了从常用字到生僻扩展区含、等 CJK 扩展区字符的大量映射保证了转换的覆盖面。三、许可证与来源合规数据文件本身是 OpenCC 词典的未修改拷贝因此必须保持 Apache-2.0 的许可证声明与归属。仓库通过两层机制落实许可证文件落盘完整保留 Apache License 2.0 原文于 licenses/OpenCC-Apache-2.0.txt并在 data/README.md 中显式注明出处longbridgeapp/opencc v0.3.13与贡献者归属不引入 GPL 代码README 明确「liuzl/da与 GPL 许可证的cedar-go实现未被 vendor 或 import」转换实现完全基于 Go 标准库。四、转换实现原理Go 标准库 map 最长匹配4.1 嵌入与初始化internal/textconv/simplified.go 使用go:embed将两份字典在编译期嵌入二进制//go:embed data/TSPhrases.txt var phrasesText string //go:embed data/TSCharacters.txt var charactersText string var traditionalToSimplified newConverter(phrasesText, charactersText)newConverter第 28-44 行按行解析用strings.Cut切出 TAB 前的 key 与之后的备选串strings.Fields拆出多个候选值只取第一个作为首选转换并记录每个字典的最大 rune 长度用于最长匹配上限。两份字典按「短语在前、单字在后」的顺序构建。4.2 转换算法convert第 53-80 行采用「短语优先、逐字典最长匹配、首选项、逐 rune 推进」的策略for pos : 0; pos len(runes); { matched : false for _, d : range c { // 历史上限单次最多匹配 10 个输入 rune limit : min(10, d.maxRunes, len(runes)-pos) for size : limit; size 0; size-- { if replacement, ok : d.values[string(runes[pos:possize])]; ok { result.WriteString(replacement) pos size matched true break } } if matched { break } } if !matched { result.WriteRune(runes[pos]); pos } }关键设计点按 UTF-8 正确处理多字节先转[]rune按 rune 滑动窗口天然支持中文与 emoji、扩展区字符混合的输入兼容历史行为注释明确「The previous converter searched at most ten input runes」即限制单次窗口不超过 10 个 rune与旧longbridgeapp/opencc转换器的行为保持一致并发安全字典在初始化后只读转换函数可安全并发调用性能保障result.Grow(len(text))预分配缓冲区避免多次扩容。4.3 行为优先级测试佐证internal/textconv/simplified_test.go 的TestDictionaryPrecedenceAndAlternatives用一个微型字典精确验证了三项语义c : newConverter(甲乙\t首選 次選\n甲乙丙\t最長\n, 甲乙丙丁\t不應優先\n丁\t尾\n) // convert(甲乙丙丁甲乙) 最長尾首選期望结果最長尾首選同时印证短语字典优先于单字字典甲乙丙命中而非甲乙丙、同窗口内最长匹配优先甲乙丙优于甲乙、同词条取第一个备选首選而非次選。五、FAQ 归一化中的实际调用链繁转简能力在 FAQ 检索链路中的入口是NormalizeQuestioninternal/types/faq.go其处理流水线为去首尾空白 → 2. 移除 URL → 3. 转小写 → 4. 去除首尾标点 →5. 繁体转简体toSimplified→textconv.ToSimplified→ 6. 全角转半角 → 7. 智能空格处理。其中第 5 步toSimplifiedinternal/types/faq.go直接委托给textconv.ToSimplified。同文件的NormalizeQueryText第 768-769 行复用同一逻辑确保搜索查询文本与入库问题走完全一致的归一化路径从而保证「繁體提问」能命中「简体知识库问题」。此外toHalfWidth第 744-764 行处理全角空格\u3000与全角 ASCII0xFF01–0xFF5E→0x21–0x5E与繁转简一起构成了 FAQ 匹配前的完整中文文本规整链。六、变更安全红线哈希固定与历史语料回归README 提出了两条重要的工程约束字典更新会影响 FAQ 归一化结果与持久化内容哈希词典变更会改变ToSimplified的输出进而改变基于归一化文本计算的 FAQ 哈希因此字典更新必须独立于转换器代码变更单独审查历史语料测试固定行为TestHistoricalConversionCorpusinternal/textconv/simplified_test.go将旧longbridgeapp/opencc v0.3.13转换器在13,177 个输入上的转换结果计算 SHA-256 摘要并固定每个字典 key 分别以「单独出现」「前key後上下文出现」「key 连续重复两次」三种形态测试另附加若干混合样例含乾隆年間乾乾淨淨的頭髮、臺灣ABC\x00後等多字节与空字符边界输入期望摘要f3afa240…bfbcc0与输入计数13177任一不符即测试失败。这意味着任何对字典或转换逻辑的修改都会被该测试拦截除非有意识地评估 FAQ 哈希兼容性。替换或升级字典时必须先运行该回归测试确认对已持久化 FAQ 的影响范围。七、如何验证与使用在仓库根目录运行转换器测试即可验证字典与实现的完整性go test ./internal/textconv/ -v该命令会依次执行基础转换用例如請聯繫客服開發環境→请联系客服开发环境、一目瞭然不瞭解→一目了然不了解、历史语料摘要校验与优先级语义测试。若输出包含ok internal/textconv且无 digest 失败则说明字典数据与旧版转换行为完全一致。字典数据本身可人工检查例如确认单字文件首行为㑮 、短语文件首行为一目瞭然 一目了然并可用sha256sum对照 data/README.md 中的两张摘要表TSCharacters.txt为6b5a0a79…9ecf09aTSPhrases.txt为b2ef895d…fa6324f校验文件未被改动。八、总结WeKnora 的繁转简字典数据模块是「数据合规 行为固化 轻量实现」三者的平衡样例数据层面仅保留 Apache-2.0 的 OpenCC v0.3.13 原始词典明确归属与许可证实现层面以 Go 标准库 map 重建「短语优先、最长匹配、首选替代」的转换器去掉 GPL 依赖工程层面通过 13,177 输入的语料测试将旧转换行为固定为不可变基线确保 FAQ 归一化与持久化哈希的长期稳定。对任何需要简体中文文本归一化能力的开发者而言这套「保留数据、重写实现、回归固话」的迁移思路本身就是一份可直接借鉴的工程范本。【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
WeKnora 繁体转简体字典数据textconv详解OpenCC 词库的移植、实现与 FAQ 归一化应用【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora导读本文围绕 WeKnora 仓库中internal/textconv/data/README.md所描述的「繁体转简体字典数据」展开深入讲解TSPhrases.txt与TSCharacters.txt两份 OpenCC 词库的来源与许可证约束、字典文件格式与 SHA-256 校验、纯 Go 标准库查表转换器的实现原理以及该能力在 FAQ 问题归一化NormalizeQuestion中的实际调用链。读完本文你将掌握 WeKnora 如何在去除 GPL 依赖的前提下保留历史繁体转简体转换行为以及如何安全地审查字典更新对持久化内容哈希的影响。一、背景为什么 WeKnora 需要一份「纯净」的繁转简字典WeKnora 是一个开源 LLM 知识平台其 FAQ 命中能力依赖对用户提问与知识库问题的文本归一化繁体中文问题需要先转换为简体才能与语料库中的简体问题做一致性匹配相关调用见 internal/types/faq.go 中的NormalizeQuestion其中第 4 步即toSimplified→textconv.ToSimplified。历史上这份能力来自第三方 Go 库longbridgeapp/openccOpenCC 的 Go 移植但该库的底层依赖cedar-go采用GPL 许可证对以 Apache-2.0 分发的 WeKnora 构成许可兼容性风险。因此仓库将字典数据与转换实现解耦仅保留 OpenCC 的两份纯数据文件Apache-2.0用 Go 标准库map重写了查表转换器见 internal/textconv/simplified.go不再 vendor 或 importliuzl/da与 GPL 的cedar-go。如 data/README.md 所声明TSPhrases.txt和TSCharacters.txt是longbridgeapp/opencc v0.3.13词典的未修改原样拷贝许可证归属 OpenCC 及 longbridge/opencc 贡献者完整许可证保留在 licenses/OpenCC-Apache-2.0.txt。二、字典文件格式、规模与内容示例2.1 文件格式两份文件均为 UTF-8 纯文本每行一条映射采用TAB 分隔繁体词/字 \t 首选简体转换 [备选1 备选2 ...]以 internal/textconv/data/TSPhrases.txt 为例一目瞭然 一目了然 不瞭解 不了解 乾乾淨淨 干干净净 乾坤 乾坤 乾隆 乾隆注意短语词典中「乾元」「乾卦」「乾坤」等保留了「乾」原形因为它们在简体语境中不应统一变为「干」——这正是 OpenCC 词典将短语优先于单字设计的原因。2.2 文件规模文件词条规模实际行数内容TSCharacters.txt4113 行单字级映射如㑮 TSPhrases.txt277 行多字短语级映射处理一字多义场景单字词典覆盖了从常用字到生僻扩展区含、等 CJK 扩展区字符的大量映射保证了转换的覆盖面。三、许可证与来源合规数据文件本身是 OpenCC 词典的未修改拷贝因此必须保持 Apache-2.0 的许可证声明与归属。仓库通过两层机制落实许可证文件落盘完整保留 Apache License 2.0 原文于 licenses/OpenCC-Apache-2.0.txt并在 data/README.md 中显式注明出处longbridgeapp/opencc v0.3.13与贡献者归属不引入 GPL 代码README 明确「liuzl/da与 GPL 许可证的cedar-go实现未被 vendor 或 import」转换实现完全基于 Go 标准库。四、转换实现原理Go 标准库 map 最长匹配4.1 嵌入与初始化internal/textconv/simplified.go 使用go:embed将两份字典在编译期嵌入二进制//go:embed data/TSPhrases.txt var phrasesText string //go:embed data/TSCharacters.txt var charactersText string var traditionalToSimplified newConverter(phrasesText, charactersText)newConverter第 28-44 行按行解析用strings.Cut切出 TAB 前的 key 与之后的备选串strings.Fields拆出多个候选值只取第一个作为首选转换并记录每个字典的最大 rune 长度用于最长匹配上限。两份字典按「短语在前、单字在后」的顺序构建。4.2 转换算法convert第 53-80 行采用「短语优先、逐字典最长匹配、首选项、逐 rune 推进」的策略for pos : 0; pos len(runes); { matched : false for _, d : range c { // 历史上限单次最多匹配 10 个输入 rune limit : min(10, d.maxRunes, len(runes)-pos) for size : limit; size 0; size-- { if replacement, ok : d.values[string(runes[pos:possize])]; ok { result.WriteString(replacement) pos size matched true break } } if matched { break } } if !matched { result.WriteRune(runes[pos]); pos } }关键设计点按 UTF-8 正确处理多字节先转[]rune按 rune 滑动窗口天然支持中文与 emoji、扩展区字符混合的输入兼容历史行为注释明确「The previous converter searched at most ten input runes」即限制单次窗口不超过 10 个 rune与旧longbridgeapp/opencc转换器的行为保持一致并发安全字典在初始化后只读转换函数可安全并发调用性能保障result.Grow(len(text))预分配缓冲区避免多次扩容。4.3 行为优先级测试佐证internal/textconv/simplified_test.go 的TestDictionaryPrecedenceAndAlternatives用一个微型字典精确验证了三项语义c : newConverter(甲乙\t首選 次選\n甲乙丙\t最長\n, 甲乙丙丁\t不應優先\n丁\t尾\n) // convert(甲乙丙丁甲乙) 最長尾首選期望结果最長尾首選同时印证短语字典优先于单字字典甲乙丙命中而非甲乙丙、同窗口内最长匹配优先甲乙丙优于甲乙、同词条取第一个备选首選而非次選。五、FAQ 归一化中的实际调用链繁转简能力在 FAQ 检索链路中的入口是NormalizeQuestioninternal/types/faq.go其处理流水线为去首尾空白 → 2. 移除 URL → 3. 转小写 → 4. 去除首尾标点 →5. 繁体转简体toSimplified→textconv.ToSimplified→ 6. 全角转半角 → 7. 智能空格处理。其中第 5 步toSimplifiedinternal/types/faq.go直接委托给textconv.ToSimplified。同文件的NormalizeQueryText第 768-769 行复用同一逻辑确保搜索查询文本与入库问题走完全一致的归一化路径从而保证「繁體提问」能命中「简体知识库问题」。此外toHalfWidth第 744-764 行处理全角空格\u3000与全角 ASCII0xFF01–0xFF5E→0x21–0x5E与繁转简一起构成了 FAQ 匹配前的完整中文文本规整链。六、变更安全红线哈希固定与历史语料回归README 提出了两条重要的工程约束字典更新会影响 FAQ 归一化结果与持久化内容哈希词典变更会改变ToSimplified的输出进而改变基于归一化文本计算的 FAQ 哈希因此字典更新必须独立于转换器代码变更单独审查历史语料测试固定行为TestHistoricalConversionCorpusinternal/textconv/simplified_test.go将旧longbridgeapp/opencc v0.3.13转换器在13,177 个输入上的转换结果计算 SHA-256 摘要并固定每个字典 key 分别以「单独出现」「前key後上下文出现」「key 连续重复两次」三种形态测试另附加若干混合样例含乾隆年間乾乾淨淨的頭髮、臺灣ABC\x00後等多字节与空字符边界输入期望摘要f3afa240…bfbcc0与输入计数13177任一不符即测试失败。这意味着任何对字典或转换逻辑的修改都会被该测试拦截除非有意识地评估 FAQ 哈希兼容性。替换或升级字典时必须先运行该回归测试确认对已持久化 FAQ 的影响范围。七、如何验证与使用在仓库根目录运行转换器测试即可验证字典与实现的完整性go test ./internal/textconv/ -v该命令会依次执行基础转换用例如請聯繫客服開發環境→请联系客服开发环境、一目瞭然不瞭解→一目了然不了解、历史语料摘要校验与优先级语义测试。若输出包含ok internal/textconv且无 digest 失败则说明字典数据与旧版转换行为完全一致。字典数据本身可人工检查例如确认单字文件首行为㑮 、短语文件首行为一目瞭然 一目了然并可用sha256sum对照 data/README.md 中的两张摘要表TSCharacters.txt为6b5a0a79…9ecf09aTSPhrases.txt为b2ef895d…fa6324f校验文件未被改动。八、总结WeKnora 的繁转简字典数据模块是「数据合规 行为固化 轻量实现」三者的平衡样例数据层面仅保留 Apache-2.0 的 OpenCC v0.3.13 原始词典明确归属与许可证实现层面以 Go 标准库 map 重建「短语优先、最长匹配、首选替代」的转换器去掉 GPL 依赖工程层面通过 13,177 输入的语料测试将旧转换行为固定为不可变基线确保 FAQ 归一化与持久化哈希的长期稳定。对任何需要简体中文文本归一化能力的开发者而言这套「保留数据、重写实现、回归固话」的迁移思路本身就是一份可直接借鉴的工程范本。【免费下载链接】WeKnoraOpen-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.项目地址: https://gitcode.com/GitHub_Trending/we/WeKnora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
宏详解)
