Design: 토론: WebAssembly, 유니코드 및 웹 플랫폼

지금까지 오프라인 피드백에서 수집한 몇 가지 잠재적인 솔루션은 다음과 같습니다.

별도의 WTF-16

인터페이스 유형에서 다음을 정의합니다.

string   := list char
string16 := list u16

다음과 같은 경우 연결하는 동안 적용되는 강제 변환을 정의합니다.

| 에서 | 로 | 기대
|------------|------------|-------------
| string | string16 | UTF-8에서 UTF-16으로 다시 인코딩
| string16 | string | WTF-16에서 UTF-8로 다시 인코딩(대체 옵션)

강제는 string 및 string16 모듈이 모두 string 경우에도 서로 인터페이스할 수 있도록 string16 모듈이 각각 WASI 호스트에서 작동하도록 합니다 string 및 string16 모듈 또는 호스트는 동일한 string 또는 string16 내보내기를 호출합니다. 그렇지 않으면 모호합니다.

이것은 또한 list u16 를 JS에 전달하는 것이 Uint16Array 또는 DOMString 가 될 수 있다는 점에서 웹 임베딩에 모호성을 도입합니다. Uint16Array 에서 DOMString 로의 JS 전체 강제 변환은 바람직하지 않은 것처럼 보이지만 JS 유형은 string16 별칭을 명시적으로 사용하여 암시할 수 있습니다(자체 바이너리 id, string16 :> list u16 는 어댑터 모듈에서 list u16 대신 필요한 경우 순전히 의미론적입니다. 따라서 별칭. 이 경우 string16 는 DOMString 되고 list u16 는 Uint16Array 됩니다.

저는 string16 라는 이름에 특별히 집착하지 않으며 다른 이름이나 모호성을 해결하기 위해 이름/ID가 필요하지 않은 다른 이름으로 해도 괜찮습니다.

list.count 사용할 수 있으므로 list.is_canon 와 유사한 최적화는 여기에서 필요하지 않습니다. 또한 아래와 같이 UTF-any 및 잠재적인 Latin1 최적화를 향한 문은 list.*_canon 어댑터 명령에서 미래를 위한 공간을 즉시 예약하여 열어둘 수 있습니다.

UTF-any

인터페이스 유형에서 다음을 정의합니다.

list.lift_canon $unit [...]
list.is_canon $unit [...]
list.lower_canon $unit [...]

where the $unit immediate is
  0: 8-bit (UTF-8, ASCII-compatible)
  1: 16-bit (UTF-16)
  2: 32-bit (UTF-32)
  3: 8-bit (Latin1, narrow UTF-16)

이 잠재적 솔루션은 잘 형성되어야 하는 경우에 고려될 수 있습니다. 이중 재인코딩 오버헤드와 코드 크기에 대한 간접적인 영향을 방지하지만 대리 문제는 해결되지 않은 상태로 둡니다. $unit 1-3은 MVP 이후에 추가 최적화로 추가되거나 일부는 바로 시작할 수 있습니다.

WTF-모든

인터페이스 유형에서 다음을 정의합니다.

list.lift_canon $unit [...]
list.is_canon $unit [...]
list.lower_canon $unit [...]

where the $unit immediate is
  0: 8-bit (WTF-8, ASCII-compatible)
  1: 16-bit (WTF-16)
  2: 32-bit (Code points except surrogate pairs)
  3: 8-bit (Latin1, narrow WTF-16)

이 잠재적인 솔루션은 또한 char 를 유니코드 스칼라 값에서 유니코드 코드 포인트로 재정의하는 한편 char 목록을 제한하여 대리 쌍을 포함하지 않도록(그러나 격리된 대리를 허용함) 해제할 때 잠재적으로 시행해야 합니다. 다시 말하지만, MVP의 구체적인 $unit 는 논쟁의 여지가 있습니다.

이것은 자체적으로 손실을 유발하지 않으므로 다른 모든 것은 실제로 MVP 후 최적화가 됩니다.

통합 W/UTF-any

인터페이스 유형에서 다음을 정의합니다.

• "대리 쌍을 수정하는 유니코드 코드 포인트 목록"을 올리지만 "유니코드 스칼라 값 목록"을 낮춥니다. 이것은 16비트 리프팅 중에만 적용되는 비기능적 디자인 전용 변경 사항입니다.
• "유니코드 코드 포인트 목록"을 얻기 위해 낮출 때 선택적 passthrough 옵션을 추가합니다. 이것은 무손실 패스스루를 가능하게 하는 기능적 추가입니다.

그렇게 함으로써 우리는 다음을 달성합니다:

• 기본적으로 잘 형성됨
• 옵션으로 WTF 언어에 대한 무손실 인코딩
• https://github.com/WebAssembly/interface-types/issues/136#issuecomment -861799460과 결합할 때: 잘 지원하고자 하는 대부분의(모든?) 언어용 내장 인코더

IIUC의 근본 문제는 IT에서 문자열이 유니코드 코드 포인트의 시퀀스가 ​​되기를 원하지만 일부 언어에서는 문자열을 잘 구성된 유니코드 문자열에 해당하거나 해당하지 않을 수 있는 i8 또는 i16 값의 시퀀스로 간주한다는 것입니다. 하나의 간단한 해결책은 언어 / 수락하거나 유효하지 않은 유니 코드 문자열을 사용하는 생산 API를 가지고하는 것입니다 (list u8) 또는 (list u16) (같은 가능성을 가진 멋진 별칭 byte_string 의도 의사 소통)보다는를 IT string 유형으로, IIRC는 (list char) 의 별칭입니다. 그렇게 하는 것의 장단점에 대해 논의한 적이 있습니까?

IT가 char 를 "유니코드 스칼라 값"으로 정의하기를 원한다는 점에서 문제가 좀 더 미묘하다고 생각합니다. 이 값은 서로게이트 코드 포인트가 있어야 하는 위치에 구멍이 있으므로 격리된 서로게이트를 나타낼 수 없습니다. . 반면에 WTF는 이 제한이 없는 "유니코드 코드 포인트"이지만 서로게이트 코드 포인트 쌍을 포함하지 않도록 시퀀스가 ​​제한됩니다(이들은 보조 코드 포인트 > U+FFFF로 대체되지만 격리된 서로게이트는 괜찮음). 이것이 당신이 의미하는 무엇입니까?

그 외에는 const char* 현재 C와 같은 바이트 문자열에 대해서는 아직 논의되지 않은 것 같습니다. 내가 놓쳤을 수도 있지만.

하나의 간단한 해결책은 언어 / 수락하거나 유효하지 않은 유니 코드 문자열을 사용하는 생산 API를 가지고하는 것입니다 (list u8) 또는 (list u16) (같은 가능성을 가진 멋진 별칭 byte_string 의도 의사 소통)보다는를 IT string 유형으로, IIRC는 (list char) 의 별칭입니다.

이것은 현재 내가 선호하는 솔루션이기도 합니다. string 가 현재 (list char) 대한 별칭으로 정의된 것과 같은 방식으로 wtf16string 유형은 (list u16) 의 별칭이 됩니다 (list char) . 별칭 IIUC의 값은 JS가 호출한 (list u16) 반환하는 함수의 결과가 JS 목록(숫자)으로 나타나는 반면 wtf16string 반환하는 함수의 결과는

표준 ABI 초안에 추가 wtf16string 별칭을 추가하는 것은 상대적으로 방해가 되지 않는 것 같습니다.

반면에 WTF는 이 제한이 없는 "유니코드 코드 포인트"이지만 서로게이트 코드 포인트 쌍을 포함하지 않도록 시퀀스가 ​​제한됩니다(이들은 보조 코드 포인트 > U+FFFF로 대체되지만 격리된 서로게이트는 괜찮음).

아, 그것은 WTF-8이 이 추가 제한이 있기 때문에 일반 (list u16) 와 동일하지 않다는 것을 의미합니까? 나는 그 뉘앙스를 높이 평가하지 않았다. 내 직관은 (list u16) 가까운 wtf16string 유형뿐만 아니라 잘 구성된 유니코드 스칼라 값의 시퀀스를 나타내는 string 유형을 모두 갖는 것은 과도하다는 것입니다 wtf16string 추가 제한 사항이 있습니다. 무제한 (list u16) 별칭을 사용하면 유니코드 형식을 적용하지 않는 시스템에서 충분히 잘 작동합니까? WTF-8 사양의 이 메모는 그럴 것이라고 제안합니다.

아, 그것은 WTF-8이 이 추가 제한이 있기 때문에 일반(목록 u16)과 동일하지 않다는 것을 의미합니까?

"UTF-8이 UTF-16과 일치시키기 위해 인위적으로 유니코드 텍스트로 제한되는 것처럼 WTF-8은 잠재적으로 잘못된 형식의 UTF-16과 일치시키기 위해 대리 코드 포인트 쌍을 제외하도록 인위적으로 제한됩니다." Iiuc, UTF-8이 너무 길거나 잘린 바이트 시퀀스를 처리하는 방식과 유사하게 처리합니다. WTF-8은 모든 (list u16) 나타낼 수 있지만 모든 (list u8) 가 유효한 WTF-8은 아닙니다.

unrestricted(list u16)에 대한 별칭을 사용하면 유니코드 형식을 적용하지 않는 시스템에서 충분히 잘 작동합니까?

WTF-16은 1:1을 임의의 u16 값에 매핑하고 이러한 값이 해석되는 방식에 따라 달라지므로 예, (list u16) 가 작동합니다.

IIUC, WTF-8은 임의의 list u8 와 완전히 동일하지 않습니다. 예를 들어, "대리 쌍 바이트 시퀀스"를 금지합니다( 여기 참조).

그러나 WTF-16은 _is_ list u16 와 동일합니다. 그들이 네이밍 테마를 공유한다는 것이 조금 이상합니다.

편집: 새로 고쳐야 합니다 :)

나는 interface-types/#135 의 대리 질문에 초점을 맞춘 첫 번째 질문/답변을 게시했습니다. 나는 그것이 상위 비트라고 생각하며, 우리가 그것에 동의할 수 있다면 하나 이상의 인코딩 형식 지원에 대한 후속 논의가 더 간단해질 것입니다.

고마워, 루크.

위와 같이 "별도의 WTF-16"을 지원하려는 경우(강제력은 WASI API에 액세스하고 글루 코드 없이 JavaScript와 인터페이스하는 데 중요합니다) 제안된 char 편안함을 느낄 것입니다. 값 범위. 그런 다음 WTF-16 언어는 통합하는 데 필요한 이스케이프 해치를 가질 뿐만 아니라 동일한 언어인 JavaScript로 작성된 모듈과 UTF-* 언어로 교체하는 방법을 통해 얻을 수 있습니다. 또한 문자열 인코딩의 불일치로 인해 발생하는 주요 문제점이 강제로 해결될 것이기 때문에 WASI btw에 대해 훨씬 더 좋게 느낄 것입니다.

서로게이트로 제안한 것처럼 별도의 string16 유형을 사용하면 여전히 interface-types/#135 에 설명된 서로게이트에 대한 모든 문제가 있으므로 두 개의 문자열 유형을 갖는 것이 더 좋지 않을 것이라고 생각합니다. .one(특히 암시적으로 상호 변환할 수 있는 경우 의미 있는 별도의 유형이 아님). 두 개의 문자열 유형을 사용하면 모든 인터페이스 디자이너와 소비자에게 정신적 부담을 주어 상황을 더욱 악화시킬 수도 있습니다("왜 두 가지 유형이 있습니까? 차이점이 무엇입니까? 언제 둘 중 하나를 사용해야 합니까?"). 마지막으로 WTF-16에 대한 지원을 추가하는 것은 일반적으로 interface-types/#135 에서도 언급된 미래 표준 진화 지침 Web/IETF에 위배됩니다. 따라서 인터페이스 유형이 없이는 실행 가능하지 않다는 실제 구체적인 증거가 없는 한 대리 베어링 유형을 추가하는 것을 고려해야 한다고 생각하지 않습니다.

웹 전용 사용 사례의 경우 JS 또는 Web API에서 문제를 해결하는 것이 합리적이라고 생각합니다. 예를 들어, wasm 가져오기 및 내보내기를 "바인딩"하기 위한 JS API를 쉽게 상상할 수 있습니다. 이것은 이미 스택 전환과 같은 다른 신흥 JS API에서 채택된 접근 방식이며 웹을 처리할 수 있는 일반적인 "바인드 가져오기"/"바인드 내보내기" JS API가 어디로 가고 있는지 궁금합니다. -Promises, JS 문자열 및 형식화된 배열 보기의 특정 사례.

서로게이트로 제안하는 것과 같은 별도의 string16 유형을 사용하면 여전히 interface-types/135에 설명된 서로게이트에 대한 모든 문제가 있습니다.

기술적으로 사실이지만 어떤 종류의 모듈과 인터페이스하는지에 대한 사전 지식 없이도 문자열이 동일한 언어, 호환되는 모든 언어 및 JavaScript로 별도로 컴파일된 모듈 사이에서 항상 작동한다는 점을 놓치고 있습니다. 제가 생각하는 대부분의 경우입니다. 원하는 char 값 범위를 잘 구성된(USV) 문자열에 할당할 수 있기 때문에 합리적인 절충안처럼 보입니다.

두 개의 문자열 유형을 사용하면 모든 인터페이스 디자이너와 소비자에게 정신적 부담을 주어 상황을 더욱 악화시킬 수 있습니다.

가끔 파손되는 대안은 나에게 훨씬 더 나쁜 것 같습니다. 그래서 그것이 필요한 경우 대부분의 사람들이 괜찮을 것이라고 생각합니다. 아마도 두 번째 문자열 유형에 대한 좋은 이름( domstring ?)은 이 사소한 문제를 완화하기에 충분할 것입니다.

마지막으로 WTF-16에 대한 지원을 추가하면 일반적으로 미래 표준 진화 지침 Web/IETF에 위배됩니다.

불행히도 영향을 받는 언어에 대한 탈출구가 없으면 IT MVP가 누군가를 위해 어딘가에서 무언가를 깨뜨릴 것이고 거의 쓸모가 없기 때문에 알려진 추세에 대한 누군가의 추론이 얼마나 건전한지는 별로 중요하지 않습니다. 내가 작업하고 있는 JavaScript와 같은 언어에 대해서는 반대할 수 밖에 없습니다.

그래서 저는 모두가 함께 살 수 있는 합리적인 해결책이나 타협점을 찾으려고 노력하고 있으며, 협력할 수 있다면 기쁠 것입니다.

나는 당신이 말하는 것이 interface-types/#135 에서 제기된 문제를 어떻게 해결하는지 또는 IT가 새로운 domstring 유형을 포함하지 않고는 일반적 으로 실행 가능하지 않을 것이라는 반증을 제공하는지 알 수 없습니다. 기존 JS API는 이미 경계에서 임의의 값 변환을 수행하기 위한 범용 이스케이프 해치를 제공하므로 이 초기 시점에서 두 번째 이스케이프 해치가 어떻게 필요한지 모르겠습니다. 대리자를 포함하는 추가 전파 문자열에 대해 제공된 강력한 지침에 대응하기 위해 더 많은 경험 기반 증거가 필요하다고 생각합니다.

(FWIW, 우리가 대리자가 없다는 데 동의할 수 있다면 string 의 표준 ABI에서 추가 인코딩으로 U TF-16을 지원하는 것에 대해 이야기하는 것이 합리적이라고 생각합니다. 그러나 그것은 완전히 별개의 주제입니다. 몇 가지 옵션이 있으므로 먼저 이해해야 하는 추상 문자열 의미와 혼동하고 싶지 않습니다.)

이미 매우 성가신 문제를 해결할 수 있다는 점에서 두 번째 단락에 감사드립니다. UTF-16 지원이 따로따로 유용하다는 점에 동의하고, Explainer/MVP에 추가해주시면 감사하겠습니다. 나를 껴줘!

그러나 첫 번째 단락에서 귀하의 주장을 따르기가 어렵습니다. 아마도 내 말을 믿지 못하겠다면 여기 Linus Torvalds가 Linux 커널을 넘어 확장되는 매우 중요한 규칙을 설명하고 있습니다. Don't break userspace . 그리고 그는 같은 강연에서 프로그래머의 지혜인 If it's an bug on the 사람들이 의존하는 버그라면 버그가 아니라

전체 시스템에서 가장 핵심적인 라이브러리가 ABI를 "개선"하고 "수정"하는 한 문제를 해결하는 데 문제가 없을 때 정말 슬픈 일입니다.

그리고 대리자에 대해 걱정할 필요가 없는 것은 실제로 일종의 기능입니다. 사용자가 여기 저기서 부주의하게 substring(0, 1) 수행하고 이를 사용하여 가져온 함수를 호출하거나 split("") , 전달 및 join() 다시, 또는 StringBuilder 를 모듈로 생성하여 마법처럼 가끔 이중 대체 문자를 생성하지 않습니다. 내 말은, 많은 인기 있는 언어들이 올바른 형식을 적용하는 것을 반대하는 이유가 있습니다. 그리고 Wasm이 이러한 언어와 그 사용자를 잘 지원하기를 원할 때 Wasm이 모듈화될수록 경계는 더 커질 것입니다. 함수가 어떤 모듈에 있는지 말하기가 더 어려워지고 문제가 더 분명해집니다.

현재의 현실을 무시하는 방식으로 무언가를 설계하는 것이 나쁜 생각이라는 것을 증명하기 위해 얼마나 더 많은 증거가 필요한지 모르겠습니다. 사실, 이것은 인터페이스 유형에서만 괜찮은 것처럼 보이지만 우리는 다른 모든 제안을 매우 높은 표준으로 유지하고 있습니다. 그리고 나는 이것에 대한 전문가는 아니지만 USV를 주장함으로써 UCS-2 언어의 요구와 관련하여 이와 똑같은 실수를 한 것은 유니코드 표준 자체였다고 생각합니다. 토론 (전체 스레드를 추천할 수 있지만 특히 침묵하기 전 마지막 의견), 2014년 WTF-8 인코딩인 일반적으로 적용되는 실용적인 솔루션에 대한 설명에서 절정에 달했습니다.

비트스트림에서 문자 인코딩 오류가 발생할 때 대체 문자를 내보내는 것은 위험한 자동 데이터 손상의 잘 알려진 형태이며 무결성이 필요한 시스템에서는 이를 금지합니다.

이와 관련하여, codePointAt가 고독한 대리를 때릴 때 예외를 throw하면 누군가가 실수로 데이터베이스의 문자열에서 잘못된 위치에 이모티콘 문자를 넣었기 때문에 전체 응용 프로그램을 중단시키는 버그가 발생할 수 있습니다.

불행히도 ecmascript는 짝을 이루지 않은 서로게이트 코드 포인트가 있는 문자열을 생성하지 않도록 하는 것을 매우 어렵게 만듭니다. 문자열에서 처음 157 .length 단위를 가져오고 아마도 "..."를 추가하여 축약하는 것만큼 쉽습니다. 그리고 BMP가 아닌 캐릭터가 드물기 때문에 실제로 그런 일이 일어난다면 그것은 기이한 사고입니다. 우리는 유니코드 위생을 개선하기 위해 위험 요소를 도입하는 것을 매우 꺼려해야 합니다.

JS, Java 및 C#에 문자열이 있는 이유는 유니코드가 2바이트로는 충분하지 않아 UCS-2가 실행 가능하지 않다는 것을 깨달았을 때 이미 많은 코드가 작성되었기 때문에 이러한 언어는 단순히 선택의 여지가 없습니다. 유사하게, 사용자 공간에 노출된 Linux 시스템 호출의 경우. 대조적으로 오늘날 IT에서 정의한 API를 사용하는 코드는 존재하지 않으므로 동일한 이전 버전과의 호환성 요구 사항이 없습니다. 여러 가지 이유로 wasm 및 인터페이스 유형은 의도적으로 기존 단일 언어 또는 시스템 호출 ABI를 완벽하게 에뮬레이트 하지 않습니다 . 유효한 목표일 수 있지만 구성 요소 모델과 별도의 프로젝트/표준/계층이 될 것입니다. 이것이 계층화 및 범위 지정의 이점입니다. 가능한 모든 목표를 달성하는 데 한 가지가 필요하지 않습니다.

물론 컴포넌트 내부 에서 문자열은 언어에 적절한 방식으로 표현될 수 있다는 점을 다시 강조하고 싶습니다. 그래서 우리는 API 의 의미론에 대해서만 이야기하고 있습니다. 이미 정의된 Web API의 경우:

1. 대리자를 전달할 필요가 없으며 종종 의미가 없다고 믿을 만한 충분한 이유가 있습니다.
2. 사용자 정의 JS API 바인딩을 사용하는 경우 항상 탈출구가 있습니다(웹 API의 100%가 웹 API에 대한 JS-글루리스 바인딩을 가져야 하는 요구 사항은 아닙니다)

따라서 WTF-16 문자열 의미를 전달하지 않고는 IT가 실행 가능하지 않을 것이라는 증거가 아직 없다고 생각합니다. 이것이 MVP에 대한 적절한 질문이라고 생각합니다.

내가 동의하지 않는 몇 가지 점:

나는 당신이 말하는 것이 interface-types/#135에서 제기된 문제를 어떻게 해결하는지 모르겠습니다.

이것은 지금 별개의 문제이며, 손실을 해결하기 위해 합리적인 타협이라고 생각하는 것에 대해 이야기하기 전의 게시물에서 이야기했습니다. 특히, 별도의 문제에서 귀하의 추론에 동의하지만, 사용 가능한 무손실 폴백이 있는 경우에만 가능합니다. 이것은 제 생각에 어느 쪽도 아닙니다. 그렇지 않다면 WTF-8/16이 더 포괄적이고 덜 제한적인 선택이며, 또한 Wasm의 높은 수준의 목표 중 하나가 웹 플랫폼과 원활하게 통합되는 것이므로 바람직하다는 의견을 유지합니다. - 웹의 호환 가능한 특성이며 인터페이스 유형에도 적용됩니다.

기존 JS API는 이미 경계에서 임의의 값 변환을 수행하기 위한 범용 이스케이프 해치를 제공하므로 이 초기 시점에서 두 번째 이스케이프 해치가 어떻게 필요한지 모르겠습니다.

사용자 정의 JS API 바인딩을 사용하는 탈출구가 항상 있습니다.

현재 다음과 같은 글루 코드가 있는 우리의 경우에는 슬프게도 충분하지 않습니다.

const STRING_SMALLSIZE = 192; // break-even point in V8
const STRING_CHUNKSIZE = 1024; // mitigate stack overflow
const utf16 = new TextDecoder("utf-16le", { fatal: true }); // != wtf16

/** Gets a string from memory. */
function getStringImpl(buffer, ptr) {
  let len = new Uint32Array(buffer)[ptr + SIZE_OFFSET >>> 2] >>> 1;
  const wtf16 = new Uint16Array(buffer, ptr, len);
  if (len <= STRING_SMALLSIZE) return String.fromCharCode(...wtf16);
  try {
    return utf16.decode(wtf16);
  } catch {
    let str = "", off = 0;
    while (len - off > STRING_CHUNKSIZE) {
      str += String.fromCharCode(...wtf16.subarray(off, off += STRING_CHUNKSIZE));
    }
    return str + String.fromCharCode(...wtf16.subarray(off));
  }
}

첫째, 우리는 Chrome과 Node.js에 대해 많은 관심을 갖고 있기 때문에 UTF-16LE에 대한 V8의 TextDecoder 가 다른 엔진보다 훨씬 느리다는 것을 발견했습니다(SM은 정말 빠름). 따라서 String.fromCharCode 는 특정 손익분기점까지 V8에서 실제로 더 빠릅니다. 그래서 우리는 지금 그것을 중심으로 최적화하기로 결정했습니다. 다음으로 WTF-16에는 TextDecoder 가 없으므로(별도의 성가신) 먼저 잘 구성된 UTF-16을 디코딩하려고 시도하고 실패하면 던지고 청크를 통해 폴백하도록 합니다. 훨씬 느린 String.fromCharCode . 스택 오버플로 가능성이 있으므로 긴 문자열에 String.fromCharCode 를 단순히 적용할 수 없기 때문에 청킹이 필요합니다.

다른 한편으로, 예를 들어 Rust는 이것을 필요로 하지 않을 것입니다. 이것이 제가 현재 IT가 마땅히 그래야 할 만큼 중립적이지 않다고 생각하는 이유 중 하나입니다. 일반적으로 IT string 의 요점은 여전히 ​​우리의 주요 interop 대상인 JS와 잘 인터페이스할 수 있다는 것입니다.

현재 IT에 정의된 API를 사용하는 코드가 없으므로 동일한 이전 버전과의 호환성 요구 사항이 없습니다.

IT가 아직 존재하지 않기 때문에 전반부는 기술적으로 사실이지만 IIUC의 요구 사항에는 예를 들어 위의 서투른 글루 코드 덩어리를 설명하는 것과 같은 기존 사용 사례를 개선하는 것이 포함됩니다. 가능한 한 많은 언어에 대해 이상적으로는 MVP 이후는 프레젠테이션에서 말했듯이 실제로 "최적화"가 됩니다. 반대로, 지금 IT는 기본적으로 UTF-8 인코더/디코더를 사용할 수 있는 언어에 대해 이미 최적화된 것으로 시작합니다. 이는 중립적이지 않다고 생각합니다.

wasm 및 인터페이스 유형은 의도적으로 기존 단일 언어 또는 시스템 호출 ABI를 완벽하게 에뮬레이트하지 않습니다.

나는 이 의견에 동의하는 것처럼 이 글을 읽었으며, 전적으로 그렇지 않습니다. 나는 여기에서 의심의 여지가 있는 이점을 기꺼이 제공하지만 내 의견으로는 IT가 현재 불필요하게 제한되어 있으므로 매우 특정한 언어 집합만 잘 지원한다고 덧붙이고 싶습니다. 반대로 WTF-8/16은 JS 문자열로 왕복하기 때문에 논리적 기본값으로 예상했던 보다 포괄적인 인코딩입니다. 우리는 여기에 동의하지 않지만 적절한 탈출구가 없는 경우에만 가능합니다. 실행 가능한 무손실 대안이 존재하여 아무도 손상되거나 불필요하게 불이익을 받지 않는다면 기본 문자열 유형에 대한 귀하의 추론에 문제가 없을 것입니다.

대리자를 전달할 필요가 없으며 종종 의미가 없다고 믿을 만한 충분한 이유가 있습니다.

우리는 여기에 동의하지 않습니다. 특히, 제 발표와 논평은 드물긴 하지만 매우 의미 있는 일(예: 무결성이 요구되는 경우)일 수 있다는 합리적인 의심을 불러일으킬 수 있다고 생각합니다. 유니코드 위생을 개선하기를 희망하는 위험" 즉, 가능하다면 다음과 같은 중요한 경우에도 작동하도록 보장되는 방식으로 표준 ABI를 설계해야 한다고 생각합니다. Java/C#/AS<->JS, Java/C#/AS<-> 자바/C#/AS. 다른 경로로의 교체는 불가피할 수 있지만 최소한 언어와 사용자는 선택권이 있습니다. 드문 경우지만 기본값은 이미 깨지지 않았습니다.

나는 여전히 IT가 이러한 WTF-16 문자열 의미를 전달하지 않고는 실행 가능하지 않을 것이라는 증거가 없다고 생각합니다.

합리적인 의심이 있고 내가 합리적인 타협이라고 믿는 것을 탐구할 의지가 없는 상황에서 입증 책임은 이제 귀하에게 있다고 예상합니다. 다시 말하지만, 나는 기본 문자열을 여러분과 잘 구성된 미래에 기꺼이 맡길 용의가 있지만, 드물지만 여전히 위험할 수 있는 것을 설명하지 않는 희생을 감수하지 않습니다. 많은 대중적인 언어가 이것의 영향을 받을 수 있으며, 일단 깨닫고 나면 이를 정당화하기가 정말 어려울 수 있습니다.

JS 글루 코드가 이상적이지 않다는 점에는 동의하지만, 이에 대한 올바른 수정은 JS API 또는 JS에 있으며, 전체 미래 구성 요소 에코시스템에 wtf-16-string 개념을 추가하는 것이 아닙니다. 그 외에도 아직 응답하지 않은 응답에 대한 새로운 정보가 없습니다. 목표/범위에 대한 질문에 대부분 동의하지 않는 것 같습니다.

TextDecoder 이상 현상은 JS에서 수정하기가 훨씬 더 어려울 것으로 예상됩니다. 이미 이것이 범위를 벗어났다고 분명히 결정했기 때문입니다. JS의 TextDecoder 는 두 함수 호출 사이에 호출되는 것이 아니라 대부분 네트워크나 저장소에서 데이터를 검색하는 데 사용되기 때문에 JS는 그렇게 할 수 있습니다.

짝수 더 흥미로운 이상이 존재조차하지 않은, 그러나,이다 TextEncoder UTF-16LE을 위해, 그래서 하나가 관련이있다 :

/** Allocates a new string in the module's memory and returns its pointer. */
function __newString(str) {
  if (str == null) return 0;
  const length = str.length;
  const ptr = __new(length << 1, STRING_ID);
  const U16 = new Uint16Array(memory.buffer);
  for (var i = 0, p = ptr >>> 1; i < length; ++i) U16[p + i] = str.charCodeAt(i);
  return ptr;
}

보시다시피 이것은 Java, C#, AS 및 기타 항목에 대한 주요 문제점이며 list u16 가 전달될 때 이 두 가지 모두 여전히 필요합니다. 그리고 이 문제의 맥락에서 동일한 언어의 두 모듈 사이의 이중 재인코딩 + 손실이 그렇게 다르지 않다는 점에서 JS API에만 국한되지 않습니다.

TextEncoder / TextDecoder 외에도 웹에서 해당 사용 사례를 처리하는 방법에 대한 전체 옵션 공간이 있습니다. 다른 하나는 new WebAssembly.Function() (일부 브라우저에서 이미 구현됨)를 확장하여 생성자에 추가 선택적 매개변수를 추가하여 문자열 변환을 수행하는 것입니다. 이러한 접근 방식은 또한 wasm의 비구성 요소 사용에서도 기능을 사용할 수 있게 하여(잠재적으로 훨씬 더 빨리) JS API가 이 사용 사례를 처리하기에 적합한 장소라는 점을 강화합니다.

참고: 위의 제안 목록 에 https://github.com/WebAssembly/interface-types/issues/135#issuecomment -863493832에 나온 "통합 W/UTF-any" 옵션을 추가했습니다. :)