WeTextProcessing：一款面向语音应用的语音文本规范化工具

12次阅读

获取下载链

微信关注「软件教程管家」公众号，回复 WeTextProcessing

WeTextProcessing 是一款面向语音应用的语音文本规范化工具：它用可解释的规则，在书面表达与口语表达之间做双向转换——语音合成前做文本规范化（TN），语音识别后做逆文本规范化（ITN）。据源稿介绍，它基于 Pynini 与 OpenFst 的加权有限状态转换器（WFST）实现规则，支持多语言，并提供 Python 接口与独立的 C++ 运行时，适合需要把规范化过程讲清楚、测明白的语音团队先行评估。

软件信息

软件名称	WeTextProcessing
软件类型	语音文本规范化工具（TN / ITN）
核心机制	基于 Pynini 与 OpenFst 的加权有限状态转换器（WFST）规则
支持语言	Armenian、Chinese、English、German、Japanese、Korean（语言代码 hy、zh、en、de、ja、ko）
处理对象	数字、日期、时间、货币、单位等结构化表达
使用方式	Python 接口、命令行、独立 C++ 运行时
适用平台	多平台（具体以仓库 README 为准）
获取方式	GitHub 开源仓库

语音文本规范化：它到底解决什么问题

语音系统里同一串意思有两种写法：人看的书面写法，和机器朗读或听写时的口语写法。WeTextProcessing 的语音文本规范化就是管这道转换，并且用规则把每一步都留下来备查。

TN（文本规范化）：书面写法转口语写法。语音合成前，把数字、日期、时间、货币、单位等书面表达转成适合朗读的形式，朗读结果才像人话。
ITN（逆文本规范化）：口语写法转书面写法。语音识别后，把口语化的识别结果恢复成数字、日期等书面表达，输出结果才方便人阅读和存档。
可解释，不是一团黑盒。据源稿介绍，项目能输出标注字段、追踪输入输出跨度，并请求唯一的 n-best 结果，规则命中了哪一条、为什么这样转，都可以追溯和比对。
配置感知的 FST 缓存。可复用的规则图不必每次重复构建，便于评估不同部署方式。

版本选择：先定语言和方向，再选接入形态

这个项目没有“一个版本通吃”的选法，选型要先回答两个问题：目标语言是什么，要做 TN 还是 ITN。不同语言和方向的规则覆盖及配置选项并不相同，不能只看多语言列表就默认各语言能力等价。

只想先验证规则：走 Python 命令行，python -m tn 与 python -m itn 两个入口分别对应两个方向，跑通一例再谈集成。
要集成进现有服务：走 Python API，与 Python 技术栈的语音流程接在一起。
要独立部署：评估项目提供的独立 C++ 运行时，具体构建步骤、运行时接口和平台要求以 runtime 文档为准。
目标语言是 Armenian、German 或 Korean：据源稿介绍，README 明确说明这三语支持包含在源码检出中，优先按源码安装路径验证，不要默认常规安装就能拿到。
版本号与许可信息：以仓库 README 为准，本文不另行标注未经核实的版本号。

安装与接入步骤

备齐底层依赖。Python 环境必须具备 Pynini 和 OpenFst；如果没有可用的兼容 wheel，需要按照 Pynini 安装说明配置底层有限状态转换器环境。据源稿介绍，Windows CI 使用 conda-forge 安装 Pynini。
确认语言、方向与表达类型。先查目标语言、TN 还是 ITN、所需表达类型是否被现有规则覆盖，覆盖不全的先记下来，不要等到上线才发现。
用命令行跑通一例。分别用 python -m tn 和 python -m itn 验证一例 TN 与一例 ITN，确认输出格式符合业务接口。
再决定集成形态。需要 Python 集成时测试 CLI 与 Python API 的行为；需要独立部署时，阅读 C++ runtime 文档并验证构建、缓存和结果一致性。
建回归样例再投入使用。为目标语言和 TN/ITN 方向建立回归样例，新增或调整规则后，检查标注结果、转换结果、跨度追踪和 n-best 行为是否仍符合预期。

必改设置：用前先定好的 5 项

目标语言与语言代码：hy、zh、en、de、ja、ko 按需选定，规则覆盖以该语言实际提供的为准。
转换方向：TN 还是 ITN，二者规则与配置不同，不能混用同一套预期。
表达类型范围：数字、日期、时间、货币、单位中本次要覆盖哪几类，逐项核对，不要默认全覆盖。
可解释输出开关：是否需要标注字段、输入输出跨度追踪、唯一 n-best 结果，调试期建议全开，上线后再按需收敛。
FST 缓存策略：按配置使用 FST 缓存，减少可复用规则图重复构建的开销；若采用 C++ 运行时，单独验证其构建流程与 Python 规则生成结果的一致性。

注意事项

各语言能力不等价：不同语言和 TN/ITN 方向的规则覆盖及配置选项并不相同，选型结论必须按“语言×方向”逐项验证。
三语要走源码路径：Armenian、German 和 Korean 支持包含在源码检出中，使用这些支持可能需要从源码安装。
依赖兼容性要锁定：维护时锁定并验证 Pynini、OpenFst 与 Python 环境的兼容性，升级任一依赖都要重跑回归样例。
C++ 运行时信息不全：公开摘要未完整列出 C++ 运行时构建要求和兼容平台，部署前需查看 README、runtime 文档或源码确认。
长期维护状态需自查：公开信息有限，长期维护状态需结合 README、源码和实际测试确认，不要只凭摘要下结论。

适用人群与同类方案对比

这款工具适合构建文本转语音（TTS）前处理、自动语音识别（ASR）后处理，以及需要处理数字、日期、时间、货币和单位等结构化表达的语音应用开发者；对于需要自定义语言规则的团队，也可结合其规则架构和 Python API 进行评估。

方案思路	适合场景	短板
WeTextProcessing 这类规则驱动方案	转换过程要可解释、可回归测试的多语言语音流程	需要管理 Pynini / OpenFst 依赖，会写规则并维护回归测试
简单字符串替换方案	表达类型很少、规则极简单的轻量场景	规则一多就难维护，转换原因难以追溯