Pegjs: 完全なUnicodeサポート、つまりBMP外のコードポイント

正直なところ、 PEG.js文法パーサーとJavaScriptの例のUnicodeサポートを更新することを除け

今のところ、より緊急の人事および仕事関連のプロジェクト（_PEG.js 0.x_を含む）に取り組んでいる間、Unicodeをよりよく理解している誰かがPRを提供するのを待ち続けます😆、または最終的には_PEGの後にそれを回避します。 js v1_、ごめんなさい。

参考までに、サロゲートペアは機能しているようです。 文法
start = result:[\uD83D\uDCA9]+ {return result.join('')}
u + 1F4A9である💩を解析します。 result.join（ ''）はサロゲートペアを元に戻すことに注意してください。そうしないと、ハンキーの代わりに['\uD83D','\uDCA9']を取得します。 範囲には問題があります。
サロゲートペアの詳細： https ：

これは、OPが要求したものに取って代わるものではありません。

@drewnolan頭を上げてくれてありがとう👍

残念ながら、その文法は\uD83D\uD83Dも解析します。

この問題に遭遇した他の人のために：私はBMPの外のコードポイントの小さなサブセットを処理するだけでよいという点で幸運です、それで私はこのマッピングを解析してすぐに反転する前にそれらをBMPの私用領域にマッピングすることになりました。

この解決策は、一般的なケースでは明らかに問題を抱えていますが、私の問題領域ではうまく機能します。

@ futagoza-説明するために最善を尽くします。 ここでいくつかの問題に直面しています。

1. Unicodeには、エンコーディング、表記法、および範囲があります
   
   
   
   1. ここで重要なのは、「範囲」（サポートされている文字）と「表記法」（それらの記述方法）です。
   
   
   2. これらは時間とともに変化します。 Unicodeは、絵文字や音符を追加したときなど、定期的に新しい文字を追加します
   
   
2. Unicodeには「表記法」があります。 これらは、 utf-16 、 ucs4などです。 これらは、意図されたデータであるcodepointsがバイトとしてエンコードされる方法です。 たとえば、 utf-16-leを使用すると、ほとんどの文字をcode unitsと呼ばれる2バイトのペアとしてエンコードできますが、コード単位のグループを使用して、最大0x10ffffまでの高価値文字を表現できます。
   
   
   
   1. 重要な理解：それは実際には十分ではありません。 絵文字、歴史的な中国語の大きな塊、この投稿の基本的な質問（黒板の数学の文字）など、興味深いものがたくさんあります。
      
      
      
      
      
      1. ISOとUnicodeコンソーシアムは明確でした：
      
      
      
   
   
   2. 重要な理解＃2：JavaScriptのクソは正式にはutf16です
      
      
      
      
      
      1. これは、Javascript文字列型では表現できないUnicode文字（それらの多く）が存在することを意味します
      
      
      
      2. OPはこれを修正するように求めています
      
      
      
      3. これは可能ですが、簡単ではありません。有名なネズミの巣であるUnicode解析アルゴリズムを実装する必要があります。
      
      
      
   
   

私もこれが欲しいのですが、現実的にはこれは起こらないでしょう

なんてこった、誰かがほぼ1年前に

なぜそれが融合しないのか

@StoneCypher私はあなたの心の火が大好きです！ しかし、なぜ現在のメンテナに苦労するのでしょうか。 誰も何も負っていません。 自分のフォークを維持してみませんか？

現在のメンテナはいない。 PEGを引き継いだ人は何もリリースしていません。 彼は次の副専攻に3年間取り組んだ後、見た目が気に入らなかったと言い、 peg.jsすべて捨てて、互換性のない別の言語で最初から書いたものからやり直しました。 AST。

このツールは、es6モジュールのサポート、typescriptのサポート、矢印のサポート、拡張されたUnicodeなど、他の人が書いた1行の修正をコミットするために、この男性を3年間待っているユーザーベースの半分を失いました。

彼に合併を求める人が十数人いて、彼は「いいえ、これは今の私の趣味のプロジェクトであり、それが何であるかが気に入らない」と言い続けています。

多くの人がこのパーサーに基づいた会社を持っています。 彼らは完全にねじ込まれています。

この男は非常に重要な道具の保守者になることを約束し、何の保守もしていません。 今度は、他の誰かにこのライブラリを良好な状態に保つようにしましょう。

自分のフォークを維持してみませんか？

私は今3年間持っています。 私のpegでは、課題追跡システムのほぼ3分の1が修正されています。

私はそれを複製し、名前を変更し、新しいフォークを作成してサイズの問題を修正し、コミットしようとしました。

これらの修正と、2017年からトラッカーに保存されている修正を他のすべての人が受け取る時が来ました。

この男はペグを維持していません。 彼はそれを死なせている。

変化の時です。

@ drewnolan-つまり、これが興味深いかどうかは

根本的な問題を理解するには、表現レベルではなく、エンコーディングレベルのビットパターンについて考える必要があります。

つまり、Unicode値が240の場合、ほとんどの人は「ああ、彼は0b1111 0000を意味する」と思うでしょう。 しかし実際には、Unicodeが240を表す方法ではありません。 一番上のビットは値ビットではなくフラグであるため、127を超えるものは2バイトで表されます。 つまり、Unicodeの240は実際にはストレージに0b0000 0001 0111 0000です（utf-7は実際のものであり、タイプミスではなく、非常に奇妙なものになります。もちろん、ウィキペディアは使用されていないと言っています。ウィキペディアは間違っています。 。これはSMSが送信されるものです。これは、トラフィック全体で最も一般的な文字エンコードである可能性があります。）

これが問題です。

バイトSTUVWXYZを書き込んだ場合、utf16でucs4データから、物事が半分にカットされた場合、ほとんどの場合、ステープルで留めることができます。

128に一度は、2バイトを超えるエンコーディングの文字の場合はできません。 （ひどく特定の数のように聞こえますね？）

2番目のバイト位置のトップビットが使用されている場合、それを半分にカットすると、1であるはずの場所に0が追加されます。 バイナリデータが値の概念を再び削除することはないため、それらを並べてステープルで留めます。 デコードされた値はエンコードされた値と同等ではなく、エンコードではなくデコードを追加しています。

ほとんどの絵文字がこの範囲外にあることがあります。 ただし、まれな中国語、ほとんどの数学、記譜法など、いくつかの言語の大きな塊はそうではありません。

確かに、あなたのアプローチは、ほとんどすべての絵文字、およびUnicode 6を使用するのに十分な一般的なすべての人間の言語に十分対応できます。これは、現状を大幅に改善したものです。

ただし、このPRは、正確性と予期しないパフォーマンスの問題の両方について十分にテストされたら、実際にマージする必要があります（ユニコードのパフォーマンスの問題が、phpが停止した理由であることを忘れないでください）。

. (dot character)式にもUni​​codeモードが必要なようです。 比較：

const string = '-🐎-👱-';

const symbols = (string.match(/./gu));
console.log(JSON.stringify(symbols, null, '  '));

const pegResult = require('pegjs/')
                 .generate('root = .+')
                 .parse(string);
console.log(JSON.stringify(pegResult, null, '  '));

出力：

[
  "-",
  "🐎",
  "-",
  "👱",
  "-"
]

[
  "-",
  "\ud83d",
  "\udc0e",
  "-",
  "\ud83d",
  "\udc71",
  "-"
]

私は最近これに取り組み、＃616をベースとして使用し、ES6構文\u{hhhhhhh}を使用するように変更しました。数時間以内に、PRを作成します。

サロゲートによって分割されたUTF-16正規表現範囲の計算は少し複雑であり、これにはhttps://github.com/mathiasbynens/regenerateを使用しました。 これはパッケージpegjsの最初の依存関係になります。それが可能であることを願っています（依存関係として追加できるUnicodeプロパティのポリフィルもあります。＃648を参照してください）。 UTF-16サロゲートがわからない場合は、ウィキペディアを参照してください。

PEG.jsをUnicode全体と互換性を持たせるために、さまざまなレベルがあります。

1. ＃616または私のES6構文バージョンで修正されたBMPの上にUnicode文字をエンコードする構文を追加します。
2. 前のポイントによって直接提供された定数文字列を認識し、
3. SyntaxErrorレポートを修正して、実際のUnicode文字を表示するために1つまたは2つのコードユニットを表示する可能性があります。
4. BMPおよび/またはアストラルコードポイントの正規表現クラスを正確に計算します-これだけでは機能しません。次のポイントを参照してください。
5. 正規表現クラスは（1）、（2）、または（ランタイムに応じて1または2）になる可能性があるため、カーソルの増分を管理します。以下の詳細を参照してください。
6. ルールドット.を実装して、1つまたは2つのコードユニットをキャッチします。

ドットルールが1つまたは2つのコード単位をキャプチャするかどうかによって解析の結果が異なる可能性があるため、ポイント5を除いて、ほとんどのポイントで下位互換性があり、古いものと非常によく似たパーサーを生成できます。 このために、ユーザーが2つまたは3つの選択肢から選択できるようにするランタイムオプションを追加することを提案します。

1. ドットルールは、BMPコードユニットのみをキャプチャします。
2. ドットルールは、Unicodeコードポイント（1または2コード単位）をキャプチャします。
3. ドットルールは、Unicodeコードポイントまたは唯一のサロゲートをキャプチャします。

正規表現クラスは、パーサーの生成中に静的に分析して、固定長（コード単位の数）があるかどうかを確認できます。 3つのケースがあります：1。BMPまたは単一のコードユニットのみ、または2. 2つのコードユニットのみ、または3.ランタイムに応じて1つまたは2つのコードユニット。 今のところ、バイトコードは正規表現クラスが常に1つのコード単位であると想定しています（ここを参照）。 静的分析を使用すると、最初の2つのケースで、このバイトコード命令のこのパラメーターを1または2に変更できます。 しかし、3番目のケースでは、実行時に一致するコードユニットの数を取得し、それに応じてカーソルを増やすために、新しいバイトコード命令を追加する必要があると思います。 新しいバイトコード命令がない他のオプションは次のとおりです。1。一致するコードユニットの数を常に計算しますが、これはBMPのみのパーサーの解析中のパフォーマンスの低下であるため、このオプションは好きではありません。 2.現在のコード単位が高サロゲートであり、その後に1または2の増分で低サロゲートが続くかどうかを計算しますが、これは、文法が常に整形式のUTF-16サロゲートであり、単独のサロゲートで文法を記述する可能性がないことを前提としています（次のポイントを参照してください）。これは、BMPのみのパーサーのパフォーマンスの低下でもあります。

孤独なサロゲートの問題があります（その後の低いサロゲートのない高いサロゲート、またはその前の高いサロゲートのない低いサロゲート）。 これについての私の意見は、正規表現クラスは排他的である必要があるということです。整形式のUTF-16 Unicode文字（BMPまたは高いサロゲートの後に低いサロゲートが続く）を持つ単独のサロゲートを使用するか、文法の作成者が気付かない危険性があります。 UTF-16の微妙な点は両方を混ぜ合わせており、結果を理解していません。UTF-16サロゲートを管理したい文法作成者は、特定の高サロゲートと低サロゲート間のリンクを記述するためにPEGルールを使用してそれを行うことができます。 パーサーの生成中にこのルールを適用するビジターを追加することを提案します。

結論として、PEGパーサーは常に前進するため、正規表現よりもPEGで孤独なサロゲートの問題を管理する方がおそらく簡単です。したがって、次のコードユニットは認識されないか、認識されないかのどちらかです。高いサロゲートと低いサロゲートの関連付けを解除し、その結果、一致するUnicode文字の数などを変更します。

アストラルUnicode文字のES6構文のPRは＃616に基づく＃651であり、クラスの開発はhttps://github.com/Seb35/pegjs/commit/0d33a7a4e13b0ac7c55a9cfaadc16fc0a5dd5f0cであり、上記のコメントのポイント2と3のみを実装してい. （ポイント5）については今のところ何もしません。

この問題に関する私の現在の開発はほぼ終了しています。より高度な作業は

グローバルな動作は、JS正規表現のフラグunicode unicodeと同様のオプション[^a]はテキスト「💯」と一致し、カーソルは2コード単位増加します）。 オプションunicodeがfalseの場合、カーソルは常に1コード単位だけ増加します。

入力に関しては、JSの正規表現と同じ方法でPEG.jsを設計するかどうかはわかりません。非ユニコードモードの文法で[\u{1F4AD}-\u{1F4AF}] （ [\uD83D\uDCAD-\uD83D\uDCAF]相当）を承認する必要がありますか？ 「入力Unicode」と「出力Unicode」を区別することができます。

• input Unicodeは、文字クラス内のすべてのUnicode文字を承認することです（これは、固定の2コード単位または固定の1コード単位として内部的に計算されます）。
• 出力Unicodeは、結果のパーサーのカーソル増分です。ルール「ドット」および「反転文字クラス」の1つのコードユニットまたは1つのUnicode文字–文字が明示的にリストされておらず、文法からの決定が必要な唯一のルール著者

個人的には、入力Unicodeを永続的に、またはデフォルトのtrueオプションを使用して承認することをお勧めします。これは、大きなオーバーヘッドがなく、デフォルトですべての人がこの可能性を有効にするためですが、出力Unicodeはfalseままである必要があります。生成されたパーサーのパフォーマンスが優れているため、

この問題全般（およびデフォルトの出力Unicodeがfalse ）に関しては、UTF-16の機能を理解することを犠牲にして、すでに文法にUnicode文字をエンコードしている可能性があることに注意してください。 ：

// rule matching [\u{1F4AD}-\u{1F4AF}]
my_class = "\uD83D" [\uDCAD-\uDCAF]

// rule matching any Unicode character
my_strict_unicode_dot_rule = $( [\u0000-\uD7FF\uE000-\uFFFF] / [\uD800-\uDBFF] [\uDC00-\uDFFF] )

// rule matching any Unicode character or a lone surrogate
my_loose_unicode_dot_rule = $( [\uD800-\uDBFF] [\uDC00-\uDFFF]? / [\u0000-\uFFFF] )

したがって、迅速なパーサーと、文法の特定の部分でUnicode文字を認識できることの両方が必要な文法作成者は、このような規則を使用できます。 したがって、この問題は、UTF-16の内部に飛び込むことなく、Unicode管理を単純化することだけを目的としています。

実装については、最初の試みで、文法テキストがUnicode文字でエンコードされており、PEG.jsパーサーの「ドット」ルールがUnicode文字を認識していることを考慮しました。 2番目の最後の試みはこれを元に戻し（ドットルールは常に解析を高速化するために1コード単位です）、訪問者のprepare-unicode-classes.jsには、文字クラスで分割されたUnicode文字を再構築するための小さなアルゴリズムがあります（例： [\uD83D\uDCAD-\uD83D\uDCAF]は構文的に[ "\uD83D", [ "\uDCAD", "\uD83D" ], "\uDCAF" ]として認識され、このアルゴリズムはこれを[ [ "\uD83D\uDCAD", "\uD83D\uDCAF" ] ]変換します）。 これを文法自体に書くことを想定していましたが、長くなり、さらに重要なことに、文字をエンコードする方法が複数あるため（ "💯"、 "uD83DuDCAF"、 "u {1F4AF}"）、書きやすくなりました。訪問者に。

2回目の試行で2つのオペコードを追加しました。

• MATCH_ASTRAL MATCH_ANYに似ていますが、Unicode文字に一致します(input.charCodeAt(currPos) & 0xFC00) === 0xD800 && input.length > currPos + 1 && (input.charCodeAt(currPos+1) & 0xFC00) === 0xDC00
• MATCH_CLASS2はMATCH_CLASSと非常に似ていますが、1つのclasses[c].test(input.substring(currPos, currPos+2)ではなく、次の2つのコードユニットに一致します。
  次に、2コード単位の文字と1コード単位の文字のどちらに一致するかに応じて、カーソルがオペコードACCEPT_Nで1または2コード単位に拡大され、文字クラスが2つに分割されます。固定長の正規表現（1または2コード単位）。

「一致」機能を使用していくつかの最適化を行い、生成中にモード（Unicodeかどうか）と文字クラスに応じて「デッドコード」パスを削除しました。

また、この実装では正規表現は常に正であることに注意してください。逆正規表現は逆の結果を返し、バイトコードになります。 これにより、サロゲート周辺のエッジケースを回避するのが簡単になりました。

私はいくつかのドキュメントを書きましたが、おそらくさらにいくつか追加します（おそらく、オプションのユニコードと自家製のUnicodeドットルールを使用したスニペットの詳細をすばやく説明するためのガイド）。 PRとして提出する前にテストを追加します。