在ECMA-262, 3rd edition[PDF]的第7.6节（“标识符”，第26页）下，我们看到以下注释：
美元符号仅用于机械生成的代码。
这似乎很合理。许多常用于生成或嵌入JavaScript的语言对$具有特殊含义，在这些语言中的JavaScript标识符中使用它会导致unexpected behavior。
“机械生成条款”出现在第2版中。在第1版中，它没有出现。从版本5开始，它在没有解释的情况下再次消失，并且仍然是第6版工作草案中的absent。
如果我不得不猜测，我会认为它最初被省略了，因为没有考虑潜在的陷阱，然后在下一版中加入时它会明显引起问题。不过，我想不出在第5版中再次删除它的好理由。
是否有任何解释包含并随后从规范中删除“机械生成的条款”（来自邮件列表，新闻组或其他地方的“文件记录”）？我无法在任何地方找到这些文件。
作为一个附带问题，任何人都可以在第6版草案中解释including zero-width characters背后的理由吗？这似乎会造成更多麻烦，因为你根本看不到这些字符，我想不出你想要这些字符在标识符中的任何理由。
更新：下面的代码交换答案中解释了最初包含“机械生成的代码”注释和包含零宽度字符的内容。唯一需要回答的是这个问题的主要焦点，即“机械生成代码”注释的删除。
答案 0 :(得分：4)
这是一个开始：Subject: SC22 N2745 - Disposition of Comments Report on DIS 16262 -ECMAScript
似乎＆＃34;只应用于机械生成的代码＆＃34;之所以添加，是因为这是JAVA的规范。
D6）7.5：根据TR 10176中的建议，DOLLAR SIGN不应该在标识符列表中.7.5应该参考＆＃34; i18n＆＃34; ISO / IEC 14652关于字母和数字定义的规范。
>>>>>>行动：部分接受--- ECMAScript遵循Java先例。注释将添加$仅应用于机械生成的代码。 ＆LT;＆LT;＆LT;＆LT;＆LT;
如果你想在过去的会议记录中跋涉，你可以看一下：
ecmascript wiki: Notes and Minutes from past meetings
关于以后的更改：
所有这些都来自邮件列表＆＃34; es5-discuss -- Discussion of ECMAScript 3.x＆＃34;。
ZWNJ and ZWJ in identifiers (was: Comments on April ES5 final draft standard tc39-2009-025)
John Cowan写道：
事实证明，Unicode 5.1完成了繁重的工作：坏消息 提升确实很重。您想要允许Cf字符 当且仅当它们实际上在语义上有区别 当代用途。原来，Unicode 5.1说，只允许 U + 200C和U + 200D然后仅在某些情况下：规则涉及 了解附近标识符的Script和Joining_Type属性 字符。细节在 http://unicode.org/reports/tr31/#Layout_and_Format_Control_Characters
David-Sarah Hopwood回答：
简单地添加U + 200C和U + 200D的缺点是什么 IdentifierPart没有任何其他上下文相关规则？
我认为这是输入方法和输入方法的综合责任 程序员确保使用
<ZWNJ>和<ZWJ>个字符 标识符中按预期;编程语言语法需要做的就是允许它们。请注意＆＃34;目标除去尽可能多的情况 可见的区别结果＆＃34; （据说出于安全原因）不是 非常适用，因为ECMAScript甚至不会强制执行 NFC 正常化。不强制执行NFC，但增加了相当大的复杂性 对于语法，正如UTR＃31所暗示的，为了防止一些 潜在的（但相对无害的，AFAICS）滥用
<ZWNJ>和。{<ZWJ>，对我来说似乎是一套不一致的设计选择。
这一起引发了一堆讨论：Last call for consensus on format-control char. issues
对此有15条回复，您可能想要阅读这些内容：
https://mail.mozilla.org/pipermail/es5-discuss/2009-June/thread.html#2832
Allen Wirfs-Brock写道：
来自5月F2F的Waldemar的笔记没有记录任何有关该决定的决定 标识符中<ZWNJ>和<ZWJ>的问题。但是，我的个人笔记 说我需要＆＃34;保留标识符并修复语法＆＃34;这也是 我记得我们在会议上决定的事情。最简单的决定是简单地添加
<ZWNJ>和<ZWJ>作为IdentifierPart的替代品。另外，文中 第7.1节说格式控制字符可以出现在 标识符可能需要缩小到只说<ZWNJ>和<ZWJ>。与F2F David-Sarah大致相同的时间 全面的提案（下面重复），除此之外 寻址
<ZWNJ>和<ZWJ>也明显改进了规则<BOM>包括将它们从字符串文字和常规文件中排除 表达式并使<BOM>出现在语法中时出现语法错误 标识符。我不是Unicode专家，但我的感觉是David-Sarah的提议 是健全的，可能与最初的清洁目标一致 规范中的Cf类。但是，他对
<BOM>的规则也是如此 看起来他们可能会使词法分析复杂化 实施阶段。我对F2F的感觉是，共识更多的是方向 上面我的简单解决方案（
<ZWNJ>和<ZWJ>在标识符中，<BOM>是 空白）而不是大卫 - 莎拉更全面的对待<BOM>。我需要对此做出最终决定，以便我可以更新草稿 因此。基于我对F2F的回忆，我将会去 使用＆＃34;简单的解决方案＆＃34;除非有明显的共识 否则。
最后的想法？
他回复的消息，根据引用的消息分成几个块：
-----原始信息----- 来自：es5-discuss-moounce at mozilla.org [mailto：es5-discuss- 在mozilla.org上反弹]代表David-Sarah Hopwood 发送时间：2009年5月28日星期四下午5:44 致：在mozilla.org上讨论es5 主题：IdentifierName的语法不允许
<ZWNJ>和<ZWJ>John Cowan写道：
David-Sarah Hopwood写道：
<IdentifierName>中遗漏格式控制字符 出现 只是一个疏忽。-1
休息
确实，我忘记了我们已经讨论过这个并且来了 一个不同的结论：
https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002432.html https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002435.html
休息
允许所有这些导致与允许相同的问题 BOM。他们中的大多数对周围的文本几乎没有明显的影响 （尤其是拉丁文脚本文本），即使是完全一致的Unicode 渲染器， 不要介意那些闷闷不乐的渲染器。结果是＆＃34; foobar＆＃34; 和 ＆＃34;富
<Cf>巴＆＃34;看起来一样但不是。根据Unicode 5.1，唯一真正影响自然的 - 语言 标识符的含义是U + 200C ZWNJ和U + 200D ZWJ。这些是 只要 甚至应该在ES5标识符中考虑的那些。 UAX＃31 （哪一个 通过引用包含在Unicode 5.1中）指定更窄的条件 其中ZWNJ和ZWJ是必不可少的;坚持条件是 非平凡，但最大限度地减少了欺骗的可能性。
考虑到风险，我不确定ZWNJ和ZWJ是否应该被允许 或不。
休息
忘记尝试将标识符欺骗最小化为安全风险。那＆＃39; S 如果要允许Unicode标识符，则不可能。它是一个 许多不同的Unicode的固有特征（即使是 标准化） 字符串看起来一样。这一点并不清楚 真正 一般编程的安全风险 - 与之相反的情况 需要对抗性代码审查，完整的ECMAScript是一个很长的路要走 从能够支持。
尝试最小化的有用之处是偶然发生的可能性 键入不同但看起来相同或看到的标识符 标识符，无法可靠地重现它。这是一个 可用性 问题，而不是安全问题。
对于可用性，它可能确实是允许
<ZWNJ>和{。}的好方法<ZWJ>但不允许其他格式控制字符。我不够 熟悉需要这些字符的脚本 但是，基于它们在Unicode中的描述似乎是合理的 标准。但是，UAX＃31中描述的复杂的脚本相关规则 限制
<ZWNJ>和<ZWJ>可能发生的上下文似乎相当 因为不可能防止欺骗，所以过分夸大了。再看一遍 https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002435.html将该帖子的提案与
<NEL>的更改结合起来，<ZWSP>和<BOM>（因为两者都会影响第7.1节），我们最终会这样做。==== 对第7.2节的更改： - 将
<NEL>，<ZWSP>和<BOM>添加到WhiteSpace和 到桌子。对第7.8.4节的修改：
DoubleStringCharacter :: SourceCharacter但不是双引号＆＃34;或反斜杠\或 LineTerminator 或
<BOM>\ EscapeSequence LineContinuationSingleStringCharacter :: SourceCharacter但不是单引号＆＃39;或反斜杠\或 LineTerminator 或
<BOM>\ EscapeSequence LineContinuationNonEscapeCharacter :: SourceCharacter但不是EscapeCharacter或LineTerminator或
<BOM>
DoubleStringCharacter :: SourceCharacter的CV但不是 双引号＆＃34;或反斜杠\或LineTerminator或
<BOM>是SourceCharacter字符本身SingleStringCharacter :: SourceCharacter的CV但不是 单引号＆＃39;或反斜杠\或LineTerminator或
<BOM>是SourceCharacter字符本身。NonEscapeCharacter的简历:: SourceCharacter但不是 EscapeCharacter或LineTerminator或
<BOM>是 SourceCharacter角色本身。替换第7.1节：
7.1 Unicode格式控制字符
Unicode格式控制字符（即，中的字符） 一般类别＆＃34; Cf＆＃34;在Unicode字符数据库中如 左到右标记或右到右标记是用于的控制代码 在没有的情况下控制一系列文本的格式 更高级别的协议，例如标记语言。
<BOM>是一个主要在开头使用的格式控制字符 用于将其标记为Unicode并允许检测文本的文本 编码和字节顺序。用于此目的的<BOM>个字符 有时也会出现在文本开头之后，例如 连接文件的结果。在ECMAScript源中，如果出现
<BOM>个字符，则会被忽略 紧接在令牌之前或之后，或在连续的范围内 WhiteSpace字符（7.2）。词汇语法没有明确说明 包括这样忽略的<BOM>个字符。这是一个语法错误<BOM>字符出现在令牌中（即，如果删除<BOM>会导致前后字符出现 部分相同的事情）。请注意，评论不是令牌，因此上述规则允许
<BOM>个字符会显示在评论中。它不允许他们 出现在字符串文字或正则表达式文字中（ 应该使用转义序列\ uFEFF）。在源文本中允许其他格式控制字符很有用 方便编辑和显示。格式控制字符其他 可以在注释，字符串文字和。中使用
<BOM>正则表达式文字。两个特定的格式控制字符，<ZWNJ>和<ZWJ>也可以在第一个之后的标识符中使用 字符。Code Unit Value Name Formal name
\u200C Zero width non-joiner <ZWNJ> \u200D Zero width joiner <ZWJ> \uFEFF Byte order mark (also called zero-width non-breaking space) <BOM>对第7.6节的修改：
[...]本标准规定了特定的字符添加： 美元符号（$）和下划线（_）允许在任何地方 标识符。第一个之后允许
<ZWNJ>和<ZWJ>字符。对第7.8.5节的修改：
RegularExpressionNonTerminator :: SourceCharacter但不是LineTerminator或
<BOM>附件A的变更： - 更新上面更改的所有作品。
附件E的变更： - 添加到第7.1节的条目： 在标记和注释中忽略字符， 但不允许在令牌内（包括字符串和 正则表达式文字）。
<ZWNJ>和<ZWJ>很重要 在标识符内而不是被剥离。
删除第7.2和15.10.2.12节的条目。
（将
<NEL>，<ZWSP>和<BOM>的添加内容恢复为 WhiteSpace的制作也为这个角色还原了这个 类，没有对第15.10.2.12节进行任何明确的更改。）- 大卫 - 萨拉霍普伍德⚥http://davidsarah.livejournal.com
es5-讨论邮件列表 es5-在mozilla.org上讨论 https://mail.mozilla.org/listinfo/es5-discuss
我不会试图将所有这些结合在一起并给你一个简洁的答案，也许其他人会，你可以接受这个作为答案，看看这是一个起点。
最后一个链接：
The August 2009 archive has the initial draft and release candidate 1 discussions for ES5.