Question

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

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

它出现了：

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

由于它是SSI命令，我需要我不将>转换为\x3e。我尝试使用--charset=utf-8和US-ascii作为Closure Compiler的输入。我也尝试在字符串中使用\u003e。无论我做什么，它都会将>输出为\x3e，这看起来很奇怪，因为它对＆lt;。

不一样。

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

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

Answer 1

即使有一个编译器选项可以避免这种情况发生，我的观点是这不是一个好习惯，因为你依赖于编译器输出一些东西（例如你的SSI字符串）可以有多精确许多不同的表示（如您所见，原始字符串已更改）。

编译器执行此操作以避免将结束HTML注释的字符串-->，以防它嵌入HTML代码中。过去常见的做法是在HTML注释中包装JavaScript，以避免在不支持JavaScript的浏览器中出现错误。

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

这可以通过将SSI字符串包含在另一个未编译的 JS文件中，或者通过在已编译的 JS中添加未编译的 SSI字符串来完成输出。像这样：

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']);

希望有所帮助。