阅读: 138
答案 1：
没有用。用 C-rome 去装个这个插件 [1]，然后打开知乎的 JS [2] 看看。JS 混淆器（比如 [3]）也就能重新命名一下变量、函数什么的。逆向工程很容易。JS 虚拟机短期内不会出现。保护好你的服务器端才是王道。[1]:-ttps://c-rome.google/webstore...[2]:static..z-i-u/static...[3]:code.google/closure/答案 2：
closure compiler是基于语法分析的混淆（准确的说是编译）。用它基本就够了，被反向后也很难看懂。前端代码没必要考虑保护，混淆或压缩纯粹是为了性能。答案 3：
可以混淆和压缩答案 4：
我觉得js从诞生起就不应该作为一种被保护的代码，因此你才会看到大量的js库都以开源方式发布，需要保护的代码是服务端的代码（防止你不想要的漏洞挖掘行为）和服务器的安全。
举个不恰当的例子，优秀的JS代码之于盗取代码的人而言就像名画之于临摹画作的人，你需要做的是把画做好就行，别人临摹反而是对你“画作”的一种肯定。因此，防止别人盗取要做的不是把画给抹掉，而是用法律武器（如果你想非开源并保护你代码版权的话）。
而虚拟机的话，js执行的宿主环境浏览器本来就可以看做一个虚拟机，除非把js弄成编译型语言，否则并无法做到源代码直接查看，但是这又会丧失了js本身优秀的动态特性
同样作为编译型语言的C# java等依然可以反编译出非常易读的代码（例如C#的反编译工具reflector），就算是C语言在编译后也可以反汇编为汇编代码，只要你有恒心，任何逆向工程都是可以的。因此，只要代码是在本地执行的，那就不存在绝对的代码保护。
js现有的保护机制主要为混淆合并等，但是更多这种工具（例如closure compiler）的初衷是用于减小js体积而不是用于混淆代码，而某些混淆加密工具反而会增大js体积，这在实践中是不可取的。
答案 5：
压缩只是减少IO的方式，对代码保护的作用应该不大。答案 6：
在一个开源时代，有必要保护吗？答案 7：
发到客户端的东西不用考虑保密的问题。考虑等于白考虑答案 8：
环境如此，再优秀的"表现"都会被拷贝，没有完善的知识产权保护体系，保护代码意义不大答案 9：
目前貌似保护不鸟，使用firefox可以直接查看引用的JS文件，就算压缩也没用，现在可以直接解压缩。答案 10：
只能压缩加混淆答案 11：
查看本页的 Javascript 并分析之，谢谢。答案 12：
-tml5本身的标签貌似强大了好多。。。要保护js。。。最好的办法就是能不用就不用。。。分享常识给亲友.
下一篇:计算字符串中子串出现的位置时结果出现了两次，可能原因是什么？ 下一篇 【方向键 ( → )下一篇】
上一篇:SAE能提供简捷实用的“网页表单数据提交”的模板功能吗？ 上一篇 【方向键 ( ← )上一篇】
快搜