Keeping string values private is a different concern, and obfuscation won't really be of much benefit. Of course, by packaging up your source into a garbled, minified mess, you have a light version of security through obscurity. Most of the time, it's your user who is viewing the source, and the string values on the client are intended for their use, so that sort of private string value isn't often necessary.
If you really had a value that you never wanted a user to see, you would have a couple of options. First, you could do some kind of encryption, which is decrypted at page load. That would probably be one of the most secure options, but also a lot of work which may be unnecessary. You could probably base64 encode some string values, and that would be easier.. but someone who really wanted those string values could easily decode them. Encryption is the only way to truly prevent anyone from accessing your data, and most people find that to be more security than they need.
Sidenote:
Obfuscation in Javascript has been known to cause some bugs. The obfuscators are getting a little better about it, but many outfits decide that they see enough benefit from minifying and gzipping, and the added savings of obfuscation isn't always worth the trouble. If you're trying to protect your source, maybe you'll decide that it's worth your while, just to make your code harder to read. JSMin is a good alternative.
I'm surprised no one has mentioned Google's Closure Compiler. It doesn't just minify/compress, it analyzes to find and remove unused code, and rewrites for maximum minification. It can also do type checking and will warn about syntax errors.
JQuery recently switched from YUI Compresser to Closure Compiler, and saw a "solid improvement"
Obfuscation can never really work. For anyone who really wants to get at your code, it's just a speed bump. Worse, it keeps your users from fixing bugs (and shipping the fixes back to you), and makes it harder for you to diagnose problems in the field. Its a waste of your time and money.
Talk to a lawyer about intellectual property law and what your legal options are. "Open Source" does not mean "people can read the source". Instead, Open Source is a particular licensing model granting permission to freely use and modify your code. If you don't grant such a license then people copying your code are in violation and (in most of the world) you have legal options to stop them.
The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.
You can obfuscate the javascript source all you want, but it will always be reverse-engineerable just by virtue of requiring all the source code to actually run on the client machine... the best option I can think of is having all your processing done with server-side code, and all the client code javascript does is send requests for processing to the server itself. Otherwise, anyone will always be able to keep track of all operations that the code is doing.
Someone mentioned base64 to keep strings safe. This is a terrible idea. Base64 is immediately recognizable by the types of people who would want to reverse engineer your code. The first thing they'll do is unencode it and see what it is.
There are a number of JavaScript obfuscation tools that are freely available; however, I think it's important to note that it is difficult to obfuscate JavaScript to the point where it cannot be reverse-engineered.
To that end, there are several options that I've used to some degree overtime:
YUI Compressor. Yahoo!'s JavaScript compressor does a good job of condensing the code that will improve its load time. There is a small level of obfuscation that works relatively well. Essentially, Compressor will change function names, remove white space, and modify local variables. This is what I use most often. This is an open-source Java-based tool.
JSMin is a tool written by Douglas Crockford that seeks to minify your JavaScript source. In Crockford's own words, "JSMin does not obfuscate, but it does uglify." It's primary goal is to minify the size of your source for faster loading in browsers.
Free JavaScript Obfuscator. This is a web-based tool that attempts to obfuscate your code by actually encoding it. I think that the trade-offs of its form of encoding (or obfuscation) could come at the cost of filesize; however, that's a matter of personal preference.
var ajax=function(a,b,d,c,e,f){
e=new FormData();
for(f in d){e.append(f,d[f]);};
c=new XMLHttpRequest();
c.open('POST',a);
c.setRequestHeader("Troll1","lol");
c.onload=b;
c.send(e);
};
window.onload=function(){
ajax('Troll.php',function(){
(new Function(atob(this.response)))()
},{'Troll2':'lol'});
}
B.稍微混淆代码
那是什么？
这与上面的 base64 代码相同，
这不是秘密的 javascript 代码
(new Function(atob('dmFyIGFqYXg9ZnVuY3Rpb24oYSxiLGQsYyxlLGYpe2U9bmV3IEZvcm1EYXRhKCk7Zm9yKGYgaW4gZCl7ZS5hcHBlbmQoZixkW2ZdKTt9O2M9bmV3IFhNTEh0dHBSZXF1ZXN0KCk7Yy5vcGVuKCdQT1NUJyxhKTtjLnNldFJlcXVlc3RIZWFkZXIoIlRyb2xsMSIsImxvbCIpO2Mub25sb2FkPWI7Yy5zZW5kKGUpO307d2luZG93Lm9ubG9hZD1mdW5jdGlvbigpe2FqYXgoJ1Ryb2xsLnBocCcsZnVuY3Rpb24oKXsgKG5ldyBGdW5jdGlvbihhdG9iKHRoaXMucmVzcG9uc2UpKSkoKX0seydUcm9sbDInOidsb2wnfSk7fQ==')))()
C 创建一个难以显示的 php 文件，其中包含真实代码
这个 php 代码是什么？
检查正确的引荐来源网址（启动器的域/目录/代码）
检查自定义标头
检查自定义 POST 变量
如果一切正常，它将向您显示正确的代码，否则是假代码或禁止 ip，关闭页面.. 无论如何。
<?php
$t1=apache_request_headers();
if(base64_encode($_SERVER['HTTP_REFERER'])=='aHR0cDovL2hlcmUuaXMvbXkvbGF1bmNoZXIuaHRtbA=='&&$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){
echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';//here is the SECRET javascript code
}else{
echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';
};
?>
<?php $t1=apache_request_headers();if(/*base64_encode($_SERVER['HTTP_REFERER'])=='PUT THE LAUNCHER REFERER HERE'&&*/$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';}else{echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';}; ?>
What i would do:
A. Troll the hacker!
This is will be in the second part my fake/obfuscated secret javascript code LAUNCHER. The one you see in the source code.
What does this code?
loads the real code
sets a custom header
posts a custom variable
var ajax=function(a,b,d,c,e,f){
e=new FormData();
for(f in d){e.append(f,d[f]);};
c=new XMLHttpRequest();
c.open('POST',a);
c.setRequestHeader("Troll1","lol");
c.onload=b;
c.send(e);
};
window.onload=function(){
ajax('Troll.php',function(){
(new Function(atob(this.response)))()
},{'Troll2':'lol'});
}
B. Obfuscate the code a little
What is that?
thats the same code as above in base64
this is not the SECRET javascript code
(new Function(atob('dmFyIGFqYXg9ZnVuY3Rpb24oYSxiLGQsYyxlLGYpe2U9bmV3IEZvcm1EYXRhKCk7Zm9yKGYgaW4gZCl7ZS5hcHBlbmQoZixkW2ZdKTt9O2M9bmV3IFhNTEh0dHBSZXF1ZXN0KCk7Yy5vcGVuKCdQT1NUJyxhKTtjLnNldFJlcXVlc3RIZWFkZXIoIlRyb2xsMSIsImxvbCIpO2Mub25sb2FkPWI7Yy5zZW5kKGUpO307d2luZG93Lm9ubG9hZD1mdW5jdGlvbigpe2FqYXgoJ1Ryb2xsLnBocCcsZnVuY3Rpb24oKXsgKG5ldyBGdW5jdGlvbihhdG9iKHRoaXMucmVzcG9uc2UpKSkoKX0seydUcm9sbDInOidsb2wnfSk7fQ==')))()
C Create a hard to display php file with the real code inside
What does this php code?
Checks for the right referrer (domain/dir/code of your launcher)
Checks for the custom HEADER
Checks for the custom POST variable
If everything is ok it will show you the right code else a fake code or ban ip, close page.. whatever.
<?php
$t1=apache_request_headers();
if(base64_encode($_SERVER['HTTP_REFERER'])=='aHR0cDovL2hlcmUuaXMvbXkvbGF1bmNoZXIuaHRtbA=='&&$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){
echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';//here is the SECRET javascript code
}else{
echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';
};
?>
Now .. if you define event handlers in the SECRET javascript it's probably accessible.. you need to define them outside with the launchcode and pointing to a nested SECRET function.
SO... is there a easy wayto get the code? document.body.appendChild(document.createElement('div')).innerText='Awesome';
I'm not sure if this works but i'm using chrome and checked Elements,Resources,Network,Sources,Timeline,Profiles,Audits but i didn't find the line above.
note1: if u open the Troll.php url from Inspect element->network in chrome you get the fake code.
note2: the whole code is written for modern browsers. polyfill needs alot more code.
The problem with interpreted languages, is that you send the source to get them working (unless you have a compiler to bytecode, but then again, it is quite trivial to decompile).
So, if you don't want to sacrifice performance, you can only act on variable and function names, eg. replacing them with a, b... aa, ab... or a101, a102, etc. And, of course, remove as much space/newlines as you can (that's what so called JS compressors do). Obfuscating strings will have a performance hit, if you have to encrypt them and decrypt them in real time. Plus a JS debugger can show the final values...
Try JScrambler. I gave it a spin recently and was impressed by it. It provides a set of templates for obfuscation with predefined settings for those who don't care much about the details and just want to get it done quickly. You can also create custom obfuscation by choosing whatever transformations/techniques you want.
I can recommend JavaScript Utility by Patrick J. O'Neil. It can obfuscate/compact and compress and it seems to be pretty good at these. That said, I never tried integrating it in a build script of any kind.
As for obfuscating vs. minifying - I am not a big fan of the former. It makes debugging impossible (Error at line 1... "wait, there is only one line") and they always take time to unpack. But if you need to... well.
A non-open-source Javascript-based application is fairly silly. Javascript is a client-side interpreted language.. Obfuscation isn't much protection..
JS obfuscation is usually done to reduce the size of the script, rather than "protect" it. If you are in a situation where you don't want your code to be public, Javascript isn't the right language..
There are plenty of tools around, but most have the word "compressor" (or "minifier") in its name for a reason..
You can't secure client side code: just press F12 on Google Chrome, pause javascript execution and you will get all strings, even those encrypted. Beautify it and rename variables and you will get almost the original code.
If you're writing server side javascript (i.e. NodeJS) is afraid of someone hacking into your server and want to make the hacker work more difficult, giving you more time to get your access back, then use javacript compilers:
You need to use Closure Compiler on Advanced Compilation, as it's the only tool that renames all your variables, even if those are used in multiple files/modules. But it just have a problem: it only work if you write in it's coding style.
I would suggest first minify with something like YUI Compressor, and then convert all string and numbers to HEX Values using something like http://www.javascriptobfuscator.com/
With this, the code would be rendered near impossible to understand and I think at this Stage it will take more time for a Hacker to re-enact your code than actually if he re-wrote from scratch. Rewriting and Cloning is what you cant actually stop. After all we are free-people !
I used it on my HTML5 game not only it reduced it size from 950KB to 150 but also made the source code unreadable closure compilers and minifiers are reversable I personally dont know how to reverse this obfuscation.
I'm under the impression that some enterprises (e.g.: JackBe) put encrypted JavaScript code inside *.gif files, rather than JS files, as an additional measure of obfuscation.
I've been using Jasob for years and it is hands down the best obfuscator out there. It has an advanced UI but is still intuitive and easy to use. It will also handle HTML and CSS files.
The best way to use it is to prefix all of your private variables with something like an underscore, then use the sort feature to group them all together and check them off as targets for obfuscation.
Users can still view your source, but it's much more difficult to decipher when your private variables are converted from something like _sUserPreferredNickName to a.
The engine will automatically tally up the number of targeted variables and prioritize them to get the maximum compression.
I don't work for Jasob and I get nothing out of promoting them, just offering some friendly advice. The downside is that it's not free and is a little pricey, but still worth it when stacked against alternatives - the 'free' options don't even come close.
I am using Closure-Compiler utility for the java-script obfuscation. It minifies the code and has more options for obfuscation. This utility is available at Google code at below URL: Closure Tools
发布评论
评论（22）
您绝对应该考虑看看 Obfuscriptor。
我超越了我们从其他工具（例如 YUI Compressor 或Google 关闭。
混淆后的代码看起来更像是加密的。 与我以前见过的任何东西都不一样。
You definitely should consider taking a look at Obfuscriptor.
I goes beyond the typical Javascript minifying tricks we've seen from other tools such as YUI Compressor or Google Closure.
The obfuscated code looks more like encrypted. Unlike anything I've seen before.
我过去用过这个，效果很好。 它不是免费的，但你绝对应该看看。
JavaScript 混淆器 编码器
I've used this in the past, and it does a good job. It's not free, but you should definitely take a look.
JavaScript Obfuscator & Encoder
混淆：
尝试YUI 压缩机。 这是一个非常流行的工具，由 Yahoo UI 团队构建、增强和维护。您还可以使用：
UglifyJS
更新：这个问题最初是在 2008 年提出的，并且提到的技术已被弃用。 您可以使用：私有字符串数据：
保持字符串值私有是一个不同的问题，并且混淆不会真正有太大好处。 当然，通过将源代码打包成乱码、缩小的混乱，您可以通过模糊性获得安全性的轻型版本。 大多数时候，您的用户正在查看源代码，并且客户端上的字符串值是供他们使用的，因此通常不需要这种私有字符串值。
如果你确实有一个你不想让用户看到的值，你会有几个选择。 首先，您可以进行某种加密，该加密在页面加载时解密。 这可能是最安全的选择之一，但也可能需要做很多不必要的工作。 您可能可以对一些字符串值进行 base64 编码，这会更容易。但是真正想要这些字符串值的人可以轻松解码它们。 加密是真正防止任何人访问您的数据的唯一方法，大多数人发现这比他们需要的更安全。
旁注：
Javascript 中的混淆已知会导致一些错误。 混淆器在这方面做得更好了，但许多机构认为他们从缩小和gzipping中看到了足够的好处，并且混淆所节省的额外费用并没有增加。总是值得麻烦的。 如果您想保护您的源代码，也许您会认为这是值得的，只是为了让您的代码更难阅读。 JSMin 是一个不错的选择。
Obfuscation:
Try YUI Compressor. It's a very popular tool, built, enhanced and maintained by the Yahoo UI team.You may also use:
UglifyJS
UPDATE: This question was originally asked on 2008, and The mentioned technologies are deprecated. you can use:Private String Data:
Keeping string values private is a different concern, and obfuscation won't really be of much benefit. Of course, by packaging up your source into a garbled, minified mess, you have a light version of security through obscurity. Most of the time, it's your user who is viewing the source, and the string values on the client are intended for their use, so that sort of private string value isn't often necessary.
If you really had a value that you never wanted a user to see, you would have a couple of options. First, you could do some kind of encryption, which is decrypted at page load. That would probably be one of the most secure options, but also a lot of work which may be unnecessary. You could probably base64 encode some string values, and that would be easier.. but someone who really wanted those string values could easily decode them. Encryption is the only way to truly prevent anyone from accessing your data, and most people find that to be more security than they need.
Sidenote:
Obfuscation in Javascript has been known to cause some bugs. The obfuscators are getting a little better about it, but many outfits decide that they see enough benefit from minifying and gzipping, and the added savings of obfuscation isn't always worth the trouble. If you're trying to protect your source, maybe you'll decide that it's worth your while, just to make your code harder to read. JSMin is a good alternative.
我很惊讶没有人提到 Google 的Closure 编译器。 它不仅仅是缩小/压缩，它还进行分析以查找和删除未使用的代码，并重写以实现最大程度的缩小。 它还可以进行类型检查并警告语法错误。
JQuery 最近从 YUI 压缩机切换到 Closure 编译器，并看到了“扎实的改进”
I'm surprised no one has mentioned Google's Closure Compiler. It doesn't just minify/compress, it analyzes to find and remove unused code, and rewrites for maximum minification. It can also do type checking and will warn about syntax errors.
JQuery recently switched from YUI Compresser to Closure Compiler, and saw a "solid improvement"
混淆永远不会真正起作用。 对于任何真正想要获取您的代码的人来说，这只是一个减速带。 更糟糕的是，它使您的用户无法修复错误（并将修复程序发回给您），并且使您更难诊断现场问题。 这是浪费你的时间和金钱。
与律师讨论知识产权法以及您的法律选择。 “开源”并不意味着“人们可以阅读源代码”。 相反，开源是一种特殊的许可模式，授予自由使用和修改代码的权限。 如果您不授予这样的许可，那么复制您的代码的人就是违法的，并且（在世界上大多数地方）您有合法的选择来阻止他们。
真正保护代码的唯一方法就是不发布它。 将重要的代码移至服务器端，并让您的公共 Javascript 代码对其进行 Ajax 调用。
在此处查看我有关混淆器的完整答案。
Obfuscation can never really work. For anyone who really wants to get at your code, it's just a speed bump. Worse, it keeps your users from fixing bugs (and shipping the fixes back to you), and makes it harder for you to diagnose problems in the field. Its a waste of your time and money.
Talk to a lawyer about intellectual property law and what your legal options are. "Open Source" does not mean "people can read the source". Instead, Open Source is a particular licensing model granting permission to freely use and modify your code. If you don't grant such a license then people copying your code are in violation and (in most of the world) you have legal options to stop them.
The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.
See my full answer about obfuscators here.
你可以根据自己的需要混淆 javascript 源代码，但它总是可以进行逆向工程的，因为需要所有源代码在客户端计算机上实际运行......我能想到的最佳选择是完成所有处理使用服务器端代码，而 javascript 所做的所有客户端代码都是向服务器本身发送处理请求。 否则，任何人都将始终能够跟踪代码正在执行的所有操作。
有人提到使用 base64 来保证字符串安全。 这是一个糟糕的主意。 想要对您的代码进行逆向工程的人可以立即识别 Base64。 他们要做的第一件事就是对其进行解密并查看它是什么。
You can obfuscate the javascript source all you want, but it will always be reverse-engineerable just by virtue of requiring all the source code to actually run on the client machine... the best option I can think of is having all your processing done with server-side code, and all the client code javascript does is send requests for processing to the server itself. Otherwise, anyone will always be able to keep track of all operations that the code is doing.
Someone mentioned base64 to keep strings safe. This is a terrible idea. Base64 is immediately recognizable by the types of people who would want to reverse engineer your code. The first thing they'll do is unencode it and see what it is.
有许多免费的 JavaScript 混淆工具； 然而，我认为值得注意的是，很难将 JavaScript 混淆到无法进行逆向工程的程度。
为此，我在某种程度上使用了几个选项：
YUI 压缩机< /a>. Yahoo! 的 JavaScript 压缩器在压缩代码方面做得很好，这将改善其加载时间。 有一定程度的混淆效果相对较好。 本质上，Compressor 将更改函数名称、删除空格并修改局部变量。 这是我最常使用的。 这是一个基于 Java 的开源工具。
JSMin 是 Douglas Crockford 编写的一个工具，旨在缩小您的 JavaScript 源代码。 用 Crockford 自己的话来说，“JSMin 不会混淆，但它确实丑化了。” 它的主要目标是缩小源代码的大小，以便在浏览器中更快地加载。
免费 JavaScript 混淆器。 这是一个基于网络的工具，试图通过实际编码来混淆您的代码。 我认为其编码（或混淆）形式的权衡可能会以文件大小为代价； 不过，这是个人喜好问题。
There are a number of JavaScript obfuscation tools that are freely available; however, I think it's important to note that it is difficult to obfuscate JavaScript to the point where it cannot be reverse-engineered.
To that end, there are several options that I've used to some degree overtime:
YUI Compressor. Yahoo!'s JavaScript compressor does a good job of condensing the code that will improve its load time. There is a small level of obfuscation that works relatively well. Essentially, Compressor will change function names, remove white space, and modify local variables. This is what I use most often. This is an open-source Java-based tool.
JSMin is a tool written by Douglas Crockford that seeks to minify your JavaScript source. In Crockford's own words, "JSMin does not obfuscate, but it does uglify." It's primary goal is to minify the size of your source for faster loading in browsers.
Free JavaScript Obfuscator. This is a web-based tool that attempts to obfuscate your code by actually encoding it. I think that the trade-offs of its form of encoding (or obfuscation) could come at the cost of filesize; however, that's a matter of personal preference.
我会做什么：
A. 攻击黑客！
这将是我的假/混淆的秘密 javascript 代码 LAUNCHER 的第二部分。
您在源代码中看到的那个。
这段代码是做什么的？
B.稍微混淆代码
那是什么？
C 创建一个难以显示的 php 文件，其中包含真实代码
这个 php 代码是什么？
如果一切正常，它将向您显示正确的代码，否则是假代码或禁止 ip，关闭页面.. 无论如何。
base64 Referrer =
http://here.is/my/launcher.html秘密 javascript =
document.body.appendChild(document.createElement('div')).innerText='Awesome' ;FAKE =
window.open('', '_self', '');window.close();现在..如果您在 SECRET javascript 中定义事件处理程序，则可能可以访问它..您需要使用启动代码在外部定义它们并指向嵌套的 SECRET 函数。
那么...有没有简单的方法来获取代码？
document.body.appendChild(document.createElement('div')).innerText='Awesome';我不确定这是否有效，但我正在使用 chrome 并检查了 Elements，资源、网络、来源、时间线、配置文件、审核，但我没有找到上面的行。
注意1：如果你在 Chrome 中从 Inspect element->network 打开 Troll.php url，你会得到假代码。
注意2：整个代码是为现代浏览器编写的。 polyfill 需要更多代码。
编辑
launcher.html
Troll.php
What i would do:
A. Troll the hacker!
This is will be in the second part my fake/obfuscated secret javascript code LAUNCHER.
The one you see in the source code.
What does this code?
B. Obfuscate the code a little
What is that?
C Create a hard to display php file with the real code inside
What does this php code?
If everything is ok it will show you the right code else a fake code or ban ip, close page.. whatever.
base64 referrer =
http://here.is/my/launcher.htmlSECRET javascript =
document.body.appendChild(document.createElement('div')).innerText='Awesome';FAKE =
window.open('', '_self', '');window.close();Now .. if you define event handlers in the SECRET javascript it's probably accessible.. you need to define them outside with the launchcode and pointing to a nested SECRET function.
SO... is there a easy wayto get the code?
document.body.appendChild(document.createElement('div')).innerText='Awesome';I'm not sure if this works but i'm using chrome and checked Elements,Resources,Network,Sources,Timeline,Profiles,Audits but i didn't find the line above.
note1: if u open the Troll.php url from Inspect element->network in chrome you get the fake code.
note2: the whole code is written for modern browsers. polyfill needs alot more code.
EDIT
launcher.html
Troll.php
解释型语言的问题在于，您发送源代码以使其正常工作（除非您有字节码编译器，但话又说回来，反编译非常简单）。
因此，如果您不想牺牲性能，则只能对变量和函数名称进行操作，例如。 用 a、b... aa、ab... 或 a101、a102 等替换它们。当然，删除尽可能多的空格/换行符（这就是所谓的 JS 压缩器所做的）。
如果您必须实时加密和解密字符串，那么混淆字符串将会影响性能。 另外，JS 调试器可以显示最终值......
The problem with interpreted languages, is that you send the source to get them working (unless you have a compiler to bytecode, but then again, it is quite trivial to decompile).
So, if you don't want to sacrifice performance, you can only act on variable and function names, eg. replacing them with a, b... aa, ab... or a101, a102, etc. And, of course, remove as much space/newlines as you can (that's what so called JS compressors do).
Obfuscating strings will have a performance hit, if you have to encrypt them and decrypt them in real time. Plus a JS debugger can show the final values...
尝试 JScrambler。 我最近试了一下，印象深刻。
它为那些不太关心细节而只想快速完成任务的人提供了一组带有预定义设置的混淆模板。 您还可以通过选择您想要的任何转换/技术来创建自定义混淆。
Try JScrambler. I gave it a spin recently and was impressed by it.
It provides a set of templates for obfuscation with predefined settings for those who don't care much about the details and just want to get it done quickly. You can also create custom obfuscation by choosing whatever transformations/techniques you want.
与我建议反对 YUI Compressor 的大多数其他答案相反； 您应该使用 Google Closure。
不是很多，因为它压缩得更多，但主要是因为它会捕获 JavaScript 错误，例如
a = [1,2,3,];，这些错误会使 IE 变得混乱。Contrary to most of the other answers I suggest against YUI Compressor; you should use Google Closure.
Not much because it compresses more, but mostly because it will catch javascript errors such as
a = [1,2,3,];which make IE go haywire.我可以推荐 Patrick J. O'Neil 的 JavaScript Utility。 它可以混淆/压缩和压缩，并且似乎在这些方面非常擅长。 也就是说，我从未尝试将其集成到任何类型的构建脚本中。
至于混淆与缩小——我不太喜欢前者。 它使得调试变得不可能（第 1 行出现错误...“等等，只有一行”）并且它们总是需要时间来解压。 但如果你需要……好吧。
I can recommend JavaScript Utility by Patrick J. O'Neil. It can obfuscate/compact and compress and it seems to be pretty good at these. That said, I never tried integrating it in a build script of any kind.
As for obfuscating vs. minifying - I am not a big fan of the former. It makes debugging impossible (Error at line 1... "wait, there is only one line") and they always take time to unpack. But if you need to... well.
基于 Javascript 的非开源应用程序相当愚蠢。 Javascript 是一种客户端解释语言。混淆并没有太多保护。JS
混淆通常是为了减少脚本的大小，而不是“保护”它。 如果您不希望自己的代码公开，那么 Javascript 不是正确的语言。
周围有很多工具，但大多数工具中都包含“压缩器”（或“压缩器”）一词名字是有原因的..
A non-open-source Javascript-based application is fairly silly. Javascript is a client-side interpreted language.. Obfuscation isn't much protection..
JS obfuscation is usually done to reduce the size of the script, rather than "protect" it. If you are in a situation where you don't want your code to be public, Javascript isn't the right language..
There are plenty of tools around, but most have the word "compressor" (or "minifier") in its name for a reason..
您无法保护客户端代码：只需在 Google Chrome 上按 F12，暂停 JavaScript 执行，您就会获得所有字符串，甚至是加密的字符串。 美化它并重命名变量然后你将得到几乎原始的代码。
如果您正在编写服务器端 javascript（即 NodeJS），担心有人侵入您的服务器，并希望让黑客更加困难，让您有更多时间恢复访问权限，那么请使用 javacript 编译器>：
您需要在高级编译中使用闭包编译器，因为它是重命名所有变量的唯一工具，即使这些变量在多个文件/模块中使用。 但它有一个问题：只有当您按照编码风格编写时，它才有效。
You can't secure client side code: just press F12 on Google Chrome, pause javascript execution and you will get all strings, even those encrypted. Beautify it and rename variables and you will get almost the original code.
If you're writing server side javascript (i.e. NodeJS) is afraid of someone hacking into your server and want to make the hacker work more difficult, giving you more time to get your access back, then use javacript compilers:
You need to use Closure Compiler on Advanced Compilation, as it's the only tool that renames all your variables, even if those are used in multiple files/modules. But it just have a problem: it only work if you write in it's coding style.
我建议首先使用 YUI Compressor 之类的工具进行缩小，然后使用 http:// 之类的工具将所有字符串和数字转换为十六进制值www.javascriptobfuscator.com/
有了这个，代码将变得几乎无法理解，我认为在这个阶段，黑客重新制定你的代码将花费比实际重写的时间更多的时间划痕。 重写和克隆是你无法真正阻止的。 毕竟我们是自由人！
I would suggest first minify with something like YUI Compressor, and then convert all string and numbers to HEX Values using something like http://www.javascriptobfuscator.com/
With this, the code would be rendered near impossible to understand and I think at this Stage it will take more time for a Hacker to re-enact your code than actually if he re-wrote from scratch. Rewriting and Cloning is what you cant actually stop. After all we are free-people !
试试这个工具 Javascript Obfuscator
我在我的 HTML5 游戏中使用了它，不仅将其大小从 950KB 减小到了 150KB，而且还使源代码不可读 闭包编译器和压缩器是可逆的 我个人不知道如何扭转这种混淆。
Try this tool Javascript Obfuscator
I used it on my HTML5 game not only it reduced it size from 950KB to 150 but also made the source code unreadable closure compilers and minifiers are reversable I personally dont know how to reverse this obfuscation.
Dean Edward's Packer 是一个出色的混淆器，尽管它主要混淆代码，而不是代码中可能包含的任何字符串元素。
请参阅：在线 Javascript 压缩工具，然后从下拉列表中选择 Packer (Dean Edwards)
Dean Edward's Packer is an excellent obfuscator, though it primarily obfuscates the code, not any string elements you may have within your code.
See: Online Javascript Compression Tool and select Packer (Dean Edwards) from the dropdown
我的印象是，一些企业（例如：JackBe）将加密的 JavaScript 代码放入 *.gif 文件中，而不是 JS 文件中，作为一种额外的混淆措施。
I'm under the impression that some enterprises (e.g.: JackBe) put encrypted JavaScript code inside *.gif files, rather than JS files, as an additional measure of obfuscation.
我已经使用 Jasob 多年了，它无疑是最好的混淆器。
它具有先进的用户界面，但仍然直观且易于使用。
它还将处理 HTML 和 CSS 文件。
使用它的最佳方法是在所有私有变量前添加下划线之类的前缀，然后使用
sort功能将它们全部分组在一起并检查< /em> 将它们作为混淆的目标。用户仍然可以查看您的源代码，但当您的私有变量从
_sUserPreferredNickName转换为a时，破译会变得更加困难。引擎将自动统计目标变量的数量并优先考虑它们以获得最大压缩。
我不为贾索布工作，我从推销他们中得不到任何好处，只是提供一些友好的建议。
缺点是它不是免费的，而且有点贵，但与其他选择相比仍然值得——“免费”选项甚至无法接近。
I've been using Jasob for years and it is hands down the best obfuscator out there.
It has an advanced UI but is still intuitive and easy to use.
It will also handle HTML and CSS files.
The best way to use it is to prefix all of your private variables with something like an underscore, then use the
sortfeature to group them all together and check them off as targets for obfuscation.Users can still view your source, but it's much more difficult to decipher when your private variables are converted from something like
_sUserPreferredNickNametoa.The engine will automatically tally up the number of targeted variables and prioritize them to get the maximum compression.
I don't work for Jasob and I get nothing out of promoting them, just offering some friendly advice.
The downside is that it's not free and is a little pricey, but still worth it when stacked against alternatives - the 'free' options don't even come close.
您尝试过 Bananascript 吗？ 它产生高度压缩且完全不可读的代码。
Have you tried Bananascript? It produces highly compressed and completely unreadable code.
我正在使用 Closure-Compiler 实用程序进行 java 脚本混淆。 它缩小了代码并具有更多混淆选项。
此实用程序可通过以下 URL 的 Google 代码获取：
闭包工具
但现在我经常听到 UglifyJS。 您可以找到 Closure Compiler 和 UglifyJS 之间的各种比较，其中 Uglify 似乎是赢家。
UglifyJS：用于 Node 的快速新 JavaScript 压缩器.js 与闭包相当
很快我就会给 UglifyJS 机会。
I am using Closure-Compiler utility for the java-script obfuscation. It minifies the code and has more options for obfuscation.
This utility is available at Google code at below URL:
Closure Tools
But now a days I am hearing much of UglifyJS. You can find various comparison between Closure Compiler and UglifyJS in which Uglify seems to be a winner.
UglifyJS: A Fast New JavaScript Compressor For Node.js That’s On Par With Closure
Soon I would give chance to UglifyJS.
作为 JavaScript/HTML/CSS 混淆器/压缩器，您还可以尝试 Patu Digua。
As a JavaScript/HTML/CSS obfuscator/compressor you can also try Patu Digua.