ここから始めましょう:件名: SC22 N2745 - Disposition of Comments Report on 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を参照して
ください。
David-Sarah Hopwood はこう答えました。
状況依存のルールを追加せずに U+200C と U+200D を IdentifierPart に単純に追加することのマイナス面は何ですか?
<ZWNJ>および<ZWJ>文字が
識別子で意図したとおりに使用されるようにすることは、入力メソッドとプログラマーの共同責任であると思います。プログラミング言語の構文が行う必要があるのは、それらを許可することだけです。
ECMAScript はNFC の正規化さえ強制しないため、「目に見える区別が得られない場合をできるだけ多く除外する」という目標 (おそらくセキュリティ上の理由から) は実際には当てはまらないことに注意してください。<ZWNJ>NFC を強制するのではなく、UTR #31 が示唆するように文法にかなりの複雑さを追加することは、 and
の潜在的な (しかし比較的無害な AFAICS) 誤用を防ぐために<ZWJ>、一貫性のない設計選択のセットのように思えます。
これは、一連の議論をまとめたものです: format-control char に関するコンセンサスの最後の呼び出し。問題
これには 15 の返信があります。おそらくそれらを読みたいと思うでしょう:
https://mail.mozilla.org/pipermail/es5-discuss/2009-June/thread.html#2832
Allen Wirfs-Brock は次のように書いています。
<ZWNJ>5 月の F2F での Waldemar のメモには、識別子の問題と<ZWJ>in 識別子に関する決定は記録されていません。しかし、私の個人的なメモには、「識別子を保持し、文法を修正する」必要があると書かれています。これは、会議で決定したことの記憶でもあります。
その決定の最も簡単な実装は、IdentifierPart の代替として単純に<ZWNJ>
andを追加することです。<ZWJ>さらに、フォーマット制御文字が識別子に出現する可能性があると述べているセクション 7.1 のテキストは、おそらく と だけに絞り込む必要が<ZWNJ>あり
<ZWJ>ます。
F2F とほぼ同時に、David-Sarah はより包括的な提案 (以下に複製) を作成しました。これは、アドレス指定に加えて<ZWNJ>、文字列リテラルと正規表現からそれらを除外し、to の構文エラーにするための<ZWJ>規則を大幅に改良する
ものです。識別子内に表示されます。<BOM><BOM>
私は Unicode の専門家ではありませんが、David-Sarah の提案は適切であり、おそらく仕様のクラス Cf をクリーンアップするという当初の目標と一致していると思います。ただし、彼のルールは<BOM>、実装の字句解析フェーズを大幅に複雑にする可能性があるようにも見えます。
F2F からの私の感覚では、コンセンサスは<ZWNJ>、<ZWJ>David <BOM>-Sarah の
<BOM>.
それに応じてドラフトを更新できるように、これについて最終決定を下す必要があります。F2F についての私の記憶に基づいて、他に明らかなコンセンサスがない限り、「単純な解決策」を使用します。
最終的な考え？
彼が返信したメッセージは、メッセージの引用に基づいてチャンクに分割されています。
-----元のメッセージ----- 差出人: mozilla.org の es5-discuss-bounces [mailto:es5-discuss- mozilla.org のバウンス] David-Sarah Hopwood の代理で送信: 5 月 28 日木曜日2009 5:44 PM To: es5-discuss at mozilla.org 件名: IdentifierName の文法は許可されておらず<ZWNJ>、<ZWJ>
ジョン・コーワンは次のように書いています。
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 固有の特性です。これが一般的なプログラミングにとって真のセキュリティ リスクであることはまったく明らかではありません。敵対的なコード レビューが必要な状況とは対照的です。
最小化を試みるのに役立つのは、異なるが同じように見える識別子を誤って入力する可能性、または識別子を見て確実に再現できない可能性です。これはユーザビリティの問題であり、セキュリティの問題ではありません。
使いやすさのために、他のフォーマット制御文字を許可<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>
セクション 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>
ではない、または SourceCharacter 文字自体である
SingleStringCharacter :: SourceCharacter の CV であり、一重引用符 '、バックスラッシュ、\、LineTerminator<BOM>
は含まれていないか、SourceCharacter キャラクターそのものです。
NonEscapeCharacter :: SourceCharacter の CV であるが、EscapeCharacter または LineTerminator で<BOM>はない、または SourceCharacter キャラクター自体である。
セクション 7.1 を置き換えます。
7.1 Unicode フォーマット制御文字
Unicode フォーマット制御文字 (つまり、LEFT-TO-RIGHT MARK や RIGHT-TO-LEFT MARK などの Unicode Character Database の General Category "Cf" の文字) は、範囲のフォーマットを制御するために使用される制御コードです。マークアップ言語など、このための上位レベルのプロトコルがない場合のテキスト。
<BOM>テキストを Unicode としてマークし、テキストのエンコーディングとバイト順を検出できるようにするために、主にテキストの開始時に使用されるフォーマット制御文字です。<BOM>この目的で意図された文字は、たとえばファイルの連結の結果として、テキストの開始後に表示されることもあります。
ECMAScript ソースで<BOM>は、トークンの直前または直後、または連続する WhiteSpace 文字 (7.2) の範囲内にある文字は無視されます。<BOM>字句文法には、そのような無視される文字が明示的に含まれていません。文字がトークン内に現れるのは構文エラーです
<BOM>(つまり、 を削除する
<BOM>と、前後の文字が同じトークンの一部になる場合)。
コメントはトークンではないことに注意してください。したがって、上記のルールでは、
<BOM>コメント内に文字を表示できます。文字列リテラルまたは正規表現リテラル内に表示することはできません (代わりにエスケープ シーケンス \uFEFF を使用する必要があります)。
ソース テキスト内の他の書式制御文字を許可すると、編集と表示が容易になります。以外の書式制御文字<BOM>は、コメント、文字列リテラル、および正規表現リテラル内で使用できます。2 つの特定のフォーマット制御文字
<ZWNJ>および<ZWJ>, も、最初の文字の後の識別子で使用できます。
コード 単位 値 名称 正式名称
\u200C ゼロ幅ノンジョイナー <ZWNJ>
\u200D ゼロ幅ジョイナー <ZWJ>
\uFEFF バイトオーダーマーク (別名
ゼロ幅の改行なしスペース) <BOM>
セクション 7.6 の変更:
[...] この標準は、特定の文字の追加を指定します。ドル記号 ($) とアンダースコア (_) は、識別子のどこでも使用できます。最初の文字の後に許可されます<ZWNJ>。<ZWJ>
セクション 7.8.5 の変更:
RegularExpressionNonTerminator :: SourceCharacter ではなく LineTerminator または<BOM>
附属書 A の変更: - 上記で変更されたすべての製品を更新します。
付録 E の変更: - セクション 7.1 のエントリに追加: 文字はトークン間およびコメント内では無視されますが、トークン内では許可されません (文字列および正規表現リテラルを含む)。<ZWNJ>削除されるので<ZWJ>はなく、識別子内で重要です。
-- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
es5-discuss メーリング リスト mozilla.org の es5-discuss
https://mail.mozilla.org/listinfo/es5-discuss
これらすべてをまとめて簡潔な答えを出すつもりはありません。おそらく他の誰かがそうするでしょうし、あなたはそれを答えとして受け入れることができます。これを出発点として見てください.
最後のリンク:
2009 年 8 月のアーカイブには、ES5 の最初のドラフトとリリース候補 1 の議論があります。