UTF-8에 대한 인수: 매우 간단합니다. JavaScript의 인코더 및 디코더 . 다시 말하지만, UTF-8은 유니코드가 아닙니다 .

UTF-8에 대한 주장: 길이 + 바이트보다 약간 더 복잡하여 잠재적인 구현 차이로 이어집니다.

다시 말하지만 UTF-8은 유니코드가 아닙니다.

무슨 말을 하는 겁니까? 이것은 말도 안되는 문장입니다.

나는 당신이 국제화 라이브러리에 풀 필요가 없다는 것을 말하려고하는 것 같아요. 이것은 사실입니다. 문자열이 UTF-8로 인코딩되어야 한다는 것은 정규화와 같은 유니코드의 더 복잡한 부분과 아무 관련이 없습니다. 이는 인간과 인터페이스하는 문자열 작업을 수행할 때 유용한 도구이지만 삼각 라이브러리가 수학을 하는 사람들에게 유용하고 정수를 인코딩하는 방법을 결정할 때는 관련이 없는 것과 같은 방식입니다.

그러나 UTF-8은 말 그대로 유니코드 인코딩입니다. 당신의 진술은 쓰여진 대로 무의미합니다. ^_^

그러나 UTF-8은 말 그대로 유니코드 인코딩입니다. 당신의 진술은 쓰여진 대로 무의미합니다. ^_^

예, 저는 특히 UTF-8이 설명하는 코드포인트 인코딩을 언급하는 것이지 적절한 코드포인트 처리가 아닙니다(이 제안의 목적을 위해 코드포인트는 불투명한 정수입니다). wasm-isms에 넣으면 UTF-8은 var[u]int와 비슷하지만 문자에 더 적합합니다. 또한 UTF-8은 유일한 유니코드 인코딩이 아니며 유니코드가 아닌 정수를 인코딩하는 데 사용할 수 있습니다. 따라서 UTF-8은 유니코드가 아닙니다.

추가 제안은 개별 코드포인트를 살펴보고 이를 사용하는 것입니다. 이것은 그 제안이 아닙니다.

그리고 그럴 이유가 없었을 것입니다. 말 그대로 i18n API가 아닌 이상 엄격한 평등 비교 및 ​​정렬을 넘어 코드 포인트에 대한 자체 검사의 필요성을 발견한 Web API는 없습니다.

또 다른 옵션은 각 코드 포인트에 대한 바이트 길이 + UTF-8입니다( @jfbastien 이 각 바이트에 대해 UTF-8이라고 말했을 때 의미한 것이 아닌 한, 저에게 이해가 되지 않는다는 것을 인정합니다). 정교한 유니코드 라이브러리가 바이트 배열, 오프셋 및 길이를 입력으로 받아 문자열을 반환할 수 있도록 허용하면서 실제로 신경 쓰지 않는 원시 파서의 경우 이것이 더 어렵게 만들지 않을 것이라고 생각합니다.

정수인 "UTF-8 코드 포인트"라는 정의에 동의합니다. 바이너리 사양은 그대로 두어야 합니다. 개별 임베더는 허용된 코드 포인트, 정규화 및 기타 뉘앙스에 대한 규칙을 정의할 수 있습니다. 분석 도구는 잠재적인 호환성 문제에 대한 경고를 제공할 수 있습니다.

오류 처리 결정도 임베더에게 맡겨야 한다고 생각합니다. 이름이 아닌 인덱스로 WASM 함수에 액세스하는 시스템은 유효할 필요가 없습니다(바이트 길이 접두사로 건너뛰기 쉽습니다).

다음은 근본적인 문제와 그 이유를 요약하려는 시도입니다. 수정 및 추가를 가장 환영합니다.

wasm 필수 모듈 가져오기/내보내기 식별자가 유효한 UTF-8이어야 합니까?

반대 이유에 대한 나의 이해는 다음과 같습니다.

• 가져오기 및 내보내기 처리는 응용 프로그램 시작의 중요한 경로에 있으며 속도를 늦출 수 있는 모든 것을 피하려는 욕구가 있습니다.
• 광범위한 불변 "핵심 wasm 사양은 문자열을 해석하지 않습니다". 문자열 해석은 일반적으로 복잡하고 그것을 캡슐화하고 높은 수준에서 추론할 수 있는 넓은 불변성과 경계를 갖고자 하는 욕구가 있습니다.
• WebAssembly 디코더는 보안에 민감한 경우가 많으므로 관련된 코드의 양을 최소화하려는 일반적인 욕구가 있습니다.
• 일부 WebAssembly 생산자는 이러한 식별자에 임의의 데이터를 포함하기를 원할 수 있으며, 문자열 형식으로 맹글링하는 대신 원하는 대로 데이터를 인코딩하는 것이 더 편리합니다.

was는 UTF-8을 필요로 하지 않는 영역에서 UTF-8을 권장해야 합니까?

그 이유는 우리가 그것을 요구할 수 없더라도 UTF-8을 언급하면 ​​생태계 간의 불필요한 비호환성을 막을 수 있기 때문입니다.

반대 이유에 대한 나의 이해는 UTF-8을 언급하는 것조차 문자열 해석 문제의 개념적 캡슐화를 손상시킬 수 있다는 것입니다.

was는 이름 섹션 이름에 UTF-8을 지정해야 합니까?

그 이유는 다음과 같습니다. 이러한 이름의 전체 목적은 표시를 위해 문자열로 변환하는 것인데 인코딩 없이는 불가능하므로 도구가 추측할 필요가 없도록 UTF-8을 지정해야 합니다.

반대 이유에 대한 내 이해는 다음과 같습니다. wasm이 지정된 인코딩이 없는 다른 영역에 다른 문자열과 유사한 항목이 있는 경우(즉, 위에서 논의한 것처럼 가져오기/내보내기) 일관성을 위해 문자열에 대한 인코딩을 지정해서는 안 됩니다. .

@sunfishcode 는 좋은 요약을 제공하지만 세 가지 중요한 사항을 추가하고 싶습니다.

@jfbastien , 문자열에 대해 바이너리 _syntax_(인코딩)를 제한하지만 _semantics_(문자 집합)를 제한하지 않는 것은 모든 대안 중에서 가장 무의미합니다. 따라서 모든 실용적인 목적을 위해 UTF-8은 유니코드를 의미합니다. 그리고 다시 말하지만 이것은 엔진에 관한 것만이 아닙니다. 이름을 유니코드로 정의하면 모든 환경의 모든 Wasm 에코 시스템에서 강제로 적용됩니다. 그리고 이는 거의 모든 환경에 약간의 유니코드 지원이 필요하다는 것을 의미합니다.

@tabatkins , 귀하의 주장에 기본 도메인 오류가 있다고 생각합니다. 우리가 말하는 문자열은 _user-facing_이 아닙니다. 그들은 _dev-facing_ 이름입니다. 많은/대부분의 프로그래밍 언어는 유니코드 식별자를 지원하지 않으며 도구도 지원하지 않습니다. 예를 들어 gdb가 유니코드 소스 식별자를 처리할 수 있습니까? 나는 그렇게 생각하지 않는다. 따라서 모든 소비자가 _이 공간에서_ 유니코드로 수렴했다고 가정하는 것은 매우 낙관적(또는 오히려 비현실적)입니다.

그리고 마지막으로, 의견 불일치는 웹상의 Wasm이 UTF-8을 가정해야 하는지 _여부_가 아니라 _어디서_ 우리가 지정하는지입니다.

나는 당신의 주장의 기초가 되는 도메인 오류가 있다고 생각합니다. 우리가 말하는 어떤 문자열도 사용자에게 표시되지 않습니다. 개발자용 이름입니다. 많은/대부분의 프로그래밍 언어는 유니코드 식별자를 지원하지 않으며 도구도 지원하지 않습니다. 예를 들어 gdb가 유니코드 소스 식별자를 처리할 수 있습니까? 나는 그렇게 생각하지 않는다. 따라서 모든 소비자가 이 공간에서 유니코드로 수렴했다고 가정하는 것은 매우 낙관적(또는 오히려 비현실적)입니다.

"dev-facing"은 "임의의 toolchain-facing"을 의미하며, 이는 사전에 인코딩에 동의해야 함을 의미합니다. 그렇지 않으면 도구가 인코딩 "탐지"(즉, 추측, 특히 짧은 값에 적용됨) 또는 대역 외 정보가 있습니다. 개발자는 여전히 사용자입니다. ^_^

많은 도구 체인이 유니코드를 이해하지 못할 것이라고 생각한다면 다른 임의의 바이너리 인코딩을 이해한다고 생각하는 이유가 확실하지 않습니다. 그것이 당신의 한계라면 어디에서나 100% 지원되는 ASCII를 지정하고 요구하십시오. ASCII로 제한하고 싶지 않다면 ASCII가 아닌 단일 인코딩 체계인 UTF-8이 허용된다는 사실을 인정해야 합니다.

"어, 대부분의 것이 ASCII만 지원하지만 만일을 대비 하여 개발자가 원하는 것은 무엇이든 넣을 수 있도록 하겠습니다"라고 말하는 것이 두 세계 모두에서 최악입니다.

"어, 대부분의 것이 ASCII만 지원하지만 만일을 대비하여 개발자가 원하는 것은 무엇이든 넣을 수 있도록 하겠습니다"라고 말하는 것은 두 세계 모두에서 최악입니다.

@tabatkins , 아무도 위의 것을 제안하지

선택의 여지가 없습니다, tho! 임베딩 환경이 비 ASCII를 지원 하지 않는 경우 문자열에 비 ASCII를 사용하지 마십시오 . (이 경우에도 인코딩 보증이 필요합니다. 예를 들어 UTF-16은 ASCII와 호환되지 않습니다!)

환경이 비 ASCII를 지원하는 경우 사용할 인코딩을 알아야 하며 모든 상황에서 올바른 선택은 UTF-8입니다.

문자열의 인코딩을 모르는 것이 어떤 이점이 있는지 상상하는 환경은 무엇입니까?

문자열에 대한 의미론(문자 집합)이 아닌 이진 구문(인코딩)을 제한하는 것은 모든 대안 중에서 가장 무의미합니다. 따라서 모든 실용적인 목적을 위해 UTF-8은 유니코드를 의미합니다.

아니요, 절대 아닙니다. 예를 들어, 동시에 (a) 문자열을 ASCII 문자로 제한하고 (b) UTF-8로 인코딩하도록 지정하는 것이 매우 합리적입니다. ASCII 문자를 사용하는 것은 인코딩을 의미하지 않으며, 그렇지 않으면 모든 인코딩이 ASCII와 호환됩니다! (예를 들어 UTF-16은 그렇지 않습니다.) 따라서 여전히 무언가를 지정해야 합니다. "ASCII 호환"인 UTF-8은 이에 적합합니다.

다시 말하지만, 이러한 이름을 ASCII 전용으로 제한해도 괜찮다면 인코딩을 US-ASCII로 지정하는 것이 합리적입니다. ASCII를 넘어서는 것이 가능하려면 인코딩을 UTF-8로 지정하는 것이 합리적입니다. 다른 것을 요구하거나 전혀 요구하지 않는 것(그리고 모든 소비자가 대역 외 정보를 추측하거나 사용하도록 강요하는 것)는 유일한 불합리한 가능성입니다.

그리고 다시 말하지만 이것은 엔진에 관한 것만이 아닙니다. 이름을 유니코드로 정의하면 모든 환경의 모든 Wasm 에코 시스템에서 강제로 적용됩니다. 그리고 이는 거의 모든 환경에 약간의 유니코드 지원이 필요하다는 것을 의미합니다.

다시 말하지만 이것은 국제화 라이브러리에 대해 말하는 것 같습니다. 우리가 논의하고 있는 것은 바이트 시퀀스를 다시 문자열로 디코딩하는 방법입니다. 매우 사소하고 매우 빠른 UTF-8을 디코딩하는 방법에 대한 지식만 있으면 됩니다.

인간 친화적인 문자열 조작을 수행하지 않는 한 코드 포인트별로 문자열을 비교하고 코드 포인트별로 문자열을 정렬하는 기능만 있으면 됩니다. 둘 다 "유니코드 지원"이 필요하지 않습니다. 예를 들어 이것이 기존 웹 기술이 사용하는 전부이며 Wasm 환경에서 일반적으로 이보다 더 복잡한 작업을 수행해야 할 이유가 없습니다.

저는 모든 문자열에 utf8을 의무화하는 것에 찬성합니다. 순수한 utf8 디코딩/인코딩은 웹이 아닌 환경에서 (다른 모든 것에 비해) 매우 낮은 impl 부담으로 보입니다. 또한 내가 본 바에 따르면 가져오기/이름에 대해 utf8을 검증하는 데 소요된 시간은 다른 모든 것에 소요된 시간에 비해 중요하지 않으므로 여기에 성능 논쟁이 있다고 생각하지 않습니다.

실질적으로 우리가 핵심 wasm 사양에 UTF8 강제하지 않았더라도, 말하기, 당신은 당신이 총 섬 아니라면 사용자 정의 툴 체인도 UTF8을 사용하지 않은 경우에 나쁜 시간은 무엇과 상호 거라고 그리고 아마 당신은 말한다 "나사"하고 어쨌든 자신의 비 utf8 작업을 수행하십시오.

내가 realllly 같이 할 것입니다 무엇을하지만, 이것에 차단하는 것 해결 # 984입니다 ...

@lukewagner 나는 #984가 이것에 대해 차단되었다고 생각하지 않습니다. 😄

난 당신이 옳은 것 같아요.

문자열의 인코딩을 모르는 것이 어떤 이점이 있는지 상상하는 환경은 무엇입니까?

@tabatkins , 아직 충분히 명확하지 않은 것 같습니다. 나는 그런 환경을 상상하지 않는다. 그러나 호환되지 않는 요구 사항이 있는 광범위한 환경을 상상합니다. 모든 것이 UTF-8의 하위 집합은 아닙니다. 예를 들어 Latin1은 여전히 ​​널리 사용됩니다. 당신은 신경 쓰지 않을 수도 있지만, 환경 다양성을 방해하는 불필요한 돌을 넣는 것은 핵심 Wasm 스펙의 일이 아닙니다.

전체 섬이 아닌 한 사용자 정의 도구 모음이 utf8도 사용하지 않으면 무엇과도 상호 운용하는 데 나쁜 시간이 걸릴 것입니다.

@lukewagner , 저는 실제로 Wasm이 잠재적으로 거의 겹치지 않는 다양한 "대륙"에서 사용될 것으로 기대합니다. 그리고 그들이하는 곳에서 interop을 지정할 수 있습니다 (실제로 이름 인코딩은 다른 플랫폼간에 모듈을 공유하는 데 가장 적은 문제가 될 것입니다. 호스트 라이브러리입니다). 전체 섬조차도 비현실적이지 않습니다. 특히 wrt 임베디드 시스템(유니코드를 거의 사용하지 않는 경향이 있음)이 그렇습니다.

비 브라우저 기반 WebAssembly 엔진을 구현하는 데 있어 가장 어려운 부분 중 하나는 브라우저(주로 JS 부분)에서 하는 방식대로 작동하도록 만드는 것입니다. 인코딩이 표준화되지 않으면 모든 사람이 웹 대상에 대해 수행된 작업을 복사하는 사실상의 표준이 될 것으로 예상합니다. 이렇게 하면 이러한 문자열을 디코딩하는 방법에 대한 정보를 찾기가 더 어려워집니다.

일부 환경에서 허용된 콘텐츠를 추가로 제한하는 데 가치가 있을 수 있지만 UTF-8을 요구하지 않으면 더 어려워집니다.

@MI3Guy , 반대 제안은 JS API의 일부로 UTF-8 인코딩을 지정하는 것입니다. 따라서 JS 임베딩을 구축하는 경우 어느 쪽이든 UTF-8로 정의되며 아무런 차이가 없습니다. (그러나 우리는 웹도 JavaScript도 아닌 다른 임베더 API도 허용하고자 합니다.)

오른쪽. 요점은 JS 임베딩을 수행하지 않는 경우 WebAssembly 도구 체인을 사용하기 위해 JS 임베더가 수행하는 많은 작업을 에뮬레이트해야 한다는 것입니다.

코드 포인트 수에 대해 varuint + 각 코드 포인트에 대해 UTF-8을 수행하십시오.

저는 이 옵션에 대해 반대 의견을 말하고 싶습니다. 이는 상황을 복잡하게 만들고 사용자별 섹션에 적용하지 않으며 적용할 수 없으며 내가 볼 수 있는 이점도 제공하지 않습니다. UTF-8 문자열의 코드 포인트 수를 알기 위해 실제로는 항상 문자열을 스캔하게 됩니다. 잘못된 인코딩이므로 코드 포인트를 계산할 수도 있습니다.

모든 것이 UTF-8의 하위 집합은 아닙니다. 예를 들어 Latin1은 여전히 ​​널리 사용됩니다. 당신은 신경 쓰지 않을 수도 있지만, 환경 다양성을 방해하는 불필요한 돌을 넣는 것은 핵심 Wasm 스펙의 일이 아닙니다.

옳은; UTF-8은 ASCII 범위를 벗어나면 거의 모든 인코딩과 다릅니다. 나는 당신의 요점이 무엇인지 잘 모르겠습니다. 실제로 Latin-1 인코딩을 사용 하는 것은 똑같아 보이지만 다른 문자를 인코딩하는 다른 인코딩이 많이 있기 때문에 정확하게 좋지 않습니다. Wasm 코드에서 "æther"라는 이름을 사용하려고 시도하고 이를 Latin-1로 인코딩하면 다른 사람이 (당당하게) UTF-8 툴체인으로 이름을 읽으려고 하면 디코딩 오류가 발생합니다. 또는 다른 사람이 비슷한 실수를 했지만 대신 Windows-1250 인코딩(중부/동부 유럽 언어용)을 사용했을 수 있습니다. 그들은 "ćther"라는 말도 안되는 단어를 얻게 됩니다.

여기서 보호하려는 "다양성"이 어떤 것인지 잘 모르겠습니다. 말 그대로 다른 인코딩을 사용하면 아무런 이점이 없으며 수많은 단점이 있습니다. 다른 인코딩으로 인코딩할 수 있는 모든 문자는 유니코드로 존재하며 UTF-8로 인코딩할 수 있지만 그 반대는 거의 사실이 아닙니다. 오늘날 UTF-8을 처리할 수 없는 관련 도구는 없습니다. 이 기술은 말 그대로 20년이 되었습니다 .

나는 웹 표준이 몇 년 전에 이 문제를 해결했다고 계속 말하고 있습니다. Wasm이 웹 규칙을 따라야 하는 웹 사양이기 때문이 아니라 텍스트 인코딩이 거의 모든 사람이 동일한 문제를 갖고 있고 웹이 이미 처리한 생태계 문제이기 때문입니다. 이를 잘못 이해하는 고통을 겪고 올바르게 수행하는 방법을 배웠습니다. Wasm에서 다시 틀리게 하는 것은 미덕이 아닙니다. 텍스트를 인코딩해야 하는 모든 환경은 처음부터 UTF-8로 바로 이동하거나 다른 모든 사람들이 겪는 동일한 실수와 고통을 겪고 결국 UTF-8로 정착합니다. (또는 드물게 다른 인코딩으로 표준화할 수 있을 정도로 충분히 고립된 환경을 개발하고 외부 환경과 통신하는 대가를 거의 지불하지 않습니다. 그러나 인코딩으로 표준화 하는 것이 이 모든 것입니다.)

따라서 JS 임베딩을 구축하는 경우 어느 쪽이든 UTF-8로 정의되며 아무런 차이가 없습니다. (그러나 우리는 웹도 JavaScript도 아닌 다른 임베더 API도 허용하고자 합니다.)

이 문제는 웹 또는 JS와 관련이 없습니다. 생태계의 모든 부분은 알려진 일관된 텍스트 인코딩을 원하며 프로그래밍 환경, 국가 및 언어 전반에 걸쳐 널리 동의되는 단일 인코딩인 UTF-8이 있습니다.

나는 '길이(바이트 단위) + UTF-8 각 바이트에 대한 varuint 수행'에 투표합니다. 그것이 논쟁의 여지가 없는 선택이 아니라고 가정하면 - 거의 모든 문자열 구현은 "코드 포인트 수"가 아닌 "코드 단위 수"로 문자열을 저장합니다. 왜냐하면 더 간단하기 때문입니다. 그러면 실제 질문은 "문자열이 아닌 경우 유효성 검사에 실패해야 합니다"가 아닙니다. 유효한 UTF-8"?

#970에서 지적했듯이 유효하지 않은 UTF-8은 UTF-16

전반적으로 UTF-8을 의무화하자고 말하고 싶습니다. 누군가가 UTF-8로 변환할 수 없는 바이트를 가지고 있는 이상한 경우(아마도 인코딩을 알 수 없기 때문에), 임의의 바이트를 UTF-8로 음역할 수 있습니다.

여기서 보호하려는 "다양성"이 어떤 것인지 잘 모르겠습니다.

@tabatkins 네, 그게 오해의 핵심인 것 같습니다.

WebAssembly는 이름에도 불구하고 웹에만 국한되지 않는다는 점을 인식하는 것이 중요합니다. 각 레이어가 가능한 한 널리 사용되도록 적절한 레이어로 정의하는 것은 매우 신중합니다.

특히 _core_는 실제로 웹 기술이 _전혀_ 아닙니다. 대신 _가상 ISA _로 생각하십시오. 이러한 추상화는 매우 풍부한(웹)에서 매우 기초적인(임베디드 시스템)에 이르기까지 다양한 환경에서 유용하며 서로 관련이 없고 대체로 호환되지 않으며 충돌하는 제약 조건이 있습니다( Wasm은 변경할 위치에 없음).

따라서 C 프로그래밍 언어의 모든 문자열 리터럴에 유니코드를 적용하는 것보다 _core_ Wasm에 유니코드를 적용하는 것은 더 이상 의미가 없습니다. 일부 잠재 고객에게 이 표준을 위반하도록 강요할 뿐입니다. 이득은 무엇입니까?

그러나 _concrete_ 환경(예: JavaScript)에서 임베딩 및 API를 정의하는 이 핵심 사양 위에 추가 사양 레이어가 있을 것입니다. 그 수준에서 문자열 인코딩을 수정하는 것은 완벽하게 이해가 되며, 반드시 그렇게 해야 합니다.

추신: Wasm의 범위를 정의하는 슬로건은 공통 프로그래밍 언어에 대한 추상화가 아니라 공통 하드웨어에 대한 추상화라는 것입니다. 그리고 하드웨어는 문자열 인코딩과 같은 소프트웨어 문제에 불가지론적입니다. 그것이 바로 ABI의 목적입니다.

@rossberg-chromium

따라서 C 프로그래밍 언어의 모든 문자열 리터럴에 유니코드를 적용하는 것보다 코어 Wasm에 유니코드를 적용하는 것은 더 이상 의미가 없습니다. 일부 잠재 고객에게 이 표준을 위반하도록 강요할 뿐입니다. 이득은 무엇입니까?

100% 동의합니다. 이 문제는 유니코드에 관한 것이 아니라 정수를 유니코드로 해석하지 않아도 되는 정수 인코딩인 UTF-8에 관한 것입니다.

나는 우리가 그것에 동의하는지 이해할 수 없습니다. UTF-8을 사용할 수 있습니까? 그렇지 않다면 그 이유는 무엇입니까?

@jfbastien , 모든 C 문자열 리터럴에 UTF-8 준수를 요구하는 것이 더 생산적입니까?

앞서 언급했듯이 인코딩은 제한하지만 문자 집합은 제한하는 것은 의미가 없습니다. 의미 없이 구문을 정의하는 것과 같습니다. 왜 그럴까요? 상호 운용성 측면에서 0을 얻지만 UTF-8을 사용하지 않는 환경(어쨌든 유니코드 환경에서만 사용)에 대해서는 여전히 인위적인 장애물을 세웁니다.

@jfbastien , 모든 C 문자열 리터럴에 UTF-8 준수를 요구하는 것이 더 생산적입니까?

이해가 안되는데 설명해주실수있나요?

앞서 언급했듯이 인코딩은 제한하지만 문자 집합은 제한하는 것은 의미가 없습니다. 의미 없이 구문을 정의하는 것과 같습니다. 왜 그럴까요? 상호 운용성 측면에서 0을 얻지만 UTF-8을 사용하지 않는 환경(어쨌든 유니코드 환경에서만 사용)에 대해서는 여전히 인위적인 장애물을 세웁니다.

토론의 핵심이라고 생각합니다.

@tabatkins 는 정확히 이것에 대한 선례를 다루었습니다.

다시 말하지만 이것은 국제화 라이브러리에 대해 말하는 것 같습니다. 우리가 논의하고 있는 것은 바이트 시퀀스를 다시 문자열로 디코딩하는 방법입니다. 매우 사소하고 매우 빠른 UTF-8을 디코딩하는 방법에 대한 지식만 있으면 됩니다.

인간 친화적인 문자열 조작을 수행하지 않는 한 코드 포인트별로 문자열을 비교하고 코드 포인트별로 문자열을 정렬하는 기능만 있으면 됩니다. 둘 다 "유니코드 지원"이 필요하지 않습니다. 예를 들어 이것이 기존 웹 기술이 사용하는 전부이며 Wasm 환경에서 일반적으로 이보다 더 복잡한 작업을 수행해야 할 이유가 없습니다.

그래서 동의합니다. 이 제안은 귀하의 말로 "의미 없는 구문 정의"입니다. 아주 흔한 일입니다. 사실, WebAssembly의 현재 길이 + 바이트 사양은 이미 이것을 하고 있습니다!

장애물이 무엇인지 이해하고 싶습니다. 난 정말 하나를 볼 수 없습니다.

WebAssembly는 이름에도 불구하고 웹에만 국한되지 않는다는 점을 인식하는 것이 중요합니다.

나는 이것이 웹과 아무 관련이 없다고 바로 앞의 논평에서 언급했습니다. 당신은 이 주장을 계속 사용하려고 하고, 그것은 나를 정말 혼란스럽게 합니다. 내가 말하는 것은 웹과 아무 관련이 없습니다. 나는 배운 교훈의 중요한 예로서 웹의 경험을 지적하고 있을 뿐입니다.

따라서 C 프로그래밍 언어의 모든 문자열 리터럴에 유니코드를 적용하는 것보다 코어 Wasm에 유니코드를 적용하는 것은 더 이상 의미가 없습니다. 일부 잠재 고객에게 이 표준을 위반하도록 강요할 뿐입니다. 이득은 무엇입니까?

문자열 리터럴이 ASCII 인코딩을 사용하기 때문에 C 에는 내장 인코딩이 있습니다. (다른 것을 원하면 적절한 바이트 시퀀스를 이스케이프하여 직접 수행해야 합니다.) 최신 C++에서는 UTF-16 및 UTF-8 문자열 리터럴을 사용할 수 있으며 여전히 임의의 바이트를 다음을 사용하여 문자열에 넣을 수 있습니다. \x 이스케이프, \u 이스케이프 적어도 값이 유효한 코드 포인트인지 확인하십시오.

문자에서 바이트로의 고유한 매핑이 없기 때문에 이 모든 것이 필요 이 하는 일 입니다. 다시 말하지만, 지정된 인코딩이 없다는 것은 언어 사용자가 다른 당사자로부터 바이트 시퀀스를 수신할 때 인코딩을 추측하여 텍스트로 되돌려야 한다는 것을 의미합니다.

상호 운용성 측면에서 0을 얻지만 UTF-8을 사용하지 않는 환경(어쨌든 유니코드 환경에서만 사용)에 대해서는 여전히 인위적인 장애물을 세웁니다.

당신이 사용하는 문자는 유니 코드에 포함되지 않는 것을 존재하는 환경에 점을 기쁘게 할 수 있습니까? 당신은 이론적인 순수성/환경 다양성 관점에서 이 입장을 방어하려고 계속 노력하고 있지만, 말 그대로 유니코드의 요점은 모든 문자 를 포함

어떤 다양성을 보호하려고 합니까? 하나의 예라도 보는 것이 좋을 것입니다. :/

@tabatkins :

WebAssembly는 이름에도 불구하고
웹으로 제한됩니다.

나는 이것이 아무것도 없다고 바로 앞의 코멘트에서 언급했습니다.
웹으로 할 수 있습니다. 당신은 이 주장을 계속 사용하려고 하고, 그것은 정말
나를 혼란스럽게 한다. 내가 말하는 것은 웹과 아무 관련이 없습니다. 나는 단지
배운 교훈의 중요한 예로서 웹의 경험을 지적합니다.

내가 강조하려고 하는 것은 Wasn이
가능한 한 현대적이든 아니든 플랫폼. 넌 해피엔딩부터 계속 말다툼을 해
모든 것이 유니코드 및/또는 UTF-8이고 모든 것이
else는 더 이상 사용되지 않습니다.

당신은 당신이 생각하는 요점을 만들고 있지 않습니다 - C

문자열 리터럴이 ASCII 인코딩을 사용하기 때문에 내장 인코딩. (네가 원한다면
다른 모든 것은 적절한 바이트를 이스케이프하여 손으로 수행해야 합니다.
시퀀스.) 최신 C++에서는 UTF-16 및 UTF-8 문자열을 사용할 수 있습니다.
리터럴, 그리고 여전히 임의의 바이트를 문자열에 넣을 수 있지만
\x 이스케이프, \u 이스케이프 적어도 값이 유효한지 확인하십시오
코드 포인트.

아니요, 그것은 잘못된 것입니다. C 사양에는 ASCII가 필요하지 않습니다. 하지도 않는다
ASCII와의 호환성이 필요합니다. 거의 임의의 "소스
문자 집합" 및 문자열 리터럴은 전체의 모든 문자를 포함할 수 있습니다.
세트. 인코딩에 관한 제약은 없으며 전적으로
구현 정의. C에서 실행되는 구현이 있습니다.
EBCDIC 플랫폼이며 현재 표준에서 여전히 지원됩니다. GCC
모든 iconv 인코딩으로 소스를 처리할 수 있습니다(이 중 약 140
UTF-8 외에), 예를 들어 아시아에서 인기 있는 UTF-16입니다. C++도 다르지 않습니다.

(그것은 @jfbastien 의 질문에도 대답해야 합니다.)

고유한 매핑이 없기 때문에 이 모든 것이 필요합니다.문자를 바이트로 . 그것이 인코딩 이 하는 일 입니다. 다시 말하지만, 가지고 있지 않은
지정된 인코딩은 언어 사용자가 수신할 때
다른 당사자의 바이트 시퀀스는 인코딩을 추측해야
그것들을 다시 텍스트로 만듭니다.

다시 말하지만 이 _will_은 환경별로 적절하게 지정됩니다. 때 누군가
동일한 생태계에서 작동하는 다른 누군가로부터 Wasm 모듈을 받습니다.
그러면 문제가 없습니다. 어떤 JS 개발자도 신경 쓸 필요가 없습니다.

그러나 누군가 _다른 생태계_에서 모듈을 수신하는 경우
걱정할 비호환성의 다른 원인이 많이 있습니다. 예를 들어
API, 내장 라이브러리 등에 대한 기대치. 양 당사자는 다음을 수행해야 합니다.
어쨌든 상호 운용성 가정에 대해 명시해야 합니다. 이름에 동의
인코딩은 가장 작은 문제가 될 것입니다.

상호 운용성 측면에서 0을 얻지만 여전히

UTF-8을 사용하지 않는 환경(유니코드 환경에서만
그래도).

사용하는 환경을 지적해 주 시겠습니까?
유니코드에 포함되지 않은 문자? 당신은 이것을 방어하려고 계속
이론적 순도/환경다양성 관점에서 입장을 취하지만,
말 그대로 유니코드의 요점은 모든문자 . 원격으로 만들 수 있는 유일한 문자 집합입니다.
그렇게 하기 위한 신뢰할 수 있는 주장과 유니코드 문자를 사용할 때
설정하면 UTF-8이 선호되는 범용 인코딩입니다.

어떤 다양성을 보호하려고 합니까? 보기에도 좋을 것이다.
하나의 예. :/

예를 들어 임베디드 OS 목록은 다음과 같습니다. https://en.wikipedia.org/wiki/
범주:Embedded_operating_systems
그들 중 일부는 아마도 UTF-8을 사용하고 일부는 사용하지 않을 것입니다. 일부는 Wasm의 용도를 찾을 수 있습니다.
대부분은 그렇지 않을 것입니다. 그러나 그것을 덜 만드는 것은 우리에게 아무런 이점이 없습니다.
그들에게 편리합니다.

그 목록에서 아직 익숙하지 않은 항목 중 하나는 DOS입니다. 같이
우리 모두가 죽는 것을 좋아하지만 DOS 시스템은 여전히 ​​활발하며 사용합니다.
OEM.

@jfbastien :

그래서 동의합니다. 이 제안은 귀하의 말로 "구문을 정의하지 않고
의미론". 이는 매우 일반적인 일입니다. 실제로 WebAssembly의
현재 길이 + 바이트 사양은 이미 이 작업을 수행합니다!

내가 모두 알고 있는 그런 일의 드문 경우는
구현별 동작을 위한 탈출구를 제공합니다. 그건
또한 유일한 합리적인 사용 사례입니다. 하지만 여기서는 의미가 없습니다. 만약 너라면
문자열에 대한 이러한 탈출 해치를 제공하려는 경우 왜 귀찮게 요구합니까?
UTF-8, 바이트 문자열 "구문"을 허용하는 대신? 없는 구문입니다.
인에이블러가 아닌 디스에이블러로서의 의미.

장애물이 무엇인지 이해하고 싶습니다. 난 정말 하나를 볼 수 없습니다.
>
일부 클라이언트는 단순히 모든 바이트 값을 사용할 수 없지만
생태계에서 사용하지 않는 중복 UTF 인코딩. 그 모든
그들의 도구 체인에 있는 도구도 이에 대해 고민해야 합니다. 그것은 그
추가 오류 사례(범위 값을 벗어남)를 생성합니다.
그렇지 않으면 그들을 위해 존재합니다.

다른 방법으로 질문해 보겠습니다. (생태계에서) 이점은 무엇입니까?
난 정말 하나를 볼 수 없습니다.

@tabatkins
구분선이 어디에 있는지 이해하고 싶습니다.
명확하게 하기 위해 조합에서 유효하지 않은지 여부에 관계없이 코드 포인트의 utf-8 인코딩만 제안하고 있습니다(10줄의 코드로 수행할 수 있음).
예를 들어 굵게 표시된 대문자는 다음을 나타내기 위해 사양에서 사용될 수 있습니다. Wasm을 구현하기 위해 국제화 라이브러리가 필요하다고 생각한다면 뭔가 잘못하고 있는 것입니까?

목표는 다음과 같습니다.

• 웹에서 끝나는 유효한 wasm이 유효하지 않은 항목에 대해 최소한 두부 문자를 표시할 수 있는지 확인하십시오.
• wasm을 생성하는 도구(웹 외부의 컨텍스트에서도)가 ASCII를 넘어서야 할 때 다른 인코딩보다 유니코드를 선호하도록 권장합니다. (전체 유효성 검사가 발생하지 않으므로 이 방향으로의 부드러운 충돌).

질문?

• 이것이 더 많은 검증에 대한 요구 사항이 될 위험이 있습니까? 이 분야에서 저의 핵심 관심사는 ICU를 의존성으로 삼키는 것이 항상 불합리한 부담이 될 것이라는 것입니다.

• 이것이 UTF-8과 충돌하는 Latin1과 같은 인코딩을 적극적으로 장려하는 목표를 의미한다고 가정합니다. 즉, 그것을 방출하는 툴체인은 비준수일 것이고 유사하게 받아들이는 구현이 될 것입니다.

• 나는 웹이 역사적으로 이전에 섬을 인코딩하던 영역의 비트를 겹치게 사용하기 때문에 이 공간을 통합하는 데 어려움을 겪었습니다. 반면에 내 인상은 UTF-8이 전환 비용이 ASCII가 아닌 사람들에 의해 불균형적으로 발생하고 일부 지역에는 더 많은 베이크인이 있다는 것과 같은 것을 설정한다는 것입니다. 유니코드 전환은 실용적인 필연이라고 생각합니다. (그리고 거의 완료). 유니코드와 관련된 일부 정치적 및 지역적 문제가 웹에서 해결된 방법을 설명하는 중앙 집중식 문서/엔티티가 있습니까?

@rossberg-chromium

• 인코딩의 일부 측면은 검증하지만 다른 측면은 검증할 때 논리적 불일치가 있습니다. 반면에 내 인상은 utf8이 이 시점에서 널리 퍼져 있다는 것입니다. 사양 불일치 또는 다른 것에 베어 utf-8 유효성 검사를 추가하는 것이 가장 불편합니까?

명확하게 하기 위해 조합에서 유효하지 않은지 여부에 관계없이 코드 포인트의 utf-8 인코딩만 제안하고 있습니다(10줄의 코드로 수행할 수 있음).

예, 잘못된 조합이 있다고 생각하지 않습니다. 기술적으로 UTF-8로 인코딩할 수 없는 일부 개별 코드포인트(UTF-16 대리용으로 예약된 코드포인트)가 있습니다. 즉, 전체 바이트 제어가 바람직하다면 WTF-8 인코딩 이 존재하지만 다음과 같은 경우 목표로 "예, 이 문자열이 때때로 문자열이 아닌 임의의 데이터를 실제로 포함하도록 허용하고 싶습니다"에 대해 매우 명시적이어야 합니다. 우리는 그쪽으로 간다. WTF-8(및 WTF-16) 형식은 UTF-* well-formedness를 시행하는 데 하위 호환성 제약이 있는 환경에 대한 공식 사양을 제공하기 위한 것입니다.

예를 들어 굵게 표시된 대문자는 다음을 나타내기 위해 사양에서 사용될 수 있습니다. Wasm을 구현하기 위해 국제화 라이브러리가 필요하다고 생각한다면 뭔가 잘못하고 있는 것입니까?

예, i18n은 어떤 방식, 모양 또는 형태로든 필요하지 않습니다. 예를 들어 CSS는 기본적으로 UTF-8을 사용하며 ASCII 범위를 벗어나는 것을 허용할 때 원시 코드포인트 비교/정렬을 수행합니다. Wasm이 이 이상으로 나아갈 이유도 없습니다.

이것이 더 많은 검증에 대한 요구 사항이 될 위험이 있습니까? 이 분야에서 저의 핵심 관심사는 ICU를 의존성으로 삼키는 것이 항상 불합리한 부담이 될 것이라는 것입니다.

웹 플랫폼은 지금까지 베어 이름에 추가 유효성 검사를 부과할 필요가 없었습니다. 내 경험에 따르면 결코 필요하지 않을 것입니다.

나는 이것이 UTF-8과 충돌하는 Latin1과 같은 인코딩을 적극적으로 [dis-ed]용기하는 목표를 의미한다고 가정합니다. 즉, 그것을 방출하는 툴체인은 비준수일 것이고 유사하게 받아들이는 구현이 될 것입니다.

예, 귀하의 단어에 "DIS couraging"로 변화. ^_^ 요점은 생산자와 소비자가 다른 끝점이 무엇을 하는지 추측할 필요 없이 바이트 시퀀스로/에서 문자열을 안정적으로 인코딩 및 디코딩할 수 있다는 것입니다. 이것은 이제까지 발생한 모든 환경에서 끔찍한 고통이었으며 현재 널리 채택된 솔루션이 있습니다.

나는 웹이 역사적으로 이전에 섬을 인코딩하던 영역의 비트를 겹치게 사용하기 때문에 이 공간을 통합하는 데 어려움을 겪었습니다. 반면에 내 인상은 UTF-8이 전환 비용이 ASCII가 아닌 사람들에 의해 불균형적으로 발생하고 일부 지역에는 더 많은 베이크인이 있다는 것과 같은 것을 설정한다는 것입니다. 유니코드 전환은 실용적인 필연이라고 생각합니다. (그리고 거의 완료). 유니코드와 관련된 일부 정치적 및 지역적 문제가 웹에서 해결된 방법을 설명하는 중앙 집중식 문서/엔티티가 있습니까?

예, 확실히 전환에 문제가 있었습니다. HTML은 여전히 ​​back-compat으로 인해 Latin-1로 기본 설정되어야 하며, 여전히 언어별 인코딩(대부분 Shift-JIS, 일본어 인코딩)을 선호하는 웹 콘텐츠의 일부가 있습니다. 그러나 세계의 대다수는 지난 20년 동안 전환했으며 전환은 이제 어느 정도 완료된 것으로 간주됩니다.

"UTF-8이 ASCII가 아닌 사람들에게 부담을 준다"는 것은 유해했지만 오랫동안 거의 완전히 사실이 아닌 소문이었습니다. 대부분의 유럽 언어는 처음에 대부분의 ASCII 알파벳을 포함하므로 대부분의 텍스트는 단일 바이트 시퀀스이며 UTF-16보다 작게 끝납니다. 병음과 같은 문자 체계에도 동일하게 적용됩니다. CJK 언어는 대부분 3바이트 UTF-8 영역을 차지하지만 특히 마크업 언어 또는 프로그래밍 언어에서 많은 양의 ASCII 문자도 포함하므로 일반적으로 다음과 같이 UTF-8에 대해 더 작거나 유사한 인코딩 크기를 참조하십시오. UTF-16 또는 특수 인코딩.

UTF-8이 실제로 특수 인코딩보다 더 많은 공간을 차지하는 것은 CJK 또는 키릴 자모와 같은 비ASCII 알파벳으로 된 다량의 원시 텍스트에만 해당됩니다. 그러나 이는 하드 드라이브 용량이 메가바이트 단위 로 측정되고 텍스트 파일 크기가 약간 증가해도 실제로 상당한 수준이 될 수 있었던 90년대 초반 에 대한 우려였습니다. 이것은 거의 20년 동안 문제가 되지 않았습니다. 크기 차이는 이제 완전히 중요하지 않습니다.

"유니코드 전환"은 이미 보편적으로 발생했습니다. 요즘 UTF-8로 인코딩할 필요가 없는 텍스트 형식은 끔찍하고 역사적인 실수를 저지르고 있습니다.

이 내용을 설명하는 특정 문서가 있는지 확실하지 않지만 어딘가에 있을 것입니다. ^_^

목표가 바이너리 사양을 가능한 한 순수하게 유지하는 것이라면 이름을 완전히 제거합시다. 어쨌든 모든 내부 참조는 인덱스를 기반으로 합니다.

대신 UTF-8이 필요한 JavaScript 사양에 필수 사용자 정의 섹션을 추가하십시오. @rossberg-chromium이 암시하는 소비에트 시대의 메인프레임과 같은 다른 환경에서는 자체 사용자 정의 섹션을 정의할 수 있습니다. 단일 WASM 파일은 두 사용자 정의 섹션을 모두 제공하여 두 플랫폼을 모두 지원할 수 있습니다. 사용자 지정 도구가 더 인기 있는 것을 변환하여 모호한 플랫폼의 누락된 섹션을 생성하는 것은 비교적 간단합니다.

목표가 바이너리 사양을 가능한 한 순수하게 유지하는 것이라면 이름을 완전히 제거합시다. 어쨌든 모든 내부 참조는 인덱스를 기반으로 합니다.

가져오기/내보내기가 작동하는 방식을 재작업한 것입니다. 그것은 테이블에 없으며 이 문제와 다른 문제에서 제안되어야 합니다.

@bradnelson , AFAICS, 특정 인코딩을 규정하지만 문자 집합은 없음
두 세계의 최악을 결합합니다.
면에서 실질적인 이점이 없는 제한, 복잡성 및 오버헤드
상호 운용성 나는 여전히 요점이 무엇인지 혼란스러워하고 있다고 생각합니다.

@rossberg-chromium 여기에서 추구하는 주요 이점은 추측의 부담에서 도구와 라이브러리를 덜어주는 것입니다.

여기에서 추구하는 주요 이점은 추측의 부담에서 도구와 라이브러리를 덜어주는 것이기 때문에 논의되는 위의 변형(UTF-8 대 WTF-8 등)은 최악의 경우에도 없는 것보다 나을 것입니다. "이 바이트를 문자 그대로 트랜스코딩할 수 없다고 확신합니다."가 "이 바이트는 windows-1252처럼 보입니다. 시도해 보겠습니다."보다 낫습니다. 추측은 오류가 발생하기 쉬운 것으로 알려져 있으며 여기에서 추구하는 주요 이점은 추측의 부담에서 도구와 라이브러리를 덜어주는 것입니다.

@sunfishcode , 어떻게? 나는 아직도 길을 잃었다.

그래서 여기에 구체적인 시나리오가 있습니다. 우리가 다른 플랫폼에 있고 내가 당신에게 모듈을 전달하려고 한다고 가정합니다. 내 플랫폼이 EBCDIC와 당신의 ASCII를 사용한다고 가정해보자. 현재 제안에 따르면 완전히 합법적입니다. 그러나 내 모듈은 당신과 당신의 도구 체인에 완전히 쓸모가 없습니다.

이 두 인코딩은 모두 7비트이므로 UTF-8은 그림에 입력조차 되지 않습니다.

그렇다면 UTF-8은 무엇을 테이블에 가져올까요? 글쎄, 나는 내가 얻는 알 수없는 문자열을 "디코딩"할 수 있습니다. 그러나 내가 아는 한 결과는 31비트 값의 _또 다른 불투명한 이진 얼룩_입니다. 어떤 정보도 제공하지 않습니다. 나는 그것을 내 자신의 문자열과 관련시키는 방법을 모릅니다.

그렇다면 왜 내가 알 수 없는 문자열을 디코딩하는 데 귀찮게 해야 합니까? 글쎄, _하지 않을 것입니다_! 8비트 값의 원래 이진 덩어리로 작업하고 공간과 주기를 절약할 수 있습니다. 하지만 사양에서는 여전히 인코딩을 허술하게 검증하기 위해 사이클을 소비해야 합니다.

이 모든 것을 고려할 때, 이 특정 제안을 채택함으로써 (핵심) Wasm 또는 도구가 얻는 것은 무엇입니까?

AFAICS, 특정 인코딩을 규정하지만 문자 집합은 지정하지 않음
두 세계의 최악을 결합합니다.
면에서 실질적인 이점이 없는 제한, 복잡성 및 오버헤드
상호 운용성 나는 여전히 요점이 무엇인지 혼란스러워하고 있다고 생각합니다.

우리는 확실히 문자 집합인 유니코드 문자 집합을 부과하고 있습니다. JF는 이전에 매우 혼란스러운 표현을 사용했습니다. 주의를 기울이지 마십시오. 그렇다고 해서 실제로 이를 시행하기 위해 Wasm에 검사를 추가해야 한다는 의미는 아닙니다. 디코더는 일반적으로 유효하지 않은 문자를 처리할 수 있을 만큼 충분히 강력합니다. (예를 들어 웹은 일반적으로 U+FFFD REPLACEMENT CHARACTER로 대체합니다.)

그래서 여기에 구체적인 시나리오가 있습니다. 우리가 다른 플랫폼에 있고 내가 당신에게 모듈을 전달하려고 한다고 가정합니다. 내 플랫폼이 EBCDIC와 당신의 ASCII를 사용한다고 가정해보자. 현재 제안에 따르면 완전히 합법적입니다. 그러나 내 모듈은 당신과 당신의 도구 체인에 완전히 쓸모가 없습니다.

수십 년의 오래된 시스템이 관련성이 있을 뿐만 아니라 너무 관련성이 높아 동일한 수십 년 동안 고통을 인코딩하는 것에 대해 우리가 배운 모든 것에 반대하는 결정을 내리는 것을 정당화하는 척하는 것을 중단 해야 합니다. 웹 어셈블리가 고대 메인프레임과 대화할 때 편의성을 극대화하기 위해 스스로를 비틀면서 텍스트 데이터를 안정적으로 전달할 수 있다는 세계의 다른 모든 사람들의 이점을 무시한다는 주장을 하는 사람은 아무도 없습니다. 당신은 언어를 손상시키고 사용자의 삶의 99.9%(매우 보수적인 추정치로)를 더 어렵게 만들 것입니다.

많은 다른 시스템이 이 모든 혼란을 겪었습니다. 인코딩 전쟁은 재미가 없었습니다. 그들은 많은 돈과 많은 시간을 낭비했고 많은 텍스트가 손상되었습니다. 우리는 그 전쟁을 끝냈습니다. 유니코드가 만들어지고 공포되어 전 세계에 걸쳐 지배적인 문자 집합이 되었으며, 이 시점에서 다른 모든 문자 집합은 말 그대로 이 시점에서 역사적 호기심에 불과합니다. 우리는 여전히 UTF-16 대 UTF-8을 사용할지 여부에 대해 저수준의 끓어오르는 싸움을 하고 있지만, 적어도 그 둘은 일반적으로 구별하기 쉽고(BOM을 보거나 null 바이트의 우세를 찾으십시오) 전체 UTF -8이 쉽게 지배합니다.

인코딩 자유에 대한 당신의 주장은 이 모든 역사, 유니코드가 도입된 이후 20년 동안 배운 모든 교훈을 무시합니다. 시스템은 특정 방식으로 인코딩되는 모든 것을 신뢰할 수 있기 때문에 대부분의 사용자가 인코딩 문제를 볼 수 없게 만드는 효과가 있는 최신 시스템 설계에 들어간 모든 경험과 전문 지식을 무시합니다. 한 번에 하나의 모지바케를 고집한다면 심각하고 치명적이며 값비싼 문제를 일으킬 것입니다.

@rossberg-chromium

그래서 여기에 구체적인 시나리오가 있습니다. 우리가 다른 플랫폼에 있고 내가 당신에게 모듈을 전달하려고 한다고 가정합니다. 내 플랫폼이 EBCDIC와 당신의 ASCII를 사용한다고 가정해보자. 현재 제안에 따르면 완전히 합법적입니다. 그러나 내 모듈은 당신과 당신의 도구 체인에 완전히 쓸모가 없습니다.

그렇다면 UTF-8은 무엇을 테이블에 가져올까요? 글쎄, 나는 내가 얻는 알 수없는 문자열을 "디코딩"할 수 있습니다. 그러나 내가 아는 한 결과는 31비트 값의 또 다른 불투명한 이진 얼룩입니다. 어떤 정보도 제공하지 않습니다. 나는 그것을 내 자신의 문자열과 관련시키는 방법을 모릅니다.

UTF-8은 그것을 자신의 문자열과 어떻게 연관시키는지 정확히 알려줄 것입니다. 그것이 바로 그것이 해결하는 문제입니다. (WTF-8도 가능할 때 그렇게 할 것이고, 할 수 없을 때 명확하게 알려줄 것입니다.)

문자열 형식으로 맹글링된 다음 UTF-8로 인코딩된 임의의 데이터 구조를 의미합니까? 그것을 해체할 수 없는 것은 사실이지만, 망가진 이름을 문자열로 최소한 명확하게 표시할 수 있습니다. 이는 일부 사용 사례에서 아무것도 없는 것보다 개선된 것입니다.

UTF-8을 유니코드가 아닌 불투명한 정수의 인코딩으로 사용하는 것에 대한 위의 논의를 의미합니까? 논의가 다소 혼란스러워진 것 같아요. "구문"국제화 "의미"를 인코딩 전화를 유혹,하지만 그 유용한 구분을 모호하게 : UTF-8은 아직 말할 수있는 소비자가 정보와 함께 할 무슨 말을하지 않고 특정 바이트 시퀀스 수단 "Ö"를. 이런 식으로 사용하면 유니코드의 인코딩이지만 위에서 제안한 "유니코드 지원"에 사용된 종류의 비용이 필요하지 않습니다.

그렇다면 왜 내가 알 수 없는 문자열을 디코딩하는 데 귀찮게 해야 합니까? 글쎄, 나는하지 않을거야! 8비트 값의 원래 이진 덩어리로 작업하고 공간과 주기를 절약할 수 있습니다. 하지만 사양에서는 여전히 인코딩을 허술하게 검증하기 위해 사이클을 소비해야 합니다.

이제 overlong 및 surrogate를 포함하여 wasm 가져오기/내보내기 식별자의 전체 UTF-8 유효성 검사를 사용하여 SpiderMonkey를 구축했습니다. AngryBots 또는 그럼에도 불구하고 30개의 가져오기가 있는 작은 emscripten 컴파일 테스트 케이스에서 WebAssembly.validate 에서 성능 차이를 감지할 수 없었습니다.

사양은 여러 관심사 사이의 절충안입니다. 시작 시간에 대한 관심에 감사하게 생각하므로 이제 몇 가지 실험을 수행하고 측정했습니다. 나는 다른 사람들이 그들 자신의 실험을 하도록 격려한다.

또한 UTF-8은 유일한 유니코드 인코딩이 아니며 유니코드가 아닌 정수를 인코딩하는 데 사용할 수 있습니다. 따라서 UTF-8은 유니코드가 아닙니다.

유니코드의 일부가 아닌(즉, U+0000에서 U+10FFFF 범위를 벗어난) UTF-8로 인코딩할 수 있는 정수는 무엇입니까? 그 말은 거짓인 것 같다.

문자의 유효성을 검사하지 않으면 21비트 정수를 인코딩할 수 있습니다.

왜 우리가 유효성을 검사하지 않을지 확실하지 않습니다...

@flagxor https://encoding.spec.whatwg.org/ 는 웹에 노출된 다양한 인코딩을 설명합니다. 그들 중 어느 것도 유니코드 문자 집합을 벗어나지 않지만 분명히 서로 바이트 호환이 가능한 것은 아닙니다.

"검증"은 무엇을 합니까? 당신의 was 프로그램을 무효로 만드시겠습니까? 합리적으로 부과될 수 있는 실질적인 결과는 없다고 생각합니다.

CSS에서 유효하지 않은 이스케이프를 사용하면 스타일시트에 U+FFFD를 넣을 뿐 이상한 일은 하지 않습니다.

@annevk :

또한 UTF-8은 유일한 유니코드 인코딩이 아니며 유니코드가 아닌 정수를 인코딩하는 데 사용할 수 있습니다. 따라서 UTF-8은 유니코드가 아닙니다.

유니코드의 일부가 아닌(즉, U+0000에서 U+10FFFF 범위를 벗어난) UTF-8로 인코딩할 수 있는 정수는 무엇입니까? 그 말은 거짓인 것 같다.

최소한 U+FFFE 및 U+FFFF는 유니코드에서 문자가 아닙니다. 코드 포인트(정수 값)는 유니코드에서 문자를 인코딩하는 데 사용되지 않지만 UTF-8로 인코딩할 수 있습니다.

그들은 여전히 ​​유니코드 코드 포인트입니다. 나는 "캐릭터"에 너무 집중하지 않을 것입니다.

@tabatkins 를 U+FFFD로 디코딩하는 것은 합리적이지만 얻을 수 있는 정수의 수를 제한합니다.

따라서 C 프로그래밍 언어의 모든 문자열 리터럴에 유니코드를 적용하는 것보다 코어 Wasm에 유니코드를 적용하는 것은 더 이상 의미가 없습니다. 일부 잠재 고객에게 이 표준을 위반하도록 강요할 뿐입니다. 이득은 무엇입니까?

당신은 C11이 추가 한 메모를 걸릴 수 있습니다 char16_t 및 char32_t 유형을 잘 한 u 접두사 UTF-16 인코딩 된 문자열 리터럴를 들어, U 접두어 UCS-4로 인코딩된 문자열 리터럴 및 UTF-8로 인코딩된 문자열 리터럴에 대한 u8 접두사. 추가에 대한 근거를 찾을 만큼 충분히 깊이 파고 들지는 않았지만 "표준 C/C++에서 유니코드를 다루는 것은 악몽"이라는 것이 적어도 동기의 일부라고 가정합니다.

@tabatkins , @sunfishcode , 좋아요, 그래서 당신은 같은 것에 대해 이야기하고 있지 않습니다. 그러나 AFAICT @jfbastien 은 그의 제안이 유니코드 문자 집합 없이 UTF-8을 지정하는 것에 관한 것임을 명시 적이고 반복적으로 밝혔습니다.

저비용이라는 주장이 뒷받침되는 유일한 해석이기도 하다.

왜냐하면 우리가 실제로 UTF-8이 유니코드를 의미한다고 가정한다면 이 요구사항은 아직 유니코드(하위 집합)를 말하지 않는 시스템의 모든 도구에 대한 UTF-8 인코딩/디코딩보다 확실히 훨씬 더 비쌉니다. 전체 트랜스코딩 레이어를 포함해야 합니다.

@tabatkins , 코어 Wasm은 기존 시스템에 내장될 것입니다. 때로는 이식성 이외의 이유로 인해 변경하거나 부과할 권한이 없습니다. 그들이 당신이 설명하는 문제에 직면한다면 그것은 Wasm과 독립적으로 존재합니다. _우리는 _그들의_ 문제를 해결할 수 없습니다.

그들 모두에 유니코드를 적용하려는 _시도_의 가능성 있는 결과는 일부 잠재적인 것들이 단순히 사양의 해당 부분을 위반하여 완전히 무의미하게 만드는 것입니다(또는 더 나쁘게는 Wasm을 완전히 무시할 것입니다).

OTOH가 적절한 계층에서 지정되면 실제로 손실 없이 그러한 위험을 감수하지 않습니다.

왜냐하면 우리가 실제로 UTF-8이 유니코드를 의미한다고 가정한다면 이 요구사항은 아직 유니코드(하위 집합)를 말하지 않는 시스템의 모든 도구에 대한 UTF-8 인코딩/디코딩보다 확실히 훨씬 더 비쌉니다. 전체 트랜스코딩 레이어를 포함해야 합니다.

ASCII가 아닌 유니코드가 아닌 기본 문자 집합을 사용하고 해당 문자를 유니코드로/에서 변환하는 기능이 없으며 Wasm에서 ASCII가 아닌 식별자를 사용해야 하는 플랫폼은 무엇입니까? (도스에서 Wasm을 사용하기로 결정한 가상의 러시아 조직이 아니라 실제로 존재한다는 의미입니다.)

@rocallahan 저는 @rossberg-chromium이 전체 ICU 라이브러리의 추가 비용을 원하지 않는 임베디드 시스템과 같은 장치에 관심이 있다고 믿습니다(또는 적어도 저는 그렇게 할 것입니다). 그들은 부풀림을 수용하거나 완전한 유효성 검사를 수행하지 않거나 ASCII가 아닌 문자를 포함하는 wasm 파일을 수락하지 않을 수 있습니다(제어할 수 없음).

또한 엄밀히 말하면 이러한 장치에는 다음과 같은 비표준 문자 집합이 있는 하드웨어가 포함되는 경우가 많습니다.
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(구피 혼합 ASCII + latin1 + 일본어 문자 세트가 있음)
그러나 우려되는 것은 무엇을 확인해야 하는지에 관계없이 관련이 있다는 것입니다.

@tabatkins 의도가 다음과 같다고 생각했지만

• 바이트의 유일한 "올바른" 해석으로 UTF-8 + 유니코드를 요구합니다.
• (비용을 절약하기 위해) 모듈의 유효성을 검사할 필요가 없음을 유니코드가 명시적으로 명시합니다.

나는 @rossberg-chromium이 전체 ICU 라이브러리의 추가 비용을 원하지 않는 임베디드 시스템과 같은 장치에 관심이 있다고 생각합니다(또는 적어도 저는 그렇게 할 것입니다). 그들은 부풀림을 수용하거나 완전한 유효성 검사를 수행하지 않거나 ASCII가 아닌 문자를 포함하는 wasm 파일을 수락하지 않을 수 있습니다(제어할 수 없음).

반복해서 말했듯이 이것은 청어입니다. ICU와 관련된 원격 작업을 수행할 필요가 없습니다. 웹은 확실히 그렇지 않습니다. 이 잘못된 정보를 퍼뜨리는 것을 멈춰주세요.

"전체 유효성 검사"는 일치하는 UTF-8 디코딩 작업의 일부로 자동으로 수행되는 매우 간단한 작업입니다.

@tabatkins 와 채팅할 때 여기서 분명히 해야 할 한 가지가 중요하다고 생각합니다.
준수하는 유니코드 디코더는 할당되지 않은 코드 포인트 등의 수정자의 임의 조합을 허용하는 데 필요합니다. 따라서 수정자 등의 잘못된 혼합은 합리적인 것으로 렌더링되지 않더라도 유니코드에서 허용해야 합니다. 넌센스 조합을 거부한 디코더는 비준수입니다.

따라서 적절한 UTF-8 디코딩에 대한 요구 사항은 몇 줄의 코드로 수행할 수 있는 것으로 범위가 명확하고 정확한 작업이며 본질적으로 바이트의 유니코드 + utf-8 해석을 지정하는 것과 동일합니다.

예. UTF-8 구문 분석은 매우 간단합니다. 유일한 합병증은 UTF-8로 인코딩할 수 없는 소수의 코드포인트이며, 호환 디코더는 대신 하나 이상의 U+FFFD 문자로 구문 분석합니다.

그러나 그것은 끝점이 할 작업입니다. Wasm은 이것에 대해 걱정할 필요가 없습니다. 호환 디코더는 임의의 비트 패턴을 처리할 수 있습니다. (그들은 대부분의 가비지 비트 패턴이 U+FFFD 문자라고 결정할 것입니다.) 지금까지 제가 요청한 것은 이러한 문자열을 UTF-8로 인코딩해야 하는 작성자 수준의 적합성 요구 사항입니다. 이를 위반하면 툴체인이 이를 오류로 표시할 수 있지만 Wasm 자체가 해야 할 일은 없습니다.

이것은 예를 들어 CSS가 유효한 스타일시트를 구성하는 문법을 정의하지만 여전히 기술적으로 임의의 비트 패턴을 허용하는 것과 유사합니다.

또한 엄밀히 말하면 이러한 장치에는 다음과 같은 비표준 문자 집합이 있는 하드웨어가 포함되는 경우가 많습니다.

사람들이 (비 ASCII 범위) Wasm 식별자를 쓰기를 기대하지 않는 한 그러한 문자 세트의 존재는 Wasm과 관련이 없습니다.

맞습니다. 모든 "UTF-8 사용"은 https://encoding.spec.whatwg.org/#utf -8-decoder를 의미합니다. ICU는 요구 사항에 가깝지 않습니다.

2017년 2월 25일 01:13에 Brad Nelson [email protected] 은 다음과 같이 썼습니다.

@tabatkins https://github.com/tabatkins 와 채팅할 때 한 가지
여기서 명확히 하는 것이 중요하다고 생각합니다.
임의의 것을 허용하려면 준수하는 유니코드 디코더가 필요합니다.
할당되지 않은 코드 포인트 등의 수식어 조합.
수정자 등은 그것을 통해서도 합리적인 것으로 렌더링되지 않습니다.
유니코드에서 허용해야 합니다. 넌센스를 거부한 디코더
조합은 호환되지 않습니다.

따라서 적절한 UTF-8 디코딩에 대한 요구 사항은 다음과 같이 명확하게 범위가 지정됩니다.
몇 줄의 코드로 수행할 수 있는 작업은 정확한 작업입니다.
기본적으로 유니코드 + utf-8을 지정하는 것과 동일합니다.
바이트 해석.

내가 말한 것을 명확히하기 위해. 나는 완전한 ICU가 아마도 그렇지 않을 것이라는 데 이의를 제기하지 않습니다.
필요합니다(예: 코드 포인트별로 이름을 정렬하는 것이 좋지 않은 것처럼 들리지만
사용성).

그러나 사소한 해독만이 남아 있다는 주장은 옳지 않다.
검증으로 끝나지 않기 때문입니다. 비유니코드 플랫폼
실제로 문자열을 처리하기 위해 트랜스코딩을 수행해야 합니다.
또한, 그들은 캐릭터의 문제를 다루어야 할 것입니다.
(어느 방향으로든) 매핑할 수 없으므로 여전히 호환성이 있습니다.
일반적으로 문제는 그냥 지나쳤습니다.

>

또한 엄밀히 말하면 이러한 장치에는 다음을 포함하는 하드웨어가 포함되는 경우가 많습니다.
다음과 같은 비표준 문자 집합:

이러한 문자 집합의 존재는 다음과 같은 경우가 아니면 Wasm과 관련이 없습니다.
사람들이 (비 ASCII 범위) Wasm 식별자를 쓰기를 기대합니다.

@rocallahan https://github.com/rocallahan , 그들은 여전히 ​​할 수 있어야 합니다
임의의 유니코드를 가져옵니다. 그러나 그들은 그것으로 무엇을 했을까요? 와즘이라면
ASCII로 제한된 그러한 플랫폼에서의 구현은 다음과 같습니다.
제안된 사양을 위반합니다. (나는 또한 그것을 의미한다고 생각할 것입니다.
누군가의 비 ASCII 문자는 문화적으로 선험적으로 관련이 없을 수 있습니다.
수상한. 그것은 그들이 결정할 문제입니다.)

게다가 (어느 방향으로든) 매핑할 수 없는 캐릭터의 문제를 처리해야 하므로 일반적으로 여전히 호환성 문제가 있고 길을 걷다 막았습니다.

이것이 이론적 관심사입니까?

그리고 그것이 합리적인 우려라면 우리는 인코딩에 의존할 수 없고 처리해야 하는 세계 의

비유니코드 플랫폼은 실제로 문자열을 처리하기 위해 트랜스코딩을 수행해야 합니다.

하지만 어떤 경우에 Wasm 문자열이 플랫폼 문자열과 상호 운용되어야 합니까? 내가 말할 수 있는 한 우리는 실제 모듈 코드로 조작된 문자열의 인코딩이 아니라 Wasm 메타데이터의 문자열 인코딩에 대해서만 이야기하고 있다고 말할 수 있습니다. (잘못된 경우 사과드립니다...) 그렇다면 interop/transcoding이 필요할 수 있는 몇 가지 가능한 경우만 생각할 수 있습니다.

• Wasm 모듈은 플랫폼 식별자를 가져옵니다.
• 플랫폼은 Wasm 식별자를 가져옵니다.
• Wasm 이름을 추출하고 인쇄하거나 플랫폼 문자열을 사용하여 저장합니다(예: 스택 추적 덤프).

오른쪽?

가상의 비유니코드 임베디드 시스템의 경우 처음 두 경우에 대한 조언은 간단합니다. 플랫폼 경계를 넘어 가져온 식별자를 ASCII로 제한하면 필요한 트랜스코딩이 간단합니다. Wasm 모듈은 여전히 ​​내부적으로 그리고 서로 연결하기 위해 전체 유니코드 이름을 사용할 수 있습니다.

세 번째 문제 --- Wasm 모듈의 닫힌 세계가 있는 경우 해당 식별자를 ASCII로 제한할 수 있습니다. 그렇지 않다면 실제로 UTF8 식별자를 접하게 되며 이를 트랜스코딩할 수 있게 되며 사양에서 UTF8을 요구하게 되어 기쁠 것입니다!

누군가의 비 ASCII 문자가 선험적으로 관련이 없음을 암시

그것은 밀짚맨 주장입니다. 여기서의 입장은 "비 ASCII 식별자를 원하면 유니코드를 사용하거나 유니코드로/에서 트랜스코딩을 구현하십시오"이며 다른 사양인 AFAIK에서는 "문화적으로 의심스럽다"는 비판을 받지 않았습니다.

>

그리고 그것이 합리적인 우려라면, 우리는 다시 한번 (발생

• 비용) 거의 모든 다른 비용에 대해 처리하는 비용세계의 Wasm 사용자 ,
  동일한 인코딩을 처리해야 하는 지옥 같은 웹 플랫폼은 통과해야 했습니다.
  그리고 결국 가능한 한 잘 고쳤습니다.

@tabatkins , 아니, 다시
이미 여러 번): 모든 임베딩 사양은 _will_ 인코딩을 지정하고
문자 집합입니다. 모든 플랫폼에서 이것에 의존할 수 있습니다. 당신은 단지 실행했을 것입니다
관련되지 않은 두 가지 사이에서 상호 운용을 시도한 경우 인코딩 질문에
에코 시스템 -- 이미 더 깊은 이유로 양립할 수 없습니다.
문자열. 그리고 이것은 다른 플랫폼과의 상호 운용성에만 영향을 미칩니다.
완전히 제외합니다. 그래서 당신은 _아무것도 잃지 않고_ 사용할 수 있는 능력을 얻습니다.
더 다양한 플랫폼에서 Wasm.

당신은 소프트웨어 엔지니어입니다. 따라서 나는 당신이 이해하고 감사한다고 가정합니다.
문제를 분리하고 최대화하기 위한 모듈화 및 계층화의 가치
재사용. 이는 사양에도 적용됩니다.

>

비유니코드 플랫폼은 실제로 트랜스코딩을 수행해야 합니다.
문자열을 처리합니다.

어떤 경우에 Wasm 문자열이 플랫폼 문자열과 상호 운용되어야 하는지,
그렇지만? 내가 말할 수있는 한 우리는 인코딩에 대해서만 이야기하고 있습니다.
에 의해 조작된 문자열의 인코딩이 아닌 Wasm 메타데이터의 문자열
실제 모듈 코드. (그게 틀리다면 사과할게...) 그럼 생각밖에 안나
interop/transcoding이 필요할 수 있는 몇 가지 가능한 경우:

• Wasm 모듈은 플랫폼 식별자를 가져옵니다.
• 플랫폼은 Wasm 식별자를 가져옵니다.
• Wasm 이름을 추출하여 인쇄하거나 플랫폼을 사용하여 저장합니다.
  문자열, 예를 들어 스택 추적을 덤프합니다.

오른쪽?

예. 즉, 실제로 문자열을 _사용_해야 할 때마다.

가상의 비유니코드 임베디드 시스템의 경우 처음 두 경우에 대해
조언은 간단합니다. 플랫폼 전체에서 가져온 식별자를 제한하십시오.
경계가 ASCII인 경우 필요한 트랜스코딩은 간단합니다. Wasm 모듈
내부적으로 그리고 서로 연결하기 위해 전체 유니코드 이름을 계속 사용할 수 있습니다.

세 번째 문제의 경우 --- Wasm 모듈의 닫힌 세계가 있는 경우
식별자를 ASCII로 제한할 수 있습니다. 그렇지 않으면 실제로
UTF8 식별자를 만나면 이를 트랜스코딩할 수 있고
사양이 UTF8로 지정되어 기쁠 것입니다!

제안에 따라 ASCII로 아무것도 제한할 수 없습니다! NS
핵심 사양이 더 허용되어야 함을 허용합니다. 그래서 당신은 만들고
내 입장.

모든 임베딩 사양은 _will_ 인코딩과 문자 집합을 지정합니다. 모든 플랫폼에서 이것에 의존할 수 있습니다. 문자열보다 더 깊은 이유로 이미 호환되지 않는 두 개의 관련되지 않은 에코 시스템 간에 상호 운용을 시도하는 경우에만 인코딩 질문에 부딪힐 것입니다.

디스어셈블러와 같은 Wasm 처리 도구는 어떻습니까? "임베딩 사양" 변형에 관계없이 모든 Wasm 모듈과 함께 작동하는 디스어셈블러를 작성할 수 있다는 것이 가치가 있지 않을까요?

제안에 따라 ASCII로 아무것도 제한할 수 없습니다!

제안에 따르면 Wasm 모듈은 ASCII로 제한되지 않지만 구현자가 Wasm 모듈 외부에 정의된 모든 식별자를 ASCII로 만들기로 선택한 경우(예: 거의 모든 시스템 라이브러리가 실제로 하는 것처럼), 이는 Wasm의 범위를 벗어납니다. 투기.

구현자가 스택 추적에서 ASCII 문자만 인쇄하고 모든 비 ASCII 유니코드 문자를 ? 또는 이와 유사한 것으로 바꾸기로 선택한 경우 실제로는 항상 사용하지 않는 유니코드 문자가 있기 때문에 사양에서 허용해야 합니다. 어쨌든 글꼴이 없습니다.

모든 Wasm 이름이 ASCII인 Wasm의 하위 집합을 정의하는 것은 Wasm 이름을 UTF8로 처리하는 도구에 의해 그러한 Wasm 모듈이 올바르게 처리될 것이기 때문에 상당히 무해할 것입니다.

당신은 소프트웨어 엔지니어입니다. 따라서 문제를 분리하고 재사용을 극대화하기 위해 모듈화 및 계층화의 가치를 이해하고 감사한다고 가정합니다. 이는 사양에도 적용됩니다.

예, 저는 소프트웨어 엔지니어입니다. 나는 또한 사양 엔지니어이기 때문에 일관성의 가치를 이해하고 생태계가 더 잘 작동하도록 하는 규범을 수립합니다. 문자 집합과 인코딩은 모듈화와 선택을 허용하는 가치가 일관성과 예측 가능성의 가치보다 훨씬 더 중요한 주제 중 하나입니다. 우리는 이것에 대한 문자 그대로 수십 년의 증거를 가지고 있습니다. 당신이 역사와이 매우 스레드에서 보여준 몇 가지있는 많은 전문가의 추천, 나는의 의견을 표현하고있어 많은 무시하고, 우리가 할 필요가 있음을 주장 할 때 - 이것은 내가 나 자신을 반복 계속 이유 이와 관련하여 자유를 허용하십시오.

이 전체(긴) 스레드를 읽은 후 이 토론을 해결할 수 있는 유일한 방법은 설명하는 이름 섹션을 바이너리 형식으로 명시적으로 지정하고 https://github.com/WebAssembly/design/pull 에서 개선하고 있다고 생각합니다. UTF-8 인코딩 이며, 저는 단순히 해당 섹션을 "utf8-names"라고 부를 것을 제안합니다. 이는 인코딩을 명시적으로 만들고 오늘날 모든 관련 플랫폼에서 WASM 바이너리를 조작하려는 거의 모든 도구는 어쨌든 UTF-8을 사용하기를 원합니다. 그들은 UTF-8만 말하는 것에 대해 용서받을 수 있습니다.

다른 플랫폼에 대한 @rossberg-chromium의 우려에 민감하며 어느 정도 동의합니다. 그러나 이것은 쉽게 고칠 수 있습니다. 스레드의 앞부분에서 누군가가 제안했듯이 이러한 시스템은 비표준 "ascii-names" 섹션이나 생태계에서 사용하는 다른 인코딩을 추가하는 것을 환영합니다. 명시적 이름을 사용하면 어떤 도구가 어떤 섹션에서 작동하는지 명확해집니다. DOS에서만 작동하는 모듈의 경우 DOS 관련 섹션이 있으면 이것이 분명해집니다. IMO 이러한 바이너리의 이름을 다른 인코딩으로 해석하는 것은 재앙이 될 것입니다.

(그런데 이것은 사용자가 업로드한 콘텐츠에 대한 문자열의 인코딩을 실수로 잃어버리고 복구할 수 없는 시스템에 대한 전쟁 이야기에서 알 수 있습니다. 시스템은 끔찍하고 경련적인 죽음을 맞이했습니다. 말 그대로 수백만 달러의 손실을 입었습니다. .)

이름 섹션(heh)에 대한 명명 표준을 채택하여 모두 "\

@titzer 예, 사용자 정의 섹션은 UTF8과 아무 관련이 없는 이국적이거나 전문화된 플랫폼을 위한 솔루션입니다. 사양에 규정하기는 꺼려지겠지만: 플랫폼이 작동 모드에서 너무 구체적이어서 UTF-8 코드 포인트를 기본 환경 설정에 매핑하는 데 신경을 쓸 수 없는 경우 다음을 수행할 수 있습니다. 선호하는 인코딩으로 이름을 제공하는 것보다 사용자 정의 섹션이 훨씬 더 많습니다.

사양에서 플랫폼별 세부 정보에 대해 사용자 정의 섹션을 사용하는 데 더 중점을 두고 플랫폼 자체 사양에서 이러한 세부 정보를 정의하도록 하는 것이 좋습니다. 일반적인 WASM 도구 체인은 일종의 플러그인 아키텍처를 통해 이를 지원할 수 있습니다.

@titzer utf8-names 전환하는 것은 괜찮습니다. 보너스로, 브라우저는 "이름"을 삭제하기 전에 릴리스에 대해 "이름"(이전 형식)과 "utf8-names"(#984 형식)를 모두 쉽게 지원할 수 있으므로 전환이 원활해집니다. 이를 배포해야 하는 시급함을 많이 제거합니다.

이미 위에서 결정했다면 죄송합니다. 하지만 분명히 말씀드리자면, 이제 BinaryEncoding.md에 있는 가져오기/내보내기 이름에 제안된 변경 사항이 있습니까?

utf8-names 괜찮습니다.

가져오기/내보내기에 @lukewagner 와 동일한 질문입니다.

@lukewagner @jfbastien 좋은 질문입니다. 위의 결정을 보지 못했습니다. 무엇보다도 우리가 현재 가지고 있는 바이너리 형식을 변경하고 싶지 않다고 생각합니다. 그래서 우리가 한 일이 합리적이라고 스스로를 납득시키기 위해 거쳐야 하는 정신적 왜곡이 무엇이든 간에 말이죠 :-)

AFAICT는 현재 가져오기/내보내기의 문자열이 해석되지 않은 바이트 시퀀스라고 가정합니다. 괜찮아. 내 생각에는 가져오기/내보내기에 사용되는 문자열의 인코딩이 이름 섹션이 아닌 방식으로 임베더에 의해 단독으로 정의되는 것을 고려하는 것이 합리적이라고 생각합니다. 예를 들어 JS는 항상 UTF-8을 사용합니다. 이름 섹션은 이름 섹션의 이름에 명시적 인코딩과 함께 제공됩니다.

짧은 버전: 가져오기/내보내기 선언의 이름 인코딩은 포함 환경의 속성이고 이름 섹션의 이름 인코딩은 사용자 섹션을 식별하는 데 사용되는 문자열에 의해 명시적입니다(예: "utf8-names").

어떻게 생각하십니까?

그것은 괜찮고 #984가 병합되기 전에 있었던 것과 일치합니다(modulo names => utf8-names ).

이름 섹션은 진정한 호환성 문제가 발생하는 가져오기/내보내기만큼 중요하지 않다고 생각합니다.

• mojibaked 이름 섹션을 로드하면 펑키한 Error.stack 및 디버깅을 얻을 수 있습니다.
• mojibaked 가져오기/내보내기를 로드하고 아무 것도 작동하지 않습니다.

우리 모두가 구현하는 임베딩이 이미 이것을 가정하고 있기 때문에 이것이 진정한 바이너리 형식 변경이라고 생각하지 않습니다.

닫기 전에 이 주제에 대해 나보다 더 잘 알고 있는 사람들의 추천에 기댈 것입니다.

UTF-8을 디코딩하는 방법을 결정해야 합니다. 잘못된 시퀀스를 U+FFFD로 바꾸거나 첫 번째 오류에서 중지합니까? 즉, https://encoding.spec.whatwg.org/#utf -8-decode-without-bom 또는 https://encoding.spec.whatwg.org/#utf -8-decode-without-를 원합니다. 붐 또는 실패. 리소스가 이름에 U+FFFD를 사용하지 않는 한 어느 쪽이든 로드가 실패할 수 있습니다.

현재 설명 된 방식으로 가져오기/내보내기 이름 바이트 배열이 UTF-8로 JS 문자열로 디코딩되지 않으면 예외가 발생합니다. 그 후, JS 문자열이 있고 가져오기 조회는 Get 측면에서 정의됩니다.

내 이해를 확인하기 위해 https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail을 수행했다면 성공적인 유효성 검사 후 코드 포인트-시퀀스 평등을 확인했음을 의미합니다. 바이트 시퀀스 평등을 확인하는 것과 동일합니까?

예.

위의 논의 후에 핵심 사양에서 가져오기/내보내기 이름에 대해 UTF-8 유효성 검사를 지원합니다.

특히 이것은 utf-8-decode-without-bom-or-fail 및 codepoint-sequence 같음( 엔진이 바이트 시퀀스 같음을 수행할 수 있음 )이므로 엔진은 유니코드 및 국제화의 무섭고 값비싼 부분을 피할 수 있습니다. 그리고 이것은 웹 임베딩과 일치합니다. 나는 이것을 실험 했고 주요 오버 헤드는 무시할 수 있음을 발견했습니다.

• Re: 하드웨어 ISA는 인코딩에 대해 불가지론적입니다. 여기서 말하는 하드웨어는 가져오기/내보내기 기능이 없으므로 비유가 직접 적용되지 않습니다. 그러한 하드웨어가 모든 종류의 바이트 시퀀스 식별자인 x86의 cpuid를 사용하는 곳을 알고 있는 한 곳은 UTF-8이라는 특정 문자 인코딩을 지정합니다.

• Re: Layering: 소프트웨어 엔지니어로서 우리는 또한 계층화와 모듈화가 그 자체가 목적이 아니라 수단이라는 것을 알고 있습니다. 예를 들어 핵심 사양에서 LEB128을 깔끔하게 제외할 수 있습니다. 그것은 더 큰 계층화와 모듈화를 제공할 것입니다. LEB128은 틀림없이 웹 사용 사례에 편향되어 있습니다.

• Re: "임베디드 시스템": 제공된 예는 DOS이지만 가져오기/내보내기 이름에 대한 UTF-8 요구 사항이 DOS 시스템에서 수행해야 하는 작업을 수행하는 데 비용이 많이 들거나 비실용적인 경우의 예는 무엇입니까?

• Re: Islands: WebAssembly는 또한 특정 엔디안을 지정하고, 부동 소수점 지원, 8비트 주소 단위가 필요하며, 불필요한 부담이 되는 실제 설정이 있음에도 불구하고 다른 선택을 합니다. WebAssembly는 많은 사람들이 공유할 수 있는 공통 플랫폼을 강화할 것으로 예상할 때 이와 같은 선택을 합니다.

• Re: 가져오기/내보내기 이름의 임의 데이터 구조: 이론적으로 유용하지만 데이터를 문자열로 맹글링하여 수행할 수도 있습니다. 맹글링은 덜 편리하지만 어렵지는 않습니다. 따라서 거기에는 절충점이 있지만 큰 것은 아닙니다(그리고 틀림없이 가져오기/내보내기에 메타데이터를 첨부해야 하는 일반적인 필요가 있는 경우 추가 목적으로 식별자를 추가하는 것보다 명시적 메커니즘을 갖는 것이 더 좋을 것입니다.)

• Re: 바이너리 호환성: 이 변경이 여전히 가능하다는 JF의 의견에도 동의합니다. utf-8-decode-without-bom-or-fail은 자동 동작 변경이 없음을 의미하며 현재 알려진 모든 wasm 생산자는 출력을 웹 임베딩과 호환되도록 유지합니다(다른 임베딩도 지원하더라도). 이미 UTF-8 내에 머물고 있습니다.

UTF-8 이름에 대한 특정 제안을 하는 PR이 이제 https://github.com/WebAssembly/design/issues/1016으로 게시됩니다

#1016을 사용하면 이 문제가 해결되었습니다.