编译了 wasm 版本的 OpenCC，在浏览器上可以直接进行简繁体转换了

[oyyd]

• Github
• 使用详情请移步文档：playground 和文档。

wasm-opencc 开放中文转换OpenCC的 wasm 版本

这个项目对 OpenCC 进行了添加修改修改，并利用Emscripten进行编译，在 OpenCC 进行中文简繁体转换的能力上具有以下特性：

• 可在浏览器环境中直接运行。
• 在 node，eletron 中运行不需要再进行 addon 编译，避免复杂的 addon 部署工作。理论上应该也可以在 React Native 和 Web Worker 中运行(未经测试)。
• 分离了字典数据的加载和文本转换功能，在浏览器中只加载必要的字典数据，并允许自定义数据加载方式，方便从 CDN 上加载数据。

开发后的一些想法

OpenCC 很好，但遗憾的是我们必须开个服务才能使用，而我先前一直想在浏览器上直接运行，对页面的文本直接进行转换。而后发现tesseract.js是使用 Emscripten 编译而成，对 wasm 相关技术的成熟度感到意外，于是便有了这个项目。

在之前，我对 wasm 最关注的一点是 现在 Emscripten/WebAssembly 是否足够成熟了呢？ 如果你期望的是开箱即用，文档社区支持齐全（文档其实比较齐全，只是在碰到问题搜索对应文档时容易遇到困难），不会碰到太多问题的工具的话，我的想法是“没有”。你当然需要了解 c/cpp 和构建工具，并且我碰到了很多问题，特别是内存操作的问题，Emscripten 会抛出一个错误数字，没有其他任何错误信息，定位非常困难。或许有类似 gdb、lldb 的工具帮助解决这些问题，只是我目前不知道。

但如果你理解 WebAssembly 本身要解决的问题并不容易，并且愿意投入时间去面对这些问题的话，我想你在开发完一个项目以后会觉得 Emscripten 比你在使用前所想象的更加成熟一些。我开发完这个项目后，目前没有测试出内存相关的问题（当然本身是 js 运行环境，这点或许不值得一提）；在把碰到的几个问题解决或避开以后，其他大部分代码都没有出现问题，剩下的就只是纯粹 js 领域的封装调用了。

另外，一开始我没有打算提供 node 版本的代码，因为 @byvoid 自己早就做了 addon 的版本。但后来想到自己在开发 addon 上经历过的问题，深知 addon 在维护和部署上的困难，就一并生成了一份在 node 运行的版本。所以我觉得在 node 环境上，即便已经有了 addon 这套调用 c/cpp 的机制，wasm 也依旧具有优势。因为你可以用更短的时间，开发出不需要编译、能运行在浏览器上的版本，同时还不用理解 v8.h、node.h、Nan，只需要学习相对简单的多得多的 Embind 就可以了。

回头来看，WebAssembly 最大的优势诚如其文档所言，你可以直接将生成 llvm 的项目运行在 js 环境下，这点和 node addon 同理。如果单纯是从应用的性能问题考虑使用相关技术工具的话，还是要慎重抉择。

[yksoft1]

并且我碰到了很多问题，特别是内存操作的问题，Emscripten 会抛出一个错误数字，没有其他任何错误信息，定位非常困难。或许有类似 gdb、lldb 的工具帮助解决这些问题，只是我目前不知道。
我只知道打开--profiling-funcs 不去掉函数名之后可以在 Firefox 中看到 call stack

[pango]

这个可以说很实用了，完全可以商用的，感谢楼主开源。

[qdwang]

我是写 rust 编译到 wasm，用 wasmbindgen 交互，感觉非常方便。

[mytry]

不复杂的项目还是编译成 asm.js 比较好，兼容性更好，代码也可以直接在控制台里看。而且最新的浏览器内部会自动把 asm.js 转成 WebAssembly 运行。

[mytry]

等等，这玩意没有分词功能吗。。。

[oyyd]

@mytry 分词要看每个配置对应使用的分词词典，词典可以自己编辑。

[oyyd]

@qdwang 哈哈，Rust 社区在这方面做了很多事情，早有耳闻。

[oyyd]

@pango 感谢支持。更应该感谢 OpenCC 原项目，只是做了些微小的工作。

[oyyd]

@yksoft1 看到你 3 天前的帖子了

[sarices]

鼠标在港澳台都是滑鼠，你只在台湾繁体做了处理，港澳没有

[oyyd]

@sarices 感谢提出。关于字典本身的问题，恐怕最好的方法是维护一套自己的字典。这也是我把字典数据的加载分离出来的原因。