编译了wasm版本的OpenCC,在浏览器上可以直接进行简繁体转换了
发布于 2 年前 作者 oyyd 1148 次浏览 来自 分享

gif

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同理。如果单纯是从应用的性能问题考虑使用相关技术工具的话,还是要慎重抉择。

2 回复

楼主思考很棒,很佩服。

@zy445566 感谢支持

回到顶部