We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 9 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(10)
实际上,您正在尝试通过技术措施解决业务问题。
任何称职的 Javascript 程序员都应该能够通过查看产品本身轻松地重新创建您所做的任何事情,而不需要任何代码。这并不是说你正在发明一些以前从未见过的新的神奇东西,你只是以一种新的方式将各个部分组合在一起,正如你自己承认的那样。这只是 JavaScript。
即使您混淆了脚本,它仍然会按原样运行,竞争对手可以直接使用它并运行它。即使代码混乱,一些定制也不应该太难。
在您的利基业务中,如果有人“窃取”您的脚本,您可能很快就会注意到。如果发生这种情况,那就是一个法律问题。如果你的竞争对手想在法律上保持清白,他们无论如何都必须从头开始重写脚本,这会自动为你赢得一些时间。
如果您的竞争对手在技术上无法在不完全窃取代码的情况下复制您的产品,那么代码是明文还是混淆的都没有什么区别。
So really, you're trying to solve a business issue with technical measures.
Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.
Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.
In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.
If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.
虽然您可以走上混淆器的漫长而危险的道路,但您通常不会看到它们在真实的生产应用程序中使用,原因很简单,它们实际上并没有做太多事情。你会注意到,Google 应用程序实际上是一堆专有且非常有价值的 JavaScript,当你仔细研究时,它只是真正最小化而不是混淆,尽管最小化器现在的工作方式,它们与混淆一样好。你确实需要知道你在做什么才能从它们中提取意义,但有决心的人会成功。
另一个问题是,混淆的代码必须有效,如果它有效,人们可以在不了解其中大部分内容的情况下将其批量撕毁,并以他们认为合适的形式使用它。当然,他们不能直接修改它,但在一些补丁上分层并不难,这些补丁重新实现了他们不喜欢的部分,而不必深入研究。这就是 JavaScript 的本质。
Google 等公司之所以没有遭受大量剪切粘贴竞争对手的困扰,是因为 JavaScript 只是软件包的一部分。为了对这些东西的使用方式和位置进行一定程度的控制,大型组件需要基于服务器。好消息是,您可以利用 Node.js 等工具来相当轻松地拆分客户端和服务器代码,而无需使用完全不同的语言重新实现各个部分。
您可能想要研究的并不是那么令人困惑,而是将您的应用程序分成可以从某种服务按需加载的部分,并且因为这些部分可以高度相互依赖,并且如果没有这个核心,大部分都无法发挥作用服务器上,您可以更大程度地控制使用该库的时间和地点。
您可以从 Google 如何转向元库中看到这一点,该元库只是充当其他库的加载器。这是统一 Google Apps、Google AdSense、Google 地图、Google Adwords 等加载调用的一步。
如果你想聪明一点,你可以像 Google 地图一样,在你的 JavaScript 库中添加一个毒丸,因为它们是动态提供的,这样它们只能在特定的子域中运行。这需要根据需要生成它们,虽然可以通过足够的专业知识将其删除,但它会阻止 JavaScript 文件的大规模复制粘贴使用。插入一个验证 document.href 的巧妙调用并不难,而在一个极力最小化的文件中找到所有这些实例将特别令人恼火,并且可能不值得付出努力。
While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.
The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.
The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.
What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.
You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.
If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.
Javascript 混淆事实:
Javascript 混淆小说:(我将跳过本节;))
Q2 的回答 - 建议的混淆工具:
Q3 的答案 - 使用混淆代码的经验
Javascript obfuscation facts:
Javascript obfuscation fiction: ( I will skip this section ;) )
Answer to Q2 - Sugested obfuscation tools:
Answer to Q3 - experiences of using obfuscated code
混淆问题的标准答案:使用混淆器足以保护我的 JavaScript 代码吗?
IMO,这是浪费时间。如果竞争对手可以清楚地理解您的代码(假设它超过几千行......),那么他们应该可以轻松地对其进行反混淆。
混淆会导致更多错误,您可以通过花时间调试它们来管理它们。这取决于编写混淆的人(无论是你还是其他人),最终只会浪费大量时间。
Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?
IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.
Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.
在您编写完代码后,Google 的 Closure Complier 会对其进行混淆。也就是说,编写代码,通过编译器运行它,然后发布优化(和混淆)的 js。
如果您使用与库交互的外部 js,您确实需要小心,因为它会更改对象的名称,因此您无法分辨什么是什么。
Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.
You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.
到目前为止,自动全代码混淆仅在闭包编译器的高级模式下可用。
使用 Closure Advanced 模式编译的代码几乎不可能进行逆向工程,即使通过美化器也是如此,因为整个代码库(包括库)都被混淆了。平均也小 25%。
仅仅缩小的 JavaScript 代码(YUI Compressor、Uglify 等)在经过美化器后很容易进行逆向工程。
如果您使用 JavaScript 库,请考虑使用 Dojo Toolkit,它与 Closure Compiler 的高级模式编译兼容(经过少量修改)。
http://dojo-toolkit.33424 .n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.
Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.
JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.
If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
您可以采用开源商业模式,并使用 GPL 或 Creative Commons BY-NC-ND 或类似协议来许可您的脚本
You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar
虽然混淆通常是一件坏事,但恕我直言,对于 Javascript,情况有点不同。这个想法不是为了混淆 Javascript 本身,而是为了生成更短的代码长度(带宽很昂贵,而且首次使用的用户可能会因为等待 Javascript 第一次加载而感到恼火)。最初称为缩小(使用诸如 minify 之类的程序),它已经发展了很多,现在可以使用完整的编译器,例如 YUI 编译器和 Google Closure 编译器。这样的编译器执行静态检查(这是一件好事,但前提是您遵循编译器的规则)、缩小(例如用“ab”替换长变量名)和许多其他优化技术。最后,您得到的是两全其美的结果,即使用非编译代码进行编码,并部署编译的(缩小的和模糊的)代码。不幸的是,您当然还需要更广泛地测试它。
While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.
不管事实是否是混淆器,任何称职的程序员都可以在大约花费您所花费的时间内重现您所做的任何事情。如果他们偷了你所做的事情,你可以起诉他们。因此,从业务角度来看,底线是,从发布那一刻起,您在竞争对手赶上之前实施设计所花费的时间大致相同。时期。这就是您获得的全部领先优势。剩下的就是你比竞争对手更快地创新,并且至少和他们一样营销。
The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.
使用 Flash 编写您的网站,或者更好的是使用 Silverlight。这将为您的公司提供无与伦比的 GUI,让您的竞争对手垂涎欲滴。但是 flash/dotnet 的编译性质不允许它们轻松地进入您的代码。这对你来说是双赢的局面;)
Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)