Argument für UTF-8: Es ist ganz einfach. Encoder und Decoder in JavaScript. Auch hier ist UTF-8 kein Unicode .

Argument gegen UTF-8: Es ist immer etwas komplizierter als Länge + Byte, was zu möglichen Abweichungen bei der Implementierung führt.

Auch hier ist UTF-8 kein Unicode.

Was sagen Sie selbst? Dies ist ein unsinniger Satz.

Ich denke, Sie wollen damit sagen, dass es nicht nötig ist, eine Internationalisierungsbibliothek hinzuzuziehen. Dies ist wahr - die Vorgabe, dass Strings in UTF-8 kodiert sind, hat nichts mit den komplizierteren Teilen von Unicode zu tun, wie der Kanonisierung. Dies sind nützliche Werkzeuge, wenn Sie Zeichenketten arbeiten, die mit Menschen interagieren, aber genauso wie eine trigonometrische Bibliothek für Leute nützlich ist, die Mathematik betreiben, und nicht relevant sind, wenn Sie entscheiden, wie Ganzzahlen kodiert werden.

Aber UTF-8 ist buchstäblich eine Unicode-Kodierung; Ihre Aussage ist wie geschrieben bedeutungslos. ^_^

Aber UTF-8 ist buchstäblich eine Unicode-Kodierung; Ihre Aussage ist wie geschrieben bedeutungslos. ^_^

Ja, ich beziehe mich speziell auf die Codepunktcodierung, die UTF-8 beschreibt, nicht auf die eigentliche Behandlung von Codepunkten (für die Zwecke dieses Vorschlags ist ein Codepunkt eine undurchsichtige ganze Zahl). In wasm-isms ausgedrückt, ist UTF-8 ähnlich wie var[u]int, aber eher für Zeichen geeignet. Außerdem ist UTF-8 nicht die einzige Unicode-Codierung und kann zum Codieren von Nicht-Unicode-Ganzzahlen verwendet werden. UTF-8 ist also kein Unicode.

Ein weiterer Vorschlag würde sich einzelne Codepunkte ansehen und etwas damit anfangen. Dies ist nicht dieser Vorschlag.

Und es gäbe keinen Grund dazu. Keine Web-API hat die Notwendigkeit gefunden, die Codepunkte über den strikten Gleichheitsvergleich und die Sortierung hinaus zu untersuchen, es sei denn, es handelt sich buchstäblich um eine i18n-API.

Eine andere Option ist Bytelänge + UTF-8 für jeden Codepunkt ( zugegebenermaßen , keinen Sinn ergab). Ich glaube nicht, dass dies für einen primitiven Parser, der sich nicht wirklich interessiert, die Dinge schwieriger machen würde, während es einer ausgeklügelten Unicode-Bibliothek ermöglicht wird, ein Byte-Array, einen Offset und eine Länge als Eingabe zu verwenden und einen String zurückzugeben.

Ich stimme der Definition als "UTF-8-Codepunkte" zu, die nur ganze Zahlen sind. Die Binärspezifikation sollte es dabei belassen. Einzelne Einbetter können Regeln für erlaubte Codepunkte, Normalisierung und andere Nuancen definieren. Analysetools können Warnungen für potenzielle Kompatibilitätsprobleme ausgeben.

Ich denke, dass Entscheidungen zur Fehlerbehandlung auch den Einbettern überlassen werden sollten. Ein System, das auf WASM-Funktionen über den Index anstatt über den Namen zugreift, muss nicht gültig sein (und sie könnten mit einem Bytelängenpräfix leicht übersprungen werden).

Hier ist ein Versuch, die zugrunde liegenden Probleme und ihre Gründe zusammenzufassen. Korrekturen und Ergänzungen sind sehr willkommen.

Sollte wasm erfordern, dass die Modul-Import-/Export-Kennungen gültiges UTF-8 sind?

Ich verstehe die Gründe dagegen:

• Die Verarbeitung von Importen und Exporten ist ein kritischer Pfad für den Anwendungsstart, und es besteht der Wunsch, alles zu vermeiden, was dies verlangsamen würde.
• Die breite Invariante "die Kern-Wasm-Spezifikation interpretiert keine Zeichenfolgen". Die String-Interpretation ist im Allgemeinen komplex, und es besteht der Wunsch, sie zu kapseln und breite Invarianten und Grenzen zu haben, über die man auf hoher Ebene nachdenken kann.
• WebAssembly-Decoder sind oft sicherheitsrelevant, daher besteht der allgemeine Wunsch, die Menge an Code zu minimieren.
• Einige WebAssembly-Produzenten möchten möglicherweise beliebige Daten in diese Bezeichner einbetten, und es ist für sie bequemer, die Daten nach Belieben zu codieren, anstatt sie in Zeichenfolgenform zu zerlegen.

Sollte wasm UTF-8 in Bereichen empfehlen, in denen es nicht erforderlich ist?

Der Grund dafür wäre, dass die Erwähnung von UTF-8, auch wenn wir es nicht verlangen können, unnötige Inkompatibilitäten zwischen dem Ökosystem verhindern kann.

Ich verstehe den Grund dagegen, dass selbst die Erwähnung von UTF-8 die konzeptionelle Kapselung von Bedenken hinsichtlich der String-Interpretation gefährden würde.

Sollte wasm UTF-8 für Namensabschnittsnamen angeben?

Der Grund dafür ist: Der gesamte Zweck dieser Namen besteht darin, zur Anzeige in Strings umgewandelt zu werden, was ohne eine Kodierung nicht möglich ist, daher sollten wir nur UTF-8 angeben, damit Tools nicht raten müssen.

Mein Verständnis des Grundes dagegen ist: Wenn wasm andere stringähnliche Dinge in anderen Bereichen hat, die keine festgelegte Codierung haben (dh Importe/Exporte wie oben beschrieben), dann sollte es aus Konsistenzgründen keine Codierungen für irgendwelche Strings festlegen .

@sunfishcode bietet eine gute Zusammenfassung, aber ich möchte drei entscheidende Punkte hinzufügen.

@jfbastien , es wäre die sinnloseste aller Alternativen, die binäre _syntax_ (eine Kodierung) aber nicht die _Semantik_ (ein Zeichensatz) für Strings einzuschränken. Für alle praktischen Zwecke impliziert UTF-8 also Unicode. Und auch hier geht es nicht nur um Motoren. Wenn Sie Unicode-Namen definieren, erzwingen Sie dies auf allen Wasm-Ökosystemen in allen Umgebungen. Und das bedeutet so ziemlich, dass alle Umgebungen eine gewisse Unicode-Unterstützung haben müssen.

@tabatkins , ich denke, Ihrem Argument liegt ein Domänenfehler zugrunde. Keine der Zeichenfolgen, über die wir sprechen, ist _benutzerorientiert_. Sie sind _dev-zugewandte_ Namen. Viele/die meisten Programmiersprachen unterstützen weder Unicode-Bezeichner noch Tools. Kann zB gdb mit Unicode-Quellkennungen umgehen? Ich glaube nicht. Daher ist es ziemlich optimistisch (oder eher unrealistisch), anzunehmen, dass alle Verbraucher _in diesem Bereich_ auf Unicode konvergiert haben.

Und schließlich ist die Meinungsverschiedenheit nicht _ob_ Wasm im Web UTF-8 annehmen soll, sondern _wo_ wir das spezifizieren.

Ich denke, Ihrem Argument liegt ein Domänenfehler zugrunde. Keine der Zeichenfolgen, über die wir sprechen, ist benutzerorientiert. Sie sind entwicklerorientierte Namen. Viele/die meisten Programmiersprachen unterstützen weder Unicode-Bezeichner noch Tools. Kann zB gdb mit Unicode-Quellkennungen umgehen? Ich glaube nicht. Daher ist es ziemlich optimistisch (oder eher unrealistisch), anzunehmen, dass alle Verbraucher in diesem Bereich auf Unicode konvergiert haben.

"dev-facing" bedeutet "willkürliche Toolchain-Orientierung", was bedeutet, dass Sie sich im Voraus auf die Codierung einigen müssen, oder die Tools müssen die Codierung "Erkennung" durchführen (d. h. raten, was besonders schlecht ist, wenn auf kurze Werte angewendet) oder haben Out-of-Band-Informationen. Entwickler sind immer noch Benutzer. ^_^

Wenn Sie der Meinung sind, dass viele Toolchains Unicode nicht verstehen, bin ich mir nicht sicher, warum Sie denken, dass sie jede andere willkürliche Binärcodierung verstehen würden. Wenn das Ihre Einschränkung ist, dann geben Sie einfach ASCII an und fordern Sie es an, das überall zu 100% unterstützt wird. Wenn Sie sich jedoch nicht auf ASCII beschränken möchten, müssen Sie akzeptieren, dass es ein einziges akzeptiertes Nicht-ASCII-Kodierungsschema gibt - UTF-8.

Zu sagen, "eh, die meisten Dinge unterstützen wahrscheinlich nur ASCII, aber wir lassen die Entwickler dort hineinlegen, was immer sie wollen, nur für den Fall " ist das Schlimmste aus beiden Welten.

Zu sagen "eh, die meisten Dinge unterstützen wahrscheinlich nur ASCII, aber wir lassen die Entwickler für den Fall der Fälle dort hineinlegen, was sie wollen" ist das Schlimmste aus beiden Welten.

@tabatkins , niemand schlägt das Obige vor. Wie gesagt, die Frage ist nicht _ob_, sondern _wo_, um solche plattform-/umgebungsspezifischen Angelegenheiten zu definieren. Wasm soll in die breitesten und heterogensten Umgebungen eingebettet werden können, von denen einige viel umfangreicher sind als andere (zum Beispiel unterstützt JS Unicode-Identifikatoren). Folglich möchten Sie die Auswahl auf Plattformbasis zulassen. Daher gehört es zu den Plattform-API-Spezifikationen und nicht zur Kernspezifikation.

Es gibt keine Wahl zu treffen, tho! Wenn Ihre Einbettungsumgebung kein Nicht-ASCII unterstützt, verwenden Sie einfach kein Nicht-ASCII in Ihren Zeichenfolgen . (Und wenn dies der Fall ist, benötigen Sie immer noch Codierungssicherheit - UTF-16 ist zum Beispiel nicht ASCII-kompatibel!)

Wenn Ihre Umgebung Nicht-ASCII unterstützt, müssen Sie wissen, welche Codierung Sie verwenden müssen, und die richtige Wahl ist in allen Situationen UTF-8.

Welche Umgebung stellen Sie sich vor, in der es von Vorteil ist, die Codierung Ihrer Zeichenfolgen nicht zu kennen?

es wäre die sinnloseste aller Alternativen, die binäre Syntax (eine Kodierung), aber nicht die Semantik (ein Zeichensatz) für Strings einzuschränken. Für alle praktischen Zwecke impliziert UTF-8 also Unicode.

Nein, absolut nicht. Zum Beispiel ist es durchaus sinnvoll, gleichzeitig (a) einen String auf die ASCII-Zeichen zu beschränken und (b) vorzugeben, dass er in UTF-8 kodiert ist. Die Verwendung von ASCII-Zeichen bedeutet keine Kodierung, sonst wären alle Kodierungen ASCII-kompatibel! (UTF-16 beispielsweise nicht.) Sie müssen also noch etwas angeben; UTF-8, da es "ASCII-kompatibel" ist, ist dafür in Ordnung.

Auch hier, wenn Sie damit einverstanden sind, diese Namen auf ASCII-only zu beschränken, dann ist es sinnvoll, die Codierung US-ASCII vorzuschreiben. Wenn Sie möchten, dass es möglich ist, über ASCII hinauszugehen, ist es sinnvoll, die Codierung in UTF-8 vorzuschreiben. Etwas anderes zu verlangen oder überhaupt nichts zu verlangen (und alle Verbraucher zu zwingen, Out-of-Band-Informationen zu erraten oder zu verwenden), sind die einzigen unvernünftigen Möglichkeiten.

Und auch hier geht es nicht nur um Motoren. Wenn Sie Unicode-Namen definieren, erzwingen Sie dies auf allen Wasm-Ökosystemen in allen Umgebungen. Und das bedeutet so ziemlich, dass alle Umgebungen eine gewisse Unicode-Unterstützung haben müssen.

Auch hier sieht es so aus, als ob Sie über Internationalisierungsbibliotheken sprechen. Was wir hier besprechen, ist lediglich, wie man Byte-Sequenzen wieder in Strings dekodiert; das erfordert nur Kenntnisse darüber, wie man UTF-8 dekodiert, was extrem trivial und extrem schnell ist.

Sofern Sie keine benutzerfreundliche String-Manipulation durchführen, benötigen Sie lediglich die Möglichkeit, Strings nach Codepunkt zu vergleichen und möglicherweise Strings nach Codepunkt zu sortieren, wobei keine von beiden "Unicode-Unterstützung" erfordert. Dies ist zum Beispiel alles, was die vorhandene Webtechnologie verwendet, und ich sehe keinen Grund, warum Wasm-Umgebungen im Allgemeinen etwas Komplizierteres tun müssen.

Ich bin dafür, utf8 für All The Strings vorzuschreiben. Reine UTF8-Dekodierung/-Kodierung scheint eine ziemlich geringe Impl-Belastung (im Vergleich zu allem anderen) für Nicht-Web-Umgebungen zu sein. Nach allem, was ich gesehen habe, ist die Zeit, die für die Validierung von utf8 für Importe / Namen aufgewendet wird, im Vergleich zu der Zeit, die für alles andere aufgewendet wird, unbedeutend, daher glaube ich nicht, dass es hier ein Leistungsargument gibt.

Praktisch gesagt, selbst wenn wir utf8 in der Kern-Wasm-Spezifikation nicht vorschreiben, hätten Sie eine Bad Time, die mit allem interoperiert, wenn Ihre benutzerdefinierte Toolchain nicht auch utf8 verwendet, es sei denn, Sie sind eine totale Insel und dann sagen Sie vielleicht einfach "Scheiß drauf" und mach trotzdem dein eigenes Nicht-utf8-Ding... denn wen interessiert es dann.

Was ich realllly wie wenn zu tun, ist Entschlossenheit # 984, die sich auf diese zu blockieren scheint ...

@lukewagner Ich glaube nicht, dass #984 diesbezüglich blockiert ist. 😄

Ich glaube du hast recht.

Welche Umgebung stellen Sie sich vor, in der es von Vorteil ist, die Codierung Ihrer Zeichenfolgen nicht zu kennen?

@tabatkins , es scheint, dass ich immer noch nicht klar genug war. Ich kann mir eine solche Umgebung nicht vorstellen. Ich stelle mir jedoch ein breites Spektrum an Umgebungen mit inkompatiblen Anforderungen vor. Nicht alles ist eine Untermenge von UTF-8, zB ist Latin1 noch ziemlich weit verbreitet. Es ist Ihnen vielleicht egal, aber es ist nicht die Aufgabe der Kernspezifikation von Wasm, der Vielfalt der Umgebung unnötige Steine ​​​​in den Weg zu legen.

Sie hätten eine schlechte Zeit, die mit allem interoperiert, wenn Ihre benutzerdefinierte Toolchain nicht auch utf8 verwendet, es sei denn, Sie sind eine totale Insel

@lukewagner , ich erwarte in der Tat, dass Wasm auf einer Vielzahl von "Kontinenten" verwendet wird, die möglicherweise nur wenige Überschneidungen aufweisen. Und wo sie es tun, können Sie Interop angeben (in der Praxis werden Namenscodierungen wahrscheinlich das geringste Problem für die gemeinsame Nutzung von Modulen zwischen verschiedenen Plattformen sein - es sind Hostbibliotheken). Selbst totale Inseln sind nicht unrealistisch, insbesondere was eingebettete Systeme betrifft (die auch für Unicode eher wenig Verwendung haben).

Einer der schwierigsten Teile bei der Implementierung einer nicht browserbasierten WebAssembly-Engine besteht darin, die Dinge so zu gestalten, wie sie im Browser funktionieren (hauptsächlich die JS-Teile). Ich erwarte, dass wir, wenn die Kodierung nicht standardisiert wird, einen De-facto-Standard haben werden, bei dem jeder kopiert, was für das Webziel getan wird. Dies führt nur dazu, dass es schwieriger wird, Informationen zum Decodieren dieser Zeichenfolgen zu finden.

Es kann sinnvoll sein, einigen Umgebungen zu erlauben, den zulässigen Inhalt weiter einzuschränken, aber das Nichterfordernis von UTF-8 führt nur zu größeren Schwierigkeiten.

@MI3Guy , der Gegenvorschlag besteht darin, die UTF-8-Codierung als Teil der JS-API anzugeben. Wenn Sie also eine JS-Einbettung erstellen, ist diese in jedem Fall als UTF-8 definiert und macht für Sie keinen Unterschied. (Wir möchten jedoch auch andere Embedder-APIs zulassen, die weder Web noch JavaScript sind.)

Rechts. Mein Punkt ist, wenn Sie keine JS-Einbettung durchführen, sind Sie gezwungen, viel von dem zu emulieren, was der JS-Einbetter tut, um die WebAssembly-Toolchain zu verwenden.

Führen Sie varuint für die Anzahl der Codepunkte + UTF-8 für jeden Codepunkt aus.

Ich möchte mich nur gegen diese Option aussprechen. Es verkompliziert die Dinge, gilt nicht und kann nicht für benutzerspezifische Abschnitte gelten und bietet keinen Vorteil, den ich sehen kann – um die Anzahl der Codepunkte in einem UTF-8-String zu kennen, scannt man in der Praxis immer den String nach ungültige Codierungen, also können Sie auch Codepunkte zählen, wenn Sie schon dabei sind.

Nicht alles ist eine Untermenge von UTF-8, zB ist Latin1 noch ziemlich weit verbreitet. Es ist Ihnen vielleicht egal, aber es ist nicht die Aufgabe der Kernspezifikation von Wasm, der Vielfalt der Umgebung unnötige Steine ​​​​in den Weg zu legen.

Richtig; UTF-8 unterscheidet sich von praktisch jeder Codierung, sobald Sie den ASCII-Bereich verlassen. Ich bin mir nicht sicher, was Sie damit meinen. Tatsächlich ist die Verwendung der Latin-1-Codierung schlecht, gerade weil es viele andere Codierungen gibt, die gleich aussehen, aber unterschiedliche Buchstaben codieren . Wenn Sie versucht haben, den Namen "æther" in Ihrem Wasm-Code zu verwenden und ihn in Latin-1 codiert, dann versucht jemand anderes (zu Recht), den Namen mit einer UTF-8-Toolchain zu lesen, und erhält einen Decodierungsfehler. Oder vielleicht hat die andere Person einen ähnlichen Fehler gemacht, aber stattdessen die Windows-1250-Codierung verwendet (für mittel- / osteuropäische Sprachen gedacht) - sie würden das unsinnige Wort "ćther" bekommen.

Ich bin mir wirklich nicht sicher, welche Art von "Vielfalt" Sie hier schützen wollen. Es gibt buchstäblich keinen Vorteil, eine andere Codierung zu verwenden, und es gibt jede Menge Nachteile. Jedes Zeichen, das Sie in einer anderen Codierung codieren können, ist in Unicode vorhanden und kann in UTF-8 codiert werden, aber das Gegenteil ist fast nie der Fall. Es gibt heute keine relevanten Tools, die nicht mit UTF-8 umgehen können; die Technologie ist buchstäblich zwei Jahrzehnte alt .

Ich sage Ihnen immer wieder, dass Webstandards diese Frage vor Jahren geklärt haben, nicht weil Wasm eine Webspezifikation ist, die Webregeln befolgen muss, sondern weil die Textcodierung ein Ökosystemproblem ist, mit dem so ziemlich jeder die gleichen Probleme hat und das Web bereits behandelt wurde mit dem Schmerz, dies falsch zu machen, und hat gelernt, wie man es richtig macht. Es ist keine Tugend, in Wasm noch einmal etwas falsch zu machen; jede Umgebung, die Text kodieren muss, geht entweder von Anfang an direkt zu UTF-8 oder macht die gleichen Fehler und erleidet die gleichen Schmerzen wie alle anderen und entscheidet sich dann schließlich für UTF-8. (Oder entwickelt in seltenen Fällen eine ausreichend isolierte Umgebung, die sie auf eine andere Kodierung standardisieren können, und zahlt nur selten den Preis für die Kommunikation mit der äußeren Umgebung. Aber sie standardisieren auf eine Kodierung , und das ist der Sinn von all dem.)

Wenn Sie also eine JS-Einbettung erstellen, ist diese in jedem Fall als UTF-8 definiert und macht für Sie keinen Unterschied. (Wir möchten jedoch auch andere Embedder-APIs zulassen, die weder Web noch JavaScript sind.)

Dieses Problem hat nichts mit dem Web oder JS zu tun. Jeder Teil des Ökosystems möchte eine bekannte, konsistente Textkodierung, und es gibt eine einzige, auf die sich in Programmierumgebungen, Ländern und Sprachen einig ist: UTF-8.

Ich stimme für 'Do varuint for length (in bytes) + UTF-8 for each Byte'. Angenommen, dies ist keine umstrittene Wahl - so ziemlich jede String-Implementierung speichert Strings als "Anzahl von Codeeinheiten" und nicht als "Anzahl von Codepunkten", weil es einfacher ist - dann ist nicht die eigentliche Frage "sollte die Validierung fehlschlagen, wenn ein String dies nicht ist? gültiges UTF-8"?

Wie ich in #970 erwähnt habe, kann ungültiges UTF-8 auf UTF-16

Im Großen und Ganzen bin ich geneigt zu sagen, lasst uns UTF-8 mandatieren. In dem seltsamen Fall, dass jemand Bytes hat, die er nicht in UTF-8 übersetzen kann (vielleicht weil die Codierung unbekannt ist), können beliebige Bytes in UTF-8 transkribiert werden.

Ich bin mir wirklich nicht sicher, welche Art von "Vielfalt" Sie hier schützen wollen.

@tabatkins , ja, das scheint der Kern des Missverständnisses zu sein.

Es ist wichtig zu wissen, dass WebAssembly trotz seines Namens nicht auf das Web beschränkt ist. Wir sind sehr vorsichtig, es in geeigneten Schichten zu definieren, so dass jede Schicht so weit wie möglich verwendet werden kann.

Vor allem ist sein _Kern_ eigentlich keine Web-Technologie _überhaupt_. Versuchen Sie es stattdessen als eine _virtuelle ISA _ vorzustellen. Eine solche Abstraktion ist in einem breiten Spektrum unterschiedlicher Umgebungen nützlich, von sehr reichhaltig (das Web) bis zu sehr rudimentär (eingebettete Systeme), die nicht unbedingt miteinander zu tun haben, weitgehend inkompatibel sein können und widersprüchliche Einschränkungen aufweisen ( dass Wasm nicht in der Lage ist, sich zu ändern).

Daher macht es nicht mehr Sinn, Unicode auf _core_ Wasm aufzuerlegen, als beispielsweise auf alle String-Literale in der Programmiersprache C. Sie würden nur einige potenzielle Kunden dazu zwingen, gegen diesen Standard zu verstoßen. Was ist der Gewinn?

Es wird jedoch zusätzlich zu dieser Kernspezifikation zusätzliche Spezifikationsebenen geben, die ihre Einbettung und API in _konkrete_ Umgebungen (wie JavaScript) definieren. Es ist durchaus sinnvoll, String-Codierungen auf dieser Ebene zu korrigieren, und das sollten wir auf jeden Fall tun.

PS: Ein Slogan, der den Umfang von Wasm definiert, ist, dass es sich um eine Abstraktion über gängige Hardware und nicht um eine Abstraktion über gängige Programmiersprachen handelt. Und Hardware ist gegenüber Softwareproblemen wie String-Codierungen agnostisch. Dafür sind ABIs da.

@rossberg-chrom

Als solches macht es nicht mehr Sinn, Unicode dem Kern von Wasm aufzuzwingen, als beispielsweise allen String-Literalen in der Programmiersprache C Unicode aufzuzwingen. Sie würden nur einige potenzielle Kunden dazu zwingen, gegen diesen Standard zu verstoßen. Was ist der Gewinn?

Ich stimme zu 100% zu%. Bei diesem Problem geht es jedoch nicht um Unicode, sondern ausschließlich um UTF-8, eine Codierung für Ganzzahlen, ohne dass die Ganzzahlen als Unicode interpretiert werden müssen.

Ich verstehe nicht, ob wir uns darin einig sind. Könnten Sie klarstellen: Sind Sie mit UTF-8 einverstanden, und wenn nicht, warum?

@jfbastien , wäre es produktiver, die UTF-8-Konformität für alle C-String-Literale zu verlangen?

Wie bereits erwähnt, macht es für mich keinen Sinn, die Kodierung, aber nicht den Zeichensatz einzuschränken. Das ist wie das Definieren von Syntax ohne Semantik. Warum würden Sie das möglicherweise tun? Sie gewinnen null in Bezug auf Interop, bauen aber dennoch künstliche Hürden für Umgebungen auf, die kein UTF-8 verwenden (was ohnehin nur Unicode-Umgebungen tun).

@jfbastien , wäre es produktiver, die UTF-8-Konformität für alle C-String-Literale zu verlangen?

Verstehe ich nicht, kannst du das klären?

Wie bereits erwähnt, macht es für mich keinen Sinn, die Kodierung, aber nicht den Zeichensatz einzuschränken. Das ist wie das Definieren von Syntax ohne Semantik. Warum würden Sie das möglicherweise tun? Sie gewinnen null in Bezug auf Interop, bauen aber dennoch künstliche Hürden für Umgebungen auf, die kein UTF-8 verwenden (was ohnehin nur Unicode-Umgebungen tun).

Ich denke, das ist der Kern der Diskussion.

@tabatkins berührte Präzedenzfälle zu genau diesem:

Auch hier sieht es so aus, als ob Sie über Internationalisierungsbibliotheken sprechen. Was wir hier besprechen, ist lediglich, wie man Byte-Sequenzen wieder in Strings dekodiert; das erfordert nur Kenntnisse darüber, wie man UTF-8 dekodiert, was extrem trivial und extrem schnell ist.

Sofern Sie keine benutzerfreundliche String-Manipulation durchführen, benötigen Sie lediglich die Möglichkeit, Strings nach Codepunkt zu vergleichen und möglicherweise Strings nach Codepunkt zu sortieren, wobei keine von beiden "Unicode-Unterstützung" erfordert. Dies ist zum Beispiel alles, was die vorhandene Webtechnologie verwendet, und ich sehe keinen Grund, warum Wasm-Umgebungen im Allgemeinen etwas Komplizierteres tun müssen.

Ich stimme also zu: Dieser Vorschlag ist in Ihren Worten "Syntax ohne Semantik definieren". Das ist eine sehr übliche Sache. Tatsächlich tut dies die aktuelle Länge + Byte-Spezifikation von WebAssembly bereits!

Ich würde gerne verstehen, was die Hürde ist. Ich sehe nicht wirklich einen.

Es ist wichtig zu wissen, dass WebAssembly trotz seines Namens nicht auf das Web beschränkt ist.

Ich habe gerade im unmittelbar vorhergehenden Kommentar gesagt, dass dies nichts mit dem Web zu tun hat. Sie versuchen immer wieder, dieses Argument zu verwenden, und es verwirrt mich wirklich. Was ich sage, hat nichts mit dem Web zu tun; Ich weise lediglich auf die Erfahrungen des Webs als wichtiges Beispiel für gewonnene Erkenntnisse hin.

Als solches macht es nicht mehr Sinn, Unicode dem Kern von Wasm aufzuzwingen, als beispielsweise allen String-Literalen in der Programmiersprache C Unicode aufzuzwingen. Sie würden nur einige potenzielle Kunden dazu zwingen, gegen diesen Standard zu verstoßen. Was ist der Gewinn?

Sie machen nicht den Punkt, den Sie denken - C hat eine integrierte Codierung, da String-Literale die ASCII-Codierung verwenden. (Wenn Sie etwas anderes wollen, müssen Sie dies von Hand tun, indem Sie die entsprechenden Bytesequenzen maskieren.) In aktuelleren C++ können Sie UTF-16- und UTF-8-String-Literale verwenden, und während Sie mit . beliebige Bytes in den String einfügen können \x Escapes, die \u Escapes überprüfen zumindest, ob der Wert ein gültiger Codepoint ist.

All dies ist erforderlich, da es keine inhärente Zuordnung von Zeichen zu Bytes gibt . Das ist , was eine Codierung der Fall ist. Auch hier bedeutet das Fehlen einer bestimmten Kodierung nur, dass Benutzer der Sprache, wenn sie Bytefolgen von anderen Parteien erhalten, die Kodierung erraten müssen, um sie wieder in Text umzuwandeln.

Sie gewinnen null in Bezug auf Interop, bauen aber dennoch künstliche Hürden für Umgebungen auf, die kein UTF-8 verwenden (was ohnehin nur Unicode-Umgebungen tun).

Können Sie bitte auf eine vorhandene Umgebung verweisen, die Zeichen verwendet, die nicht in Unicode enthalten sind? Sie versuchen immer wieder, diese Position vom Standpunkt der theoretischen Reinheit/Umgebungsvielfalt aus zu verteidigen, aber buchstäblich besteht der Sinn von Unicode darin, alle Zeichen einzuschließen . Es ist der einzige Zeichensatz, der ein entfernt glaubwürdiges Argument dafür liefern kann, und wenn Sie den Unicode-Zeichensatz verwenden, ist UTF-8 die bevorzugte universelle Codierung.

Welche Vielfalt wollen Sie schützen? Es wäre toll, auch nur ein einziges Beispiel zu sehen. :/

@tabatkins :

Es ist wichtig zu wissen, dass WebAssembly trotz seines Namens nicht
auf das Web beschränkt.

Ich habe gerade im unmittelbar vorhergehenden Kommentar gesagt, dass dies nichts hat
mit dem Netz zu tun. Du versuchst immer wieder, dieses Argument zu verwenden, und es ist wirklich
verwirrt mich. Was ich sage, hat nichts mit dem Web zu tun; ich bin bloß
und verweist auf die Erfahrungen mit dem Web als wichtiges Beispiel für gewonnene Erkenntnisse.

Was ich zu betonen versuche, ist, dass Wasm auf so viele anwendbar sein sollte
Plattformen wie möglich, modern oder nicht. Du streitest weiter vom Happy End
des Spektrums, wo alles Unicode und/oder UTF-8 ist und alles
sonst ist einfach veraltet.

Du machst nicht den Punkt, von dem du denkst, dass du ihn machst - C hat a

integrierte Kodierung, da Zeichenfolgenliterale die ASCII-Kodierung verwenden. (Falls Sie es wollen
alles andere müssen Sie von Hand tun, indem Sie das entsprechende Byte maskieren
Sequenzen.) In aktuelleren C++ können Sie UTF-16- und UTF-8-Strings haben
Literale, und während Sie mit beliebige Bytes in den String einfügen können
\x Escapes, die \u Escapes verifizieren zumindest, dass der Wert gültig ist
Codepunkt.

Nein, das ist falsch. Die C-Spezifikation erfordert kein ASCII. Es geht nicht einmal
erfordern Kompatibilität mit ASCII. Es erlaubt fast beliebige "Quellen"
Zeichensätze" und String-Literale können jedes beliebige Zeichen aus dem vollen enthalten
einstellen. Es gibt keine Einschränkungen bezüglich der Kodierung, es ist vollständig
Implementierung definiert. Es gab Implementierungen von C, die auf laufen
EBCDIC-Plattformen, und das wird vom aktuellen Standard noch unterstützt. GCC
kann Quellen in jeder iconv-Kodierung verarbeiten (von denen es etwa 140 . gibt)
neben UTF-8), zB UTF-16, das in Asien beliebt ist. C++ ist nicht anders.

(Das sollte auch die Frage von @jfbastien beantworten.)

All dies ist erforderlich, da es keine inhärente Abbildung von gibtZeichen in Bytes . Das ist , was eine Codierung der Fall ist. Wieder kein a
angegebene Kodierung bedeutet nur, dass Benutzer der Sprache, wenn sie empfangen
Byte-Sequenzen von anderen Parteien, müssen die Codierung erraten, um zu drehen
sie wieder in Text.

Nochmals: dies _wird_ pro Umgebung entsprechend spezifiziert. Wenn jemand
erhält ein Wasm-Modul von jemand anderem, der im selben Ökosystem tätig ist
dann gibt es kein problem. Kein JS-Entwickler wird sich jemals darum kümmern müssen.

Wenn jedoch jemand ein Modul von einem _anderen Ökosystem_ erhält, dann
Es gibt viele andere Ursachen für Inkompatibilität, über die Sie sich Sorgen machen müssen, z
Erwartungen an API, integrierte Bibliotheken usw. Beide Parteien müssen
ihre Interop-Annahmen sowieso explizit sein. Einen Namen vereinbaren
Codierung wird das geringste ihrer Probleme sein.

Du gewinnst null in Bezug auf Interop, errichtest aber trotzdem künstliche Hürden für

Umgebungen, die kein UTF-8 verwenden (was nur Unicode-Umgebungen tun .)
ohnehin).

Können Sie bitte auf eine existierende Umgebung hinweisen, die
Zeichen, die nicht in Unicode enthalten sind? Du versuchst das immer wieder zu verteidigen
Position vom Standpunkt der theoretischen Reinheit/Umweltdiversität, aber
Der Sinn von Unicode besteht buchstäblich darin, alleZeichen . Es ist der einzige Zeichensatz, der aus der Ferne eine erstellen kann
glaubwürdiges Argument dafür, und wenn Sie das Unicode-Zeichen verwenden
gesetzt ist, ist UTF-8 die bevorzugte universelle Kodierung.

Welche Vielfalt wollen Sie schützen? Es wäre toll, sogar zu sehen
ein einziges Beispiel. :/

Hier ist beispielsweise eine Liste eingebetteter Betriebssysteme: https://en.wikipedia.org/wiki/
Kategorie:Embedded_operating_systems
Einige von ihnen verwenden wahrscheinlich UTF-8, andere nicht. Einige mögen eine Verwendung für Wasm finden,
höchstwahrscheinlich nicht. Aber es hat keinen Vorteil für uns, es weniger zu machen
bequem für sie.

Ein Eintrag aus dieser Liste, den Sie wahrscheinlich noch kennen, ist DOS. Wie
So sehr wir es alle mögen, zu sterben, DOS-Systeme sind immer noch lebendig, und sie verwenden
OEM.

@jfbastien :

Ich stimme also zu: Dieser Vorschlag ist in Ihren Worten "Syntax definieren ohne
Semantik". Das ist eine sehr gängige Vorgehensweise
aktuelle Länge + Byte Angabe tut dies bereits!

Die seltenen Vorkommnisse von so etwas, die mir bekannt sind, haben alles damit zu tun
Bereitstellung einer Fluchtluke für implementierungsspezifisches Verhalten. Das ist
auch der einzige sinnvolle Anwendungsfall. Das macht hier aber keinen Sinn. wenn du
wollen eine solche Notluke für Saiten bieten, warum dann die Mühe machen?
UTF-8, anstatt eine beliebige Byte-Zeichenfolge "Syntax" zuzulassen? Das ist Syntax ohne
Semantik als Disabler, nicht als Enabler.

Ich würde gerne verstehen, was die Hürde ist. Ich sehe nicht wirklich einen.
>
Dass manche Clients nicht einfach alle Byte-Werte verwenden können, sondern durchlaufen müssen
redundante UTF-Codierungen, die in ihrem Ökosystem keine Verwendung haben. Das alles
Werkzeuge in ihren Werkzeugketten werden sich auch damit beschäftigen müssen. Dass es
erzeugt zusätzliche Fehlerfälle (außerhalb des zulässigen Bereichs), die nicht
sonst für sie existieren.

Lassen Sie mich umgekehrt fragen: Was ist der Nutzen (in ihren Ökosystemen)?
Ich sehe nicht wirklich einen.

@tabatkins
Ich möchte sicherstellen, dass ich verstehe, wo die Trennlinie liegt.
Um das klarzustellen, schlagen Sie NUR die utf-8-Codierung von Codepunkten vor, unabhängig davon, ob sie in Kombination ungültig sind (das kann in 10 Codezeilen erfolgen).
Fettgedruckte Großbuchstaben könnten zum Beispiel in der Spezifikation verwendet werden, um anzuzeigen: Sie machen etwas falsch, wenn Sie denken, dass Sie eine Internationalisierungsbibliothek benötigen, um Wasm zu implementieren?

Ziele dabei wären:

• Stellen Sie sicher, dass jeder gültige Wasm, der im Web landet, zumindest Tofu-Zeichen für ungültige Dinge anzeigen kann.
• Ermutigen Sie Tools, die Wasm erzeugen (auch in Kontexten außerhalb des Webs), Unicode anderen Codierungen vorzuziehen, wenn sie über ASCII hinausgehen müssen. (Ein weicher Stoß in diese Richtung, da keine vollständige Validierung stattfindet).

Fragen?

• Besteht die Gefahr, dass dies zu einer schleichenden Anforderung für mehr Validierung wird? Ich denke, mein Hauptanliegen in diesem Bereich wäre, dass es immer eine unangemessene Belastung sein wird, beispielsweise die Intensivstation als Abhängigkeit zu schlucken.

• Ich nehme an, dies impliziert das Ziel, Codierungen wie Latin1 aktiv zu fördern, die mit UTF-8 kollidieren? Dh Toolchains, die es ausgeben, wären nicht konform, Implementierungen, die es ähnlich akzeptieren.

• Ich grok, das Web hatte in der Vergangenheit Probleme, diesen Raum zu vereinheitlichen, da Bits aus Regionen, die zuvor Inseln kodierten, überlappend verwendet wurden. Auf der anderen Seite habe ich den Eindruck, dass UTF-8 Dinge so einrichtet, dass die Kosten der Umstellung überproportional von Nicht-ASCII-Leute getragen werden und dass einige Regionen mehr Einbacken haben. Ich könnte mir vorstellen, dass die Unicode-Umstellung praktisch unvermeidlich ist (und fast vollständig). Gibt es ein zentralisiertes Dokument / eine zentrale Einheit, auf die wir hinweisen können, die aufzeigt, wie einige der politischen und regionalen Probleme rund um Unicode im Web gelöst wurden?

@rossberg-chrom

• Ich sehe die logische Inkonsistenz darin, einige Aspekte einer Codierung zu validieren, andere jedoch nicht. Auf der anderen Seite ist mein Eindruck, dass utf8 an dieser Stelle allgegenwärtig ist (und dass ein kleiner Schubs in Tools + Validierung geringe Kosten verursacht). Ist Ihr größtes Unbehagen, die bloße UTF-8-Validierung zur Spezifikation hinzuzufügen, die Inkonsistenz oder etwas anderes?

Um das klarzustellen, schlagen Sie NUR die utf-8-Codierung von Codepunkten vor, unabhängig davon, ob sie in Kombination ungültig sind (das kann in 10 Codezeilen erfolgen).

Ja, aber ich glaube nicht, dass es irgendwelche ungültigen Kombinationen gibt; Es gibt nur einige einzelne Codepunkte (die für UTF-16-Surrogate reserviert sind), die technisch nicht als UTF-8 kodiert werden können. Das heißt, wenn eine vollständige Byte-Kontrolle wünschenswert ist, existiert die WTF-8-Codierung , aber wir sollten sehr explizit sein, "ja, wir möchten zulassen, dass diese Strings manchmal tatsächlich beliebige Nicht-String-Daten enthalten" als Ziel, wenn wir gehen diesen Weg. Das Format WTF-8 (und WTF-16) ist nur dazu gedacht, eine formale Spezifikation für Umgebungen bereitzustellen, die Rückwärtskompatibilitätsbeschränkungen zur Erzwingung der UTF-*-Wohlformung aufweisen.

Fettgedruckte Großbuchstaben könnten zum Beispiel in der Spezifikation verwendet werden, um anzuzeigen: Sie machen etwas falsch, wenn Sie denken, dass Sie eine Internationalisierungsbibliothek benötigen, um Wasm zu implementieren?

Ja, i18n ist in keiner Weise, Form oder Form erforderlich. CSS ist beispielsweise standardmäßig auf UTF-8 eingestellt und führt nur einen Vergleich/Sortierung von Rohcodepunkten durch, wenn es Dinge außerhalb des ASCII-Bereichs zulässt. Auch für Wasm kein Grund, weiter zu gehen.

Besteht die Gefahr, dass dies zu einer schleichenden Anforderung für mehr Validierung wird? Ich denke, mein Hauptanliegen in diesem Bereich wäre, dass es immer eine unangemessene Belastung sein wird, beispielsweise die Intensivstation als Abhängigkeit zu schlucken.

Die Webplattform musste bisher keine zusätzlichen Validierungen für bloße Namen auferlegen. Meine Erfahrung zeigt, dass es nie nötig sein wird.

Ich nehme an, dies impliziert das Ziel, Codierungen wie Latin1, die mit UTF-8 kollidieren, aktiv [zu entmutigen]? Dh Toolchains, die es ausgeben, wären nicht konform, Implementierungen, die es ähnlich akzeptieren.

Ja, mit der Änderung auf „dis ermutigend“ in deinen Worten. ^_^ Der springende Punkt ist, dass Produzenten und Konsumenten zuverlässig Strings in/von Byte-Sequenzen kodieren und dekodieren können, ohne raten zu müssen, was der andere Endpunkt tut. Dies war ein schrecklicher Schmerz für jede Umgebung, die jemals damit konfrontiert wurde, und es gibt jetzt eine weit verbreitete Lösung dafür.

Ich grok, das Web hatte in der Vergangenheit Probleme, diesen Raum zu vereinheitlichen, da Bits aus Regionen, die zuvor Inseln kodierten, überlappend verwendet wurden. Auf der anderen Seite habe ich den Eindruck, dass UTF-8 Dinge so einrichtet, dass die Kosten der Umstellung überproportional von Nicht-ASCII-Leute getragen werden und dass einige Regionen mehr Einbacken haben. Ich könnte mir vorstellen, dass die Unicode-Umstellung praktisch unvermeidlich ist (und fast vollständig). Gibt es ein zentralisiertes Dokument / eine zentrale Einheit, auf die wir hinweisen können, die aufzeigt, wie einige der politischen und regionalen Probleme rund um Unicode im Web gelöst wurden?

Ja, es gab definitiv Probleme beim Übergang; HTML ist aufgrund der Rückwärtskompatibilität immer noch erforderlich, um standardmäßig auf Latin-1 zu setzen, und es gibt immer noch einige kleine Bereiche von Webinhalten, die eine sprachspezifische Kodierung bevorzugen (meistens Shift-JIS, eine Kodierung in japanischer Sprache). Aber die überwiegende Mehrheit der Welt hat in den letzten zwei Jahrzehnten umgestellt, und der Übergang gilt jetzt als mehr oder weniger abgeschlossen.

Das "UTF-8 belastet Nicht-ASCII-Leute" war lange Zeit ein verderbliches, aber fast völlig unwahres Gerücht. Die meisten europäischen Sprachen enthalten in erster Linie den Großteil des ASCII-Alphabets, sodass der größte Teil ihres Textes aus Einzelbyte-Sequenzen besteht und kleiner als UTF-16 ist. Gleiches gilt für Schriftsysteme wie Pinyin. CJK-Langs belegen hauptsächlich den 3-Byte-UTF-8-Bereich, enthalten jedoch auch große Mengen an ASCII-Zeichen, insbesondere in Markup-Sprachen oder Programmiersprachen UTF-16 oder deren spezielle Codierungen.

Nur für große Mengen an Rohtext in CJK- oder Nicht-ASCII-Alphabeten wie Kyrillisch sehen wir, dass UTF-8 tatsächlich mehr Platz beansprucht als eine spezielle Codierung. Dies waren jedoch Bedenken in den frühen 90er Jahren , als die Festplattenkapazität in Megabyte gemessen wurde und eine leichte Vergrößerung der Textdateigrößen tatsächlich signifikant sein konnte. Dies ist seit fast 20 Jahren kein Thema mehr; der Größenunterschied ist jetzt völlig belanglos.

Was den "Unicode-Übergang" angeht, ist das schon ziemlich allgemein passiert. Ein Textformat, das heutzutage nicht selbst mit UTF-8 kodiert werden muss, macht einen schrecklichen, ahistorischen Fehler.

Ich bin mir nicht sicher, ob es ein bestimmtes Dokument gibt, das diese Dinge beschreibt, aber ich wette, sie existieren irgendwo. ^_^

Wenn das Ziel darin besteht, die binäre Spezifikation so rein wie möglich zu halten, entfernen wir die Namen vollständig. Alle seine internen Referenzen basieren sowieso auf einem Index.

Fügen Sie stattdessen der JavaScript-Spezifikation einen obligatorischen benutzerdefinierten Abschnitt hinzu, der UTF-8 erfordert. Andere Umgebungen, wie der Mainframe aus der Sowjetzeit, auf den @rossberg-chromium anspielt, können ihren eigenen benutzerdefinierten Abschnitt definieren. Eine einzelne WASM-Datei könnte beide Plattformen unterstützen, indem sie beide benutzerdefinierten Abschnitte bereitstellt. Für benutzerdefinierte Tools wäre es relativ einfach, den fehlenden Abschnitt einer obskuren Plattform zu generieren, indem ein populärerer Abschnitt konvertiert wird.

Wenn das Ziel darin besteht, die binäre Spezifikation so rein wie möglich zu halten, entfernen wir die Namen vollständig. Alle seine internen Referenzen basieren sowieso auf einem Index.

Das ist eine Überarbeitung der Funktionsweise des Imports / Exports. Es liegt nicht auf dem Tisch und sollte in einer anderen Ausgabe als dieser vorgeschlagen werden.

@bradnelson , AFAICS, schreibt eine bestimmte Kodierung vor, aber keinen Zeichensatz
vereint das Schlimmste aus beiden Welten: Es verursacht Kosten in Form von
Einschränkungen, Komplexität und Overhead ohne tatsächlichen Nutzen in Bezug auf
interop. Ich glaube, ich bin immer noch verwirrt, was der Sinn sein soll.

@rossberg-chromium Der Hauptvorteil, der hier angestrebt wird, besteht darin, Tools und Bibliotheken von der Last des Ratens zu entlasten.

Da hier der primäre Nutzen darin besteht, Tools und Bibliotheken vom Raten zu entlasten, wäre jede der oben diskutierten Varianten (UTF-8 vs. WTF-8 etc.) besser als nichts, denn selbst im schlimmsten Fall "Ich bin mir sicher, dass ich diese Bytes nicht buchstäblich transcodieren kann" ist besser als "diese Bytes sehen aus, als wären sie Windows-1252; vielleicht werde ich das versuchen". Schätzen ist bekanntermaßen fehleranfällig, und der Hauptnutzen, der hier angestrebt wird, besteht darin, Tools und Bibliotheken von der Last des Ratens zu entlasten.

@sunfishcode , wie? Ich bin immer noch verloren.

Hier also ein konkretes Szenario. Angenommen, wir befinden uns auf verschiedenen Plattformen und ich versuche, Ihnen ein Modul zu übergeben. Nehmen wir als Argument an, dass meine Plattform EBCDIC und Ihre ASCII verwendet. Völlig legitim nach dem aktuellen Vorschlag. Mein Modul wird jedoch für Sie und Ihre Werkzeugkette völlig nutzlos sein.

Beide Codierungen sind 7-Bit, so dass UTF-8 nicht einmal in das Bild eingeht.

Was würde UTF-8 also auf den Tisch bringen? Nun, ich könnte jede unbekannte Zeichenfolge "decodieren", die ich bekomme. Aber soweit ich weiß, ist das Ergebnis _nur ein weiterer undurchsichtiger binärer Blob_ mit 31-Bit-Werten. Es liefert keine Informationen. Ich habe keine Ahnung, wie ich es mit meinen eigenen Saiten in Verbindung bringen soll.

Warum sollte ich mir dann überhaupt die Mühe machen, eine unbekannte Zeichenfolge zu decodieren? Nun, _ich würde nicht_! Ich könnte genauso gut mit dem ursprünglichen binären Blob von 8-Bit-Werten arbeiten und Platz und Zyklen sparen. Die Spezifikation würde jedoch immer noch erfordern, dass ich Zyklen aufwende, um die Codierung vakant zu validieren.

Wenn man all das bedenkt, was würde (Kern-)Wasm oder Werkzeuge gewinnen, wenn man diesen speziellen Vorschlag annimmt?

AFAICS, das eine bestimmte Kodierung vorschreibt, aber keinen Zeichensatz
vereint das Schlimmste aus beiden Welten: Es verursacht Kosten in Form von
Einschränkungen, Komplexität und Overhead ohne tatsächlichen Nutzen in Bezug auf
interop. Ich glaube, ich bin immer noch verwirrt, was der Sinn sein soll.

Wir führen definitiv einen Zeichensatz durch - den Unicode-Zeichensatz. JF hat die Dinge vorhin sehr verwirrend formuliert, pass nicht auf. Das bedeutet nicht, dass wir Wasm Prüfungen hinzufügen müssen, um dies tatsächlich durchzusetzen; Decoder sind normalerweise robust genug, um mit ungültigen Zeichen umzugehen. (Das Web beispielsweise ersetzt sie normalerweise nur durch U+FFFD ERSATZZEICHEN.)

Hier also ein konkretes Szenario. Angenommen, wir befinden uns auf verschiedenen Plattformen und ich versuche, Ihnen ein Modul zu übergeben. Nehmen wir als Argument an, dass meine Plattform EBCDIC und Ihre ASCII verwendet. Völlig legitim nach dem aktuellen Vorschlag. Mein Modul wird jedoch für Sie und Ihre Werkzeugkette völlig nutzlos sein.

Sie müssen aufhören, so zu tun, als seien jahrzehntelange alte Systeme nicht nur relevant, sondern auch so relevant, dass sie Entscheidungen rechtfertigen, die all dem widersprechen, was wir über die gleichen Jahrzehnte über das Kodieren von Schmerz gelernt haben. Sie helfen niemandem mit dieser Beharrlichkeit, dass Web Assembly sich selbst verzerrt, um den Komfort beim Chatten mit alten Mainframes zu maximieren, während Sie den Vorteil ignorieren, dass jeder andere auf der Welt in der Lage ist, Textdaten zuverlässig zu kommunizieren. Sie werden nur der Sprache schaden und 99,9 % (als sehr konservative Schätzung) des Lebens der Benutzer erschweren.

Viele verschiedene Systeme haben dieses Durcheinander durchgemacht. Die Codierungskriege machten keinen Spaß; Sie verschwendeten viel Geld und viel Zeit und führten zu vielen beschädigten Texten. Wir haben diese Kriege beendet. Unicode wurde erstellt und verbreitet und wurde zum dominierenden Zeichensatz auf der ganzen Welt, bis zu dem Punkt, dass alle anderen Zeichensätze zu diesem Zeitpunkt buchstäblich nichts anderes als historische Kuriositäten sind. Wir haben immer noch brodelnde Kämpfe auf niedriger Ebene darüber, ob wir UTF-16 oder UTF-8 verwenden sollen, aber zumindest sind diese beiden normalerweise leicht zu unterscheiden (schauen Sie sich die BOM an oder suchen Sie nach einem Übergewicht von Null-Bytes) und insgesamt UTF -8 dominiert handlich.

Ihr Beharren auf Verschlüsselungsfreiheit ignoriert all diese Geschichte, alle Lektionen, die Sie in den zwei Jahrzehnten seit der Einführung von Unicode gelernt haben. Es ignoriert all die Erfahrung und das Know-how, die in die Entwicklung moderner Systeme eingeflossen sind und die dazu geführt haben, dass Codierungsprobleme für die meisten Benutzer

@rossberg-chrom

Hier also ein konkretes Szenario. Angenommen, wir befinden uns auf verschiedenen Plattformen und ich versuche, Ihnen ein Modul zu übergeben. Nehmen wir als Argument an, dass meine Plattform EBCDIC und Ihre ASCII verwendet. Völlig legitim nach dem aktuellen Vorschlag. Mein Modul wird jedoch für Sie und Ihre Werkzeugkette völlig nutzlos sein.

Was würde UTF-8 also auf den Tisch bringen? Nun, ich könnte jede unbekannte Zeichenfolge "decodieren", die ich bekomme. Aber soweit ich weiß, ist das Ergebnis nur ein weiterer undurchsichtiger binärer Blob mit 31-Bit-Werten. Es liefert keine Informationen. Ich habe keine Ahnung, wie ich es mit meinen eigenen Saiten in Verbindung bringen soll.

UTF-8 würde Ihnen genau sagen, wie Sie es mit Ihren eigenen Strings in Beziehung setzen können. Genau das ist das Problem, das es löst. (WTF-8 würde es auch tun, wenn es kann, und es würde Ihnen eindeutig sagen, wenn es nicht kann.)

Meinen Sie eine beliebige Datenstruktur, die in Stringform zerlegt und dann als UTF-8 codiert wurde? Es ist wahr, dass Sie es nicht entschlüsseln könnten, aber Sie könnten den verstümmelten Namen zumindest eindeutig als Zeichenfolge anzeigen, was eine Verbesserung gegenüber dem Nichtvorhandensein für einige Anwendungsfälle darstellt.

Meinen Sie die obige Diskussion über die Verwendung von UTF-8 als Kodierung undurchsichtiger Ganzzahlen und nicht als Unicode? Ich glaube, die Diskussion ist etwas durcheinander geraten. Es ist verlockend , kodieren „Syntax“ und Internationalisierung „Semantik“ zu nennen, aber das trübt eine nützliche Unterscheidung: UTF-8 kann immer noch sagen , dass eine bestimmte Byte - Sequenz bedeutet „Ö“ ohne zu sagen , was die Verbraucher mit dieser Information zu tun haben. Auf diese Weise verwendet, handelt es sich um eine Kodierung von Unicode, die jedoch nicht die Art von Kosten erfordert, die oben unter "Unicode-Unterstützung" vorgeschlagen wurde.

Warum sollte ich mir dann überhaupt die Mühe machen, eine unbekannte Zeichenfolge zu decodieren? Nun, ich würde nicht! Ich könnte genauso gut mit dem ursprünglichen binären Blob von 8-Bit-Werten arbeiten und Platz und Zyklen sparen. Die Spezifikation würde jedoch immer noch erfordern, dass ich Zyklen aufwende, um die Codierung vakant zu validieren.

Ich habe jetzt einen SpiderMonkey mit vollständiger UTF-8-Validierung von Wasm-Import-/Export-Identifikatoren erstellt, einschließlich Überlängen und Surrogate. Ich konnte keinen Leistungsunterschied in WebAssembly.validate feststellen, weder bei AngryBots noch bei einem kleinen emscripten-kompilierten Testfall, der dennoch 30 Importe hat.

Die Spezifikation ist ein Kompromiss zwischen mehreren Anliegen. Ich weiß die Sorge um die Startzeit zu schätzen, deshalb habe ich jetzt einige Experimente durchgeführt und gemessen. Ich ermutige andere, ihre eigenen Experimente zu machen.

Außerdem ist UTF-8 nicht die einzige Unicode-Codierung und kann zum Codieren von Nicht-Unicode-Ganzzahlen verwendet werden. UTF-8 ist also kein Unicode.

Welche ganzen Zahlen kann UTF-8 kodieren, die nicht Teil von Unicode sind (dh außerhalb des Bereichs U+0000 bis U+10FFFF)? Diese Aussage scheint falsch zu sein.

Wenn Sie Ihre Zeichen nicht validieren, können Sie eine beliebige 21-Bit-Ganzzahl codieren.

Ich bin mir nicht ganz sicher, warum wir nicht validieren würden...

@flagxor https://encoding.spec.whatwg.org/ beschreibt die verschiedenen Codierungen, die im Web verfügbar sind. Beachten Sie, dass keiner von ihnen den Unicode-Zeichensatz verlässt, aber sie sind offensichtlich nicht alle miteinander Byte-kompatibel.

Was würde "Validierung" bewirken? Machen Sie Ihr wasm-Programm ungültig? Ich glaube nicht, dass es irgendwelche tatsächlichen Konsequenzen gibt, die vernünftigerweise auferlegt werden können.

Wenn Sie beispielsweise ein ungültiges Escape in CSS verwenden, wird nur ein U + FFFD in Ihr Stylesheet eingefügt, es macht nichts Seltsames.

@annevk :

Außerdem ist UTF-8 nicht die einzige Unicode-Codierung und kann zum Codieren von Nicht-Unicode-Ganzzahlen verwendet werden. UTF-8 ist also kein Unicode.

Welche ganzen Zahlen kann UTF-8 kodieren, die nicht Teil von Unicode sind (dh außerhalb des Bereichs U+0000 bis U+10FFFF)? Diese Aussage scheint falsch zu sein.

Zumindest: U+FFFE und U+FFFF sind Nichtzeichen in Unicode. Die Codepunkte (die Integer-Werte) werden von Unicode niemals zum Kodieren von Zeichen verwendet, können jedoch in UTF-8 kodiert werden.

Sie sind jedoch immer noch Unicode-Codepoints. Ich würde mich nicht zu sehr auf "Charaktere" konzentrieren.

Die Decodierung von

Als solches macht es nicht mehr Sinn, Unicode dem Kern von Wasm aufzuzwingen, als beispielsweise allen String-Literalen in der Programmiersprache C Unicode aufzuzwingen. Sie würden nur einige potenzielle Kunden dazu zwingen, gegen diesen Standard zu verstoßen. Was ist der Gewinn?

Beachten Sie, dass C11 die Typen char16_t und char32_t sowie ein u Präfix für UTF-16-codierte Zeichenfolgenliterale und ein U Präfix für . hinzugefügt hat UCS-4-codierte Zeichenfolgenliterale und ein u8 Präfix für UTF-8-codierte Zeichenfolgenliterale. Ich habe nicht tief genug gegraben, um ihre Gründe für das Hinzufügen zu finden, aber ich gehe davon aus, dass der "Umgang mit Unicode in Standard-C/C++ ein Albtraum" ist, zumindest ein Teil der Motivation.

@tabatkins , @sunfishcode , okay, du redest also nicht über dasselbe. Aber AFAICT @jfbastien hat explizit und wiederholt erklärt, dass sein Vorschlag darin besteht, UTF-8 ohne den Unicode-Zeichensatz anzugeben.

Dies ist auch die einzige Auslegung, unter der die Behauptung der geringen Kosten Bestand hat.

Denn wenn wir tatsächlich _do_ annehmen, dass UTF-8 Unicode impliziert, dann ist diese Anforderung sicherlich viel teurer als nur die UTF-8-Kodierung/-Dekodierung für jedes Tool auf einem System, das noch nicht (eine Untermenge von) Unicode spricht – sie 'müssen eine vollständige Transcodierungsebene enthalten.

@tabatkins , Core Wasm wird in bereits vorhandene Systeme eingebettet - manchmal aus anderen Gründen als der Portabilität -, die keine Macht haben, etwas zu ändern oder aufzuerlegen. Wenn sie mit den von Ihnen beschriebenen Problemen konfrontiert sind, existieren diese unabhängig von Wasm. _Wir_ können _ihre_ Probleme nicht lösen.

Das wahrscheinliche Ergebnis eines _versuchen_, Unicode allen aufzuzwingen, wäre, dass einige potenzielle einfach diesen Teil der Spezifikation verletzen, was ihn völlig gegenstandslos macht (oder schlimmer noch, sie würden Wasm ganz ignorieren).

Wenn wir OTOH auf einer angemessenen Ebene spezifizieren, gehen wir dieses Risiko nicht ein – ohne in der Praxis etwas zu verlieren.

Denn wenn wir tatsächlich davon ausgehen, dass UTF-8 Unicode impliziert, dann ist diese Anforderung sicherlich viel teurer als nur die UTF-8-Kodierung/-Dekodierung für jedes Tool auf einem System, das noch nicht (eine Untermenge von) Unicode spricht – sie 'müssen eine vollständige Transcodierungsebene enthalten.

Welche Plattformen gibt es, die einen nativen Zeichensatz verwenden, der nicht Unicode und nicht ASCII ist, keine Möglichkeiten zum Konvertieren dieser Zeichen in / aus Unicode haben und in Wasm Nicht-ASCII-Bezeichner verwenden müssen? (Ich meine, wirklich existieren, nicht irgendeine hypothetische russische Organisation, die sich dafür entscheidet, Wasm in DOS zu verwenden.)

@rocallahan Ich glaube, @rossberg-chromium befasst sich (oder zumindest ich) mit Geräten wie eingebetteten Systemen, die nicht die zusätzlichen Kosten einer vollständigen ICU-Bibliothek haben möchten. Sie wären entweder gezwungen, Bloat zu akzeptieren, keine vollständige Validierung durchzuführen oder keine Wasm-Dateien zu akzeptieren, die Nicht-ASCII-Zeichen enthalten (auf die sie möglicherweise keine Kontrolle haben).

Genau genommen enthalten solche Geräte auch oft Hardware mit nicht standardmäßigen Zeichensätzen wie:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(Was einen albernen gemischten ASCII + Latin1 + japanischen Zeichensatz hat)
Aber die Sorge ist, was Sie validieren müssen, was unabhängig davon relevant ist.

@tabatkins obwohl ich dachte, dass dies die Absicht ist:

• Mandate UTF-8 + Unicode als einzige "richtige" Interpretation der Bytes
• Geben Sie explizit an, dass der Unicode nicht validiert werden muss, damit das Modul validiert wird (um Kosten zu sparen)

Ich glaube, @rossberg-chromium befasst sich (oder zumindest ich) mit Geräten wie eingebetteten Systemen, die nicht die zusätzlichen Kosten einer vollständigen ICU-Bibliothek haben möchten. Sie wären entweder gezwungen, Bloat zu akzeptieren, keine vollständige Validierung durchzuführen oder keine Wasm-Dateien zu akzeptieren, die Nicht-ASCII-Zeichen enthalten (auf die sie möglicherweise keine Kontrolle haben).

Wie immer wieder gesagt, ist dies ein Ablenkungsmanöver. Es besteht keine Notwendigkeit, irgendetwas im Zusammenhang mit der Intensivstation aus der Ferne zu tun; das Web tut dies definitiv nicht. Bitte hören Sie auf, diese falschen Informationen zu verbreiten.

"Vollständige Validierung" ist eine äußerst triviale Operation, die automatisch als Teil einer konformen UTF-8-Decodierungsoperation durchgeführt wird.

Beim Chatten mit @tabatkins ist eine Sache meiner Meinung nach entscheidend, um hier klar zu sein:
Ein konformer Unicode-Decoder ist ERFORDERLICH, um beliebige Kombinationen von Modifikatoren, nicht zugewiesenen Codepunkten usw. zuzulassen. Eine verirrte Mischung von Modifikatoren usw., auch wenn sie nicht zu etwas Sinnvollem führt, muss von Unicode zugelassen werden. Ein Decoder, der unsinnige Kombinationen zurückweist, wäre nicht konform.

Die Anforderung für eine ordnungsgemäße UTF-8-Decodierung ist also genau so definiert, dass sie in einer Handvoll Codezeilen ausgeführt werden kann, ist eine exakte Operation und entspricht im Wesentlichen der Angabe einer Unicode + UTF-8-Interpretation der Bytes.

Jawohl. Das Parsen von UTF-8 ist extrem trivial; Die einzigen Komplikationen sind die Handvoll Codepunkte, die Sie nicht in UTF-8 codieren dürfen, die ein konformer Decoder stattdessen als ein oder mehrere U+FFFD-Zeichen analysiert.

Aber das ist eine Operation für den Endpunkt . Wasm braucht sich um nichts davon zu kümmern; kompatible Decoder können jedes beliebige Bitmuster verarbeiten, das Sie ihnen zuwerfen. (Sie werden einfach entscheiden, dass der größte Teil eines Müll-Bit-Musters aus U+FFFD-Zeichen besteht.) Alles, was ich die ganze Zeit verlangt habe, ist eine Konformitätsanforderung auf Autorenebene, dass diese Strings mit UTF-8 codiert werden. Wenn Sie dagegen verstoßen, kann Ihre Toolchain dies als Fehler markieren, aber Wasm selbst muss nichts tun.

Dies ist beispielsweise ähnlich wie CSS, das eine Grammatik für ein gültiges Stylesheet definiert, aber technisch immer noch jedes beliebige Bitmuster akzeptiert.

Genau genommen enthalten solche Geräte auch oft Hardware mit nicht standardmäßigen Zeichensätzen wie:

Die Existenz solcher Zeichensätze ist für Wasm irrelevant, es sei denn, Sie erwarten, dass Benutzer Wasm-Kennungen in den (Nicht-ASCII-Bereichen) von ihnen schreiben.

Richtig, alles "UTF-8 verwenden" bedeutet https://encoding.spec.whatwg.org/#utf -8-decoder. Die Intensivstation ist nicht einmal annähernd eine Anforderung.

Am 25. Februar 2017 um 01:13 Uhr schrieb Brad Nelson [email protected] :

Im Chat mit @tabatkins https://github.com/tabatkins , eine Sache
das ist meiner Meinung nach entscheidend, um hier klar zu sein:
Ein konformer Unicode-Decoder ist ERFORDERLICH, um beliebige
Kombinationen von Modifikatoren, nicht zugewiesenen Codepunkten usw. Also eine verirrte Mischung aus
Modifikatoren usw., auch wenn es nicht zu etwas Sinnvollem wird, ist
erforderlich, um von Unicode zugelassen zu werden. Ein Decoder, der Unsinn zurückwies
Kombinationen wären nicht konform.

Die Anforderung für eine ordnungsgemäße UTF-8-Decodierung ist also klar definiert
etwas, das Sie in einer Handvoll Codezeilen tun können, ist eine exakte Operation,
und entspricht im Wesentlichen der Angabe von Unicode + utf-8
Interpretation der Bytes.

Um zu verdeutlichen, was ich gesagt habe. Ich bestreite nicht, dass eine vollständige Intensivstation wahrscheinlich nicht sein würde
notwendig (obwohl zB das Sortieren von Namen nach Codepunkten schlecht klingt
Benutzerfreundlichkeit).

Die Behauptung, dass nur noch triviale Dekodierung übrig bleibt, ist jedoch nicht richtig
entweder, weil es nicht mit der Validierung aufhört. Nicht-Unicode-Plattformen
gezwungen wären, eine Transcodierung durchzuführen, um ihre Strings tatsächlich zu handhaben.
Außerdem müssten sie sich mit dem Problem der Charaktere auseinandersetzen, die
kann nicht zugeordnet werden (in beide Richtungen), sodass Sie immer noch Kompatibilität haben
Probleme im Allgemeinen, nur die Dose die Straße runter getreten.

>

Genau genommen enthalten solche Geräte auch oft Hardware, die über
nicht standardmäßige Zeichensätze wie:

Die Existenz solcher Zeichensätze ist für Wasm irrelevant, es sei denn, Sie
erwarten, dass die Leute Wasm-Identifikatoren in den (Nicht-ASCII-Bereichen) von ihnen schreiben.

@rocallahan https://github.com/rocallahan , sie müssen es immer noch können
nehmen Sie beliebigen Unicode ein. Aber was würden sie damit anfangen? Wenn ein Wasm
Implementierung auf einer solchen Plattform auf ASCII beschränkt, dann wäre es
gegen die vorgeschlagene Spezifikation verstoßen. (Ich würde das auch als implizierend betrachten
Nicht-ASCII-Zeichen von jemandem sind von vornherein irrelevant, können kulturell sein
fraglich. Das sollte ihre Entscheidung sein.)

Darüber hinaus müssten sie sich mit dem Problem von Zeichen befassen, die nicht zugeordnet werden können (in beide Richtungen), sodass Sie im Allgemeinen immer noch Kompatibilitätsprobleme haben, wenn Sie einfach die Dose runtertreten.

Ist das ein theoretisches Problem?

Und wenn es ein vernünftiges Anliegen ist, müssen wir noch einmal die (Auftreten * Kosten) der Behandlung gegen die Kosten abwägen, die praktisch jeder andere Benutzer von Wasm auf der Welt nicht auf eine Kodierung verlassen kann und sich mit der Dieselbe Kodierungs-Hölle musste die Webplattform durchlaufen und schließlich so gut wie möglich repariert werden.

Nicht-Unicode-Plattformen wären gezwungen, eine Transcodierung durchzuführen, um ihre Strings tatsächlich zu verarbeiten.

In welchen Fällen müssen Wasm-Strings jedoch mit Plattform-Strings interagieren? Soweit ich das beurteilen kann, sprechen wir nur über die Codierung von Strings in den Wasm-Metadaten, nicht über die Codierung von Strings, die durch den tatsächlichen Modulcode manipuliert werden. (Wenn das falsch ist, entschuldige ich mich...) Dann fallen mir nur ein paar mögliche Fälle ein, in denen Interop/Transcoding erforderlich sein könnte:

• Ein Wasm-Modul importiert eine Plattformkennung
• Die Plattform importiert eine Wasm-Kennung
• Sie können Wasm-Namen extrahieren und drucken oder mit Plattform-Strings speichern, um zB einen Stack-Trace zu erstellen.

Rechts?

Für hypothetische eingebettete Nicht-Unicode-Systeme ist der Rat für die ersten beiden Fälle einfach: Begrenzen Sie die über die Plattformgrenze importierten Kennungen auf ASCII, dann ist die erforderliche Transcodierung trivial. Wasm-Module konnten intern und zum Verlinken untereinander weiterhin vollständige Unicode-Namen verwenden.

Für das dritte Problem --- Wenn Sie eine geschlossene Welt von Wasm-Modulen haben, können Sie deren Bezeichner auf ASCII beschränken. Wenn nicht, werden Sie in der Praxis auf UTF8-Identifikatoren stoßen und diese besser transcodieren können, und Sie werden froh sein, dass UTF8 von der Spezifikation vorgeschrieben wird!

was bedeutet, dass die Nicht-ASCII-Zeichen von jemandem von vornherein irrelevant sind

Das ist ein Strohmann-Argument. Die Position hier ist "wenn Sie Nicht-ASCII-Identifikatoren möchten, verwenden Sie Unicode oder implementieren Sie die Transcodierung in / von Unicode", und es wurde in anderen Spezifikationen, AFAIK, nicht als "kulturell fragwürdig" kritisiert.

>

Und wenn es ein berechtigtes Anliegen ist, müssen wir noch einmal das (Vorkommen

• Kosten) damit umzugehen gegen die Kosten praktisch aller anderenBenutzer von Wasm in der Welt nicht auf eine Kodierung verlassen können, und
  mit der gleichen Kodierungs-Hölle zu kämpfen, die die Web-Plattform durchmachen musste,
  und schließlich repariert, so gut es ging.

@tabatkins , nein, schon wieder (und irgendwie habe ich das Gefühl, dass ich diese 100 wiederholt habe
schon mal): jede Einbettungsspezifikation _wird_ eine Kodierung angeben und
Zeichensatz. Darauf können Sie sich auf jeder Plattform verlassen. Du würdest immer nur rennen
in Codierungsfragen, wenn Sie versucht haben, zwischen zwei nicht verwandten zu interagieren
Ökosysteme – die bereits aus tieferen Gründen inkompatibel sein werden als
Saiten. Und dies würde sich nur auf die Interop mit Plattformen auswirken, die Sie sonst verwenden würden
ganz ausschließen. Sie _verlieren also nichts_, gewinnen aber die Fähigkeit zu verwenden
Wasm auf diversen Plattformen.

Sie sind Software-Ingenieure. Daher gehe ich davon aus, dass Sie es verstehen und schätzen
den Wert von Modularisierung und Schichtung, um Anliegen zu trennen und zu maximieren
Wiederverwendung. Das gilt auch für Spezifikationen.

>

Nicht-Unicode-Plattformen wären gezwungen, tatsächlich eine Transcodierung durchzuführen
ihre Saiten handhaben.

In welchen Fällen müssen Wasm-Strings mit Plattform-Strings interagieren?
obwohl? Soweit ich das beurteilen kann, sprechen wir nur über die Kodierung von
Zeichenfolgen in den Wasm-Metadaten, nicht die Kodierung von Zeichenfolgen, die von manipuliert wurden
eigentlicher Modulcode. (Wenn das falsch ist, entschuldige ich mich...) Dann kann ich nur denken
von wenigen möglichen Fällen, in denen Interop/Transcoding erforderlich sein könnte:

• Ein Wasm-Modul importiert eine Plattformkennung
• Die Plattform importiert eine Wasm-Kennung
• Sie können Wasm-Namen extrahieren und drucken oder mit der Plattform speichern
  Strings, zB um einen Stack-Trace zu erstellen.

Rechts?

Jawohl. Mit anderen Worten, jedes Mal, wenn Sie tatsächlich einen String _verwenden_ müssen.

Für hypothetische eingebettete Nicht-Unicode-Systeme gilt für die ersten beiden Fälle:
Der Rat ist einfach: Begrenzen Sie die über die Plattform importierten Identifikatoren
Grenze zu ASCII, dann ist die erforderliche Transcodierung trivial. Wasm-Module
konnte intern und zum Verlinken immer noch vollständige Unicode-Namen verwenden.

Für die dritte Ausgabe --- Wenn Sie eine geschlossene Welt von Wasm-Modulen haben, können Sie
können ihre Bezeichner auf ASCII beschränken. Wenn nicht, dann wirst du in der Praxis
auf UTF8-Identifikatoren stoßen und Sie sollten sie besser transcodieren können, und
Sie werden froh sein, dass UTF8 die Spezifikation erfordert!

Nach dem Vorschlag dürfen Sie nichts auf ASCII beschränken! Zu
erlauben, dass die Kernspezifikation mehr zulässt. Also machst du
mein Punkt.

jede Einbettungsspezifikation _wird_ eine Kodierung und einen Zeichensatz angeben. Darauf können Sie sich auf jeder Plattform verlassen. Sie würden nur dann auf Codierungsfragen stoßen, wenn Sie versuchten, zwischen zwei nicht zusammenhängenden Ökosystemen zu interagieren – die bereits aus tieferen Gründen als Strings inkompatibel sind.

Was ist mit Wasm-Verarbeitungswerkzeugen wie Disassemblern? Wäre es nicht wertvoll, einen Disassembler schreiben zu können, der mit jedem Wasm-Modul funktioniert, unabhängig von "Einbettungsspezifikationsvarianten"?

Nach dem Vorschlag dürfen Sie nichts auf ASCII beschränken!

Nach dem Vorschlag wären Wasm-Module nicht auf ASCII beschränkt, aber wenn ein Implementierer beschließen würde, alle seine Bezeichner außerhalb von Wasm-Modulen als ASCII zu definieren (z spez.

Wenn ein Implementierer sich dafür entschieden hat, nur ASCII-Zeichen in einem Stack-Trace zu drucken und alle Nicht-ASCII-Unicode-Zeichen durch ? oder ähnliches zu ersetzen, muss dies von der Spezifikation zugelassen werden, da es in der Praxis immer Unicode-Zeichen gibt, die Sie nicht verwenden habe sowieso keine Schriftart.

Trotzdem wäre es ziemlich harmlos, eine Untermenge von Wasm zu definieren, in der alle Wasm-Namen ASCII sind, da solche Wasm-Module von Tools, die Wasm-Namen als UTF8 behandeln, korrekt verarbeitet würden.

Sie sind Software-Ingenieure. Daher gehe ich davon aus, dass Sie den Wert von Modularisierung und Schichtung verstehen und schätzen, um Bedenken zu trennen und die Wiederverwendung zu maximieren. Das gilt auch für Spezifikationen.

Ja, ich bin Software-Ingenieur. Ich bin auch ein Spec Engineer, daher verstehe ich den Wert von Konsistenz und der Festlegung von Normen, die das Ökosystem verbessern. Zeichensätze und Kodierungen sind eines der Themen, bei denen der Wert der Modularisierung und Auswahl durch den Wert der Konsistenz und Vorhersagbarkeit bei weitem aufgewogen wird. Dafür haben wir buchstäblich jahrzehntelange Beweise. Das ist , warum ich mich immer wieder zu wiederholen - Sie Geschichte sind zu ignorieren und die Empfehlung vieler Experten, von denen einige in diesem Thread angezeigt, und viele mehr , die ich , die die Meinungen von, wenn Sie darauf bestehen , dass wir müssen in dieser Hinsicht Freiheit zulassen.

Nachdem ich diesen ganzen (langen) Thread gelesen habe, denke ich, dass die einzige Möglichkeit, diese Diskussion zu lösen, darin besteht, explizit anzugeben, dass der Namensabschnitt, den wir beschreiben, im Binärformat vorliegt und in https://github.com/WebAssembly/design/pull . verbessert wird eine UTF-8-Kodierung , und ich würde vorschlagen, dass wir diesen Abschnitt einfach "utf8-names" nennen . Das macht die Kodierung explizit, und fast sicher wollen alle Tools, die heute WASM-Binärdateien auf allen relevanten Plattformen manipulieren wollen, sowieso UTF-8 sprechen. Ihnen könnte vergeben werden, dass sie nur UTF-8 sprechen.

Ich bin sensibel für die Bedenken von @rossberg-chromium für andere Plattformen und stimme bis zu einem gewissen Grad zu. Dies ist jedoch leicht zu beheben. Wie jemand zuvor in dem Thread vorgeschlagen hat, sind diese Systeme mehr als willkommen, einen nicht standardmäßigen Abschnitt "ascii-names" oder eine andere Codierung hinzuzufügen, die ihr Ökosystem verwendet. Bei expliziten Namen wird deutlich, welche Tools mit welchen Abschnitten arbeiten. Bei Modulen, die nur unter DOS funktionieren, würde dies aus dem Vorhandensein von DOS-spezifischen Abschnitten ersichtlich. IMO wäre es eine Katastrophe, die Namen dieser Binärdateien so zu interpretieren, dass sie eine andere Codierung haben.

(Dies wird übrigens von Kriegsgeschichten über ein System informiert, das versehentlich die Codierungen der Zeichenfolgen für von Benutzern hochgeladenen Inhalten verloren hat und sie nie wiederherstellen konnte. Das System starb einen schrecklichen, krampfartigen Tod. Buchstäblich gingen Millionen von Dollar verloren .)

Wir könnten sogar einen Benennungsstandard für Namensabschnitte (heh) übernehmen, sodass sie alle "\

@titzer Ja, benutzerdefinierte Abschnitte sind hier die Lösung für exotische oder spezialisierte Plattformen, die mit UTF8 nichts zu tun haben wollen. Ich würde jedoch zögern, dies in der Spezifikation vorzuschreiben: Wenn eine Plattform in ihrer Funktionsweise so spezifisch ist, dass sie sich nicht einmal die Mühe machen kann, UTF-8-Codepunkte ihrer nativen Präferenz zuzuordnen, möchten sie möglicherweise dies tun mit benutzerdefinierten Abschnitten viel mehr als nur Namen in ihrer bevorzugten Codierung bereitzustellen.

Ich empfehle, mehr Wert darauf zu legen, benutzerdefinierte Abschnitte für plattformspezifische Details in der Spezifikation zu verwenden und diese Details von den plattformeigenen Spezifikationen definieren zu lassen. Gängige WASM-Toolchains könnten sie über eine Art Plug-in-Architektur unterstützen.

@titzer Der Wechsel zu utf8-names klingt gut. Als Bonus würde es den Übergang glätten, da Browser problemlos sowohl "Namen" (im alten Format) als auch "utf8-names" (im #984-Format) für ein oder zwei Releases unterstützen könnten, bevor "Namen" fallen gelassen wird, was wiederum entfernt eine Menge Dringlichkeit, um dies bereitzustellen.

Entschuldigung, wenn dies bereits oben entschieden wurde, aber um es klar zu sagen: Gibt es eine vorgeschlagene Änderung der Import-/Exportnamen von dem, was jetzt in BinaryEncoding.md ist?

utf8-names hört sich gut an.

Gleiche Frage wie @lukewagner zum Import/Export.

@lukewagner @jfbastien Gute Frage. Ich habe oben keine Entscheidung gesehen. Ich denke, vor allem wollen wir das Binärformat von dem, was wir jetzt haben, nicht ändern. Es sind also wirklich nur die mentalen Verrenkungen, die wir durchmachen müssen, um uns davon zu überzeugen, was wir getan haben :-)

AFAICT wir gehen derzeit davon aus, dass Strings im Import/Export nicht interpretierte Bytefolgen sind. Das ist in Ordnung. Ich denke, es ist vernünftig, die Kodierung von Strings, die für den Import/Export verwendet werden, ausschließlich vom Einbetter in einer Weise zu definieren, die der Namensabschnitt nicht ist; ZB verwendet JS immer UTF-8. Der Namensabschnitt enthält eine explizite Codierung im Namen des Namensabschnitts.

Kurzfassung: Die Kodierung von Namen in Import-/Export-Deklarationen ist eine Eigenschaft der Einbettungsumgebung, die Kodierung von Namen im Namensabschnitt ist explizit durch den String, der zur Identifizierung des Benutzerabschnitts verwendet wird (zB "utf8-names").

WDYT?

Das ist für mich in Ordnung und entspricht dem, was wir vor der Zusammenführung von #984 hatten (modulo names => utf8-names ).

Ich denke, der Abschnitt mit den Namen ist nicht so wichtig wie der Import/Export, wo die wahren Kompatibilitätsprobleme auftreten:

• Laden Sie einen Abschnitt mit Mojibaked-Namen und Sie erhalten funky Error.stack und Debugging.
• Laden Sie einen Mojibaked-Import/Export und nichts funktioniert.

Ich glaube nicht, dass dies wirklich eine Änderung des binären Formats ist, da die Einbettungen, die wir alle implementieren, dies bereits annehmen.

Ich würde mich auf die Empfehlung von Leuten stützen, die sich mit diesem Thema besser auskennen als ich, bevor ich schließe.

Sie müssen entscheiden, wie Sie UTF-8 dekodieren. Ersetzen Sie fehlerhafte Sequenzen durch U+FFFD oder halten Sie beim ersten Fehler an? Das heißt, Sie möchten entweder https://encoding.spec.whatwg.org/#utf -8-decode-ohne-bom oder https://encoding.spec.whatwg.org/#utf -8-decode-ohne- scheitern oder scheitern. In beiden Fällen wird das Laden wahrscheinlich fehlschlagen, es sei denn, die Ressource verwendet U+FFFD in ihrem Namen.

So wie es derzeit beschrieben ist , lösen wir eine Ausnahme aus, wenn das Import-/Export-Namensbyte-Array nicht als UTF-8 in einen JS-String dekodiert werden kann. Danach haben Sie einen JS-String und die Importsuche wird in Form von Get .

Um mein Verständnis zu überprüfen, wenn wir https://encoding.spec.whatwg.org/#utf -8-decode-ohne-bom-or-fail gemacht hätten, würde dies bedeuten, dass nach erfolgreicher Validierung die Codepunkt-Sequenz-Gleichheit überprüft wird wäre gleichbedeutend mit der Prüfung auf Byte-Sequenz-Gleichheit?

Jawohl.

Nach der obigen Diskussion unterstütze ich die Validierung von UTF-8 für Import-/Exportnamen in der Kernspezifikation.

Konkret wäre dies utf-8-decode-ohne-bom-or-fail und Codepoint-Sequence-Gleichheit (damit Engines Byte-Sequence-Gleichheit ausführen können ), sodass Engines die beängstigenden und teuren Teile von Unicode und Internationalisierung vermeiden würden. Und dies steht im Einklang mit der Web-Einbettung. Ich habe damit experimentiert und fand den Hauptaufwand vernachlässigbar.

• Betreff: Hardware-ISAs sind agnostisch gegenüber der Kodierung: Die Hardware, über die wir hier sprechen, hat keine Importe/Exporte als solche, daher trifft die Analogie nicht direkt zu. Der einzige Ort, den ich kenne, wo solche Hardware Byte-Sequenz-Identifikatoren jeglicher Art verwendet, die cpuid von x86, spezifiziert eine bestimmte Zeichenkodierung: UTF-8.

• Betreff: Layering: Als Software-Ingenieure wissen wir auch, dass Layering und Modularisierung Mittel und kein Selbstzweck sind. Zum Beispiel könnten wir LEB128 sauber aus der Kernspezifikation herausrechnen. Dies würde eine stärkere Schichtung und Modularisierung ermöglichen. LEB128 ist wohl eher auf Web-Anwendungsfälle ausgerichtet.

• Re: "Eingebettete Systeme": Ein Beispiel ist DOS, aber was wäre ein Beispiel für etwas, das eine UTF-8-Anforderung für Import-/Exportnamen von einem DOS-System erfordern würde, das teuer oder unpraktisch wäre?

• Betreff: Inseln: WebAssembly spezifiziert auch eine bestimmte Endianness, erfordert Gleitkomma-Unterstützung, 8-Bit-Adresseinheiten und trifft andere Entscheidungen, obwohl es echte Einstellungen gibt, die unnötig belasten würden. WebAssembly trifft Entscheidungen wie diese, wenn es erwartet, dass sie die gemeinsame Plattform stärken, die viele Menschen teilen können.

• Betreff: Beliebige Datenstrukturen in Import/Export-Namen: Das ist theoretisch sinnvoll, kann aber auch über das Zerlegen von Daten in Strings erfolgen. Das Verstümmeln ist weniger bequem, aber nicht schwierig. Es gibt also einen Kompromiss, aber keinen großen (und wenn es allgemein erforderlich ist, Metadaten an Importe/Exporte anzuhängen, wäre es besser, einen expliziten Mechanismus zu haben, als Bezeichner mit zusätzlichen Zwecken zu versehen.)

• Betreff: Binärkompatibilität: Ich stimme auch JF zu, dass diese Änderung noch machbar ist. utf-8-decode-ohne-bom-or-fail würde keine stillschweigenden Verhaltensänderungen bedeuten, und zu diesem Zeitpunkt halten alle bekannten wasm-Produzenten ihre Ausgabe kompatibel mit der Web-Einbettung (auch wenn sie auch andere Einbettungen unterstützen). Sie bleiben bereits innerhalb von UTF-8.

Ein PR, der einen spezifischen Vorschlag für UTF-8-Namen macht, wird jetzt als https://github.com/WebAssembly/design/issues/1016 veröffentlicht.

Mit #1016 ist dies nun behoben.