为什么美元符号不再“仅用于机械生成的代码中？”

Question

在ECMA-262，第3版^[PDF]中 ，在第7.6节（“标识符”，第26页）下，我们看到以下注释：

美元符号仅适用于机械生成的代码。

这似乎是合理的。 许多通常用于生成或嵌入JavaScript的语言都具有$的特殊含义，并且在这些语言的JavaScript标识符中使用$会导致意外的行为 。

“机械生成的子句”出现在版本2中。在版本1中，它不存在。 由于5版，它再次消失，不用解释，它仍然没有从第6版的工作草案。

如果我不得不猜测，我会假设它最初是被省略的，因为没有考虑潜在的陷阱，然后在很明显会引起问题的下一版中将其添加进来。 我想不出有充分的理由在版本5中再次将其删除。

对于从规范中包含并随后删除“机械生成的子句”（邮件列表，新闻组或其他地方的“纸迹”），是否有任何解释？ 我在任何地方都找不到此文档。

---

作为附带的问题，任何人都可以解释在版本6草案中包括零宽度字符的背后原理吗？ 鉴于您根本看不到这些字符，这似乎会造成更大的麻烦，而且我也无法想出您要在标识符中使用这些字符的任何原因。

---

更新：最初包含“机械生成的代码”注释和包含零宽度字符的信息将在下面的Codewaggle答案中进行说明。 唯一需要回答的是该问题的主要焦点，即删除 “机械生成的代码”注释。

Answer 1

这是一个开始： 主题：SC22 N2745-关于DIS 16262的注释报告的处置-ECMAScript

似乎添加了“只应用于机械生成的代码”，因为这是JAVA的规范。

D6）7.5：根据TR 10176中的建议，DOLLAR SIGN不应出现在标识符列表中。7.5对于字母和数字的定义，请参阅ISO / IEC 14652的“ i18n”规范。

>>>>>>操作：部分接受-ECMAScript遵循Java的先例。 注释中将添加$只应用于机械生成的代码。 <<<<<

如果您想浏览过去的会议记录，可以在这里查看：
ecmascript Wiki：以往会议的笔记和纪要

---

关于以后的更改：
所有这些都来自邮件列表“ es5-discuss-ECMAScript 3.x的讨论 ”。

标识符中的ZWNJ和ZWJ（是：对ES4月4最终草案标准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>字符。 编程语言语法所需要做的就是允许它们。

请注意，“尽可能多地排除无明显区别的结果”（据称出于安全原因）的目标实际上并不适用，因为ECMAScript甚至不执行 NFC标准化。 如UTR＃31所述，为了不强制使用NFC而是给语法增加相当大的复杂性，以防止某些可能的（但相对无害的， <ZWNJ> ）滥用<ZWNJ>和<ZWJ> ，这似乎是一组不一致的设计选择对我来说。

---

这是一堆讨论： 关于格式控制char的最后呼吁。 问题

对此有15条答复，您可能需要阅读以下内容：
https://mail.mozilla.org/pipermail/es5-discuss/2009-June/thread.html#2832

艾伦·维尔夫斯·布洛克（Allen Wirfs-Brock）写道：

Waldemar在5月F2F上发表的笔记没有在标识符中记录有关<ZWNJ>和<ZWJ>问题的任何决定。 但是，我的个人笔记说，我需要“保留标识符并修正语法”，这也是我对会议决定的回忆。

该决定的最简单实现是简单地添加<ZWNJ>和<ZWJ>作为IdentifierPart的替代项。 另外，第7.1节中的文字说格式控制字符可能出现在标识符中，大概需要缩小到仅说<ZWNJ>和<ZWJ> 。

大约在F2F的同时，David-Sarah提出了更全面的建议（在下面重复），该建议除了解决<ZWNJ>和<ZWJ>还显着完善了<BOM>的规则，包括将它们从字符串文字和正则表达式中排除并使<BOM>出现在标识符中成为语法错误。

我不是Unicode专家，但是我的感觉是David-Sarah的建议是正确的，并且可能与清理规范中Cf类的最初目标一致。 但是，他的<BOM>规则似乎也可以使实施的词法分析阶段大大复杂化。

从F2F上我的感觉是，共识更多地是指向我上面的简单解决方案（标识符中的<ZWNJ>和<ZWJ> ， <BOM>是空白）的方向，而不是David-Sarah对<BOM>更全面的处理。

我需要对此做出最终决定，以便可以相应地更新草案。 基于对F2F的回忆，除非另有明显共识，否则我将采用“简单解决方案”。

最后的想法？

他回复的消息根据消息引用分为几部分：

-----原始消息-----发自：mozilla.org上的es5-discuss-bounces [motomozilla.org上的mailto：es5-discuss- bounces]代表David-Sarah Hopwood发送：5月28日，星期四， 2009年5:44 PM收件人：mozilla.org上的es5-discuss主题：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渲染器中，它们中的大多数对周围的文本（尤其是拉丁脚本文本）也几乎没有可见的影响，不要在意渲染它们的渲染器。 结果是“ foobar”和“ foo <Cf> bar”看起来相同，但不同。

根据Unicode 5.1，唯一真正影响标识符自然语言含义的是U + 200C ZWNJ和U + 200D ZWJ。 这些是甚至应在ES5标识符中考虑的标识符。 UAX＃31（包含在Unicode 5.1中作为参考）规定了ZWNJ和ZWJ必不可少的较窄条件； 遵守条件并非易事，但可以最大程度地减少欺骗的可能性。

考虑到风险，我不确定是否应该允许ZWNJ和ZWJ。

打破

忘记尝试将标识符欺骗最小化是一种安全风险。 如果根本不允许Unicode标识符，那是不可能的。 Unicode的固有特征是，许多不同的字符串（即使经过规范化处理）也将看起来相同。 尚不清楚这是否是常规编程的真正安全隐患-与需要对抗性代码审查的情况相反，要获得全面的ECMAScript支持还需要很长的路要走。

试图最小化有用的是偶然输入不同但看起来相同的标识符的机会，或者看到标识符并且无法可靠地重现它的机会。 这是可用性问题，而不是安全问题。

为了提高可用性，允许<ZWNJ>和<ZWJ>可能是一个好方法，但不允许使用其他格式控制字符。 我对要求这些字符的脚本不太熟悉，但是根据Unicode标准中对它们的描述，这似乎是合理的。

但是，鉴于无法防止欺骗，在UAX＃31中描述的用于限制<ZWNJ>和<ZWJ>可能出现的上下文的复杂脚本相关规则似乎<ZWNJ>头了。 同样，请参阅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，但不能使用双引号“或反斜杠\\或LineTerminator或<BOM> \\ EscapeSequence LineContinuation

SingleStringCharacter :: SourceCharacter，但不包含单引号'或反斜杠\\或LineTerminator或<BOM> \\ EscapeSequence LineContinuation

NonEscapeCharacter :: SourceCharacter，但不是EscapeCharacter或LineTerminator或<BOM>

• DoubleStringCharacter :: SourceCharacter的CV而不是双引号“或反斜杠\\或LineTerminator或<BOM>的CV是SourceCharacter字符本身

• SingleStringCharacter :: SourceCharacter的CV而不是单引号'或反斜杠\\或LineTerminator或<BOM>的CV是SourceCharacter字符本身。

• NonEscapeCharacter :: SourceCharacter的CV而不是EscapeCharacter或LineTerminator或<BOM>的CV是SourceCharacter字符本身。

替换第7.1节：

7.1 Unicode格式控制字符

Unicode格式控制字符（即Unicode字符数据库中通用类别“ Cf”中的字符，例如LEFT-TO-RIGHT MARK或RIGHT-TO-LEFT MARK）是用于控制范围的格式的控制代码。缺少高级协议（例如标记语言）的文本。

<BOM>是一种格式控制字符，主要用于文本的开头，以将其标记为Unicode，并允许检测文本的编码和字节顺序。 用于此目的的<BOM>字符有时也可以在文本开头之后出现，例如，由于串联文件而引起的。

在ECMAScript源代码中，如果<BOM>字符紧接在标记之前或之后或在连续的空白字符（7.2）范围内出现，则会被忽略。 词汇语法没有明确包含此类被忽略的<BOM>字符。 <BOM>字符出现在令牌中是一种语法错误（也就是说，如果删除<BOM>将导致前一个字符和后一个字符成为同一令牌的一部分）。

请注意，注释不是标记，因此上述规则允许<BOM>字符出现在注释中。 不允许它们出现在字符串文字或正则表达式文字中（应使用转义序列\\ uFEFF代替）。

允许在源文本中使用其他格式控制字符以方便编辑和显示非常有用。 注释，字符串文字和正则表达式文字中可以使用<BOM>以外的格式控制字符。 在第一个字符之后的标识符中也可以使用两个特定的格式控制字符<ZWNJ>和<ZWJ> 。

\n   代码单位值名称正式名称\n\n  
  
  
\n\n   \\ u200C零宽度非连接器<ZWNJ>\n   \\ u200D零宽度细木工<ZWJ>\n   \\ uFEFF字节顺序标记（也称为\n                        零宽度不间断空格）<BOM>\n

对第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产品中，也将其还原为\\ s字符类，而无需对15.10.2.12节进行任何显式更改。）

-大卫-莎拉·霍普伍德⚥ http://davidsarah.livejournal.com

---

es5-discuss邮件列表es5-discuss，位于mozilla.org https://mail.mozilla.org/listinfo/es5-discuss

---

我不会尝试将所有这些放在一起，给您一个简洁的答案，也许其他人会并且您可以接受，作为答案，将此作为起点。

最后一个链接：
2009年8月的归档文件包含ES5的初稿和候选版本1讨论。