• 项目位置
• 使用详情请移步文档：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同理。如果单纯是从应用的性能问题考虑使用相关技术工具的话，还是要慎重抉择。