不知不觉中BurpCrypto从诞生到现在已经一岁半了，在这段时间里我对插件的基础功能进行了持续的Bug修复与优化，并在0.1.9版本中加入有史以来最重磅的功能 — 多JS引擎切换功能。
为什么需要多JS引擎切换
因为各个JS库的兼容性、功能完善性和运行性能差异问题，我加入了市面上最常见的三种可以嵌入Java内的运行库。
Rhino
Rhino运行库为目前兼容性最强的库，也是目前的默认引擎，其目前由Mozilla基金会负责开发与管理，没错就是Firefox相同的开发团队，这意味这它将会最快的获得最新的JS特性。除了不支持XHR以外，它几乎是最完美的JS引擎。不过从网络上也搜集到了关于Rhino直接调用Java组件实现网络请求的方式，如果可能的话，后续将会提供直接在该引擎内使用Java的org.apache.commons.httpclient组件实现网络请求的方法。
Jre Built-In
顾名思义，该引擎是集成在Jre中的ScriptEngine组件，也是BurpCrypto最初使用的JS引擎，这意味着它将获得最强的稳定性，但是也意味着它的功能陈旧，JS兼容性较差，不过好在性能还算可以，所以在0.1.9版本以引擎切换的契机重新回归。
HtmlUnit
该组件为0.1.9中新加入的引擎，该引擎最大的亮点为不仅支持JS引擎，而且支持无头HTML渲染，同时它也是目前唯一的，支持XHR的JS引擎，这将使网络请求支持成为现实，但是它也有不可避免的缺陷，该组件的冷启动极慢，组件体积较大（0.1.9版本文件体积直接接近20MB），内存、CPU占用率高，如果是性能较差的电脑可能在点击Start Attack后直接卡死 😥。
多种引擎切换的到来也导致上手难度直线上升，可能大多数用户需要爬不少坑才会领会各个引擎的特点与功能优势，于是我在某天突然有个想法，为什么不像maven一样做一个官方的JS仓库自动解决依赖关系呢，于是BurpCrypto-JsLibrary诞生了。
该仓库主要解决的问题是，在面对复杂系统的时候降低重复的工作量，对市面上常见的加解密、编解码库进行收集，并预先测试其兼容性，提供引擎使用建议、JS库的代码提示，用户使用时像maven一样使用UI直接搜索关键字引入即可，同时为了降低贡献门槛、提供较强可读性，使用yaml作为库描述文件格式，目前初步的schema如下：
- name: MD5 # 库的名字，唯一的
description: MD5 Message-Digest Algorithm # 库的描述信息
author: Whwlsfb(https://github.com/whwlsfb/) # 作者信息
engine: # 您测试通过的并且推荐使用的JS引擎，可写多个，目前可用的引擎有：[Rhino, JreBuiltIn, HtmlUnit]
- Rhino
path: # 您的JS库在本项目中的路径，可写多个。将按照顺序载入。
- lib/md5.js
functionCase: # JS库的函数列表，用户将通过该信息直接插入函数。
- functionName: md5
useCase: | # $PARM$ 是用户在代码编辑器中选中的文字，将会被`useCase`替换.
md5($PARM$);
example: | # 该代码库的使用示例.
md5('123456');
> e10adc3949ba59abbe56e057f20f883e
目前设想的远程ExecJs模块的运行逻辑大概如下：
目前该功能仍处于规划阶段，如果各位师傅有什么建议也欢迎提出。
其他功能
BurpCrypto走到今日，除部分小众功能外（国密算法、ExecJS直接调用内置模块），功能已经接近过饱和，在远程ExecJs模块开发完成后将逐渐走入Bug修复阶段并不再加入新功能，留出时间开发新工具。