UTF-8の議論：それは非常に簡単です。 JavaScriptのエンコーダーとデコーダー。 繰り返しますが、 UTF-8はUnicodeではありません。

UTF-8に対する議論：長さ+バイトよりも少し複雑であり、実装の相違が生じる可能性があります。

繰り返しますが、UTF-8はUnicodeではありません。

何言ってるの？ これはナンセンスな文章です。

国際化ライブラリを利用する必要はないと言っていると思います。 これは真実です。文字列をUTF-8でエンコードすることを義務付けることは、正規化など、Unicodeのより複雑な部分とは何の関係もありません。 これらは、人間とインターフェイスする文字列作業を行うときに便利なツールですが、trigライブラリが数学を行う人々に役立つのと同じように、整数のエンコード方法を決定するときには関係ありません。

しかし、UTF-8は文字通りUnicodeエンコーディングです。 あなたの声明は書かれているように無意味です。 ^ _ ^

しかし、UTF-8は文字通りUnicodeエンコーディングです。 あなたの声明は書かれているように無意味です。 ^ _ ^

はい、私はUTF-8が説明するコードポイントエンコーディングを具体的に参照していますが、コードポイントの適切な処理ではありません（この提案の目的上、コードポイントは不透明な整数です）。 wasm-ismsに入れると、UTF-8はvar [u] intに似ていますが、文字により適しています。 さらに、UTF-8はUnicodeエンコーディングだけではなく

さらなる提案は、個々のコードポイントを調べて、それらを使って何かをするでしょう。 これはその提案ではありません。

そして、そうする理由はありません。 文字通りi18nAPIでない限り、厳密な同等性の比較と並べ替えを超えてコードポイントを内省する必要性を見つけたWebAPIはありません。

別のオプションは、各コードポイントのバイト長+ UTF-8です（ @jfbastienは、各バイトのUTF-8と言ったときに意味がない限り、私には意味がありませんでした）。 洗練されたUnicodeライブラリがバイト配列、オフセット、長さを入力として受け取り、文字列を返すことを可能にしながら、これが実際には気にしないプリミティブパーサーにとってこれ以上難しいことになるとは思いません。

単なる整数である「UTF-8コードポイント」としての定義に同意します。 バイナリ仕様はそのままにしておく必要があります。 個々の埋め込み者は、許可されるコードポイント、正規化、およびその他のニュアンスに関するルールを定義できます。 分析ツールは、潜在的な互換性の問題について警告を提供する可能性があります。

エラー処理の決定も埋め込み者に任せるべきだと思います。 名前ではなくインデックスでWASM関数にアクセスするシステムは、それらが有効である必要はありません（そして、バイト長のプレフィックスでスキップするのは簡単です）。

これは、根本的な問題とその理由を要約する試みです。 訂正や追加は大歓迎です。

wasmではモジュールのインポート/エクスポート識別子が有効なUTF-8である必要がありますか？

反対の理由についての私の理解は次のとおりです。

• インポートとエクスポートの処理は、アプリケーションの起動のクリティカルパス上にあり、速度を低下させるようなものは避けたいという要望があります。
• 幅広い不変条件「コアwasm仕様は文字列を解釈しません」。 文字列の解釈は一般に複雑であり、それをカプセル化し、高レベルで推論できる幅広い不変条件と境界を持ちたいという要望があります。
• WebAssemblyデコーダーはセキュリティに敏感であることが多いため、関連するコードの量を最小限に抑えることが一般的に望まれています。
• 一部のWebAssemblyプロデューサーは、これらの識別子に任意のデータを埋め込みたい場合があります。データを文字列形式にマングリングするよりも、データを好きなようにエンコードする方が便利です。

wasmはUTF-8を必要としない領域で推奨する必要がありますか？

その理由は、たとえそれを要求できなくても、UTF-8に言及することで、エコシステム間の不必要な非互換性を思いとどまらせる可能性があるためです。

反対の理由についての私の理解は、UTF-8に言及することでさえ、文字列解釈の懸念の概念的なカプセル化を損なうことになるということです。

wasmは名前セクション名にUTF-8を指定する必要がありますか？

理由は次のとおりです。これらの名前の全体的な目的は、表示用の文字列に変換することです。これは、エンコードなしでは不可能です。したがって、ツールが推測する必要がないように、UTF-8を指定する必要があります。

反対の理由の私の理解は次のとおりです：wasmが指定されたエンコーディングを持たない他の領域に他の文字列のようなものを持っている場合（つまり、上記のインポート/エクスポート）、一貫性のために、文字列のエンコーディングを指定するべきではありません。

@sunfishcodeは良い要約を提供しますが、3つの重要なポイントを追加したいと思います。

@jfbastien 、文字列のバイナリ_syntax_（エンコーディング）を制限するが、_semantics_（文字セット）を制限しないことは、すべての選択肢の中で最も無意味です。 したがって、すべての実用的な目的で、UTF-8はUnicodeを意味します。 繰り返しますが、これはエンジンだけではありません。 名前をUnicodeとして定義すると、すべての環境のすべてのWasmecoシステムでそれを強制することになります。 そしてそれは、すべての環境でUnicodeをサポートする必要があることを意味します。

@tabatkins 、あなたの議論の根底にあるドメインエラーがあると思います。 私たちが話している文字列はどれも_ユーザー向け_ではありません。 それらは_dev-faceing_名です。 多くの/ほとんどのプログラミング言語はUnicode識別子をサポートしておらず、ツールもサポートしていません。 たとえば、gdbはUnicodeソース識別子を処理できますか？ そうは思いません。 したがって、すべての消費者が_この空間で_Unicodeに収束したと仮定することは非常に楽観的（というより非現実的）です。

そして最後に、不一致は、Web上のWasmがUTF-8を想定すべきかどうかではありませんが、それを指定します。

あなたの議論の根底にあるドメインエラーがあると思います。 私たちが話している文字列はどれもユーザー向けではありません。 それらは開発者向けの名前です。 多くの/ほとんどのプログラミング言語はUnicode識別子をサポートしておらず、ツールもサポートしていません。 たとえば、gdbはUnicodeソース識別子を処理できますか？ そうは思いません。 したがって、すべての消費者がこの空間でUnicodeに収束したと仮定することは、非常に楽観的（というより非現実的）です。

「開発者向け」とは「任意のツールチェーン向け」を意味します。つまり、事前にエンコードすることに同意する必要があります。そうしないと、ツールはエンコードの「検出」（つまり、推測）を行う必要があります。これは特に悪い場合です。短い値に適用される）または帯域外情報がある。 開発者はまだユーザーです。 ^ _ ^

多くのツールチェーンがUnicodeを理解しないと思うなら、なぜ他の任意のバイナリエンコーディングを理解すると思うのかわかりません。 それがあなたの制限であるなら、ASCIIを指定して要求するだけです。ASCIIはどこでも100％サポートされています。 ASCIIに制限したくない場合は、受け入れられる非ASCIIエンコーディングスキームが1つあることを受け入れる必要があります-UTF-8。

「ええと、ほとんどのものはおそらくASCIIしかサポートしていませんが、万が一に備えて開発者に必要なものを入れさせます」と言って、両方の世界で最悪です。

「ええと、ほとんどのものはおそらくASCIIしかサポートしていませんが、万が一に備えて開発者に必要なものを入れさせます」と言うのは、両方の世界で最悪です。

@tabatkins 、誰も上記を提案していません。 私が言ったように、問題はそのようなプラットフォーム/環境固有の問題を定義するかどうかではなく、どこにあるかです。 Wasmは、最も広く、最も異種の範囲の環境に埋め込むことができると想定されており、他の環境よりもはるかに豊富なものもあります（たとえば、JSはUnicode識別子をサポートします）。 したがって、プラットフォームごとに選択できるようにする必要があります。 したがって、コア仕様ではなくプラットフォームAPI仕様に属します。

作る選択はありません、トー！ 埋め込み環境が非ASCIIをサポートしていない場合は、文字列で非ASCIIを使用しないでください。 （この場合でも、エンコードの保証が必要です。たとえば、UTF-16はASCII互換ではありません！）

ご使用の環境が非ASCIIをサポートしている場合は、使用するエンコードを知っておく必要があります。すべての状況で正しい選択はUTF-8です。

文字列のエンコーディングを知らないことが利点となる環境をどのように想像していますか？

文字列のセマンティクス（文字セット）ではなく、バイナリ構文（エンコーディング）を制限することは、すべての選択肢の中で最も無意味です。 したがって、すべての実用的な目的で、UTF-8はUnicodeを意味します。

いいえ、絶対にありません。 たとえば、（a）文字列をASCII文字に制限し、（b）UTF-8でエンコードするように指示することは完全に合理的です。 ASCII文字を使用しても、エンコーディングを意味するわけではありません。そうでない場合、すべてのエンコーディングはASCII互換になります。 （たとえば、UTF-16はそうではありません。）したがって、まだ何かを指定する必要があります。 「ASCII互換」であるUTF-8は、これに適しています。

繰り返しますが、これらの名前をASCIIのみに制限しても問題がない場合は、エンコードをUS-ASCIIにすることを義務付けるのが妥当です。 ASCIIを超えて使用できるようにしたい場合は、エンコードをUTF-8にすることを義務付けるのが妥当です。 他のものを義務付けること、または何も義務付けないこと（およびすべての消費者に帯域外情報を推測または使用することを強制すること）は、唯一の不合理な可能性です。

繰り返しますが、これはエンジンだけではありません。 名前をUnicodeとして定義すると、すべての環境のすべてのWasmecoシステムでそれを強制することになります。 そしてそれは、すべての環境でUnicodeをサポートする必要があることを意味します。

繰り返しますが、これは国際化ライブラリについて話しているように見えます。 ここで説明しているのは、バイトシーケンスをデコードして文字列に戻す方法だけです。 これには、UTF-8のデコード方法に関する知識が必要です。UTF-8は非常に簡単で非常に高速です。

人間に優しい文字列操作を行っているのでない限り、必要なのはコードポイントで文字列を比較し、場合によってはコードポイントで文字列を並べ替える機能だけです。どちらも「Unicodeサポート」を必要としません。 たとえば、これは既存のWeb技術が使用するすべてであり、Wasm環境が一般にこれよりも複雑なことを行う必要がある理由はわかりません。

All TheStringsにutf8を義務付けることに賛成です。 純粋なutf8デコード/エンコードは、Web以外の環境では、（他のすべてと比較して）実装の負担がかなり少ないように見えます。 また、私が見たところ、インポート/名前のutf8の検証に費やされる時間は、他のすべてに費やされる時間と比較して重要ではないため、ここでパフォーマンスの議論はないと思います。

実際には、コアwasm仕様でutf8を義務付けていなくても、完全なアイランドでない限り、カスタムツールチェーンもutf8を使用していなければ、何かと相互運用するのは悪い時間になります。 「それをねじ込んで」、とにかくあなた自身の非utf8のことをしてください...それなら誰が気にするからです。

しかし、私が本当にやりたいのは、これをブロックしているように見える解決＃984です...

@ lukewagner ＃984がこれでブロックされているとは思わない。 😄

私はあなたが正しいと思います。

文字列のエンコーディングを知らないことが利点となる環境をどのように想像していますか？

@tabatkins 、私はまだ十分に明確ではないようです。 そんな環境は想像できません。 ただし、互換性のない要件を持つさまざまな環境を想像します。 すべてがUTF-8のサブセットであるわけではありません。たとえば、Latin1はまだかなり広く使用されています。 気にしないかもしれませんが、環境の多様性の邪魔になる不必要な石を置くことは、Wasmのコア仕様の仕事ではありません。

あなたが完全な島でない限り、カスタムツールチェーンもutf8を使用しなかった場合、何かと相互運用するのは悪い時間になります

@lukewagner 、私は確かに、Wasmが潜在的にほとんど重複しないさまざまな「大陸」で使用されることを期待しています。 そして、それらがどこで相互運用を指定することができます（実際には、名前のエンコードは、異なるプラットフォーム間でモジュールを共有するための最も問題が少ないでしょう-それはホストライブラリです）。 島全体でさえ、特に組み込みシステム（Unicodeをほとんど使用しない傾向がある）では非現実的ではありません。

非ブラウザーベースのWebAssemblyエンジンを実装する上で最も難しい部分の1つは、ブラウザーでの動作と同じように動作させることです（主にJS部分）。 エンコーディングが標準化されない場合、誰もがWebターゲットに対して行われたことをコピーするデファクトスタンダードになると思います。 これにより、これらの文字列をデコードする方法に関する情報を見つけるのが難しくなります。

一部の環境で許可されるコンテンツをさらに制限できるようにすることには価値があるかもしれませんが、UTF-8を必要としないと、さらに困難になります。

@ MI3Guy 、反対の提案は、

右。 私のポイントは、JS埋め込みを行っていない場合、WebAssemblyツールチェーンを使用するためにJS埋め込みが行うことの多くをエミュレートする必要があるということです。

コードポイントの数+各コードポイントのUTF-8に対してvaruintを実行します。

私はこのオプションに反対して発言したいと思います。 それは物事を複雑にし、ユーザー固有のセクションには適用できず、適用できず、私が見ることができる利点もありません。UTF-8文字列のコードポイントの数を知るために、実際には常に文字列をスキャンしてエンコーディングが無効であるため、コードポイントを数えた方がよいでしょう。

すべてがUTF-8のサブセットであるわけではありません。たとえば、Latin1はまだかなり広く使用されています。 気にしないかもしれませんが、環境の多様性の邪魔になる不必要な石を置くことは、Wasmのコア仕様の仕事ではありません。

正しい; ASCII範囲を離れると、UTF-8は事実上すべてのエンコーディングとは異なります。 これであなたの主張が何なのかわかりません。 実際には、Latin-1エンコーディングを使用することは、同じように見えても異なる文字をエンコードする他のエンコーディングがたくさんあるため、悪い

ここであなたがどのような「多様性」を守ろうとしているのか、私にはよくわかりません。 他のエンコーディングを使用するメリットは文字通りなく、多くのデメリットがあります。 別のエンコーディングでエンコードできるすべての文字はUnicodeに存在し、UTF-8でエンコードできますが、その逆はほとんどありません。 今日、UTF-8を処理できない関連ツールはありません。 この技術は文字通り20年前のものです。

WasmがWebルールに従う必要のあるWeb仕様であるためではなく、テキストエンコーディングがほとんどすべての人が同じ問題を抱えているエコシステムの問題であり、Webがすでに対処しているため、Web標準は何年も前にこの質問を解決したと言い続けますこれを間違えることの苦痛で、そしてそれを正しくする方法を学びました。 Wasmで再び間違ってしまうことにメリットはありません。 テキストをエンコードする必要のあるすべての環境は、最初からUTF-8に直接移行するか、他のすべての人と同じ間違いを犯して同じ苦痛を味わい、最終的にUTF-8に落ち着きます。 （または、まれに、異なるエンコーディングで標準化できる十分に分離された環境を開発し、外部環境との通信の代償を払うことはめったにありません。しかし、これらすべてのポイントであるエンコーディングで

したがって、JS埋め込みを構築している場合は、どちらの方法でもUTF-8として定義されており、違いはありません。 （ただし、WebでもJavaScriptでもない他の埋め込みAPIも許可したいと思います。）

この問題は、WebやJSとは何の関係もありません。 エコシステムのすべての部分で、既知の一貫性のあるテキストエンコーディングが必要であり、プログラミング環境、国、言語全体で広く合意されているUTF-8が1つあります。

私は「長さ（バイト単位）+各バイトのUTF-8にvaruintを実行する」に投票します。 それが物議を醸す選択ではないと仮定すると、ほとんどすべての文字列実装は、文字列を「コードポイントの数」ではなく「コードユニットの数」として格納します。これは、より単純であるためです。「文字列がそうでない場合、検証が失敗するかどうか」は本当の問題ではありません。有効なUTF-8 "？

＃970で指摘したように、無効なUTF-8はUTF-16にれる可能性があるため、無効なUTF-8が許可されている場合、元のバイトを格納したくないソフトウェアはその必要はありません。 一方、UTF-8が有効かどうかを確認するのは難しくありません（ただし、答える必要があります-長すぎるシーケンスを受け入れる必要がありますか？代理文字ですか？）

全体として、UTF-8を義務付けようと言いたいです。 誰かがUTF-8に変換できないバイトを持っているという奇妙なケースでは（おそらくエンコーディングが不明なため）、任意のバイトをUTF-8に音訳することができます。

ここであなたがどのような「多様性」を守ろうとしているのか、私にはよくわかりません。

@tabatkins 、はい、それは誤解の核心のようです。

WebAssemblyは、その名前にもかかわらず、Webに限定されないことを理解することが重要です。 各レイヤーが可能な限り広く使用できるように、適切なレイヤーで定義することには非常に注意が必要です。

最も注目すべきは、その_core_は実際には_まったく_Webテクノロジーではないということです。 その代わり、_virtualとしてそれについて考えてみるISA _。 このような抽象化は、非常に豊富な（Web）から非常に初歩的な（組み込みシステム）まで、さまざまな環境で役立ちます。これらの環境は、必ずしも相互に関係がなく、ほとんど互換性がなく、競合する制約があります（そのWasmは変更する立場にありません）。

そのため、Cプログラミング言語のすべての文字列リテラルにUnicodeを課すよりも、_core_WasmにUnicodeを課すことは意味がありません。 一部の潜在的なクライアントに、この標準のビットに違反するように強制するだけです。 利益は何ですか？

ただし、このコアスペックの上に、_concrete_環境（JavaScriptなど）での埋め込みとAPIを定義する追加のスペックレイヤーがあります。 そのレベルで文字列エンコーディングを修正することは完全に理にかなっています、そして、どうしても、そうすべきです。

PS：Wasmの範囲を定義するスローガンは、それが一般的なプログラミング言語の抽象化ではなく、一般的なハードウェアの抽象化であるということです。 また、ハードウェアは、文字列エンコーディングなどのソフトウェアの問題に依存しません。 それがABIの目的です。

@ rossberg-クロム

そのため、Cプログラミング言語のすべての文字列リテラルにUnicodeを課すよりも、コアWasmにUnicodeを課すことは意味がありません。 一部の潜在的なクライアントに、この標準のビットに違反するように強制するだけです。 利益は何ですか？

私は100％同意します。 ただし、この問題はUnicodeに関するものではなく、整数をUnicodeとして解釈することを義務付けずに、純粋にUTF-8（整数のエンコーディング）に関するものです。

同意するかどうかわかりません。 明確にできますか：UTF-8で問題ありませんか？そうでない場合はその理由を教えてください。

@jfbastien 、すべてのC文字列リテラルにUTF-8準拠を要求することは、これ以上生産的でしょうか？

前に述べたように、エンコードを制限することは意味がありませんが、文字セットを制限することは意味がありません。 これは、セマンティクスなしで構文を定義するようなものです。 なぜあなたはおそらくそれをするのですか？ 相互運用に関してはゼロになりますが、UTF-8を使用しない環境（とにかくUnicode環境のみが使用します）に対しては、人為的なハードルが発生します。

@jfbastien 、すべてのC文字列リテラルにUTF-8準拠を要求することは、これ以上生産的でしょうか？

わかりませんが、はっきりさせていただけますか？

前に述べたように、エンコードを制限することは意味がありませんが、文字セットを制限することは意味がありません。 これは、セマンティクスなしで構文を定義するようなものです。 なぜあなたはおそらくそれをするのですか？ 相互運用に関してはゼロになりますが、UTF-8を使用しない環境（とにかくUnicode環境のみが使用します）に対しては、人為的なハードルが発生します。

議論の核心だと思います。

@tabatkinsはまさにこれの前例に触れました：

繰り返しますが、これは国際化ライブラリについて話しているように見えます。 ここで説明しているのは、バイトシーケンスをデコードして文字列に戻す方法だけです。 これには、UTF-8のデコード方法に関する知識が必要です。UTF-8は非常に簡単で非常に高速です。

人間に優しい文字列操作を行っているのでない限り、必要なのはコードポイントで文字列を比較し、場合によってはコードポイントで文字列を並べ替える機能だけです。どちらも「Unicodeサポート」を必要としません。 たとえば、これは既存のWeb技術が使用するすべてであり、Wasm環境が一般にこれよりも複雑なことを行う必要がある理由はわかりません。

だから私は同意します：この提案は、あなたの言葉では、「セマンティクスなしで構文を定義する」ことです。 それは非常に一般的なことです。 実際、WebAssemblyの現在の長さ+バイトの仕様はすでにこれを行っています！

ハードルとは何かを知りたいのですが。 本当に見えません。

WebAssemblyは、その名前にもかかわらず、Webに限定されないことを理解することが重要です。

直前のコメントで、これはWebとは何の関係もないと述べました。 あなたはこの議論を使い続けようとします、そしてそれは私を本当に混乱させます。 私が言っていることはウェブとは何の関係もありません。 私は単に、学んだ教訓の重要な例としてWebの経験を指摘しているだけです。

そのため、Cプログラミング言語のすべての文字列リテラルにUnicodeを課すよりも、コアWasmにUnicodeを課すことは意味がありません。 一部の潜在的なクライアントに、この標準のビットに違反するように強制するだけです。 利益は何ですか？

文字列リテラルはASCIIエンコーディングを使用するため、Cには組み込みのエンコーディングがあります。 （他に何かが必要な場合は、適切なバイトシーケンスをエスケープして手動で行う必要があります。）最新のC ++では、UTF-16およびUTF-8文字列リテラルを使用できますが、 \xエスケープ、 \uエスケープは、少なくとも値が有効なコードポイントであることを確認します。

文字からバイトへの固有のマッピングがないため、これらすべてが必要です。 それがエンコーディングが行うことです。 繰り返しますが、指定されたエンコーディングがないということは、言語のユーザーが他の当事者からバイトシーケンスを受け取ったときに、エンコーディングを推測してテキストに戻す必要があることを意味します。

相互運用に関してはゼロになりますが、UTF-8を使用しない環境（とにかくUnicode環境のみが使用します）に対しては、人為的なハードルが発生します。

Unicodeに含まれていない文字を使用する既存の環境を指摘していただけますか？ あなたは理論的な純度/環境の多様性の観点からこの立場を擁護しようとし続けますが、文字通りUnicodeの全体的なポイントはすべての文字を含める

どのような多様性を保護しようとしていますか？ 一例でも見られたら嬉しいです。 ：/

@tabatkins ：

WebAssemblyは、その名前にもかかわらず、そうではないことを理解することが重要です。
Webに限定されます。

直前のコメントで、これには何もないと述べました
ウェブと関係があります。 あなたはこの議論を使い続けようとします、そしてそれは本当にです
私を混乱させます。 私が言っていることはウェブとは何の関係もありません。 私はただ
学んだ教訓の重要な例として、Webの経験を指摘します。

私が強調しようとしているのは、Wasmは多くの人に適用できるはずだということです
可能な限りプラットフォーム、現代かどうか。 あなたは幸せな終わりから議論し続けます
すべてがUnicodeおよび/またはUTF-8であり、すべてが
それ以外の場合は非推奨です。

あなたはあなたがしていると思うことを主張しては

文字列リテラルはASCIIエンコーディングを使用するため、組み込みエンコーディング。 （お望みならば
あなたが適切なバイトをエスケープすることによって手でそれをしなければならない他の何か
シーケンス。）最新のC ++では、UTF-16およびUTF-8文字列を使用できます。
リテラル、そしてあなたはまだ任意のバイトを文字列に入れることができますが
\ xエスケープ、\ uエスケープは、少なくとも値が有効であることを確認します
コードポイント。

いいえ、それは正しくありません。 C仕様はASCIIを必要としません。 それもしません
ASCIIとの互換性が必要です。 それはほぼ任意の「ソース」を許可します
文字セット」と文字列リテラルには、完全な文字から任意の文字を含めることができます
設定。 エンコーディングに関する制約はありません、それは完全にです
実装定義。 で実行されているCの実装があります
EBCDICプラットフォーム、およびそれは現在の標準で引き続きサポートされています。 GCC
任意のiconvエンコーディング（約140個あります）でソースを処理できます
UTF-8以外）、たとえばアジアで人気のあるUTF-16。 C ++も例外ではありません。

（それは@jfbastienの質問にも答えるはずです。）

からの固有のマッピングがないため、これらすべてが必要です。文字からバイト。 それがエンコーディングが行うことです。 繰り返しますが、
指定されたエンコーディングとは、その言語のユーザーが受信したときに
他の当事者からのバイトシーケンスは、変換するためにエンコーディングを推測する必要があります
それらをテキストに戻します。

繰り返しますが、これは環境ごとに適切に指定されます。 誰かが
同じエコシステムで動作している他の誰かからWasmモジュールを受け取ります
それなら問題ありません。 JS開発者が気にする必要はありません。

ただし、誰かが_別のエコシステム_からモジュールを受け取っている場合は、
心配すべき非互換性の原因は他にもたくさんあります。
API、組み込みライブラリなどに関する期待。両当事者は以下を行う必要があります。
とにかく、相互運用の前提について明確にしてください。 名前に同意する
エンコーディングは彼らの問題の中で最も少ないものになるでしょう。

相互運用に関してはゼロになりますが、それでも

UTF-8を使用しない環境（Unicode環境のみが使用します）
とりあえず）。

を使用する既存の環境を指摘していただけますか
Unicodeに含まれていない文字？ あなたはこれを守ろうとし続けます
理論的な純度/環境の多様性の観点からの位置、しかし
文字通り、Unicodeの全体的なポイントは、すべての文字。 リモートで作成できる唯一の文字セットです
そうするための信頼できる議論、そしてあなたがUnicode文字を使用しているとき
セットでは、UTF-8が推奨されるユニバーサルエンコーディングです。

どのような多様性を保護しようとしていますか？ でも見るのは素晴らしいことです
単一の例。 ：/

たとえば、組み込みOSのリストは次のとおりです： https ：
カテゴリ：組み込み_オペレーティングシステム
それらのいくつかはUTF-8を使用する可能性が高く、使用しないものもあります。 Wasmの用途を見つける人もいるかもしれませんが、
ほとんどの場合、そうはなりません。 しかし、それを減らすことには私たちにとって何のメリットもありません
彼らにとって便利です。

あなたがおそらくまだよく知っているそのリストからの1つのエントリはDOSです。 NS
私たち全員が死ぬのが好きなのと同じように、DOSシステムはまだ活気があり、
OEM。

@jfbastien ：

だから私は同意します：この提案は、あなたの言葉では、「構文を定義せずに
セマンティクス」。これは非常に一般的なことです。実際、WebAssemblyの
現在の長さ+バイトの仕様はすでにこれを行っています！

私が知っているそのようなことのまれな出来事はすべてと関係があります
実装固有の動作のためのエスケープハッチを提供します。 それは
また、唯一の合理的なユースケースです。 ただし、ここでは意味がありません。 もし、あんたが
文字列にそのようなエスケープハッチを提供したいのなら、なぜわざわざ必要なのか
UTF-8、バイト文字列「構文」を許可する代わりに？ それはなしの構文です
イネーブラーではなく、ディセーブルとしてのセマンティクス。

ハードルとは何かを知りたいのですが。 本当に見えません。
>>
一部のクライアントは単純にすべてのバイト値を使用することはできませんが、通過する必要があります
エコシステムで使用されない冗長UTFエンコーディング。 そのすべて
ツールチェーン内のツールもそれを気にする必要があります。 そのこと
（範囲外の値の）追加のエラーケースを作成しますが、
そうでなければ彼らのために存在します。

逆に質問させてください:(彼らのエコシステムにおける）利点は何ですか？
本当に見えません。

@tabatkins
境界線がどこにあるかを確実に理解したい。
明確にするために、組み合わせて無効であるかどうかに関係なく、コードポイントのutf-8エンコーディングのみを提案しています（これは10行のコードで実行できます）。
たとえば、太字の大文字を仕様で使用して、次のことを示すことができます。Wasmを実装するために国際化ライブラリが必要だと思われる場合、何か問題がありますか？

これの目標は次のとおりです。

• Web上で終わる有効なwasmが、少なくとも無効なものの豆腐文字を表示できることを確認してください。
• （Web以外のコンテキストでも）wasmを生成するツールが、ASCIIを超える必要がある場合は、他のエンコーディングよりもUnicodeを優先するように推奨します。 （完全な検証が行われないため、この方向にソフトバンプが発生します）。

質問？

• これがさらなる検証のための忍び寄る要件になる危険性はありますか？ この分野での私の中心的な関心事は、ICUを依存関係として飲み込むことは常に不合理な負担になるだろうと思います。

• これは、UTF-8と衝突するLatin1のようなエンコーディングを積極的に奨励するという目標を意味していると思いますか？ つまり、それを放出するツールチェーンは非準拠であり、同様にそれを受け入れる実装です。

• 以前はアイランドをエンコードしていたリージョンのビットが重複して使用されていたため、これまでWebでこのスペースを統合するのに問題がありました。 一方、私の印象では、UTF-8は、移行のコストが非ASCIIの人々によって不釣り合いに負担され、一部の地域ではより多くの部分が組み込まれるように設定されています。ユニコード移行は実際的な必然性だと思います。 （そしてほぼ完了）。 Unicodeに関する政治的および地域的な問題のいくつかがWeb上でどのように解決されたかに対処する、指摘できる一元化されたドキュメント/エンティティはありますか？

@ rossberg-クロム

• エンコーディングの一部の側面を検証する際に論理的な矛盾が見られますが、他の側面は検証されていません。 一方、私の印象では、utf8はこの時点で普及しています（そして、ツールと検証のわずかな微調整は低コストです）。 あなたの主な不快感は、仕様に裸のutf-8検証を追加することで、矛盾やその他の何かがありますか？

明確にするために、組み合わせて無効であるかどうかに関係なく、コードポイントのutf-8エンコーディングのみを提案しています（これは10行のコードで実行できます）。

はい、無効な組み合わせはないと思います。 UTF-8としてエンコードするには技術的に無効な個々のコードポイント（UTF-16サロゲート用に予約されているもの）がいくつかあります。 とはいえ、フルバイト制御が望ましい場合は、 WTF-8エンコーディングが存在しますが、目標として「はい、これらの文字列に実際に任意の非文字列データを含めることを許可したい」ということを明確にする必要があります。私たちはそのように行きます。 WTF-8（およびWTF-16）形式は、UTF- *整形式の実施に後方互換性の制約がある環境の正式な仕様を提供することのみを目的としています。

たとえば、太字の大文字を仕様で使用して、次のことを示すことができます。Wasmを実装するために国際化ライブラリが必要だと思われる場合、何か問題がありますか？

はい、i18nはいかなる方法、形状、形式でも必要ありません。 たとえば、CSSのデフォルトはUTF-8であり、ASCII範囲外のものを許可する場合は、生のコードポイントの比較/ソートを実行します。 Wasmがこれ以上進む理由もありません。

これがさらなる検証のための忍び寄る要件になる危険性はありますか？ この分野での私の中心的な関心事は、ICUを依存関係として飲み込むことは常に不合理な負担になるだろうと思います。

これまでのところ、Webプラットフォームでベアネームに追加の検証を課す必要はありませんでした。 私の経験では、それは決して必要ではないことを示唆しています。

これは、UTF-8と衝突するLatin1のようなエンコーディングを積極的に[無効化]するという目標を意味していると思いますか？ つまり、それを放出するツールチェーンは非準拠であり、同様にそれを受け入れる実装です。

はい、あなたの言葉で「DIS couraging」への変更を伴います。 ^ _ ^要点は、プロデューサーとコンシューマーが、他のエンドポイントが何をしているのかを推測することなく、バイトシーケンスとの間で文字列を確実にエンコードおよびデコードできることです。 これは、これまでに遭遇したすべての環境にとって恐ろしい苦痛であり、現在広く採用されている解決策があります。

以前はアイランドをエンコードしていたリージョンのビットが重複して使用されていたため、これまでWebでこのスペースを統合するのに問題がありました。 一方、私の印象では、UTF-8は、移行のコストが非ASCIIの人々によって不釣り合いに負担され、一部の地域ではより多くの部分が組み込まれるように設定されています。ユニコード移行は実際的な必然性だと思います。 （そしてほぼ完了）。 Unicodeに関する政治的および地域的な問題のいくつかがWeb上でどのように解決されたかに対処する、指摘できる一元化されたドキュメント/エンティティはありますか？

はい、移行中に間違いなく問題がありました。 HTMLは、バックコンパットのためにデフォルトでLatin-1にする必要があり、言語固有のエンコーディング（主に日本語エンコーディングであるShift-JIS）を好むWebコンテンツの小さなポケットがまだいくつかあります。 しかし、世界の大多数は過去20年間で切り替えを行っており、移行はほぼ完了したと見なされています。

「UTF-8は非ASCIIの人々に負担をかける」というのは、長い間、有害ですが、ほとんど完全に真実ではないという噂です。 ほとんどのヨーロッパ言語には、そもそもASCIIアルファベットの大部分が含まれているため、テキストのほとんどは1バイトシーケンスであり、最終的にUTF-16よりも小さくなります。 同じことが拼音のような書記体系にも当てはまります。 CJK言語は主に3バイトのUTF-8領域を占めますが、特にマークアップ言語やプログラミング言語では大量のASCII文字も含まれているため、一般に、UTF-8のエンコードサイズは小さいか類似しています。 UTF-16またはそれらの特殊なエンコーディング。

UTF-8が実際に特殊なエンコーディングよりも多くのスペースを占めるのは、CJKまたはキリル文字などの非ASCIIアルファベットの大量の生テキストの場合のみです。 ただし、これらは懸念事項でした。 90年代初頭、ハードドライブの容量がメガバイト単位で測定され、テキストファイルサイズのわずかな増加が実際に重大な問題になる可能性がありました。 これは20年近く懸念されていません。 サイズの違いは今ではまったく重要ではありません。

「Unicodeへの移行」については、すでにかなり普遍的に行われています。 最近、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ビット値の_ちょうど別の不透明なバイナリblob_です。 情報は提供しません。 それを自分の文字列に関連付ける方法がわかりません。

それでは、なぜ私は未知の文字列をデコードすることさえわざわざするのでしょうか？ ええと、_私はしません_！ 8ビット値の元のバイナリブロブを使用して、スペースとサイクルを節約することもできます。 ただし、この仕様では、エンコーディングを空虚に検証するためにサイクルを費やす必要があります。

これらすべてを考慮すると、この特定の提案を採用することで、（コア）Wasmまたはツールは何を得るでしょうか？

AFAICS、特定のエンコーディングを規定していますが、文字セットは規定していません
両方の世界の最悪の組み合わせ：それは次の点でコストを課します
制限、複雑さ、およびオーバーヘッドがあり、実際のメリットはありません。
相互運用。 私はまだポイントが何であるか混乱していると思います。

私たちは間違いなく文字セット、つまりUnicode文字セットを課しています。 JFは以前、非常に紛らわしい言い回しをしていたので、注意を払わないでください。 これは、実際にこれを実施するためにWasmにチェックを追加する必要があるという意味ではありません。 デコーダーは通常、無効な文字を処理するのに十分な堅牢性を備えています。 （たとえば、Webは通常、それらをU + FFFD REPLACEMENT CHARACTERに置き換えるだけです。）

これが具体的なシナリオです。 異なるプラットフォームを使用していて、モジュールを渡そうとしているとします。 議論のために、私のプラットフォームがEBCDICとあなたのASCIIを使用していると仮定します。 現在の提案の下で完全に合法です。 それでも、私のモジュールはあなたとあなたのツールチェーンにとって完全に役に立たないでしょう。

数十年前のシステムが関連しているだけでなく、関連性がため、同じ数十年にわたって痛みをエンコードすることについて私たちが学んだすべてに反する決定を下すのを正当化するのをやめる

多くの異なるシステムがこの混乱のすべてを通り抜けました。 エンコーディング戦争は面白くありませんでした。 彼らは多くのお金と時間を浪費し、多くの破損したテキストをもたらしました。 私たちはそれらの戦争を終えました。 Unicodeが作成され、公布され、全世界で支配的な文字セットになりました。この時点で、他のすべての文字セットは文字通り歴史的な好奇心にすぎません。 UTF-16とUTF-8のどちらを使用するかについては、まだ低レベルの煮えたぎる戦いがありますが、少なくともこれら2つは通常、簡単に区別できます（BOMを確認するか、ヌルバイトの優位性を探します）。 -8が手軽に支配します。

エンコーディングの自由に対するあなたの主張は、この歴史のすべて、Unicodeが導入されてから20年で学んだすべての教訓を無視しています。 システムは特定の方法でエンコードされているすべてのものを信頼できるため、エンコードの問題をほとんどのユーザーに見えなくする効果があった最新のシステムの設計に費やされたすべての経験と専門知識を無視します。 一度に1つずつ文字化けを続けると、深刻で、有害で、費用のかかる問題が発生します。

@ rossberg-クロム

これが具体的なシナリオです。 異なるプラットフォームを使用していて、モジュールを渡そうとしているとします。 議論のために、私のプラットフォームがEBCDICとあなたのASCIIを使用していると仮定します。 現在の提案の下で完全に合法です。 それでも、私のモジュールはあなたとあなたのツールチェーンにとって完全に役に立たないでしょう。

では、UTF-8は何をもたらすのでしょうか？ ええと、私は私が得た未知の文字列を「デコード」することができました。 しかし、私が知っている限りでは、結果は31ビット値の別の不透明なバイナリブロブになります。 情報は提供しません。 それを自分の文字列に関連付ける方法がわかりません。

UTF-8は、それを独自の文字列に関連付ける方法を正確に教えてくれます。 それはまさにそれが解決する問題です。 （WTF-8は、可能であればそれも行い、不可能な場合は明確に通知します。）

文字列形式にマングルされてUTF-8としてエンコードされた任意のデータ構造を意味しますか？ 確かにそれをデマングルすることはできませんが、少なくともマングルされた名前を文字列として明確に表示することはできます。これは、一部のユースケースでは何も持たないことよりも改善されています。

Unicodeではなく不透明な整数のエンコーディングとしてUTF-8を使用することについての上記の説明を意味しますか？ 議論は少し混乱していると思います。 エンコーディングを「構文」、国際化を「セマンティクス」と呼びたくなりますが、それは有用な区別をあいまいにします。UTF-8は、消費者がその情報と何をしなければ意味すると言うことができます。 このように使用すると、Unicodeのエンコーディングになりますが、上記で「Unicodeサポート」を使用したようなコストは必要ありません。

それでは、なぜ私は未知の文字列をデコードすることさえわざわざするのでしょうか？ まあ、私はしません！ 8ビット値の元のバイナリブロブを使用して、スペースとサイクルを節約することもできます。 ただし、この仕様では、エンコーディングを空虚に検証するためにサイクルを費やす必要があります。

これで、overlongやサロゲートを含むwasmインポート/エクスポート識別子の完全なUTF-8検証を備えたSpiderMonkeyを構築しました。 AngryBotsでも、30のインポートがあるにもかかわらず、emscriptenでコンパイルされた小さなテストケースでも、 WebAssembly.validateパフォーマンスの違いを検出できませんでした。

仕様は、複数の懸念事項の間の妥協点です。 起動時間の心配がありますので、実験をして測定しました。 私は他の人に彼ら自身の実験をすることを勧めます。

さらに、UTF-8はUnicodeエンコーディングだけではなく、Unicode以外の整数をエンコードするために使用できます。 したがって、UTF-8はUnicodeではありません。

Unicodeの一部ではない（つまり、U +0000からU + 10FFFFの範囲外の）UTF-8でエンコードできる整数はどれですか？ その声明は間違っているようです。

文字を検証しない場合は、任意の21ビット整数をエンコードできます。

なぜ検証しないのかよくわかりません...

@flagxor https://encoding.spec.whatwg.org/は、Webに公開されているさまざまなエンコーディングについて説明しています。 それらのどれもUnicode文字セットの外に出ることはありませんが、明らかにすべてが互いにバイト互換であるとは限らないことに注意してください。

「検証」は何をしますか？ あなたのwasmプログラムを無効にしますか？ 合理的に課すことができる実際の結果はないと思います。

同様に、CSSで無効なエスケープを使用すると、U + FFFDがスタイルシートに追加されるだけで、奇妙なことは何も起こりません。

@annevk ：

さらに、UTF-8はUnicodeエンコーディングだけではなく、Unicode以外の整数をエンコードするために使用できます。 したがって、UTF-8はUnicodeではありません。

Unicodeの一部ではない（つまり、U +0000からU + 10FFFFの範囲外の）UTF-8でエンコードできる整数はどれですか？ その声明は間違っているようです。

少なくとも：U + FFFEとU + FFFFはUnicodeでは文字ではありません。 コードポイント（整数値）は、Unicodeが文字をエンコードするために使用することはありませんが、UTF-8でエンコードすることはできます。

ただし、これらはまだUnicodeコードポイントです。 私は「キャラクター」にあまり焦点を合わせません。

@tabatkinsをU +

そのため、Cプログラミング言語のすべての文字列リテラルにUnicodeを課すよりも、コアWasmにUnicodeを課すことは意味がありません。 一部の潜在的なクライアントに、この標準のビットに違反するように強制するだけです。 利益は何ですか？

C11がchar16_tおよびchar32_tタイプに加えて、UTF-16でエンコードされた文字列リテラルのuプレフィックス、 Uプレフィックスを追加したことに注意してください。 UCS-4でエンコードされた文字列リテラル、およびUTF-8でエンコードされた文字列リテラルのu8プレフィックス。 それらを追加する理由を見つけるのに十分なほど深く掘り下げていませんでしたが、「標準のC / C ++でUnicodeを扱うことは悪夢です」は、少なくとも動機の一部であると思います。

@ tabatkins 、 @ sunfishcode 、わかりました。同じことについて話しているわけではありません。 しかし、AFAICT @jfbastienは、彼の提案はUnicode文字セットなしでUTF-8を指定することに関するものであると明示的かつ繰り返し述べています。

それはまた、低コストの主張が支持される唯一の解釈です。

UTF-8がUnicodeを意味すると実際に_do_仮定すると、この要件は、Unicode（のサブセット）をまだ話していないシステム上のツールのUTF-8エンコード/デコードよりもはるかに高価になるためです。完全なトランスコーディング層を含める必要があります。

@tabatkins 、コアWasmは、既存のシステムに組み込まれます-移植性以外の理由で-変更したり、何かを課したりすることはできません。 あなたが説明する問題に直面した場合、それらはWasmとは独立して存在します。 _We_は_their_の問題を修正できません。

それらすべてにUnicodeを課そうとする_試み_の可能性のある結果は、いくつかの潜在的なものが仕様のその部分に単に違反し、それを完全に無意味にすることです（さらに悪いことに、彼らはWasmを完全に無視します）。

OTOHが適切なレイヤーで指定した場合、実際には何も失うことなく、そのリスクを冒すことはありません。

UTF-8がUnicodeを意味すると実際に想定している場合、この要件は、Unicode（のサブセット）をまだ話していないシステム上のツールのUTF-8エンコーディング/デコーディングよりも確かにはるかに高価です-彼らは完全なトランスコーディング層を含める必要があります。

UnicodeでもASCIIでもないネイティブ文字セットを使用し、それらの文字をUnicodeとの間で変換する機能がなく、Wasmで非ASCII識別子を使用する必要があるプラットフォームはどのようなものですか？ （つまり、DOSで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 + Unicodeを義務付ける
• モジュールが検証するためにUnicodeが検証する必要がないことを明示的に述べる（コストを節約するため）

@ rossberg-chromiumは、完全なICUライブラリの追加コストを望まない組み込みシステムのようなデバイスに関係している（または少なくとも私はそうなるだろう）と思います。 彼らは、膨張を受け入れることを余儀なくされるか、完全な検証を行わないか、または非ASCII文字を含むwasmファイルを受け入れないかのいずれかです（これは制御できない可能性があります）。

繰り返し述べたように、これは赤いニシンです。 ICUに関連してリモートで何もする必要はありません。 ウェブは間違いなくそうしません。 この誤った情報の拡散を止めてください。

「完全検証」は非常に簡単な操作であり、準拠するUTF-8デコード操作の一部として自動的に実行されます。

@tabatkinsとチャットする
修飾子の割り当てられていないコードポイントなどの任意の組み合わせを許可するには、準拠するUnicodeデコーダーが必要です。したがって、修飾子などの漂遊混合は、それが意味のあるものにレンダリングされない場合でも、Unicodeで許可される必要があります。 ナンセンスな組み合わせを拒否したデコーダーは非準拠になります。

したがって、適切にUTF-8デコードするための要件は、数行のコードで実行できるものであることが明確にスコープされており、正確な操作であり、バイトのUnicode + utf-8解釈を指定することと本質的に同等です。

はい。 UTF-8の解析は非常に簡単です。 唯一の問題は、UTF-8でのエンコードが許可されていない少数のコードポイントです。これは、準拠したデコーダーが1つ以上のU + FFFD文字として解析します。

しかし、それはエンドポイントが実行する操作です。 Wasmはこれに関係する必要はありません。 準拠したデコーダーは、スローした任意のビットパターンを処理できます。 （彼らは、ごみのビットパターンのほとんどがU + FFFD文字であると判断するだけです。）私がずっと求めてきたのは、これらの文字列をUTF-8でエンコードするという作成者レベルの適合要件だけです。 これに違反した場合、ツールチェーンはエラーとしてフラグを立てることができますが、Wasm自体が行う必要のあることは何もありません。

これは、たとえば、有効なスタイルシートを構成するものの文法を定義するCSSに似ていますが、技術的には任意のビットパターンを受け入れます。

また、厳密に言えば、このようなデバイスには、次のような非標準の文字セットを持つハードウェアが含まれていることがよくあります。

そのような文字セットの存在は、人々がそれら（の非ASCII範囲）にWasm識別子を書くことを期待しない限り、Wasmとは無関係です。

そうです、「UTF-8を使用する」という意味はすべてhttps://encoding.spec.whatwg.org/#utf-8-decoderです。 ICUは要件にさえ近づいていません。

午前1時13分に2017年2月25日、ブラッド・ネルソン[email protected]は書きました：

@tabatkins https://github.com/tabatkinsとのチャットで、1つのことが
ここで明確にすることが重要だと思います。
任意のUnicodeデコーダーを使用できるようにする必要があります
修飾子の未割り当てのコードポイントなどの組み合わせ。
モディファイアなどは、それが意味のあるものにレンダリングされなくても、
Unicodeで許可する必要があります。 ナンセンスを拒否したデコーダー
組み合わせは非準拠になります。

したがって、UTF-8デコードを適切に行うための要件は、次のように明確にスコープされています。
数行のコードで実行できることは、正確な操作です。
基本的に、Unicode + utf-8を指定するのと同じです。
バイトの解釈。

私が言ったことを明確にするために。 私は完全なICUがおそらくそうではないだろうと異議を唱えません
必要です（たとえば、コードポイントで名前を並べ替えるのは悪いように聞こえますが
使いやすさ）。

ただし、些細なデコードだけが残っているという主張は正しくありません
検証だけにとどまらないからです。 非Unicodeプラットフォーム
実際に文字列を処理するためにトランスコーディングを実行する必要があります。
さらに、彼らはキャラクターの問題に対処する必要があります
（どちらの方向にも）マッピングできないため、互換性はあります
一般的な問題は、缶を蹴っただけです。

>>

また、厳密に言えば、そのようなデバイスには、多くの場合、
次のような非標準の文字セット：

そのような文字セットの存在は、あなたがいない限り、Wasmとは無関係です。
人々がそれら（の非ASCII範囲）にWasm識別子を書くことを期待してください。

@rocallahan https://github.com/rocallahan 、彼らはまだできる必要があります
任意のUnicodeを取り込みます。 しかし、彼らはそれで何をしますか？ Wasmの場合
ASCIIに制限されたそのようなプラットフォームでの実装は、
提案された仕様に違反しています。 （私はそれがそれを意味するとも考えます
誰かの非ASCII文字は無関係です先験的に文化的かもしれません
疑わしい。 それは彼らが決めることです。）

さらに、（どちらの方向にも）マップできない文字の問題に対処する必要があるため、一般的に互換性の問題が発生し、缶を蹴り飛ばすだけです。

これは理論上の懸念ですか？

そして、それは合理的な懸念だ場合、我々は再び世界のエンコーディングに依存することができない

非Unicodeプラットフォームは、実際に文字列を処理するためにトランスコーディングを実行することを余儀なくされます。

しかし、Wasmストリングはどのような場合にプラットフォームストリングと相互運用する必要がありますか？ 私が知る限り、Wasmメタデータ内の文字列のエンコードについてのみ話しているのであり、実際のモジュールコードによって操作される文字列のエンコードについては話していません。 （それが間違っている場合は、お詫びします...）次に、相互運用/トランスコーディングが必要になる可能性のあるいくつかのケースのみを考えることができます。

• Wasmモジュールはプラットフォーム識別子をインポートします
• プラットフォームはWasm識別子をインポートします
• Wasm名を抽出して印刷するか、プラットフォーム文字列を使用して保存します。たとえば、スタックトレースをダンプします。

右？

仮想の非Unicode組み込みシステムの場合、最初の2つのケースでは、アドバイスは単純です。プラットフォームの境界を越えてインポートされる識別子をASCIIに制限すると、必要なトランスコーディングは簡単です。 Wasmモジュールは、内部および相互リンクのために完全なUnicode名を引き続き使用できます。

3番目の問題について--- Wasmモジュールの閉じた世界がある場合は、それらの識別子をASCIIに制限できます。 そうでない場合は、実際にはUTF8識別子に遭遇し、それらをトランスコードできる方がよいでしょう。仕様でUTF8が義務付けられていることをうれしく思います。

誰かの非ASCII文字が先験的に無関係であることを意味します

それはストローマンの議論です。 ここでの位置付けは、「非ASCII識別子が必要な場合は、Unicodeを使用するか、Unicodeとの間のトランスコーディングを実装する」であり、他の仕様であるAFAIKでは「文化的に疑わしい」との批判は受けていません。

>>

そして、それが合理的な懸念である場合、私たちはもう一度（発生

• コスト）実質的に他のすべてのコストに対して
  エンコーディングに依存できない
  同じエンコーディングを処理する必要があります-Webプラットフォームが通過しなければならなかった地獄、
  そして最終的には可能な限り修正されました。

@tabatkins 、いや、また（そしてどういうわけか私はこれを100回繰り返したような気がする
すでに回）：すべての埋め込み仕様はエンコーディングを指定し、
キャラクターセット。 すべてのプラットフォームで、これを信頼できます。 あなたは今まで走っただけだろう
無関係な2つの間で相互運用しようとした場合は、エンコードの質問に
エコシステム-より深い理由ですでに互換性がない
文字列。 そして、これは他の方法で行うプラットフォームとの相互運用にのみ影響します
完全に除外します。 だからあなたは_何も失うことはありません_が、使用する能力を獲得します
より多様なプラットフォームでのWasm。

あなたはソフトウェアエンジニアです。 そのため、私はあなたが理解し、感謝していると思います
関心の分離と最大化のためのモジュール化と階層化の価値
再利用。 それはスペックにも当てはまります。

>>

非Unicodeプラットフォームは、実際にトランスコーディングを実行することを余儀なくされます
それらの文字列を処理します。

どのような場合に、Wasmストリングはプラットフォームストリングと相互運用する必要がありますか？
けれど？ 私が知る限り、私たちはのエンコーディングについて話しているだけです
Wasmメタデータ内の文字列であり、によって操作される文字列のエンコーディングではありません
実際のモジュールコード。 （それが間違っているなら、私は謝罪します...）そして私は考えることしかできません
相互運用/トランスコーディングが必要になる可能性のあるいくつかのケースの例：

• Wasmモジュールはプラットフォーム識別子をインポートします
• プラットフォームはWasm識別子をインポートします
• Wasm名を抽出して印刷するか、プラットフォームを使用して保存します
  文字列、たとえばスタックトレースをダンプします。

右？

はい。 言い換えれば、実際に文字列を使用する必要があるたびに。

仮想の非Unicode組み込みシステムの場合、最初の2つのケースでは、
アドバイスは簡単です：プラットフォーム全体にインポートされる識別子を制限します
ASCIIの境界である場合、必要なトランスコーディングは簡単です。 Wasmモジュール
内部的にも相互にリンクするためにも完全なUnicode名を使用できます。

3番目の問題について--- Wasmモジュールの閉じた世界がある場合は、
識別子をASCIIに制限できます。 そうでない場合は、実際には
UTF8識別子に遭遇すると、それらをトランスコードできるようになります。
仕様で義務付けられているUTF8を喜んでいただけることでしょう。

この提案では、ASCIIに制限することはできません。 に
コアスペックがより許容される必要があることを許可します。 だからあなたは作っています
私のポイント。

すべての埋め込み仕様は、エンコーディングと文字セットを指定します。 すべてのプラットフォームで、これを信頼できます。 2つの無関係なエコシステム間で相互運用しようとした場合にのみ、エンコーディングの質問に遭遇することになります。これは、文字列よりも深い理由ですでに互換性がありません。

逆アセンブラなどのWasm処理ツールはどうですか？ 「埋め込み仕様」のバリアントに関係なく、任意のWasmモジュールで動作する逆アセンブラを作成できることは価値がありませんか？

この提案では、ASCIIに制限することはできません。

提案では、WasmモジュールはASCIIに限定されませんが、実装者がWasmモジュールの外部で定義されたすべての識別子をASCIIにすることを選択した場合（たとえば、ほとんどすべてのシステムライブラリが実際に行うように！）、それはWasmの範囲外になります。スペック。

実装者がスタックトレースでASCII文字のみを出力し、すべての非ASCII Unicode文字を?などに置き換えることを選択した場合、実際には常にUnicode文字が存在するため、仕様で許可する必要があります。とにかくフォントがありません。

そうは言っても、すべてのWasm名がASCIIであるWasmのサブセットを定義することは、そのようなWasmモジュールがWasm名をUTF8として扱うツールによって正しく処理されるため、かなり無害です。

あなたはソフトウェアエンジニアです。 そのため、関心の分離と再利用の最大化のために、モジュール化と階層化の価値を理解し、理解していると思います。 それはスペックにも当てはまります。

はい、私はソフトウェアエンジニアです。 私はスペックエンジニアでもあるので、一貫性の価値と、エコシステムをより良く機能させるための規範を確立することの価値を理解しています。 文字セットとエンコーディングは、モジュール化と選択を可能にすることの価値が、一貫性と予測可能性の価値よりもはるかに重要である主題の1つです。 これについては、文字通り何十年にもわたる証拠があります。 あなたは、この非常にスレッドにまで示してきたそのうちのいくつかは、歴史と多くの専門家の勧告を無視している、とあなたは私たちがする必要があることを主張したときに多くの人がより多くの私は、の意見を表現していた-私は自分自身を繰り返し続ける理由はここにありますこの点で自由を許可します。

この（長い）スレッド全体を読んだ後、この議論を解決する唯一の方法は、バイナリ形式で説明し、 https：//github.com/WebAssembly/design/pullでます/ 984はUTF-8エンコーディングであり、そのセクションを単に「utf8-names」と呼ぶことを提案します。 これにより、エンコーディングが明示的になり、今日、関連するすべてのプラットフォームでWASMバイナリを操作するすべてのツールが、とにかくUTF-8を話したいと考えています。 彼らはUTF-8だけを話すことを許されるかもしれません。

私は他のプラットフォームに対する@ rossberg-chromiumの懸念に敏感であり、ある程度同意します。 ただし、これは簡単に修正できます。 スレッドの前半で誰かが提案したように、これらのシステムは、非標準の「ASCII名」セクションまたはエコシステムが使用するその他のエンコーディングを追加することを歓迎します。 明示的な名前を使用すると、どのツールがどのセクションで機能するかが明らかになります。 DOSでのみ機能するモジュールの場合、これはDOS固有のセクションの存在から明らかになります。 IMOは、これらのバイナリの名前を異なるエンコーディングであると解釈するのは大変なことです。

（ちなみに、これは、ユーザーがアップロードしたコンテンツの文字列のエンコーディングを誤って失い、復元できなかったシステムに関する戦争の話から通知されています。システムは恐ろしい、痙攣的な死を遂げました。文字通り、数百万ドルが失われました。 。）

名前セクションに命名基準を採用することもできます（heh）。

@titzerええ、カスタムセクションは、UTF8とは何の関係も望まないエキゾチックまたは特殊なプラットフォーム向けのソリューションです。 ただし、仕様で規定することを躊躇します。プラットフォームの動作モードが非常に特殊で、UTF-8コードポイントをネイティブの設定にマッピングすることすらできない場合は、次のことを行うことをお勧めします。カスタムセクションでは、好みのエンコーディングで名前を指定するだけでなく、はるかに多くのことができます。

仕様のプラットフォーム固有の詳細にカスタムセクションを使用することに重点を置き、プラットフォーム独自の仕様でそれらの詳細を定義することをお勧めします。 一般的なWASMツールチェーンは、ある種のプラグインアーキテクチャを介してそれらをサポートできます。

@titzer utf8-namesへの切り替えは問題ないようです。 ボーナスとして、ブラウザは「名前」を削除する前に、リリースの「名前」（古い形式）と「utf8-names」（＃984形式）の両方を簡単にサポートできるため、移行がスムーズになります。これを展開するための多くの緊急性を取り除きます。

これがすでに上記で決定されている場合は申し訳ありませんが、明確にするために、現在BinaryEncoding.mdにあるものからインポート/エクスポート名に提案された変更はありますか？

utf8-namesは問題ないようです。

インポート/エクスポートに関する@lukewagnerと同じ質問。

@ lukewagner @ jfbastien良い質問です。 私は上記の決定を見ませんでした。 何よりも、バイナリ形式を現在のものから変更したくないと思います。 ですから、私たちがやったことが合理的であると自分自身に納得させるために私たちが経験しなければならない精神的なゆがみは本当に何でもです:-)

AFAICT現在、インポート/エクスポートの文字列は解釈されていないバイトシーケンスであると想定しています。 それはいいです。 インポート/エクスポートに使用される文字列のエンコーディングは、namesセクションでは定義されていない方法で、埋め込みによってのみ定義されると考えるのが妥当だと思います。 たとえば、JSは常にUTF-8を使用します。 名前セクションには、名前セクションの名前に明示的なエンコーディングが付属しています。

短いバージョン：インポート/エクスポート宣言での名前のエンコードは埋め込み環境のプロパティです。名前セクションでの名前のエンコードは、ユーザーセクションを識別するために使用される文字列（「utf8-names」など）によって明示されます。

WDYT？

これは私にとっては問題なく、＃984がマージされる前の状態と一致します（モジュロnames => utf8-names ）。

名前のセクションは、真の互換性の問題が発生するインポート/エクスポートほど重要ではないと思います。

• 文字化けされた名前のセクションをロードすると、ファンキーなError.stackとデバッグが表示されます。
• 文字化けのインポート/エクスポートをロードしても何も機能しません。

私たち全員が実装する埋め込みはすでにこれを想定しているので、これは本当にバイナリ形式の変更ではないと思います。

締めくくる前に、このトピックについて私よりもよく知っている人々の推薦に頼りたいと思います。

UTF-8をどのようにデコードするかを決定する必要があります。 エラーのあるシーケンスをU + FFFDに置き換えますか、それとも最初のエラーで停止しますか？ つまり、 https： //encoding.spec.whatwg.org/#utf-8-decode-without-bomまたはhttps://encoding.spec.whatwg.org/#utf-8-decode-without-のいずれかが必要です。 bom-or-fail。 リソースがその名前にU + FFFDを使用していない限り、どちらの方法でもロードは失敗する可能性があります。

現在説明されてGetで定義されます。

私の理解を確認するために、 https： //encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-failを実行した場合、検証が成功した後、コードポイントシーケンスの同等性を確認することを意味しますバイトシーケンスが等しいかどうかをチェックするのと同じでしょうか？

はい。

上記の説明の後、コア仕様のインポート/エクスポート名のUTF-8の検証をサポートします。

具体的には、これはutf-8-decode-without-bom-or-fail 、およびコードポイントシーケンスの同等性（エンジンがバイトシーケンスの同等性を実行できるようにする）であるため、エンジンはUnicodeと国際化の恐ろしくて高価な部分を回避します。 そして、これはWebの埋め込みと一致しています。 私はこれを実験して、主なオーバーヘッドが無視できることを発見しました。

• Re：ハードウェアISAはエンコーディングにとらわれません：ここで話しているハードウェアにはインポート/エクスポートがないため、類推は直接適用されません。 そのようなハードウェアがあらゆる種類のバイトシーケンス識別子を使用する場所を私が知っている1つの場所、x86のcpuidは、特定の文字エンコーディングを指定します：UTF-8。

• Re：階層化：ソフトウェアエンジニアとして、階層化とモジュール化は手段であり、それ自体が目的ではないことも知っています。 たとえば、コア仕様からLEB128を明確に除外することができます。 これにより、より優れた階層化とモジュール化が実現します。 LEB128は、間違いなくWebのユースケースに偏っています。

• Re：「組み込みシステム」：与えられた例はDOSですが、インポート/エクスポート名のUTF-8要件がDOSシステムに要求するものの例は何でしょうか？

• Re：Islands：WebAssemblyは特定のエンディアンを指定し、浮動小数点サポート、8ビットアドレス単位を必要とし、その他の選択を行いますが、実際の設定では不必要な負担がかかります。 WebAssemblyは、多くの人が共有できる共通のプラットフォームを強化することを期待しているときに、そのような選択を行います。

• Re：インポート/エクスポート名の任意のデータ構造：これは理論的には便利ですが、データを文字列にマングリングすることによっても実行できます。 マングリングはそれほど便利ではありませんが、難しくはありません。 したがって、そこにはトレードオフがありますが、大きなものではありません（そして、おそらく、インポート/エクスポートにメタデータを添付する一般的な必要性がある場合は、追加の目的で識別子をサドルするよりも明示的なメカニズムがある方が良いでしょう）。

• Re：バイナリ互換性：この変更はまだ実行可能であるというJFにも同意します。 utf-8-decode-without-bom-or-failは、サイレント動作の変更がないことを意味します。現時点では、すべての既知のwasmプロデューサーは出力をWeb埋め込みと互換性を保ちます（他の埋め込みもサポートしている場合でも）。すでにUTF-8内にとどまっています。

UTF-8名の具体的な提案を行うPRは、 https：//github.com/WebAssembly/design/issues/1016として投稿されるようになりました

＃1016で、これは修正されました。