開動你的小手，nwjs 實現FTP客戶端

前言

基於什麼目的我會手動開發一個 FTP 客戶端呢？其實，很簡單，愛折騰，若是不是喜歡折騰，可能就不會對軟件開發如此癡迷，對其中的實現原理如此癡迷，一個不喜歡折騰的程序員，可能會失去方向感。最近公司集成第三方廠商的業務愈來愈多，SDK 也愈來愈大，SVN 服務器不容許對超過 50 MB以上的 SDK 進行管理，那咱們將這些 SDK 放哪兒呢？沒錯，就是 FTP 服務器，過去的半年我做爲 Mac 的用戶使用 FTP 體驗極其糟糕，系統的 Finder 訪問 FTP 服務器沒法訪問，線上的軟件也沒找到合適的，半年下來我搗鼓了虛擬機，裝了 Window10 ，在 Mac 和 Window10 之間，常年處於無縫切換的狀態。

事實上，出於對原理的好奇，決定動手開發 FTP 客戶端，開發過程總共 20 小時，大約 4 個晚上，中間也遇到過問題，也一併解決，整個兒過程下來，收穫頗豐。

基本功能概覽

客戶端下載地址 blogzzyc.obs.cn-east-2.myhuaweicloud.com/ipa/ftpclie…

• FTP 文件導航
• 文件下載
• 刪除文件
• 右鍵文件上傳
• 右鍵新增文件夾

技術選型

FTP 業務的核心，必定是與服務器的鏈接，在 gihtub 上找到了一個 4 年前的產物「node-ftp」。

總體文檔上看下來，功能齊全，手動測試了下，能夠正常訪問 FTP 服務器，因而就決定使用該模塊。（這裏有一個小問題，我沒有全面測試 API，只測了一個鏈接的 API，致使在後續開發過程當中使用 API 的時候 產生中文編碼問題，這裏體現了技術調研，必定要嚴謹，仔細）

客戶端容器使用 nwjs（node-webkit），實際上我對這個技術關注已久，一直沒有機會可以動手實踐一下，這回終於讓我用上了，nwjs 其實是一個 Hybrid App，你能夠直接在容器中使用 nodejs 的 API 做爲 Native Code，仍是很爽的。

表現層，我則使用了 Vue+ElmemtUI，當下最火，開發效率高，非他們莫屬。

開始開發

廢話不說，直接上手幹，在網上找了一款現成的 Vue+ElementUI 後臺項目模版，一頓 npm instal、npm run serve ，將項目運行出來，迅速將模版中不須要的模塊刪除，一番操做後，就遇到了第一個問題，Vue 的工程裏不能直接用 nodejs？使用 npm run serve 啓動了本地的開發服務，哦！？，須要將地址跑在 nwjs 裏才行吧，因而前往 nwjs.io 的官網，看了下文檔後，開啓了 remote-debug 模式，而後把地址放在調試模式的容器中跑起來，這下應該成功了吧？，一運行，仍是報紅，後來我仔細想了下，Webpack 有一個編譯過程，若是在 Vue 的工程中直接寫 nodejs 的代碼，可能會被編譯 es5 其餘的語法，機智如我，因而我在 public 目錄下新增 NWBridge.js 文件，在 index.html 主動引入文件，該文件負責鏈接 Vue 的事件和 nodejs 的 API，再次運行，再次用 remote-debug 運行，仍是不行，理論上此次應該是成功的，可是並無，我又想了下，是否是 nwjs 不容許在線地址調用 nodejs，我打開 nwjs 的 DevTool，輸入了 location.href=開發地址，此次直接跑起來，可是 nodejs 的 API 依舊沒有調用成功，只剩下最後依照，只能打成 nwjs 本地調試包，利用命令執行，接下來就是使用npm run build，而後增長 package.json 文件，新增一個 nwjs 的開發目錄 nw，將生成的源碼包和 package.json 文件放進去，而後利用全局命令nwjs ./nw，這一次運行成功，nodejs API 也調用成功了，內心大喜，可是一想，每次修改東西都須要幹這件事情，太複雜，能不能將這件事情自動化，因而我就修改了 npm run build 命令，變成了以下 (vue-cli-service build)&&(rm -rf ./nw/dist)&&(mv dist ./nw)&&(nwjs ./nw) 一頓操做，搞定，這樣每次修改完後，只須要執行npm run build 就能夠預覽、調試了，到此，開發環境算是搭建好了。

頁面的怎麼開發的，就不說了，工做量也很少無非就那麼幾下，接下來準備對接第一個 API ，顯示目標服務器的目錄，一頓搗鼓後，就有了以下效果：

很開心，因而對接各個模塊的點擊，進入子目錄，這時候遇到了嚴重的問題，中文目錄沒法訪問，點擊無效果，這個問題我花的時間最長，解決花了 6 個小時，這裏要注意咱們一開始是拿不到中文目錄的，如今能看到中文是由於我使用了iconv-lite模塊，對其進行 GBK 轉 UTF-8 編碼，因此能夠看到中文目錄，FTP 的服務器必定是個 Window 服務器，由於 GBK 只有 Window 纔有，而 nodejs 中不支持 GBK，因此須要這個著名的庫iconv-lite。到目前爲止，表現層可能沒法解決這個問題了，因而我將內容最小化，利用 js 腳本直接執行中文命令，我發現不行，並不能訪問，因此不得不讀 node-ftp 的源碼，源碼比較少，我花了兩個小時就看完了，我發現其原理和 smtp、iamp 相似，一樣是架起 socket 鏈接指定服務器，而後向管道里寫入 FTP 標準的指令，例如LIST命令，到這裏我忽然理解，管道寫過來的是 GBK，寫回去的必定也是 GBK 才行，因而修改源代碼，將管道統一寫回的地方，利用 iconv-lite 進行一層轉換，可發現仍是不行，因而我就取回管道過來的中文字節，對其中的中文字節手動篩選，找到指定文件名的中文變量，將字節原封不動的從管道寫回去，這一次，成功了！！，這證實理論沒錯，因而我再次對寫死的中文，經過一層轉換寫回管道，可仍是不行，此次又是爲何呢？無奈，再次排查後，發現我直接用寫死的‘中文字符串’，轉換出來的字節和從FTP管道寫回來的中文參數轉換出來的字節，差了一位，就由於一位致使沒法執行命令，因而這一次，我直接用FTP管道寫回的中文變量，再次訪問其子目錄，果真這一次成功了。

放一張成功的圖，成功進入其餘子目錄。

上述問題解決後，基本沒有大問題了，因而開始開發剩下的內容，其中包括上傳文件、下載文件、刪除文件、新增文件夾、導航欄麪包屑、FTP記錄讀寫等，這其中下載文件遇到一個問題，文件保存對話框如何打開，由於 <input type='file' /> 標籤只負責選擇上傳文件操做，到這裏我想到 nwjs 容器應該會提供對應的方法，因而又再次前往 nwjs.io 官網閱讀文檔，果真讓我找到了以下內容：

果真 nwjs 對 input 標籤進行重載，讓他支持了文件另存爲，OK！！到此功能所有完成，最後開始打包咱們的 App。

總結

爲何我須要去作這件事情，由於有計劃就須要付諸實踐，不然想法只能留在腦海裏，nwjs 就留了好久，而作完這件事情後，我又發現本身對 Hybrid App 的理解更加深入，做爲程序員，主動性驅動很重要，必定要主動的發現需求，發現問題，主動的去溝通，去交互，程序員之間無非就是比誰先踏出本身的一畝三分地，誰先主動行動，誰才能收穫更多。