我需要编写一个与GUI相关的JavaScript库。它会给我的网站带来一些优势（就我能提供的功能而言） - 直到我的竞争对手玩它足够长的时间来弄清楚如何自己编写（或者最终破解下载的脚本）。我可以接受这样一个事实：它会随着时间的推移而被模仿 - 这对于课程（它的业务部分）而言是相同的。我只想在几个月的时间里呼吸人们去的地方“哇 - 他们这样做了怎么样？” - 这给了我几个月的免费宣传和一些动力去转移其他事情。
要明确的是，我甚至不关心那些仍然会破解消息来源的核心黑客 - 这就是一场不值得战斗的失败战斗（无论如何我接受我的代码并非“如此珍贵”）。然而，我无法忍受的是，通过使用任何人都可以下载和使用的普通JavaScript，有效地简单地将所有已经进入图书馆的艰苦工作交给竞争对手。如果有人打算使用我的工作，那么我肯定不想简单地把它交给他们 - 我希望他们努力解码它。如果他们可以解码它，他们应该得到代码（他们最有可能发现他们自己可以编写更好的代码 - 他们只是没有商业意义将所有[普通的香草]组件放入特定订单） - 所以，我并没有声称没有人可以写这个（这在任何情况下都是荒谬的说法） - 而是，我所说的是没有人（到目前为止）已经提出了我正在讨论的功能，可供这个特定行业使用 - 而且我（认为是企业家而不是极客/编码员 ），想要为它的所有价值而榨取它，而它持续下去，直到它（不可避免地）被黑客攻击。
事实证明，我正在“攻击”的行业中没有一个网站具有此功能，因此这种图书馆的价值是不可否认的，不值得讨论（也就是说这不是我在这里要求的）
我想要找到的是混淆javascript库的优点和缺点，以便我可以做出最终决定。
我最关心的两个问题是调试，以及混淆器可能引入的细微错误。
我想知道：
如何管理这些风险（能够调试错误的代码，确保/最大限度地减少混淆错误）
您是否可以推荐任何质量好的行业标准混淆器（最好是您自己使用的东西）。
您在生产环境中使用混淆代码的经验是什么？
答案 0 :(得分：33)
如果他们可以解码它们，他们应该得到代码（他们很可能会发现他们自己可以编写更好的代码 - 他们只是没有商业意义将所有[普通的香草]组件放入特定的订单）。
实际上，您正试图通过技术措施来解决业务问题。
任何值得他作为Javascript程序员的人应该能够通过查看产品本身来重新创建你很容易做的事情，而不需要代码。这并不像你正在发明一些前所未见的新魔法，你只是以一种新的方式将各个部分组合在一起，就像你承认自己一样。这只是Javascript。
即使您对脚本进行了模糊处理，它仍然会按原样运行，竞争对手可以随意使用它并运行它。即使使用混淆代码，一些自定义也不应该太难。
在您的利基业务中，如果有人“偷走”您的脚本，您可能会很快注意到。如果发生这种情况，这是一个法律问题。如果你的竞争对手想要合法清楚，那么无论如何他们都必须从头开始重写脚本，这会自动为你买一些时间。
如果您的竞争对手在技术上无法在不直接窃取代码的情况下复制您的产品，那么无论代码是清晰还是混淆，都不会产生任何影响。
答案 1 :(得分：15)
虽然你可以沿着混淆器的漫长而危险的道路走下去，但你通常不会在实际的生产应用程序中看到它们，原因很简单，因为它们并没有真正起作用。您会注意到，谷歌应用程序，实际上是一堆专有且非常有价值的JavaScript，只有真正最小化并且没有混淆，尽管最小化程序现在的工作方式，它们与混淆一样好。你真的需要知道你正在做什么来从中提取意义，但确定的意思将成功。
另一个问题是混淆代码必须工作，如果它有效，人们可以批量翻录它，而不是理解它的大部分内容，并按照他们认为合适的形式使用它。当然，他们不能直接修改它，但是在一些补丁上重新实现他们不喜欢的部分而不必太深入并不难。这只是JavaScript的本质。
谷歌之类没有遭遇大量剪切和粘贴竞争对手的原因是因为JavaScript只是该软件包的一部分。为了对这些东西的使用方式和位置进行任何程度的控制，大型组件需要基于服务器。好消息是你可以利用Node.js之类的东西来分割客户端和服务器代码，而不必用完全不同的语言重新实现部分。
您可能想要调查的内容并不是那么混淆，而是将您的应用程序拆分为可以从某种服务按需加载的部分，并且因为这些部分可能是高度相互依赖的，而且大部分都是非功能性的如果没有这个核心服务器，您可以更大程度地控制使用此库的时间和位置。
您可以在Google如何转移到元库中看到这些元素，元库只是作为其他库的加载器。这是统一Google Apps，Google AdSense，Google地图，Google Adwords等加载调用的一步。
如果你想变得有点聪明，你可以像谷歌地图一样添加毒药，因为它们是动态提供的，因此它们只能在特定的子域中运行。这需要根据需要生成它们，虽然它可以随时以足够的专业知识删除，但它可以防止JavaScript文件的批量复制粘贴使用。要插入一个验证document.href的聪明的调用并不难，并且在一个积极最小化的文件中找到所有这些实例会特别令人愤怒，并且可能不值得付出努力。
答案 2 :(得分：4)
Javascript混淆事实：
Javascript混淆小说:(我将跳过本节;））
回答Q2 - Sugested混淆工具：
回答第3季 - 使用混淆代码的经验
答案 3 :(得分：3)
混淆问题的标准答案：Is using an obfuscator enough to secure my JavaScript code?
IMO，这是浪费时间。如果竞争对手能够清楚地理解你的代码（假设这些代码超过几千行......），他们应该毫不费力地对其进行反混淆。我如何管理这些风险？ 能够调试错误的代码， 确保/最小化 混淆错误）
混淆会导致更多错误，您可以花时间调试它们来管理它们。这取决于编写混淆的人（无论是你还是其他人），最终只会浪费大量时间。
您使用的经验如何？ 生产中混淆的代码 环境？
答案 4 :(得分：1)
Google的Closure Complier在您编写完代码后会对代码进行模糊处理。也就是说，编写代码，通过编译器运行代码，并发布优化（和混淆）的js。
你做需要小心，如果你使用与lib接口的外部js，因为它改变你的对象的名字，所以你不知道是什么。
答案 5 :(得分：1)
目前，自动完整代码混淆仅在Closure Compiler的高级模式下可用。
使用Closure Advanced模式编译的代码几乎不可能进行逆向工程，甚至不能通过美化器，因为整个代码库（包括库）都是混淆的。它平均也小25％。
仅仅缩小的JavaScript代码（YUI Compressor，Uglify等）在通过美化器后很容易进行逆向工程。
如果您使用JavaScript库，请考虑使用Closure Compiler的高级模式编译兼容（经过微小修改）的Dojo Toolkit。
答案 6 :(得分：0)
您可以采用开源商业模式并使用GPL或知识共享BY-NC-ND或类似许可您的脚本
答案 7 :(得分：0)
虽然混淆一般是坏事，恕我直言，用Javascript，故事有点不同。我们的想法不是混淆Javascript本身，而是产生更短的代码长度（带宽很昂贵，并且首次使用的用户可能会因为第一次等待你的Javascript加载而生气）。最初称为缩小（使用minify之类的程序），它已经发展了很多，现在可以使用完整的编译器，例如YUI编译器和Google Closure Compiler。这样的编译器执行静态检查（这是一件好事，但只有当你遵循编译器的规则时），缩小（例如用'ab'替换那个长变量名），以及许多其他优化技术。最后，你得到的是两个世界中最好的，在非编译代码中编码，以及部署编译（缩小和混淆）代码。不幸的是，你当然也需要更广泛地测试它。
答案 8 :(得分：0)
真相是混淆与否，任何值得他盐的程序员都可以在你花费的时间内复制你所做的任何事情。如果他们偷了你所做的，你可以起诉他们。从业务角度来看，最重要的是，从您发布的那一刻起，您实施设计的时间大致相同，直到竞争对手赶上。期。这就是你获得的所有先机。其余的是你比竞争对手更快地进行创新，并且至少和他们一样营销。
答案 9 :(得分：-1)
在Flash中编写您的网站，或者更好地在Silverlight中编写。这将为您的公司提供无与伦比的GUI，让您的竞争对手垂涎三尺。但是flash / dotnet的编译性质不允许他们轻松选择你的代码。这对你来说是一个双赢的局面;）