Pegjs: 완전한 유니코드 지원, 즉 BMP 외부의 코드포인트

솔직히 말해서, PEG.js 문법 파서 와 JavaScript 예제에 대한 유니코드 지원 업데이트를 제외하고 저는 유니코드에 대한 지식이 거의 또는 전혀 없기 때문에 현재 이 문제를 해결할 수 없습니다(두 문법 모두에 명확하게 명시되어 있습니다. _Non -BMP 문자는 완전히 무시됩니다_).

지금은 더 긴급한 개인 및 업무 관련 프로젝트(_PEG.js 0.x_ 포함)를 진행하는 동안 유니코드를 더 잘 이해하는 사람이 PR을 제공하거나 결국 _PEG 이후에 처리하기를 계속 기다릴 것입니다. js v1_, 죄송합니다.

참고로 대리 쌍이 작동하는 것으로 보입니다. 문법
start = result:[\uD83D\uDCA9]+ {return result.join('')}
u+1F4A9인 💩를 구문 분석합니다. result.join('') 은 서로게이트 쌍을 다시 결합합니다. 그렇지 않으면 hankey 대신 ['\uD83D','\uDCA9'] 를 얻습니다. 범위가 문제가 됩니다.
대리 쌍에 대한 추가 정보: https://en.wikipedia.org/wiki/UTF-16#U +010000_to_U+10FFFF

이것은 OP가 요청한 것을 결코 대체하지 않습니다.

@drewnolan 알려 주셔서 감사합니다 👍

불행히도 그 문법은 \uD83D\uD83D 도 구문 분석합니다.

이 문제에 직면한 다른 사람들을 위해: 저는 운이 좋게도 BMP 외부에 있는 코드포인트의 작은 부분집합만 처리하면 되므로 결국 나중에 이 매핑을 구문 분석하고 반전하기 전에 BMP의 개인 사용 영역 에 매핑하게 되었습니다. .

이 솔루션은 분명히 일반적인 경우에 문제로 가득 차 있지만 내 문제 영역에서는 잘 작동합니다.

@futagoza - 최선을 다해 설명하겠습니다. 여기에서 몇 가지 문제에 직면하고 있습니다.

1. 유니코드에는 인코딩, 표기법 및 범위가 있습니다.
   
   
   
   1. 여기서 중요한 것은 "범위" - 지원되는 문자 - 및 "표기법" - 작성 방법입니다.
   
   
   2. 시간이 지남에 따라 변경됩니다. 유니코드는 이모티콘이나 음표를 추가할 때와 같이 주기적으로 새 문자를 추가합니다.
   
   
2. 유니코드에는 "표기법"이 있습니다. utf-16 , ucs4 등과 같은 것들이 있습니다. 이는 의도한 데이터인 codepoints 를 바이트로 인코딩하는 방식입니다. 예를 들어 utf-16-le 를 사용하면 대부분의 문자를 code units 라는 2바이트 쌍으로 인코딩할 수 있지만 코드 단위 그룹을 사용하여 최대 0x10ffff 까지 값이 높은 문자를 표현할 수 있습니다.
   
   
   
   1. 주요 이해: 충분히 높지 않습니다. 이모티콘, 역사적 중국어의 큰 덩어리, 이 게시물의 기본 질문(칠판 수학 문자)과 같은 많은 흥미로운 항목이 해당 행 위에 있습니다.
      
      
      
      
      
      1. ISO와 유니코드 컨소시엄은 분명히 했습니다. 그들은 결코 그것을 수정하지 않습니다 . 더 높은 문자를 원하면 utf-16보다 큰 인코딩을 사용하십시오.
      
      
      
   
   
   2. 핵심 이해 #2: 빌어 먹을 자바 스크립트는 공식적으로 utf16입니다
      
      
      
      
      
      1. 이것은 Javascript 문자열 유형이 나타낼 수 없는 유니코드 문자(많은 문자)가 있음을 의미합니다.
      
      
      
      2. OP에서 이 문제를 해결하도록 요청합니다.
      
      
      
      3. 이것은 가능하지만 쉽지는 않습니다. 쥐의 둥지로 유명한 유니코드 구문 분석 알고리즘을 구현해야 합니다.
      
      
      
   
   

나도 이거 하고 싶은데 현실적으로 안될듯

젠장, 누군가가 거의 1년 전에 전체 문자열 파서 교체를 커밋 했고 오버헤드를 인식했기 때문에 일반적으로 표준 JS 문자열을 사용하도록 했습니다.

병합되지 않은 이유

@StoneCypher 나는 당신의 마음속의 불을 사랑합니다! 하지만 왜 현재 유지 관리자를 힘들게 합니까? 아무도 빚진 것이 없습니다. 자신의 포크를 유지 관리하지 않는 이유는 무엇입니까?

현재 유지 보수가 없습니다. PEG를 인수한 사람은 아무 것도 공개하지 않았습니다. 그는 모든 던지고, 그 다음 3 년 동안 마이너에서 일한 그는 그 모습처럼하지 않았다 peg.js 호환되지 않는로, 멀리, 그가 다른 언어로 처음부터 쓴 일부터 시작 AST.

이 도구는 es6 모듈 지원, 타이프스크립트 지원, 화살표 지원, 확장된 유니코드 등과 같이 다른 사람들이 작성한 한 줄 수정 사항을 커밋하기 위해 3년을 기다리는 동안 사용자 기반의 절반을 잃었습니다.

그에게 병합을 요청하는 수십 명의 사람들이 있고 그는 계속 "아니요, 이것은 이제 내 취미 프로젝트이고 그것이 무엇인지 좋아하지 않습니다"라고 계속 말합니다.

많은 사람들이 이 파서를 기반으로 하는 회사를 가지고 있습니다. 완전히 망했어.

이 사람은 매우 중요한 도구의 유지 관리를 약속하고 유지 관리를 한 번도 하지 않았습니다. 이제 다른 사람이 이 라이브러리를 양호한 상태로 유지하도록 할 때입니다.

자신의 포크를 유지 관리하지 않는 이유는 무엇입니까?

나는 이제 3 년 동안 가지고 있습니다. 내 peg 문제 추적기의 거의 1/3이 수정되었습니다.

나는 그것을 복제하고, 이름을 바꾸고, 커밋을 시도하기 위해 크기 문제를 수정하기 위해 새 포크를 만들어야 했습니다. 왜냐하면 광산이 너무 많이 표류했기 때문입니다.

2017년 이후로 추적기에 앉아 있었던 것뿐만 아니라 다른 모든 사람들이 이러한 수정 사항을 받을 때입니다.

이 사람은 말뚝을 유지하지 않습니다. 그는 죽게 내버려 둡니다.

변화의 시간입니다.

@drewnolan- 그래서 이것이 흥미로운지 아닌지 확실하지 않지만 대리 쌍은 실제로 작동하지 않습니다. 그저 우연의 일치로 보통 그렇게 하는 것뿐입니다.

근본적인 문제를 이해하려면 표현 수준이 아닌 인코딩 수준 비트 패턴에 대해 생각해야 합니다.

즉, 유니코드 값이 240이면 대부분의 사람들은 "오, 그는 0b1111 0000 합니다."라고 생각할 것입니다. 그러나 실제로는 유니코드가 240을 나타내는 방식이 아닙니다. 127 이상은 2바이트로 표현되는데, 상위 비트가 값 비트가 아니라 플래그이기 때문입니다. 따라서 유니코드의 240은 실제로 저장소에 0b0000 0001 0111 0000 입니다(실제이고 오타가 아닌 utf-7 제외, 상황이 매우 이상해집니다. 그리고 예, Wikipedia에서 사용하지 않는다고 말합니다. Wikipedia가 잘못되었습니다. . SMS가 전송되는 방식으로 전체 트래픽에서 가장 일반적인 문자 인코딩일 수 있습니다.)

여기 문제가 있습니다.

STUV WXYZ 바이트를 작성한 다음 ucs4 데이터에서 utf16을 작성하는 경우 항목이 반으로 잘리면 꽤 자주 다시 함께 스테이플할 수 있습니다.

128에서 한 번은 기본적으로 2바이트 인코딩을 초과하는 문자에 대해 할 수 없습니다. (굉장히 구체적인 숫자처럼 들리지 않습니까?)

두 번째 바이트 위치의 최상위 비트가 사용 중일 때 이를 반으로 자르면 1이어야 하는 위치에 0이 추가되기 때문입니다. 이진 데이터로 다시 나란히 스테이플링해도 가치 개념이 다시 제거되지 않습니다. 디코딩된 값은 인코딩된 값과 동일하지 않으며 인코딩이 아닌 디코딩을 추가합니다.

대부분의 이모티콘이 이 범위 밖에 있습니다. 그러나 희귀 중국어, 대부분의 수학 및 음악 기호를 포함하여 여러 언어의 큰 덩어리는 그렇지 않습니다.

물론, 당신의 접근 방식은 거의 모든 이모티콘과 유니코드 6으로 들어갈 수 있을 만큼 일반적인 모든 인간 언어에 대해 충분히 훌륭합니다. 이는 현상 유지에 비해 엄청난 개선입니다

그러나 이 PR은 정확성과 예상치 못한 성능 문제에 대해 충분히 테스트되면 실제로 병합되어야 합니다(유니코드 성능 문제가 php가 죽은 이유임을 기억하십시오)

. (dot character) 표현식에도 유니코드 모드가 필요한 것 같습니다. 비교하다:

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의 첫 번째 종속성이 될 것입니다. 가능하기를 바랍니다(종속성으로 추가될 수 있는 유니코드 속성에 대한 폴리필도 있습니다. #648 참조). UTF-16 대리를 모르는 경우 Wikipedia를 참조하십시오 .

PEG.js를 전체 유니코드와 호환되도록 만들기 위해 다양한 수준이 있습니다.

1. #616 또는 내 ES6 구문 버전으로 수정된 BMP 위에 유니코드 문자를 인코딩하는 구문을 추가합니다.
2. 이전 포인트에서 직접 제공한 상수 문자열을 인식하고,
3. 실제 유니코드 문자를 표시하기 위해 1 또는 2 코드 단위를 표시하도록 SyntaxError 보고를 수정합니다.
4. BMP 및/또는 아스트랄 코드 포인트에 대한 정규식 클래스를 정확하게 계산합니다. 이것만으로는 작동하지 않습니다. 다음 포인트를 참조하십시오.
5. 정규식 클래스가 이제 (1), (2) 또는 (런타임에 따라 1 또는 2)일 수 있으므로 커서 증가를 관리합니다. 아래 세부 정보를 참조하십시오.
6. 점 . 규칙을 구현하여 1개 또는 2개의 코드 단위를 포착합니다.

대부분의 포인트에 대해 우리는 이전 버전과 매우 유사한 파서를 이전 버전과 매우 유사한 파서를 생성할 수 있습니다. 파싱 결과는 점 규칙이 하나 또는 두 개의 코드 단위를 캡처하는지에 따라 달라질 수 있기 때문입니다. 이를 위해 사용자가 두 가지 또는 세 가지 선택 중에서 선택할 수 있도록 런타임 옵션을 추가할 것을 제안합니다.

1. 점 규칙은 BMP 코드 단위만 캡처하고,
2. 점 규칙은 유니코드 코드 포인트(1 또는 2 코드 단위)를 캡처합니다.
3. 점 규칙은 유니코드 코드 포인트 또는 단독 대리자를 캡처합니다.

Regex 클래스는 고정 길이(코드 단위 수)가 있는지 확인하기 위해 파서 생성 중에 정적으로 분석될 수 있습니다. 3가지 경우가 있습니다. 1. BMP 또는 단일 코드 단위만, 2. 두 개의 코드 단위만, 또는 3. 런타임에 따라 하나 또는 두 개의 코드 단위. 현재 바이트코드는 정규식 클래스가 항상 하나의 코드 단위라고 가정합니다( 여기 참조 ). 정적 분석을 통해 이 바이트코드 명령어의 매개변수를 첫 번째 두 경우에 대해 1 또는 2로 변경할 수 있습니다. 그러나 세 번째 경우에는 런타임에 일치하는 코드 단위 수를 얻고 그에 따라 커서를 늘리기 위해 새 바이트코드 명령을 추가해야 한다고 생각합니다. 새로운 바이트코드 명령어가 없는 다른 옵션은 다음과 같습니다. 1. 항상 일치하는 코드 단위 수를 계산하지만 이것은 BMP 전용 파서에 대한 구문 분석 중 성능 저하이므로 이 옵션을 좋아하지 않습니다. 2. 현재 코드 단위가 1 또는 2의 증분에 대해 낮은 대리가 뒤따르는 상위 대리인지 계산하기 위해, 그러나 이것은 문법이 고독한 대리로 문법을 작성할 가능성 없이 항상 잘 구성된 UTF-16 대리를 가지고 있다고 가정합니다( 다음 항목 참조) 이는 BMP 전용 구문 분석기의 성능 저하이기도 합니다.

고독한 대리(뒤에 하위 대리가 없는 상위 대리 또는 상위 대리가 없는 하위 대리)에 대한 질문이 있습니다. 이에 대한 내 의견은 정규식 클래스가 독점적이어야 한다는 것입니다. 잘 구성된 UTF-16 유니코드 문자(BMP 또는 상위 대리 다음에 하위 대리)가 있는 고독한 대리를 사용하거나, 그렇지 않으면 문법 작성자가 인식하지 못하는 위험이 있습니다. UTF-16의 미묘함은 둘을 혼합하고 결과를 이해하지 못합니다. UTF-16 대리를 스스로 관리하려는 문법 작성자는 PEG 규칙을 사용하여 특정 상위 대리와 하위 대리 사이의 링크를 설명할 수 있습니다. 파서 생성 중에 이 규칙을 시행하는 방문자를 추가할 것을 제안합니다.

결론적으로, PEG 파서는 항상 전진하기 때문에 정규식보다 PEG에서 고독한 대리자 문제를 관리하는 것이 더 쉬울 수 있습니다. 상위 서로게이트를 하위 서로게이트와 연결 해제하고 결과적으로 일치하는 유니코드 문자 수 등을 변경합니다.

아스트랄 유니코드 문자에 대한 ES6 구문에 대한 PR은 #616을 기반으로 하는 #651이고 클래스 개발은 https://github.com/Seb35/pegjs/commit/0d33a7a4e13b0ac7c55a9cfaadc16fc0a5dd5f0c입니다. 커서 증가(4번 지점)에 대한 빠른 해킹과 . 규칙 점(5번 지점)에 대해서는 현재로서는 아무 것도 없습니다.

이 문제에 대한 현재 개발은 대부분 완료되었으며 더 고급 작업은 https://github.com/Seb35/pegjs/tree/dev-astral-classes-final에 있습니다. 위에서 언급한 5가지 사항이 모두 처리되고 전역 동작은 에지 케이스와 관련하여 JS 정규식을 모방하려고 시도합니다(많은 경우가 있음).

전역 동작은 JS 정규식의 플래그 unicode unicode 와 유사한 [^a] 는 "💯" 텍스트와 일치하고 커서가 2 코드 단위로 증가합니다. unicode 옵션이 false인 경우 커서는 항상 1 코드 단위로 증가합니다.

입력과 관련하여 JS regexes와 동일한 방식으로 PEG.js를 디자인하는지 확실하지 않습니다. 비유니코드 모드의 문법에서 [\u{1F4AD}-\u{1F4AF}] ( [\uD83D\uDCAD-\uD83D\uDCAF] ) 를 승인해야 합니까? "입력 유니코드"와 "출력 유니코드"를 구분할 수 있습니다.

• 입력 유니코드는 문자 클래스의 모든 유니코드 문자를 승인하는 것입니다(내부적으로 고정 2코드 단위 또는 고정 1코드 단위로 계산됨).
• 출력 유니코드는 결과 파서의 커서 증분입니다. 'dot' 및 'inverted characters class' 규칙에 대해 1개의 코드 단위 또는 1개의 유니코드 문자 – 문자가 명시적으로 나열되지 않고 문법에서 결정이 필요한 유일한 규칙 작가

개인적으로 저는 입력 유니코드를 영구적으로 또는 기본 true 옵션을 사용하여 인증하는 것을 선호합니다. 왜냐하면 상당한 오버헤드가 없고 기본적으로 모든 사람이 이 가능성을 사용할 수 있기 때문입니다. 그러나 출력 유니코드는 false 유지되어야 합니다.

일반적으로 이 문제와 관련하여(및 기본값이 false 출력 유니코드에 대해) UTF-16의 기능을 이해하는 대가로 이미 문법에서 유니코드 문자를 인코딩할 가능성이 있음을 명심해야 합니다. :

// 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] )

따라서 빠른 파서를 원하고 문법의 특정 부분에서 유니코드 문자를 인식할 수 있는 문법 작성자는 이러한 규칙을 사용할 수 있습니다. 결과적으로 이 문제는 UTF-16 내부를 살펴보지 않고 유니코드 관리를 단순화하는 것에 관한 것입니다.

구현에 대해, 나는 문법 텍스트가 유니코드 문자로 인코딩되었고 PEG.js 파서의 '점' 규칙이 유니코드 문자를 인식한다고 첫 번째 시도 에서 고려했습니다. 두 번째이자 마지막 시도 는 이것을 되돌렸고(빠른 구문 분석을 위해 점 규칙은 항상 1 코드 단위임) 방문자 prepare-unicode-classes.js에 문자 클래스의 분할 유니코드 문자를 재구성하는 작은 알고리즘이 있습니다(예: [\uD83D\uDCAD-\uD83D\uDCAF] 는 구문상 [ "\uD83D", [ "\uDCAD", "\uD83D" ], "\uDCAF" ] 로 인식되며 이 알고리즘은 이것을 [ [ "\uD83D\uDCAD", "\uD83D\uDCAF" ] ] 변환합니다. 나는 이것을 문법 자체에 작성하는 것을 상상했지만 길고 더 중요하게는 문자를 인코딩하는 여러 가지 방법("💯", "uD83DuDCAF", "u{1F4AF}")이 있으므로 쓰기가 더 쉽습니다. 방문자에서.

두 번째 시도에서 두 개의 opcode를 추가했습니다.

• MATCH_ASTRAL은 MATCH_ANY와 유사하지만 유니코드 문자 (input.charCodeAt(currPos) & 0xFC00) === 0xD800 && input.length > currPos + 1 && (input.charCodeAt(currPos+1) & 0xFC00) === 0xDC00 와 일치합니다.
• MATCH_CLASS2는 MATCH_CLASS와 매우 유사하지만 하나의 classes[c].test(input.substring(currPos, currPos+2) 대신 다음 두 코드 단위를 일치시킵니다.
  그런 다음 2-코드 단위 문자 또는 1-코드-단위 문자를 일치하는지 여부에 따라 커서가 opcode ACCEPT_N 사용하여 1 또는 2 코드 단위로 증가하고 문자 클래스는 두 개로 분할됩니다. 고정 길이의 정규식(1 또는 2 코드 단위).

모드(유니코드 여부)와 문자 클래스에 따라 "데드 코드" 경로를 생성하는 동안 제거하여 "일치" 기능으로 몇 가지 최적화를 수행했습니다.

또한 이 구현에서 정규식은 항상 양수입니다. 역 정규식은 반대 결과를 반환하여 바이트 코드를 생성합니다. 이렇게 하면 서로게이트 주변의 엣지 케이스를 피하기가 더 쉬웠습니다.

몇 가지 문서를 작성했지만 아마도 몇 가지를 더 추가할 것입니다(아마도 옵션 유니코드의 세부 사항과 집에서 만든 유니코드 점 규칙이 있는 스니펫에 대한 세부 정보를 빠르게 설명하기 위한 가이드). PR로 제출하기 전에 테스트를 추가하겠습니다.