闭包编译器正在修改字符串中的尾括号

Closure Compiler modifying end bracket in string

本文关键字：字符串 编译器 修改 闭包      更新时间：2023-09-26

我尝试通过闭包编译器运行以下Javascript代码：

var firstRun = eval("<?--#exec cmd_argument='command'-->");

结果是：

var a=eval(" <?--#exec cmd_argument='command'--'x3e")

由于它是SSI命令，我需要I不将>转换为'x3e。我已经尝试使用--charset=utf-8和US-ascii作为闭包编译器的输入。我还尝试在字符串中使用'u003e。无论我做什么，它都将>输出为'x3e，这似乎很奇怪，因为它对<没有做同样的操作；。

我使用的闭包编译器的输入命令是：

java -jar compiler.jar --js file.js --js_output_file newfile.js

即使有编译器选项可以避免这种情况的发生，我的观点是这不是一个好的做法，因为你依赖于编译器输出的东西（在这种情况下是你的SSI字符串）的精确性，这些东西可以有很多不同的表示形式（正如你可以看到的原始字符串被更改了）。

编译器这样做是为了避免字符串-->，如果HTML注释嵌入HTML代码中，它将结束HTML注释。在不支持JavaScript的浏览器中，将JavaScript封装在HTML注释中以避免出现错误曾经是一种常见的做法。

可能的解决方案：你能单独包含SSI字符串，这样它就不会经过编译过程吗？这样就可以保证它不会受到编译器的影响。

这可以通过将SSI字符串包含在另一个未编译JS文件中来实现，也可以通过在编译JS输出中预先设置已编译

var MY_GLOBAL_SSI_STRING = "<?--#exec cmd_argument='command'-->";
// compiled code follows...

然后，您可以从（待编译的）代码中引用MY_GLOBAL_SSI_STRING，如下所示：

var firstRun = eval(goog.global['MY_GLOBAL_SSI_STRING']);

希望能有所帮助。

相关文章：