- 專案位置
- 使用詳情請移步文件：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同理。如果單純是從應用的效能問題考慮使用相關技術工具的話，還是要慎重抉擇。