Tag: JSMC

这个工具之前是一直不想发的，原因就是怕流传开了会触碰都Tora的G点，产生一系列的Captcha导致脚本失效之类的问题。

今天想了想，趁着Tora还健在，把这个东西发出来吧，不过希望这个工具不要给非acg圈子内的人用来净传一些无关紧要的东西，不过即使没有这个工具，其实Tora现在上面也依然混杂着各种奇怪的东西。[:locked]

这东西虽然比MCATOM写得早，但是我还是把它归类在MCATOM下吧。（顺带磨白cunhan哥的plowshare脚本，v5~[:otz])

先说说工具的作用。

最初的发想来自于风大的115养号工具。当时就考虑自己写这么一款工具，用于以下用途：

1：通过脚本获取用户上传ftp地址

2：通过脚本获取用户上传的文件地址

3：获取tora下载地址

先说正文。4天前用PYTHON写完了JSMC抓取链接的脚本，东西比较简单。不过自己对于PYTHON的开发库并不熟悉，核心部分用了2个小时就搞定了，不过有关用户界面却花费了将近4天时间，都迟迟拿不下来。很大一部分原因就是因为KDE和QT的关系让我不曾考虑用PYQT去尝试开发，转而走上了WXWIDGET的路子。不过WXWIDGET开发起来调试问题又有不少，对于我这种PYTHON初心者来说就比较麻烦了。于是最后还是用CMD把剩余的部分完成了（WIN下的GBK默认编码害死人，2套系统，一套JIS，一套GBK，LINUX下是UTF-8，太坑人了）。

不过这个真的只是个过渡产品。本来想补充图形的，受村汗哥启发，最后重新把脚本用GM写了出来，正当自己准备测试并编译写成FF插件的时候，功夫网发威了，TORA或许有可能塔布嗯莫西卡西呆，从此就成为了一个传说，成为了一个记忆，就算脚本没用了调试过程中的经验还值得的，嘛嘛，让他去吧，自己也就先把这东西放出来好了。

http://misuzi.org/files/fetchurl.user.js

简单说明下使用环境：FF3.6+GM 0.91。

简单总结下脚本开发中的遇到的种种问题。

1：GM_XMLHTTPREQUEST的延迟WRAPING。这个问题记得曾经在DIVEINTOGREASEMONKEY中看到过，不过这次在开发还是碰到了。因为安全性的问题，非沙箱对象在调用该方法的时候会报错，需要在调用前加上setTimeout(function(){GM_xmlhttprequest{....}},0)来调用，或者加上GM_WAIT来调用.

2:沙箱内外的JQUERY版本,GM内重新REQUIRE回来的JQUERY不会和页面中的JQUERY冲突,所以不用担心版本冲突.

3:有关跨域请求的问题。在写脚本前想到了3种实现方案。不过最后发现只有2种有效。其一：IFRAME或者AJAX的GETSCRIPT，其二：YQL语言，其三：GM或者FF插件。

其中2，3方案是有效的，不过其实YQL语言相当于介入一个SERVER作为代理来返回跨域请求数据，而实际操作中，自己并不希望有三方PROXY介入，因为这样的做法会损害到安全性，所以最后采取了GM的解决方案。除此之外，FF插件，也可以通过PYCOMET等工具来利用自己已经写好的PYTHON的脚本作为中介，不过鉴于太麻烦，也没有最终采用。

4：GM脚本的调试问题。之前花过大量的时间来研究如何最高效地开发GM脚本。因为GM是完全沙箱操作，所以也不能像开发外挂JS那样，边通过控制台操作，边书写脚本。不过也有这种方案，就是采用独立命名空间后，将命名空间赋值到unsafeWindow下的某命名空间，从而可以通过CONSOLE在加载GM脚本后进行一部分调试工作，对于排错来说可以带来极大的便利。最后吐槽一声，FF下的FIREBUG的CONSOLE，总会莫名其妙的加载不能。除此之外，GM的错误信息，多数情况是导出到FF的JS控制台中的，而非FIREBUG的控制台中。所以在加载过程中，即使手动指定了GM_log=unsaeWindow.cocnsole.log的前提下，倘若脚本中有语法错误的话，脚本未能成功加载，错误信息还是会输出到JS控制台中，盯着FIREBUG的控制台只会浪费自己更多的时间。

嘛，菜鸟一只，能想到的目前也只就这么多了，其他的以后想到再说了。