这是一个开始：主题：SC22 N2745 - DIS 16262 评论报告的处理 -ECMAScript
似乎添加了“仅应用于机械生成的代码”，因为这是 JAVA 的规范。
D6) 7.5：根据 TR 10176 中的建议，美元符号不应出现在标识符列表中。7.5 应参考 ISO/IEC 14652 的“i18n”规范来了解字母和数字的定义。
>>>>>>行动：部分接受 --- ECMAScript 遵循 Java 的先例。注释将添加 $ 只能用于机械生成的代码。
如果您想仔细阅读过去的会议记录，可以查看此处：
ecmascript wiki：过去会议的笔记和纪要
关于后期改动：
所有这些都来自邮件列表“es5-discuss -- ECMAScript 3.x 的讨论".
标识符中的 ZWNJ 和 ZWJ（原为：对 4 月 ES5 最终草案标准 tc39-2009-025 的评论）
约翰·考恩写道：
事实证明，Unicode 5.1 已经完成了繁重的工作：坏消息
是提升确实很重。您想要允许 Cf 字符
当且仅当它们确实在语义上进行了区分
当代使用。 Unicode 5.1 表示，事实证明，只允许
U+200C 和 U+200D，然后仅在某些情况下：规则涉及
了解附近标识符的 Script 和 Joining_Type 属性
人物。详情请见http://unicode.org/reports/tr31/#Layout_and_Format_Control_Characters
.
大卫-莎拉·霍普伍德 回复:
简单地添加 U+200C 和 U+200D 的缺点是什么
IdentifierPart 没有任何额外的上下文相关规则？
我认为这是输入法和输入法的共同责任
程序员要确保<ZWNJ> and <ZWJ>使用字符如预期在标识符中；编程语言语法所需要做的就是允许它们。
请注意，“排除尽可能多的情况”的目标
可见的区分结果”（据说是出于安全原因）不是
确实适用，因为 ECMAScript 不enforce甚至NFC
正常化。不强制执行 NFC 而是增加相当大的复杂性
正如 UTR #31 所建议的，为了防止某些
潜在的（但相对无害的，AFAICS）滥用<ZWNJ> and
<ZWJ>，对我来说似乎是一组不一致的设计选择。
这引起了一系列讨论：最后呼吁就格式控制字符达成共识。问题
对此有 15 条回复，您可能需要阅读这些回复：
https://mail.mozilla.org/pipermail/es5-discuss/2009-June/thread.html#2832
艾伦·维尔夫斯-布洛克写道：
瓦尔德马 (Waldemar) 在 5 月 F2F 上的笔记并未记录任何关于
问题在于<ZWNJ> and <ZWJ>在标识符中。不过我个人的笔记
说我需要“保留标识符并修复语法”，这也是
我记得我们在会议上做出的决定。
该决策最简单的实现就是简单地添加<ZWNJ>
and <ZWJ>作为 IdentifierPart 的替代品。此外，文本中
第 7.1 节说格式控制字符可以出现在
标识符大概需要缩小到仅表示<ZWNJ> and
<ZWJ>.
大约在同一时间，F2F David-Sarah 制作了更多
综合提案（复制如下）除
寻址<ZWNJ> and <ZWJ>还大幅细化了规则<BOM>包括将它们从字符串文字和常规中排除
表达式并使其成为语法错误<BOM>出现在
一个标识符。
我不是 Unicode 专家，但我的感觉是 David-Sarah 的提议
是合理的并且可能符合最初的清洁目标
规范中的 Cf 级。然而，他的规则<BOM>还
看起来它们可能会使词法分析变得非常复杂
实施阶段。
我从 F2F 中得到的感觉是，共识更多的是在这个方向上
我上面的简单解决方案（<ZWNJ> and <ZWJ>在标识符中，<BOM>是
空白）而不是 David-Sarah 更全面的处理<BOM>.
我需要对此做出最终决定，以便更新草稿
因此。根据我对 F2F 的回忆，我要去
除非有明显的共识，否则采用“简单解决方案”
否则。
最后的想法？
他回复的消息根据消息引用分为几部分：
- - -原始信息 - - -
来自：mozilla.org 的 es5-discuss-bounces [mailto:es5-discuss-
在 mozilla.org 上跳出] 代表 David-Sarah Hopwood
发送时间：2009 年 5 月 28 日星期四下午 5:44
至：mozilla.org 上的 es5 讨论
主题：IdentifierName 的语法不允许<ZWNJ> and <ZWJ>
约翰·考恩写道：
大卫-莎拉·霍普伍德剧本：
格式控制字符的省略<IdentifierName>出现
只是一个疏忽。
-1
Break
事实上，我忘记了我们已经讨论过这个问题并得出结论
不同的结论：
https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002432.html
https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002435.html.
Break
允许所有这些都会导致与允许相同类型的问题
物料清单。大多数对周围文本几乎没有明显的影响
（尤其是拉丁文字）即使在完全符合 Unicode 的情况下
渲染器，
别介意渲染器将它们消音。结果是“foobar”
和
“富<Cf>酒吧”看起来一样，但其实不然。
根据 Unicode 5.1，唯一真正影响自然的 -
语言
标识符的含义是 U+200C ZWNJ 和 U+200D ZWJ。这些是
仅有的
ES5 标识符中甚至应该考虑这些。 UAX#31
（哪个
通过引用包含在 Unicode 5.1 中）指定更窄的条件
其中ZWNJ和ZWJ是必不可少的；坚持条件就是
这很重要，但可以最大限度地减少欺骗的可能性。
考虑到风险，我不确定ZWNJ和ZWJ是否应该被允许
或不。
Break
忘记尝试尽量减少标识符欺骗作为安全风险。那是
如果完全允许 Unicode 标识符，则不可能。它是一个
Unicode 的固有特征有许多不同的（即使当
标准化）
字符串看起来是一样的。完全不清楚这是一个
真的
一般编程的安全风险——与以下情况相反
需要对抗性代码审查，这对于完整的 ECMAScript 来说还有很长的路要走
从能够支持。
尝试最大程度地减少意外发生的可能性是有用的
输入不同但看起来相同的标识符，或者看到一个
标识符并且无法可靠地复制它。这是一个
可用性
问题，而不是安全问题。
对于可用性来说，允许这样做确实可能是一个好方法<ZWNJ> and
<ZWJ>但不允许使用其他格式控制字符。我还不够
熟悉需要这些角色才能确定的脚本
但根据 Unicode 中的描述，这似乎是合理的
标准。
然而，UAX #31 中描述的复杂的依赖于脚本的规则
限制上下文<ZWNJ> and <ZWJ>可能会发生，看起来相当
考虑到不可能防止欺骗，就有点过头了。再次，参见https://mail.mozilla.org/pipermail/es5-discuss/2009-April/002435.html.
将该帖子中的提案与更改相结合<NEL>,
<ZWSP> and <BOM>（因为两者都会影响第 7.1 节），我们最终会得到这样的结果。
====
对第 7.2 节的更改：
- 恢复添加<NEL>, <ZWSP>, and <BOM>到空白和
到桌子上。
对第 7.8.4 节的更改：
双字符串字符::
SourceCharacter 但不是双引号 " 或反斜杠 \ 或
行终结符
或者<BOM>\ 转义序列行延续
单字符串字符::
SourceCharacter 但不是单引号 ' 或反斜杠 \ 或
行终结符
或者<BOM>\ 转义序列行延续
非转义字符::
SourceCharacter 但不是 EscapeCharacter 或 LineTerminator 或<BOM>
DoubleStringCharacter :: SourceCharacter 的 CV 但不是
双引号 " 或反斜杠 \ 或行终止符或<BOM>是 SourceCharacter 字符本身
SingleStringCharacter :: SourceCharacter 的 CV 但不是
单引号 ' 或反斜杠 \ 或行终止符或<BOM>是 SourceCharacter 字符本身。
NonEscapeCharacter :: SourceCharacter 的 CV 但不是
EscapeCharacter 或 LineTerminator 或<BOM>是个
SourceCharacter 字符本身。
替换第 7.1 节：
7.1 Unicode格式控制字符
Unicode 格式控制字符（即，
Unicode 字符数据库中的通用类别“Cf”，例如
从左到右标记或从右到左标记）是用于
在没有的情况下控制一系列文本的格式
为此的高级协议，例如标记语言。
<BOM>是一个格式控制字符，主要用于开头
将其标记为 Unicode 并允许检测文本的文本
编码和字节顺序。<BOM>用于此目的的字符
有时也可以出现在文本开始之后，例如
连接文件的结果。
在 ECMAScript 源代码中，<BOM>出现的字符将被忽略
紧接在标记之前或之后，或者在连续的范围内
空白字符 (7.2)。词法语法没有明确
包括此类被忽略的<BOM>人物。这是一个语法错误<BOM>出现在标记中的字符（也就是说，如果删除<BOM>将导致前面和后面的字符
同一令牌的一部分）。
请注意，注释不是标记，因此上述规则允许<BOM>出现在评论中的字符。这不允许他们
出现在字符串文字或正则表达式文字中（
应使用转义序列 \uFEFF）。
在源文本中允许使用其他格式控制字符很有用
以方便编辑和显示。格式控制字符 其他
比<BOM>可以在注释、字符串文字中使用
正则表达式文字。两个特定的格式控制字符，<ZWNJ> and <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> and <ZWJ>在第一个之后被允许
特点。
对第 7.8.5 节的更改：
正则表达式非终止符::
SourceCharacter 但不是 LineTerminator 或<BOM>
附录 A 的变更：
- 更新上面更改的所有产品。
附录 E 的变更：
- 添加到第 7.1 节的条目：
标记之间和注释中的字符被忽略，
但不允许在令牌内（包括字符串和
正则表达式文字）。<ZWNJ> and <ZWJ>是重要的
在标识符内而不是被剥离。
-
删除第 7.2 节和 15.10.2.12 节的条目。
（恢复添加<NEL>, <ZWSP>, and <BOM>到
空白生产也会将其恢复为 \s 字符
类，无需对第 15.10.2.12 节进行任何显式更改。）
--
大卫-莎拉·霍普伍德 ⚥http://davidsarah.livejournal.com
es5-讨论邮件列表
在 mozilla.org 上讨论 es5https://mail.mozilla.org/listinfo/es5-discuss
我不会尝试将所有这些放在一起并给你一个简洁的答案，也许其他人会，你可以接受这个答案，将此视为一个起点。
最后一个链接：
2009 年 8 月的存档包含 ES5 的初始草案和候选版本 1 的讨论。
