Argument pour UTF-8 : c'est très simple. encodeur et décodeur en JavaScript. Encore une fois, UTF-8 n'est pas Unicode .

Argument contre UTF-8 : c'est toujours un peu plus compliqué que longueur + octets, ce qui entraîne des divergences d'implémentation potentielles.

Encore une fois, UTF-8 n'est pas Unicode.

Qu'est-ce que tu dis même? C'est une phrase absurde.

Je pense que vous essayez de dire qu'il n'est pas nécessaire de faire appel à une bibliothèque d'internationalisation. C'est vrai - exiger que les chaînes soient codées en UTF-8 n'a rien à voir avec toutes les parties les plus compliquées d'Unicode, comme la canonisation. Ce sont des outils utiles lorsque vous travaillez sur des chaînes de caractères qui s'interfacent avec des humains, mais de la même manière qu'une bibliothèque de trig est utile pour les personnes faisant des mathématiques, et non pertinente pour décider comment encoder des entiers.

Mais UTF-8 est littéralement un encodage Unicode ; votre déclaration n'a pas de sens telle qu'elle est écrite. ^_^

Mais UTF-8 est littéralement un encodage Unicode ; votre déclaration n'a pas de sens telle qu'elle est écrite. ^_^

Oui, je fais spécifiquement référence à l'encodage des points de code que décrit UTF-8, et non au traitement des points de code proprement dit (aux fins de cette proposition, un point de code est un entier opaque). Mis dans wasm-isms, UTF-8 est similaire à var[u]int, mais plus approprié aux caractères. De plus, UTF-8 n'est pas le seul codage Unicode et il peut être utilisé pour coder des entiers non Unicode. Ainsi, UTF-8 n'est pas Unicode.

Une autre proposition examinerait les points de code individuels et ferait quelque chose avec eux. Ce n'est pas cette proposition.

Et il n'y aurait aucune raison de le faire. Aucune API Web n'a trouvé le besoin d'introspecter les points de code au-delà de la comparaison et du tri d'égalité stricte, à moins qu'il ne s'agisse littéralement d'une API i18n.

Une autre option est la longueur d'octet + UTF-8 pour chaque point de code ( @jfbastien à moins que ce ne soit ce que vous vouliez dire lorsque vous avez dit UTF-8 pour chaque octet, ce qui, je l'admets, n'avait pas de sens pour moi). Je ne pense pas que cela rendrait les choses plus difficiles pour un analyseur primitif qui ne s'en soucie pas vraiment, tout en permettant à une bibliothèque Unicode sophistiquée de prendre un tableau d'octets, un décalage et une longueur en entrée et de renvoyer une chaîne.

Je suis d'accord avec la définition en tant que "points de code UTF-8", qui ne sont que des entiers. La spécification binaire devrait en rester là. Les intégrateurs individuels peuvent définir des règles concernant les points de code autorisés, la normalisation et d'autres nuances. Les outils d'analyse peuvent fournir des avertissements pour des problèmes de compatibilité potentiels.

Je pense que les décisions de gestion des erreurs devraient également être laissées aux intégrateurs. Un système qui a accédé aux fonctions WASM par index plutôt que par nom n'a pas besoin qu'elles soient valides (et il serait facile de les ignorer avec un préfixe de longueur d'octet).

Voici une tentative de résumer les problèmes sous-jacents et leurs raisons. Les corrections et ajouts sont les bienvenus.

Wasm devrait-il exiger que les identifiants d'import/export de module soient UTF-8 valides ?

Ma compréhension des raisons contre est :

• Le traitement des importations et des exportations est sur le chemin critique pour le démarrage de l'application, et il y a un désir d'éviter tout ce qui pourrait le ralentir.
• L'invariant large « la spécification de base de wasm n'interprète pas les chaînes ». L'interprétation des chaînes est complexe en général, et il y a un désir de l'encapsuler et d'avoir des invariants et des limites larges sur lesquels on peut raisonner à un niveau élevé.
• Les décodeurs WebAssembly sont souvent sensibles à la sécurité, il y a donc un désir général de minimiser la quantité de code impliquée.
• Certains producteurs WebAssembly peuvent souhaiter incorporer des données arbitraires dans ces identifiants, et il est plus pratique pour eux d'encoder les données comme ils le souhaitent au lieu de les transformer sous forme de chaîne.

Wasm devrait-il recommander l'UTF-8 dans les domaines où il ne l'exige pas ?

La raison en serait que même si nous ne pouvons pas l'exiger, mentionner UTF-8 peut décourager les incompatibilités inutiles entre l'écosystème.

Ma compréhension de la raison contre est que même mentionner UTF-8 compromettrait l'encapsulation conceptuelle des problèmes d'interprétation des chaînes.

Wasm doit-il spécifier UTF-8 pour les noms de section de nom ?

La raison en est la suivante : le but de ces noms est d'être converti en chaînes pour l'affichage, ce qui n'est pas possible sans encodage, nous devons donc simplement spécifier UTF-8 afin que les outils n'aient pas à deviner.

Ma compréhension de la raison contre est la suivante: si wasm a d'autres choses semblables à des chaînes dans d'autres domaines qui n'ont pas d'encodage désigné (c'est-à-dire les importations / exportations comme indiqué ci-dessus), alors pour des raisons de cohérence, il ne devrait pas désigner d'encodages pour aucune chaîne .

@sunfishcode fournit un bon résumé, mais je souhaite ajouter trois points cruciaux.

@jfbastien , ce serait la plus inutile de toutes les alternatives de restreindre la _syntaxe_ binaire (un encodage) mais pas la _semantics_ (un jeu de caractères) pour les chaînes. Donc, à toutes fins utiles, UTF-8 implique Unicode. Et encore une fois, il ne s'agit pas que de moteurs. Si vous définissez des noms en Unicode, vous les forcez sur tous les éco-systèmes Wasm dans tous les environnements. Et cela signifie à peu près que tous les environnements doivent avoir une prise en charge Unicode.

@tabatkins , je pense qu'il y a une erreur de domaine sous-jacente à votre argument. Aucune des chaînes dont nous parlons n'est orientée vers l'utilisateur. Ce sont des noms orientés vers le développement. Beaucoup/la plupart des langages de programmation ne prennent pas en charge les identifiants Unicode, ni les outils. Est-ce que gdb peut par exemple gérer les identifiants de source Unicode ? Je ne pense pas. Il est donc assez optimiste (ou plutôt irréaliste) de supposer que tous les consommateurs ont convergé vers Unicode _dans cet espace_.

Et enfin, le désaccord n'est pas _si_ Wasm sur le Web doit supposer UTF-8, mais _où_ nous le spécifions.

Je pense qu'il y a une erreur de domaine sous-jacente à votre argument. Aucune des chaînes dont nous parlons n'est orientée utilisateur. Ce sont des noms destinés aux développeurs. Beaucoup/la plupart des langages de programmation ne prennent pas en charge les identifiants Unicode, ni les outils. Est-ce que gdb peut par exemple gérer les identifiants de source Unicode ? Je ne pense pas. Il est donc assez optimiste (ou plutôt irréaliste) de supposer que tous les consommateurs ont convergé vers Unicode dans cet espace.

« orienté vers le développement » signifie « orienté vers la chaîne d'outils arbitraire », ce qui signifie que vous devez vous mettre d'accord sur l'encodage à l'avance, sinon les outils devront effectuer l'encodage « détection » (c'est-à-dire, deviner, ce qui est particulièrement mauvais quand appliqué à des valeurs courtes) ou avoir des informations hors bande. Les développeurs sont toujours des utilisateurs. ^_^

Si vous pensez que beaucoup de chaînes d'outils ne comprendront pas Unicode, alors je ne sais pas pourquoi vous pensez qu'elles comprendraient tout autre codage binaire arbitraire. Si c'est votre limitation, spécifiez et exigez simplement ASCII, qui est pris en charge à 100% partout. Si vous n'êtes pas prêt à vous limiter à l'ASCII, vous devez accepter qu'il existe un seul schéma de codage non ASCII accepté - UTF-8.

Dire "eh, la plupart des choses ne supportent probablement que l'ASCII, mais nous laisserons les développeurs y mettre ce qu'ils veulent juste au cas où " est le pire des deux mondes.

Dire "eh, la plupart des choses ne supportent probablement que l'ASCII, mais nous laisserons les développeurs y mettre ce qu'ils veulent juste au cas où" est le pire des deux mondes.

@tabatkins , personne ne propose ce qui précède. Comme je l'ai dit, la question n'est pas _si_ mais _où_ pour définir de telles questions spécifiques à la plate-forme/à l'environnement. Wasm est censé être intégrable dans la gamme la plus large et la plus hétérogène d'environnements, certains beaucoup plus riches que d'autres (par exemple, JS prend en charge les identifiants Unicode). Par conséquent, vous souhaitez autoriser le choix par plate-forme. Par conséquent, il appartient aux spécifications de l'API de la plate-forme et non à la spécification de base.

Il n'y a pas de choix à faire, tho! Si votre environnement d'intégration ne prend pas en charge le non-ASCII, vous n'utilisez tout

Si votre environnement prend en charge le non-ASCII, vous devez savoir quel encodage utiliser, et le bon choix dans toutes les situations est UTF-8.

Quel environnement imaginez-vous où il est avantageux de ne pas connaître l'encodage de vos chaînes ?

ce serait la plus inutile de toutes les alternatives de restreindre la syntaxe binaire (un encodage) mais pas la sémantique (un jeu de caractères) pour les chaînes. Donc, à toutes fins utiles, UTF-8 implique Unicode.

Non, absolument pas. Par exemple, il est parfaitement raisonnable de simultanément (a) restreindre une chaîne aux caractères ASCII et (b) dicter qu'elle soit encodée en UTF-8. L'utilisation de caractères ASCII n'implique pas un encodage, sinon tous les encodages seraient compatibles ASCII ! (Par exemple, UTF-16 ne l'est pas.) Vous devez donc toujours spécifier quelque chose ; UTF-8, étant "compatible ASCII", est parfait pour cela.

Encore une fois, si vous êtes d'accord pour restreindre ces noms à l'ASCII uniquement, il est alors raisonnable d'exiger que l'encodage soit US-ASCII. Si vous voulez qu'il soit possible d'aller au-delà de l'ASCII, alors il est raisonnable d'exiger que l'encodage soit UTF-8. Exiger quoi que ce soit d'autre, ou ne rien imposer du tout (et forcer tous les consommateurs à deviner ou à utiliser des informations hors bande), sont les seules possibilités déraisonnables.

Et encore une fois, il ne s'agit pas que de moteurs. Si vous définissez des noms en Unicode, vous les forcez sur tous les éco-systèmes Wasm dans tous les environnements. Et cela signifie à peu près que tous les environnements doivent avoir une prise en charge Unicode.

Encore une fois, on dirait que vous parlez de bibliothèques d'internationalisation. Nous discutons uniquement de la façon de décoder les séquences d'octets en chaînes ; cela nécessite juste une connaissance de la façon de décoder UTF-8, ce qui est extrêmement trivial et extrêmement rapide.

À moins que vous ne fassiez une manipulation de chaînes conviviale, tout ce dont vous avez besoin est la possibilité de comparer les chaînes par point de code et éventuellement de trier les chaînes par point de code, aucun d'entre eux ne nécessitant de "prise en charge Unicode". C'est tout ce que la technologie Web existante utilise, par exemple, et je ne vois aucune raison pour laquelle les environnements Wasm auraient, en général, besoin de faire quelque chose de plus compliqué que cela.

Je suis en faveur de l'obligation d'utf8 pour All The Strings. Le décodage/encodage utf8 pur semble être une charge d'implémentation assez faible (par rapport à tout le reste) pour les environnements non Web. De plus, d'après ce que j'ai vu, le temps passé à valider utf8 pour les importations/noms sera insignifiant par rapport au temps passé sur tout le reste, donc je ne pense pas qu'il y ait un argument de performance ici.

En pratique, même si nous n'imposions pas utf8 dans la spécification de base de wasm, vous auriez un mauvais moment à interagir avec n'importe quoi si votre chaîne d'outils personnalisée n'utilisait pas également utf8 à moins que vous ne soyez une île totale et alors peut-être que vous venez de dire "Vissez-le" et faites votre propre truc non-utf8 de toute façon... car alors, peu importe.

Ce que j'aimerais vraiment faire, cependant, c'est la résolution #984, qui semble bloquer là-dessus...

@lukewagner Je ne pense pas que le #984 soit bloqué là-dessus. ??

Je suppose que vous avez raison.

Quel environnement imaginez-vous où il est avantageux de ne pas connaître l'encodage de vos chaînes ?

@tabatkins , il semble que je n'ai toujours pas été assez clair. Je n'imagine pas un tel environnement. Cependant, j'imagine un large éventail d'environnements avec des exigences incompatibles. Tout n'est pas un sous-ensemble d'UTF-8, par exemple Latin1 est encore assez largement utilisé. Vous ne vous en souciez peut-être pas, mais ce n'est pas le travail de la spécification principale de Wasm de mettre des pierres inutiles sur la voie de la diversité de l'environnement.

vous auriez du mal à interagir avec n'importe quoi si votre chaîne d'outils personnalisée n'utilisait pas également utf8, sauf si vous êtes une île totale

@lukewagner , je m'attends en effet à ce que Wasm soit utilisé sur une variété de "continents" qui ont potentiellement peu de chevauchement. Et là où ils le font, vous pouvez spécifier l'interopérabilité (en pratique, les codages de noms seront probablement le moindre problème pour le partage de modules entre différentes plates-formes - ce sont les bibliothèques hôtes). Même les îlots totaux ne sont pas irréalistes, en particulier par rapport aux systèmes embarqués (qui ont également tendance à avoir peu d'utilité pour Unicode).

L'une des parties les plus difficiles de la mise en œuvre d'un moteur WebAssembly non basé sur un navigateur consiste à faire fonctionner les choses comme dans le navigateur (principalement les parties JS). Je m'attends à ce que si l'encodage n'est pas standardisé, nous aboutirons à un standard de facto où tout le monde copie ce qui est fait pour la cible web. Il en résultera simplement qu'il sera plus difficile de trouver des informations sur la façon de décoder ces chaînes.

Il peut être utile d'autoriser certains environnements à restreindre davantage le contenu autorisé, mais ne pas exiger UTF-8 entraînera simplement plus de difficultés.

@MI3Guy , la contre-proposition consiste à spécifier l'encodage UTF-8 dans le cadre de l'API JS. Donc, si vous construisez un embedding JS, il est défini comme UTF-8 de toute façon et ne fait aucune différence pour vous. (Cependant, nous souhaitons également autoriser d'autres API d'intégration qui ne sont ni Web ni JavaScript.)

Droit. Mon point est que si vous ne faites pas d'intégration JS, vous êtes obligé d'émuler une grande partie de ce que fait l'intégration JS afin d'utiliser la chaîne d'outils WebAssembly.

Faites varuint pour le nombre de points de code + UTF-8 pour chaque point de code.

Je voudrais juste m'élever contre cette option. Cela complique les choses, ne s'applique pas et ne peut pas s'appliquer aux sections spécifiques à l'utilisateur et n'offre aucun avantage que je puisse voir. Afin de connaître le nombre de points de code dans une chaîne UTF-8, en pratique, vous finissez toujours par rechercher la chaîne codages invalides, vous pouvez donc aussi compter les points de code pendant que vous y êtes.

Tout n'est pas un sous-ensemble d'UTF-8, par exemple Latin1 est encore assez largement utilisé. Vous ne vous en souciez peut-être pas, mais ce n'est pas le travail de la spécification principale de Wasm de mettre des pierres inutiles sur la voie de la diversité de l'environnement.

Correct; UTF-8 diffère de pratiquement tous les encodages une fois que vous quittez la plage ASCII. Je ne sais pas quel est votre point avec cela, tho. En fait, l' utilisation de l'encodage Latin-1 est mauvaise, précisément parce qu'il existe de nombreux autres encodages qui se ressemblent mais encodent des lettres différentes . Si vous avez essayé d'utiliser le nom "æther" dans votre code Wasm et que vous l'avez codé en Latin-1, alors quelqu'un d'autre essaie (à juste titre) de lire le nom avec une chaîne d'outils UTF-8, il obtiendra une erreur de décodage. Ou peut-être que l'autre personne faisait une erreur similaire, mais utilisait à la place l'encodage Windows-1250 (destiné aux langues d'Europe centrale/orientale) - ils obtiendraient le mot absurde "ćther".

Je ne sais vraiment pas quel genre de "diversité" vous essayez de protéger ici. Il n'y a littéralement aucun avantage à utiliser un autre encodage, et des tonnes d'inconvénients. Chaque caractère que vous pouvez encoder dans un autre encodage est présent en Unicode et peut être encodé en UTF-8, mais l'inverse n'est presque jamais vrai. Il n'y a pas d'outils pertinents aujourd'hui qui ne peuvent pas gérer UTF-8 ; la technologie est littéralement vieille de deux décennies .

Je n'arrête pas de vous dire que les normes Web ont réglé cette question il y a des années, non pas parce que Wasm est une spécification Web qui doit suivre les règles du Web, mais parce que l'encodage de texte est un problème d'écosystème avec lequel à peu près tout le monde a les mêmes problèmes, et le Web a déjà été traité avec la douleur de se tromper, et a appris à le faire correctement. Il n'y a aucune vertu à se tromper à nouveau dans Wasm ; chaque environnement qui doit encoder du texte va directement en UTF-8 depuis le début, ou fait les mêmes erreurs et souffre la même douleur que tout le monde, puis s'installe finalement sur UTF-8. (Ou, dans de rares cas, développe un environnement suffisamment isolé pour pouvoir se standardiser sur un encodage différent, et ne paie que rarement le prix de la communication avec l'environnement extérieur. Mais ils se standardisent sur un encodage , ce qui est l'intérêt de tout cela.)

Donc, si vous construisez un embedding JS, il est défini comme UTF-8 de toute façon et ne fait aucune différence pour vous. (Cependant, nous souhaitons également autoriser d'autres API d'intégration qui ne sont ni Web ni JavaScript.)

Ce problème n'a rien à voir avec le Web ou JS. Chaque partie de l'écosystème veut un codage de texte connu et cohérent, et il y en a un seul qui est largement accepté dans les environnements de programmation, les pays et les langues : UTF-8.

Je vote pour 'Do varuint pour la longueur (en octets) + UTF-8 pour chaque octet'. En supposant que ce ne soit pas un choix controversé - à peu près toutes les implémentations de chaîne stockent les chaînes en tant que "nombre d'unités de code" plutôt que "nombre de points de code", car c'est plus simple - alors la vraie question n'est-elle pas "la validation devrait-elle échouer si une chaîne n'est pas UTF-8 valide" ?

Comme je l'ai souligné dans le n° 970, l' UTF-8 invalide peut être renvoyé en UTF-16, donc si l'UTF-8 invalide est autorisé, les logiciels qui ne veulent pas stocker les octets d'origine n'ont pas à le faire. D'un autre côté, vérifier si UTF-8 est valide n'est pas difficile (bien que nous devions répondre : les séquences trop longues doivent-elles être acceptées ? Les caractères de substitution ?)

Dans l'ensemble, je suis enclin à dire mandatons UTF-8. Dans le cas étrange où quelqu'un a des octets qu'il ne peut pas traduire en UTF-8 (peut-être parce que l'encodage est inconnu), des octets arbitraires peuvent être translittérés en UTF-8.

Je ne sais vraiment pas quel genre de "diversité" vous essayez de protéger ici.

@tabatkins , oui, cela semble être le cœur du malentendu.

Il est important de réaliser que WebAssembly, malgré son nom, ne se limite pas au web. Nous sommes très prudents pour le définir en couches adaptées, de telle sorte que chaque couche soit aussi largement utilisable que possible.

Plus particulièrement, son _noyau_ n'est pas du tout une technologie Web. Essayez plutôt de penser comme _console virtuelle_ ISA _. Une telle abstraction est utile dans un large spectre d'environnements différents, du très riche (le web) au très rudimentaire (les systèmes embarqués), qui n'ont pas forcément rien à voir les uns avec les autres, peuvent être largement incompatibles, et avoir des contraintes conflictuelles ( que Wasm n'est pas en mesure de changer).

En tant que tel, cela n'a pas plus de sens d'imposer Unicode à _core_ Wasm que, disons, d'imposer Unicode à tous les littéraux de chaîne dans le langage de programmation C. Vous ne feriez que contraindre certains clients potentiels à violer cette partie de la norme. Quel est le gain?

Il y aura, cependant, des couches de spécifications supplémentaires au-dessus de cette spécification de base qui définiront son intégration et son API dans des environnements _concrete_ (tels que JavaScript). Il est parfaitement logique de corriger les encodages de chaînes à ce niveau, et par tous les moyens, nous devrions le faire.

PS : Un slogan qui définit la portée de Wasm est qu'il s'agit d'une abstraction sur du matériel commun, et non d'une abstraction sur des langages de programmation communs. Et le matériel est indépendant des problèmes logiciels tels que les codages de chaînes. C'est à cela que servent les ABI.

@rossberg-chrome

En tant que tel, cela n'a pas plus de sens d'imposer Unicode sur le noyau Wasm que, disons, d'imposer Unicode sur tous les littéraux de chaîne dans le langage de programmation C. Vous ne feriez que contraindre certains clients potentiels à violer cette partie de la norme. Quel est le gain?

Je suis d'accord à 100%. Ce problème ne concerne cependant pas Unicode, il concerne uniquement UTF-8, un codage pour les entiers, sans exiger que les entiers soient interprétés comme Unicode.

Je ne comprends pas si nous sommes d'accord là-dessus. Pourriez-vous clarifier : êtes-vous d'accord avec UTF-8, et sinon pourquoi ?

@jfbastien , serait-il plus productif d'exiger la conformité UTF-8 pour tous les littéraux de chaîne C ?

Comme je l'ai noté plus tôt, cela n'a aucun sens pour moi de restreindre l'encodage mais pas le jeu de caractères. C'est comme définir la syntaxe sans sémantique. Pourquoi voudriez-vous faire ça? Vous ne gagnez rien en termes d'interopérabilité, mais vous dressez toujours des obstacles artificiels pour les environnements qui n'utilisent pas UTF-8 (ce que seuls les environnements Unicode font de toute façon).

@jfbastien , serait-il plus productif d'exiger la conformité UTF-8 pour tous les littéraux de chaîne C ?

Je ne comprends pas, pouvez-vous préciser ?

Comme je l'ai noté plus tôt, cela n'a aucun sens pour moi de restreindre l'encodage mais pas le jeu de caractères. C'est comme définir la syntaxe sans sémantique. Pourquoi voudriez-vous faire ça? Vous ne gagnez rien en termes d'interopérabilité, mais vous dressez toujours des obstacles artificiels pour les environnements qui n'utilisent pas UTF-8 (ce que seuls les environnements Unicode font de toute façon).

Je pense que c'est le nœud de la discussion.

@tabatkins a évoqué des précédents exactement à ceci:

Encore une fois, on dirait que vous parlez de bibliothèques d'internationalisation. Nous discutons uniquement de la façon de décoder les séquences d'octets en chaînes ; cela nécessite juste une connaissance de la façon de décoder UTF-8, ce qui est extrêmement trivial et extrêmement rapide.

À moins que vous ne fassiez une manipulation de chaînes conviviale, tout ce dont vous avez besoin est la possibilité de comparer les chaînes par point de code et éventuellement de trier les chaînes par point de code, aucun d'entre eux ne nécessitant de "prise en charge Unicode". C'est tout ce que la technologie Web existante utilise, par exemple, et je ne vois aucune raison pour laquelle les environnements Wasm auraient, en général, besoin de faire quelque chose de plus compliqué que cela.

Alors je suis d'accord : cette proposition est, selon vos termes, "définir la syntaxe sans sémantique". C'est une chose très courante à faire. En fait, la spécification actuelle de longueur + octets de WebAssembly le fait déjà !

J'aimerais comprendre quel est l'obstacle. Je n'en vois pas vraiment.

Il est important de réaliser que WebAssembly, malgré son nom, ne se limite pas au web.

Je viens de dire dans le commentaire qui précède immédiatement que cela n'a rien à voir avec le web. Vous continuez d'essayer d'utiliser cet argument, et cela m'embrouille vraiment. Ce que je dis n'a rien à voir avec le web ; Je ne fais que citer l'expérience du Web comme un exemple important de leçons apprises.

En tant que tel, cela n'a pas plus de sens d'imposer Unicode sur le noyau Wasm que, disons, d'imposer Unicode sur tous les littéraux de chaîne dans le langage de programmation C. Vous ne feriez que contraindre certains clients potentiels à violer cette partie de la norme. Quel est le gain?

Vous n'êtes pas faire le point que vous pensez que vous faites - C a un codage intégré, comme des chaînes utilisent le codage ASCII. (Si vous voulez autre chose, vous devez le faire à la main en échappant les séquences d'octets appropriées.) Dans le C++ plus actuel, vous pouvez avoir des littéraux de chaîne UTF-16 et UTF-8, et bien que vous puissiez toujours mettre des octets arbitraires dans la chaîne avec \x échappe, les échappements \u vérifient au moins que la valeur est un point de code valide.

Tout cela est nécessaire, car il n'y a pas de mappage inhérent des caractères aux octets . C'est ce que un codage fait. Encore une fois, ne pas avoir d'encodage spécifié signifie simplement que les utilisateurs de la langue, lorsqu'ils reçoivent des séquences d'octets d'autres parties, doivent deviner l'encodage pour les retransformer en texte.

Vous ne gagnez rien en termes d'interopérabilité, mais vous dressez toujours des obstacles artificiels pour les environnements qui n'utilisent pas UTF-8 (ce que seuls les environnements Unicode font de toute façon).

Pouvez-vous s'il vous tous les caractères . C'est le seul jeu de caractères qui peut constituer un argument à distance crédible pour le faire, et lorsque vous utilisez le jeu de caractères Unicode, UTF-8 est l'encodage universel préféré.

Quelle diversité essayez-vous de protéger ? Ce serait formidable de voir ne serait-ce qu'un seul exemple. :/

@tabatkins :

Il est important de réaliser que WebAssembly, malgré son nom, n'est pas
limité au web.

Je viens de dire dans le commentaire qui précède immédiatement que cela n'a rien
à voir avec le Web. Vous continuez d'essayer d'utiliser cet argument, et c'est vraiment
sème en moi une certaine confusion. Ce que je dis n'a rien à voir avec le web ; je suis simplement
citant l'expérience du Web comme un exemple important de leçons apprises.

Ce que j'essaie de souligner, c'est que Wasm devrait être applicable à autant de
plates-formes possibles, modernes ou non. Vous continuez à vous disputer depuis la fin heureuse
du spectre où tout est Unicode et/ou UTF-8, et tout
else est simplement obsolète.

Vous n'êtes pas faire le point que vous pensez que vous faites - C a un

codage intégré, car les littéraux de chaîne utilisent l'encodage ASCII. (Si tu veux
tout ce que vous devez faire à la main en échappant à l'octet approprié
séquences.) Dans le C++ plus actuel, vous pouvez avoir des chaînes UTF-16 et UTF-8
littéraux, et bien que vous puissiez toujours mettre des octets arbitraires dans la chaîne avec
\x s'échappe, les échappements \u vérifient au moins que la valeur est valide
point de code.

Non, c'est faux. La spécification C ne nécessite pas l'ASCII. Il ne fait même pas
nécessitent une compatibilité avec l'ASCII. Il permet presque arbitraire "source
jeux de caractères" et les littéraux de chaîne peuvent contenir n'importe quel caractère
ensemble. Il n'y a pas de contraintes concernant l'encodage, il est entièrement
défini par la mise en œuvre. Il y a eu des implémentations de C en cours d'exécution sur
plates-formes EBCDIC, et cela est toujours pris en charge par la norme actuelle. CCG
peut traiter les sources dans n'importe quel encodage iconv (dont il y a environ 140
outre UTF-8), par exemple UTF-16 qui est populaire en Asie. C++ n'est pas différent.

(Cela devrait également répondre à la question de @jfbastien .)

Tout cela est nécessaire, car il n'y a pas de mappage inhérent decaractères en octets . C'est ce que un codage fait. Encore une fois, ne pas avoir de
l'encodage spécifié signifie simplement que les utilisateurs de la langue, lorsqu'ils reçoivent
séquences d'octets d'autres parties, doivent deviner l'encodage pour tourner
les remettre dans le texte.

Encore une fois : ceci _sera_ spécifié de manière appropriée par environnement. Quand quelqu'un
reçoit un module Wasm de quelqu'un d'autre opérant dans le même écosystème
alors il n'y a pas de problème. Aucun développeur JS n'aura jamais besoin de s'en soucier.

Si, cependant, quelqu'un reçoit un module d'un autre écosystème, alors
il y a beaucoup d'autres sources d'incompatibilité dont il faut s'inquiéter, par exemple
attentes concernant l'API, les bibliothèques intégrées, etc. Les deux parties devront
être explicite sur leurs hypothèses d'interopérabilité de toute façon. Se mettre d'accord sur un nom
l'encodage sera le moindre de leurs problèmes.

Vous gagnez zéro en termes d'interopérabilité, mais vous dressez toujours des obstacles artificiels pour

environnements qui n'utilisent pas UTF-8 (ce que seuls les environnements Unicode font
De toute façon).

Pouvez-vous s'il vous
caractères qui ne sont pas inclus dans Unicode ? Tu continues d'essayer de défendre ça
position du point de vue de la pureté théorique / diversité de l'environnement, mais
littéralement, tout l'intérêt d'Unicode est d'inclure tous lespersonnages . C'est le seul jeu de caractères qui peut faire un
argument crédible pour le faire, et lorsque vous utilisez le caractère Unicode
défini, UTF-8 est l'encodage universel préféré.

Quelle diversité essayez-vous de protéger ? Ce serait bien de voir même
un seul exemple. :/

Par exemple, voici une liste d'OS embarqués : https://en.wikipedia.org/wiki/
Catégorie :Systèmes_d'exploitation_embarqués
Certains d'entre eux utilisent probablement UTF-8, d'autres non. Certains peuvent trouver une utilité à Wasm,
ne le fera probablement pas. Mais il n'y a aucun avantage pour nous à le rendre moins
pratique pour eux.

Une entrée de cette liste que vous connaissez probablement encore est DOS. Comme
autant que nous aimons tous qu'il meure, les systèmes DOS sont toujours vivants, et ils utilisent
OEM.

@jfbastien :

Alors je suis d'accord : cette proposition est, selon vos termes, "définir la syntaxe sans
sémantique". C'est une chose très courante à faire. En fait, WebAssembly
la longueur actuelle + la spécification d'octets le fait déjà !

Les rares occurrences d'une telle chose que je connaisse ont toutes à voir avec
fournissant une trappe d'évacuation pour un comportement spécifique à la mise en œuvre. C'est
aussi le seul cas d'utilisation raisonnable. Cela n'a pas de sens ici, cependant. Si tu
voulez fournir une telle trappe d'évacuation pour les cordes, alors pourquoi s'embêter à exiger
UTF-8, au lieu d'autoriser n'importe quelle chaîne d'octets « syntaxe » ? C'est la syntaxe sans
sémantique comme un handicapeur, pas comme un facilitateur.

J'aimerais comprendre quel est l'obstacle. Je n'en vois pas vraiment.
>
Que certains clients ne peuvent pas simplement utiliser toutes les valeurs d'octet mais doivent passer par
encodages UTF redondants qui n'ont aucune utilité dans leur écosystème. Que tout
les outils de leurs chaînes d'outils devront également s'en soucier. qu'il
crée des cas d'erreur supplémentaires (valeurs hors limites) qui ne seraient pas
sinon exister pour eux.

Permettez-moi de demander l'inverse : quel est l'avantage (dans leurs écosystèmes) ?
Je n'en vois pas vraiment.

@tabatkins
Je veux m'assurer que je comprends où se situe la ligne de démarcation.
Pour être clair, vous suggérez UNIQUEMENT l'encodage utf-8 des points de code, qu'ils soient invalides en combinaison (cela peut être fait en 10 lignes de code).
Les majuscules en gras pourraient par exemple être utilisées dans la spécification pour indiquer : vous faites quelque chose de mal si vous pensez avoir besoin d'une bibliothèque d'internationalisation pour implémenter Wasm ?

Les objectifs de ceci seraient :

• Assurez-vous que tout wasm valide qui se retrouve sur le Web peut au moins afficher des caractères de tofu pour des éléments invalides.
• Encouragez les outils qui génèrent du wasm (même dans des contextes en dehors du Web) à préférer l'unicode aux autres encodages lorsqu'ils doivent aller au-delà de l'ascii. (Une légère bosse dans cette direction car la validation complète ne se produit pas).

Des questions?

• Y a-t-il un danger que cela devienne une exigence rampante pour plus de validation ? Je pense que ma principale préoccupation dans cet espace serait qu'il sera toujours un fardeau déraisonnable d'avaler, par exemple, les soins intensifs en tant que dépendance.

• Je suppose que cela implique l'objectif d'encourager activement les encodages comme Latin1 qui entrent en conflit avec UTF-8 ? C'est-à-dire que les chaînes d'outils qui l'émettent seraient non conformes, les implémentations qui l'acceptent de la même manière.

• Je grok le Web a historiquement eu du mal à unifier cet espace en raison de l'utilisation chevauchante de bits provenant de régions qui encodaient auparavant des îles. D'un autre côté, j'ai l'impression que l'UTF-8 met en place des choses telles que les coûts de la transition sont supportés de manière disproportionnée par des personnes non ASCII et que certaines régions ont plus de temps. J'imagine que la transition Unicode est une fatalité pratique (et presque complet). Existe-t-il un document/une entité centralisée que nous pouvons indiquer et qui explique comment certains des problèmes politiques et régionaux liés à l'unicode ont été résolus sur le Web ?

@rossberg-chrome

• Je vois l'incohérence logique dans la validation de certains aspects d'un encodage mais pas d'autres. D'un autre côté, mon impression est que l'utf8 est omniprésent à ce stade (et qu'un petit coup de pouce dans les outils + validation a un faible coût). Est-ce que votre principal inconfort en ajoutant la simple validation utf-8 à la spécification est l'incohérence ou autre chose ?

Pour être clair, vous suggérez UNIQUEMENT l'encodage utf-8 des points de code, qu'ils soient invalides en combinaison (cela peut être fait en 10 lignes de code).

Oui, bien que je ne pense pas qu'il y ait de combinaisons invalides ; il y a juste quelques points de code individuels (ceux réservés aux substituts UTF-16) qui ne sont techniquement pas valides pour coder en UTF-8. Cela dit, si le contrôle complet des octets est souhaitable, l' encodage WTF-8 existe, mais nous devrions être très explicites sur "oui, nous voulons permettre à ces chaînes de contenir parfois des données arbitraires non-chaînes" comme objectif si nous allons par là. Le format WTF-8 (et WTF-16) est uniquement destiné à fournir une spécification formelle pour les environnements qui ont des contraintes de rétrocompatibilité sur l'application de la bonne formation UTF-*.

Les majuscules en gras pourraient par exemple être utilisées dans la spécification pour indiquer : vous faites quelque chose de mal si vous pensez avoir besoin d'une bibliothèque d'internationalisation pour implémenter Wasm ?

Oui, i18n n'est pas requis de quelque manière que ce soit. CSS utilise par défaut l'UTF-8, par exemple, et ne fait que la comparaison/le tri des points de code bruts lorsqu'il autorise des choses en dehors de la plage ASCII. Aucune raison pour que Wasm aille plus loin non plus.

Y a-t-il un danger que cela devienne une exigence rampante pour plus de validation ? Je pense que ma principale préoccupation dans cet espace serait qu'il sera toujours un fardeau déraisonnable d'avaler, par exemple, les soins intensifs en tant que dépendance.

La plate-forme Web n'a jamais eu besoin d'imposer une validation supplémentaire sur les noms nus jusqu'à présent. Mon expérience suggère que ce ne sera jamais nécessaire.

Je suppose que cela implique l'objectif d'encourager activement les encodages comme Latin1 qui entrent en conflit avec UTF-8 ? C'est-à-dire que les chaînes d'outils qui l'émettent seraient non conformes, les implémentations qui l'acceptent de la même manière.

Oui, avec le changement de « dis ralisant » dans vos mots. ^_^ L'essentiel est que les producteurs et les consommateurs peuvent encoder et décoder de manière fiable des chaînes vers/depuis des séquences d'octets sans avoir à deviner ce que fait l'autre point de terminaison. Cela a été une douleur horrible pour tous les environnements qui l'ont déjà rencontré, et il existe maintenant une solution largement adoptée pour cela.

Je grok le Web a historiquement eu du mal à unifier cet espace en raison de l'utilisation chevauchante de bits provenant de régions qui encodaient auparavant des îles. D'un autre côté, j'ai l'impression que l'UTF-8 met en place des choses telles que les coûts de la transition sont supportés de manière disproportionnée par des personnes non ASCII et que certaines régions ont plus de temps. J'imagine que la transition Unicode est une fatalité pratique (et presque complet). Existe-t-il un document/une entité centralisée que nous pouvons indiquer et qui explique comment certains des problèmes politiques et régionaux liés à l'unicode ont été résolus sur le Web ?

Oui, il y avait certainement des problèmes dans la transition ; HTML doit toujours être défini par défaut sur Latin-1 en raison de la rétrocompatibilité, et il existe encore quelques petites poches de contenu Web qui préfèrent un codage spécifique à la langue (principalement Shift-JIS, un codage en japonais). Mais la grande majorité du monde a basculé au cours des deux dernières décennies, et la transition est considérée comme plus ou moins achevée maintenant.

L'"UTF-8 pèse sur les non-ASCII" est depuis longtemps une rumeur pernicieuse, mais presque entièrement fausse. La plupart des langues européennes incluent la majorité de l'alphabet ASCII en premier lieu, donc la plupart de leur texte est constitué de séquences à un octet et finit par être plus petit que l'UTF-16. La même chose s'applique aux systèmes d'écriture comme Pinyin. Les langages CJK occupent principalement la région UTF-8 à 3 octets, mais ils incluent également de grandes quantités de caractères ASCII, en particulier dans les langages de balisage ou les langages de programmation. UTF-16 ou leurs encodages spécialisés.

Ce n'est que pour de grandes quantités de texte brut en CJK ou en alphabets non ASCII tels que le cyrillique que l'UTF-8 prend en réalité plus de place qu'un encodage spécialisé. Il s'agissait toutefois de préoccupations au début des années 90 , lorsque la capacité du disque dur était mesurée en mégaoctets et qu'une légère augmentation de la taille des fichiers texte était en fait susceptible d'être significative. Cela n'a pas été une préoccupation depuis près de 20 ans; la différence de taille est tout à fait sans importance maintenant.

En ce qui concerne "la transition Unicode", cela s'est déjà produit de manière assez universelle. Un format de texte qui n'a pas besoin d'être encodé avec UTF-8 de nos jours commet une terrible erreur ahistorique.

Je ne suis pas sûr d'un document spécifique qui décrit ce genre de choses, mais je parie qu'ils existent quelque part. ^_^

Si le but est de garder la spécification binaire aussi pure que possible, supprimons entièrement les noms. Toutes ses références internes sont basées sur l'index, de toute façon.

Au lieu de cela, ajoutez une section personnalisée obligatoire à la spécification JavaScript qui nécessite UTF-8. D'autres environnements, tels que le mainframe de l'ère soviétique auquel @rossberg-chromium fait allusion, peuvent définir leur propre section personnalisée. Un seul fichier WASM pourrait prendre en charge les deux plates-formes en fournissant les deux sections personnalisées. Il serait relativement simple pour un outillage personnalisé de générer la section manquante d'une plate-forme obscure en convertissant une section plus populaire.

Si le but est de garder la spécification binaire aussi pure que possible, supprimons entièrement les noms. Toutes ses références internes sont basées sur l'index, de toute façon.

C'est une refonte du fonctionnement de l'import/export. Ce n'est pas sur la table et devrait être suggéré dans un autre numéro que celui-ci.

@bradnelson , AFAICS, prescrivant un encodage spécifique mais pas de jeu de caractères
combine le pire des deux mondes : il impose des coûts en termes de
restrictions, complexité et frais généraux sans bénéfice réel en termes de
interopérabilité. Je suppose que je ne comprends toujours pas ce que le point serait.

@rossberg-chromium Le principal avantage recherché ici est de soulager les outils et les bibliothèques du fardeau des devinettes.

Étant donné que le principal avantage recherché ici est de soulager les outils et les bibliothèques du fardeau des devinettes, l'une des variantes ci-dessus discutées (UTF-8 contre WTF-8, etc.) serait mieux que rien car même dans le pire des cas, "Je suis sûr que je ne peux pas transcoder ces octets littéralement" est mieux que "ces octets ressemblent à des fenêtres-1252 ; peut-être que je vais essayer ça". La devinette est connue pour être sujette aux erreurs, et le principal avantage recherché ici est de soulager les outils et les bibliothèques du fardeau de la devinette.

@sunfishcode , comment ? Je suis toujours perdu.

Voici donc un scénario concret. Supposons que nous soyons sur différentes plates-formes et que j'essaie de vous transmettre un module. Supposons pour les besoins de l'argument que ma plate-forme utilise EBCDIC et le vôtre ASCII. Totalement légitime dans le cadre de la proposition actuelle. Pourtant, mon module sera complètement inutile pour vous et votre chaîne d'outils.

Ces deux encodages sont 7 bits, donc UTF-8 n'entre même pas dans l'image.

Alors, qu'est-ce que UTF-8 apporterait à la table ? Eh bien, je pourrais "décoder" n'importe quelle chaîne inconnue que je reçois. Mais pour autant que je sache, le résultat est _juste un autre blob binaire opaque_ de valeurs de 31 bits. Il ne fournit aucune information. Je n'ai aucune idée de comment le relier à mes propres cordes.

Alors, pourquoi me donnerais-je la peine de décoder une chaîne inconnue ? Eh bien, _je ne le ferais pas_ ! Je pourrais aussi bien travailler avec le blob binaire d'origine de valeurs 8 bits et économiser de l'espace et des cycles. Cependant, la spécification m'obligerait toujours à passer des cycles pour valider l'encodage.

Compte tenu de tout cela, qu'est-ce que le Wasm (noyau) ou les outils gagneraient à adopter cette proposition particulière ?

AFAICS, prescrivant un encodage spécifique mais pas de jeu de caractères
combine le pire des deux mondes : il impose des coûts en termes de
restrictions, complexité et frais généraux sans bénéfice réel en termes de
interopérabilité. Je suppose que je ne comprends toujours pas ce que le point serait.

Nous imposons définitivement un jeu de caractères - le jeu de caractères Unicode. JF formulait les choses de manière très confuse plus tôt, ne faites pas attention. Cela ne signifie pas que nous devons ajouter des vérifications à Wasm pour appliquer cela ; les décodeurs sont généralement suffisamment robustes pour traiter les caractères invalides. (Le Web, par exemple, les remplace généralement par U+FFFD CARACTÈRE DE REMPLACEMENT.)

Voici donc un scénario concret. Supposons que nous soyons sur différentes plates-formes et que j'essaie de vous transmettre un module. Supposons pour les besoins de l'argument que ma plate-forme utilise EBCDIC et le vôtre ASCII. Totalement légitime dans le cadre de la proposition actuelle. Pourtant, mon module sera complètement inutile pour vous et votre chaîne d'outils.

Vous devez arrêter de prétendre que les systèmes vieux de plusieurs décennies sont non seulement pertinents, mais si pertinents qu'ils justifient de prendre des décisions qui vont à l'encontre de tout ce que nous avons appris sur l'encodage de la douleur au cours de ces mêmes décennies. Vous n'aidez personne avec cette insistance sur le fait que Web Assembly se contorsionne pour maximiser la commodité lors de la discussion avec d'anciens mainframes, tout en ignorant l'avantage que tout le monde dans le monde puisse communiquer des données textuelles de manière fiable. Vous allez juste nuire à la langue et rendre la vie des utilisateurs plus difficile à 99,9% (en tant qu'estimation très prudente).

De nombreux systèmes différents ont traversé tout ce gâchis. Les guerres d'encodage n'étaient pas amusantes ; ils ont gaspillé beaucoup d'argent et beaucoup de temps et ont abouti à beaucoup de texte corrompu. Nous avons fini ces guerres, tho. Unicode a été créé et promulgué et est devenu le jeu de caractères dominant dans le monde entier, au point que tous les autres jeux de caractères ne sont littéralement rien de plus que des curiosités historiques à ce stade. Nous avons encore des combats mijotés de bas niveau pour savoir s'il faut utiliser UTF-16 contre UTF-8, mais au moins ces deux sont généralement faciles à distinguer (regardez la nomenclature ou recherchez une prépondérance d'octets nuls) et l'UTF global -8 domine haut la main.

Votre insistance sur la liberté d'encodage ignore toute cette histoire, toutes les leçons apprises au cours des deux décennies qui ont suivi l'introduction d'Unicode. Il ignore toute l'expérience et l'expertise nécessaires à la conception de systèmes modernes, ce qui a eu pour effet de rendre les problèmes d'encodage invisibles pour la plupart des utilisateurs, car les systèmes peuvent compter sur tout ce qui est encodé d'une manière particulière. Vous allez créer des problèmes sérieux, pernicieux et coûteux si vous persistez dans cette voie, un mojibake à la fois.

@rossberg-chrome

Voici donc un scénario concret. Supposons que nous soyons sur différentes plates-formes et que j'essaie de vous transmettre un module. Supposons pour les besoins de l'argument que ma plate-forme utilise EBCDIC et le vôtre ASCII. Totalement légitime dans le cadre de la proposition actuelle. Pourtant, mon module sera complètement inutile pour vous et votre chaîne d'outils.

Alors, qu'est-ce que UTF-8 apporterait à la table ? Eh bien, je pourrais "décoder" n'importe quelle chaîne inconnue que je reçois. Mais pour autant que je sache, le résultat n'est qu'un autre blob binaire opaque de valeurs 31 bits. Il ne fournit aucune information. Je n'ai aucune idée de comment le relier à mes propres cordes.

UTF-8 vous dira exactement comment le relier à vos propres chaînes. C'est exactement le problème qu'il résout. (WTF-8 le ferait aussi quand il le pouvait, et il vous dirait sans ambiguïté quand il ne le peut pas.)

Voulez-vous dire une structure de données arbitraire transformée en chaîne puis codée en UTF-8 ? Il est vrai que vous ne seriez pas en mesure de le démanteler, mais vous pourriez au moins afficher sans ambiguïté le nom déformé sous forme de chaîne, ce qui est une amélioration par rapport au fait de ne rien avoir pour certains cas d'utilisation.

Voulez-vous dire la discussion ci-dessus sur l'utilisation d'UTF-8 comme codage d'entiers opaques et non d'Unicode ? Je pense que la discussion est devenue quelque peu confuse. Il est tentant d'appeler l'encodage « syntaxe » et l'internationalisation « sémantique », mais cela masque une distinction utile : UTF-8 peut toujours dire qu'une certaine séquence d'octets signifie « Ö » sans dire ce que les consommateurs ont à faire avec cette information. Utilisé de cette manière, il s'agit d'un encodage Unicode, mais il ne nécessite pas le type de coût suggéré par le "Support Unicode" ci-dessus.

Alors, pourquoi me donnerais-je la peine de décoder une chaîne inconnue ? Eh bien, je ne le ferais pas ! Je pourrais aussi bien travailler avec le blob binaire d'origine de valeurs 8 bits et économiser de l'espace et des cycles. Cependant, la spécification m'obligerait toujours à passer des cycles pour valider l'encodage.

J'ai maintenant construit un SpiderMonkey avec une validation UTF-8 complète des identifiants d'import/export de wasm, y compris overlong et les substituts. Je n'ai pas pu détecter de différence de performances dans WebAssembly.validate , que ce soit sur AngryBots, ou sur un petit cas de test compilé par emscripten qui compte néanmoins 30 importations.

La spécification est un compromis entre plusieurs préoccupations. J'apprécie le souci du temps de démarrage, j'ai donc maintenant mené quelques expériences et l'ai mesuré. J'encourage les autres à faire leurs propres expériences.

De plus, UTF-8 n'est pas le seul codage Unicode et il peut être utilisé pour coder des entiers non Unicode. Ainsi, UTF-8 n'est pas Unicode.

Quels entiers UTF-8 ne font pas partie d'Unicode (c'est-à-dire en dehors de la plage U+0000 à U+10FFFF) ? Cette affirmation semble fausse.

Si vous ne validez pas vos caractères, vous pouvez encoder n'importe quel entier de 21 bits.

Je ne sais pas trop pourquoi nous ne validerions pas...

@flagxor https://encoding.spec.whatwg.org/ décrit les différents encodages exposés sur le Web. Notez qu'aucun d'entre eux ne sort du jeu de caractères Unicode, mais ils ne sont évidemment pas tous compatibles entre eux.

Que ferait la « validation » ? Rendre votre programme wasm invalide ? Je ne pense pas qu'il y ait des conséquences réelles qui peuvent être raisonnablement imposées.

Par exemple, utiliser un échappement invalide dans CSS met simplement un U + FFFD dans votre feuille de style, cela ne fait rien de bizarre.

@annevk :

De plus, UTF-8 n'est pas le seul codage Unicode et il peut être utilisé pour coder des entiers non Unicode. Ainsi, UTF-8 n'est pas Unicode.

Quels entiers UTF-8 ne font pas partie d'Unicode (c'est-à-dire en dehors de la plage U+0000 à U+10FFFF) ? Cette affirmation semble fausse.

Au minimum : U+FFFE et U+FFFF ne sont pas des caractères en Unicode. Les points de code (les valeurs entières) ne seront jamais utilisés par Unicode pour encoder des caractères, mais ils peuvent être encodés en UTF-8.

Ce sont toujours des points de code Unicode. Je ne me concentrerais pas trop sur les "personnages".

Le décodage de

En tant que tel, cela n'a pas plus de sens d'imposer Unicode sur le noyau Wasm que, disons, d'imposer Unicode sur tous les littéraux de chaîne dans le langage de programmation C. Vous ne feriez que contraindre certains clients potentiels à violer cette partie de la norme. Quel est le gain?

Vous pouvez noter que C11 a ajouté les types char16_t et char32_t ainsi qu'un préfixe u pour les littéraux de chaîne encodés en UTF-16, un préfixe U pour Littéraux de chaîne codés UCS-4 et un préfixe u8 pour les littéraux de chaîne codés UTF-8. Je n'ai pas creusé assez profondément pour trouver leur justification pour les ajouter, mais je suppose que "traiter avec Unicode en C/C++ standard est un cauchemar" est au moins une partie de la motivation.

@tabatkins , @sunfishcode , d'accord, donc vous ne parlez pas de la même chose. Mais AFAICT @jfbastien a déclaré explicitement et à plusieurs reprises que sa proposition consiste à spécifier UTF-8 sans le jeu de caractères Unicode.

C'est aussi la seule interprétation selon laquelle l'affirmation du faible coût tient.

Parce que si nous supposons réellement que UTF-8 implique Unicode, alors cette exigence est certainement beaucoup plus chère que le simple codage/décodage UTF-8 pour n'importe quel outil sur n'importe quel système qui ne parle pas encore (un sous-ensemble de) Unicode -- ils J'aurais besoin d'inclure une couche de transcodage complète.

@tabatkins , le noyau Wasm sera intégré dans des systèmes préexistants - parfois pour d'autres raisons que la portabilité - sur lesquels il n'a pas le pouvoir de changer ou d'imposer quoi que ce soit. S'ils sont confrontés aux problèmes que vous décrivez, ceux-ci existent indépendamment de Wasm. _Nous_ ne pouvons pas résoudre _leurs_ problèmes.

Le résultat probable d'_essayer_ d'imposer Unicode à tous serait que certains potentiels violeront simplement cette partie de la spécification, la rendant entièrement discutable (ou pire, ils ignoreront complètement Wasm).

Si OTOH nous le spécifions à un niveau adéquat, nous ne courons pas ce risque - sans rien perdre en pratique.

Parce que si nous supposons réellement que UTF-8 implique Unicode, cette exigence est certainement beaucoup plus chère que le simple codage/décodage UTF-8 pour n'importe quel outil sur n'importe quel système qui ne parle pas encore (un sous-ensemble de) Unicode - ils J'aurais besoin d'inclure une couche de transcodage complète.

Quelles plates-formes existent qui utilisent un jeu de caractères natif qui n'est ni Unicode, ni ASCII, n'ont aucune possibilité de convertir ces caractères vers/depuis Unicode et auraient besoin d'utiliser des identifiants non ASCII dans Wasm ? (Je veux dire exister vraiment, pas une organisation russe hypothétique qui décide d'utiliser Wasm sous DOS.)

@rocallahan Je crois que @rossberg-chromium est concerné (ou du moins je le serais) avec des appareils comme les systèmes embarqués, qui ne voudraient pas du coût supplémentaire d'une bibliothèque ICU complète. Ils seraient soit obligés d'accepter le ballonnement, soit de ne pas effectuer de validation complète, soit de ne pas accepter les fichiers wasm contenant des caractères non ASCII (sur lesquels ils pourraient ne pas avoir de contrôle).

De plus, à proprement parler, ces appareils incluent souvent du matériel qui a des jeux de caractères non standard tels que :
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(Qui a un jeu de caractères mixte ascii + latin1 + japonais)
Mais la préoccupation est ce que vous êtes obligé de valider, ce qui est pertinent malgré tout.

@tabatkins bien que je pensais avoir indiqué que l'intention est :

• Mandater UTF-8 + Unicode comme seule interprétation "correcte" des octets
• Indiquez explicitement que l'Unicode n'a pas à valider pour que le module valide (pour économiser le coût)

Je crois que @rossberg-chromium s'intéresse (ou du moins je le serais) à des appareils tels que les systèmes embarqués, qui ne voudraient pas du coût supplémentaire d'une bibliothèque ICU complète. Ils seraient soit obligés d'accepter le ballonnement, soit de ne pas effectuer de validation complète, soit de ne pas accepter les fichiers wasm contenant des caractères non ASCII (sur lesquels ils pourraient ne pas avoir de contrôle).

Comme indiqué à plusieurs reprises, il s'agit d'un hareng rouge. Il n'est pas nécessaire de faire quoi que ce soit à distance en rapport avec les soins intensifs ; le web ne le fait certainement pas. S'il vous plaît, arrêtez de diffuser ces informations incorrectes.

La "validation complète" est une opération extrêmement triviale, effectuée automatiquement dans le cadre d'une opération de décodage UTF-8 conforme.

En discutant avec @tabatkins , une chose que je pense est cruciale d'être claire ici :
Un décodeur Unicode conforme est OBLIGATOIRE pour permettre des combinaisons arbitraires de modificateurs, points de code non alloués, etc. Ainsi, un mélange égaré de modificateurs, etc., même s'il ne rend pas quelque chose de sensé, doit être autorisé par Unicode. Un décodeur qui rejetterait les combinaisons absurdes serait non conforme.

Ainsi, l'exigence de décoder correctement UTF-8 est clairement définie pour être quelque chose que vous pouvez faire dans une poignée de lignes de code, est une opération exacte et équivaut essentiellement à spécifier une interprétation unicode + utf-8 des octets.

Oui. L'analyse d'UTF-8 est extrêmement triviale ; les seules complications sont la poignée de points de code que vous n'êtes pas autorisé à encoder en UTF-8, qu'un décodeur compatible analysera à la place comme un ou plusieurs caractères U+FFFD.

Mais c'est une opération que le point de

Ceci est similaire, par exemple, à CSS définissant une grammaire pour ce qui constitue une feuille de style valide, mais acceptant toujours techniquement tout modèle arbitraire de bits.

De plus, à proprement parler, ces appareils incluent souvent du matériel qui a des jeux de caractères non standard tels que :

L'existence de tels jeux de caractères n'est pas pertinente pour Wasm à moins que vous ne vous attendiez à ce que les gens écrivent des identificateurs Wasm dans les (plages non-ASCII de) eux.

D'accord, tout ce que signifie "utiliser UTF-8" est https://encoding.spec.whatwg.org/#utf -8-decoder. ICU n'est même pas proche d'une exigence.

Le 25 février 2017 à 01h13, Brad Nelson [email protected] a écrit :

En discutant avec @tabatkins https://github.com/tabatkins , une chose
que je pense qu'il est crucial d'être clair ici:
Un décodeur Unicode conforme est OBLIGATOIRE pour permettre des
combinaisons de modificateurs, points de code non alloués, etc. Donc, un mélange égaré de
modificateurs etc, même si cela ne rend pas quelque chose de sensé, est
doit être autorisé par Unicode. Un décodeur qui rejette le non-sens
les combinaisons seraient non conformes.

Ainsi, l'exigence de décoder correctement UTF-8 est clairement définie pour être
quelque chose que vous pouvez faire dans une poignée de lignes de code, est une opération exacte,
et est essentiellement équivalent à spécifier un unicode + utf-8
interprétation des octets.

Pour clarifier ce que j'ai dit. Je ne conteste pas qu'une unité de soins intensifs complète ne serait probablement pas
nécessaire (bien que, par exemple, trier les noms par points de code sonne comme mauvais
convivialité).

Cependant, l'affirmation selon laquelle seul le décodage trivial reste n'est pas correcte
soit, car cela ne s'arrête pas à la validation. Plateformes non Unicode
seraient obligés d'effectuer un transcodage pour réellement gérer leurs chaînes.
De plus, ils auraient à faire face au problème des personnages qui
ne peut pas être mappé (dans les deux sens), vous auriez donc toujours la compatibilité
problèmes en général, vient de lancer la boîte sur la route.

>

De plus, à proprement parler, ces appareils incluent souvent du matériel qui n'a
jeux de caractères non standard tels que :

L'existence de tels jeux de caractères n'est pas pertinente pour Wasm, à moins que vous ne
attendez-vous à ce que les gens écrivent des identificateurs Wasm dans les (plages non ASCII de) eux.

@rocallahan https://github.com/rocallahan , ils doivent encore pouvoir
prendre en Unicode arbitraire. Mais qu'en feraient-ils ? Si un Wasm
mise en œuvre sur une telle plate-forme restreinte à l'ASCII, il serait
violant la spécification proposée. (Je considérerais également que cela implique que
les caractères non-ASCII de quelqu'un ne sont pas pertinents a priori peuvent être culturellement
discutable. Cela devrait être à eux de décider.)

De plus, ils devraient faire face au problème des caractères qui ne peuvent pas être mappés (dans les deux sens), donc vous auriez toujours des problèmes de compatibilité en général, il suffit de lancer la boîte sur la route.

Est-ce une préoccupation théorique ?

Et si c'est une préoccupation raisonnable, nous devons encore une fois peser le (l'occurrence * le coût) de gérer cela par rapport au coût de pratiquement tous les autres utilisateurs de Wasm dans le monde ne pouvant pas dépendre d'un encodage et devant faire face à la même encodage-enfer que la plate-forme Web a dû traverser, et finalement réparé aussi bien qu'elle le pouvait.

Les plates-formes non Unicode seraient obligées d'effectuer un transcodage pour gérer réellement leurs chaînes.

Dans quels cas les chaînes Wasm doivent-elles interagir avec les chaînes de la plate-forme ? Pour autant que je sache, nous ne parlons que de l'encodage des chaînes dans les métadonnées Wasm, pas de l'encodage des chaînes manipulées par le code du module réel. (Si c'est faux, je m'excuse...) Alors je ne peux penser qu'à quelques cas possibles où l'interopérabilité/le transcodage pourraient être nécessaires :

• Un module Wasm importe un identifiant de plateforme
• La plateforme importe un identifiant Wasm
• Vous devez extraire les noms Wasm et les imprimer ou les enregistrer à l'aide de chaînes de plate-forme, par exemple pour vider une trace de pile.

Droit?

Pour les systèmes embarqués hypothétiques non Unicode, pour les deux premiers cas, le conseil est simple : limitez les identifiants importés à travers la frontière de la plate-forme en ASCII, alors le transcodage requis est trivial. Les modules Wasm pouvaient toujours utiliser des noms Unicode complets en interne et pour se lier les uns aux autres.

Pour le troisième problème --- si vous avez un monde fermé de modules Wasm, vous pouvez limiter leurs identifiants à l'ASCII. Sinon, en pratique, vous rencontrerez des identifiants UTF8 et vous feriez mieux de pouvoir les transcoder, et vous serez heureux que la spécification ait mandaté UTF8 !

ce qui implique que les caractères non-ASCII de quelqu'un ne sont pas pertinents a priori

C'est un argument d'homme de paille. La position ici est "si vous voulez des identifiants non-ASCII, utilisez Unicode ou implémentez le transcodage vers/depuis Unicode", et cela n'a pas suscité de critiques comme "culturellement discutable" dans d'autres spécifications, AFAIK.

>

Et s'il s'agit d'une préoccupation raisonnable, nous devons encore une fois peser le (l'occurrence

• coût) de traiter cela contre le coût de pratiquement tous les autresutilisateur de Wasm dans le monde ne pouvant pas dépendre d'un encodage, et
  avoir à gérer le même encodage - l'enfer que la plate-forme Web a dû traverser,
  et finalement réparé aussi bien qu'il le pouvait.

@tabatkins , non, encore une fois (et j'ai l'impression d'avoir répété 100
fois déjà) : chaque spécification d'intégration _précisera_ un codage et
jeu de caractères. Sur chaque plate-forme, vous pouvez compter sur cela. Tu n'aurais jamais couru
dans l'encodage des questions si vous essayez d'interagir entre deux
écosystèmes - qui seront déjà incompatibles pour des raisons plus profondes que
cordes. Et cela n'affecterait que l'interopérabilité avec les plates-formes que vous auriez autrement
exclure entièrement. Ainsi vous _ne perdez rien_ mais gagnez la possibilité d'utiliser
Wasm sur des plateformes plus diverses.

Vous êtes des ingénieurs logiciels. En tant que tel, je suppose que vous comprenez et appréciez
la valeur de la modularisation et de la superposition, pour séparer les préoccupations et maximiser
réutilisation. Cela s'applique également aux spécifications.

>

Les plates-formes non Unicode seraient obligées d'effectuer le transcodage pour réellement
manipuler leurs cordes.

Dans quels cas les chaînes Wasm doivent-elles interagir avec les chaînes de la plate-forme,
bien que? Pour autant que je sache, nous ne parlons que de l'encodage de
chaînes dans les métadonnées Wasm, et non l'encodage des chaînes manipulées par
code du module réel. (Si c'est faux, je m'excuse...) Alors je ne peux que penser
de quelques cas possibles où l'interopérabilité/transcodage pourrait être nécessaire :

• Un module Wasm importe un identifiant de plateforme
• La plateforme importe un identifiant Wasm
• Vous pouvez extraire les noms Wasm et les imprimer ou les enregistrer à l'aide de la plate-forme
  chaînes, par exemple pour vider une trace de pile.

Droit?

Oui. En d'autres termes, chaque fois que vous avez réellement besoin d'_utiliser_ une chaîne.

Pour les systèmes embarqués hypothétiques non Unicode, pour les deux premiers cas,
le conseil est simple : limitez les identifiants importés sur la plateforme
limite à l'ASCII, alors le transcodage requis est trivial. Modules Wasm
pourraient toujours utiliser des noms Unicode complets en interne et pour se lier les uns aux autres.

Pour le troisième numéro --- si vous avez un monde fermé de modules Wasm, vous
peuvent limiter leurs identifiants à l'ASCII. Sinon, en pratique, vous
rencontrer des identifiants UTF8 et vous feriez mieux de pouvoir les transcoder, et
vous serez heureux que la spécification ait mandaté UTF8 !

Selon la proposition, vous ne seriez pas autorisé à limiter quoi que ce soit à l'ASCII ! À
permettre que la spécification de base aurait besoin d'être plus autorisant. Alors tu fais
mon point.

chaque spécification d'intégration _précisera_ un codage et un jeu de caractères. Sur chaque plate-forme, vous pouvez compter sur cela. Vous ne rencontreriez des questions d'encodage que si vous essayiez d'interagir entre deux écosystèmes non liés - qui seront déjà incompatibles pour des raisons plus profondes que les chaînes.

Qu'en est-il des outils de traitement Wasm tels que les désassembleurs ? Ne serait-il pas utile de pouvoir écrire un désassembleur qui fonctionne avec n'importe quel module Wasm, quelles que soient les variantes de "spécification d'intégration" ?

Selon la proposition, vous ne seriez pas autorisé à limiter quoi que ce soit à l'ASCII !

Selon la proposition, les modules Wasm ne seraient pas limités à l'ASCII, mais si un implémenteur choisissait de définir tous leurs identifiants en dehors des modules Wasm ASCII (par exemple, comme le font à peu près toutes les bibliothèques système !), cela sortirait du cadre de Wasm. spéc.

Si un implémenteur a choisi d'imprimer uniquement des caractères ASCII dans une trace de pile et de remplacer tous les caractères Unicode non ASCII par ? ou similaire, cela doit être autorisé par la spécification, car en pratique, il existe toujours des caractères Unicode que vous ne pas de police pour de toute façon.

Cela dit, définir un sous-ensemble de Wasm dans lequel tous les noms Wasm sont ASCII serait assez inoffensif puisque de tels modules Wasm seraient traités correctement par des outils qui traitent les noms Wasm comme UTF8.

Vous êtes des ingénieurs logiciels. En tant que tel, je suppose que vous comprenez et appréciez la valeur de la modularisation et de la superposition, pour séparer les préoccupations et maximiser la réutilisation. Cela s'applique également aux spécifications.

Oui, je suis ingénieur logiciel. Je suis également ingénieur de spécifications, donc je comprends la valeur de la cohérence et de l'établissement de normes qui améliorent le fonctionnement de l'écosystème. Les jeux de caractères et les codages sont l'un des sujets où la valeur de permettre la modularisation et le choix est largement contrebalancée par la valeur de la cohérence et de la prévisibilité. Nous en avons littéralement des décennies de preuves. C'est pourquoi je ne cesse de me répéter - vous ignorez l'histoire et la recommandation de nombreux experts, dont plusieurs sont apparus dans ce fil même, et bien d'autres dont je représente les opinions, lorsque vous insistez sur le fait que nous devons laisser la liberté à cet égard.

Après avoir lu tout ce (long) fil, je pense que la seule façon de résoudre cette discussion est de spécifier explicitement que la section des noms que nous décrivons au format binaire et que nous améliorons dans https://github.com/WebAssembly/design/pull /984 est un codage UTF-8 , et je proposerais que nous appelions simplement cette section "utf8-names" . Cela rend l'encodage explicite, et presque certainement tous les outils qui veulent manipuler les binaires WASM sur toutes les plates-formes pertinentes aujourd'hui veulent de toute façon parler UTF-8. Ils pourraient être pardonnés de ne parler que de l'UTF-8.

Je suis sensible aux préoccupations de @rossberg-chromium pour les autres plateformes, et dans une certaine mesure, je suis d'accord. Cependant, cela est facilement réparable. Comme quelqu'un l'a suggéré plus tôt dans le fil, ces systèmes sont plus que bienvenus pour ajouter une section "ascii-names" non standard ou tout autre encodage utilisé par leur écosystème. Avec des noms explicites, il devient évident quels outils fonctionnent avec quelles sections. Pour les modules qui ne fonctionnent que sous DOS, cela deviendrait évident du fait de la présence de sections spécifiques à DOS. OMI, ce serait un désastre d'interpréter les noms de ces binaires comme ayant un codage différent.

(Au fait, cela est informé d'histoires de guerre sur un système qui a accidentellement perdu les encodages des chaînes pour le contenu téléchargé par l'utilisateur, et n'a jamais pu les récupérer. Le système est mort d'une mort horrible et spasmodique. Littéralement, des millions de dollars ont été perdus .)

Nous pourrions même adopter une norme de nommage pour les sections de noms (heh), afin qu'elles soient toutes "\

@titzer Oui, les sections personnalisées sont la solution ici pour les plateformes exotiques ou spécialisées qui ne veulent rien avoir à faire avec UTF8. J'hésiterais à prescrire dans la spécification, cependant : si une plate-forme est si spécifique dans son mode de fonctionnement qu'elle ne peut même pas se donner la peine de mapper les points de code UTF-8 à leur préférence native, ils peuvent vouloir faire beaucoup plus avec des sections personnalisées que de simplement fournir des noms dans leur encodage préféré.

Je recommande de mettre davantage l'accent sur l'utilisation de sections personnalisées pour les détails spécifiques à la plate-forme dans la spécification, et de laisser les propres spécifications de la plate-forme définir ces détails. Les chaînes d'outils WASM courantes pourraient les prendre en charge via une sorte d'architecture de plug-in.

@titzer Passer à utf8-names semble bien. En prime, cela faciliterait la transition puisque les navigateurs pourraient facilement prendre en charge à la fois les "noms" (dans l'ancien format) et les "noms utf8" (au format #984) pour une version ou deux avant de supprimer les "noms" qui à leur tour supprime beaucoup d'urgence pour obtenir ce déployé.

Désolé si cela a déjà été décidé ci-dessus, mais pour être clair : y a-t-il une proposition de modification des noms d'import/export par rapport à ce qui se trouve dans BinaryEncoding.md maintenant ?

utf8-names sonne bien.

Même question que @lukewagner sur l'import/export.

@lukewagner @jfbastien Bonne question. Je n'ai pas vu de décision ci-dessus. Je pense surtout que nous ne voulons pas changer le format binaire de ce que nous avons actuellement. Donc c'est vraiment les contorsions mentales que nous devons traverser pour nous convaincre que ce que nous avons fait est rationnel :-)

AFAICT, nous supposons actuellement que les chaînes dans les importations/exportations sont des séquences d'octets non interprétées. C'est très bien. Je pense qu'il est raisonnable de considérer l'encodage des chaînes utilisées pour l'import/export comme étant uniquement défini par l'embedder d'une manière que la section des noms ne l'est pas ; Par exemple, JS utilise toujours UTF-8. La section des noms est livrée avec un encodage explicite dans le nom de la section des noms.

Version courte : l'encodage des noms dans les déclarations d'import/export est une propriété de l'environnement d'intégration, l'encodage des noms dans la section names est explicite par la chaîne utilisée pour identifier la section utilisateur (par exemple "utf8-names").

WDYT ?

Cela me convient et correspond à ce que nous avions avant la fusion de #984 (modulo names => utf8-names ).

Je pense que la section des noms n'est pas aussi importante que l'import/export, où se produisent les vrais problèmes de compatibilité :

• Chargez une section de noms mojibaked et vous obtenez Error.stack et débogage funky.
• Chargez un import/export mojibaked et rien ne fonctionne.

Je ne pense pas qu'il s'agisse vraiment d'un changement de format binaire puisque les intégrations que nous implémentons tous le supposent déjà.

Je m'appuierais sur la recommandation de personnes qui connaissent mieux que moi ce sujet avant de conclure.

Vous devrez décider de la façon dont vous décoderez l'UTF-8. Remplacez-vous les séquences erronées par U+FFFD ou arrêtez-vous à la première erreur ? Autrement dit, vous voulez soit https://encoding.spec.whatwg.org/#utf -8-decode-without-bom ou https://encoding.spec.whatwg.org/#utf -8-decode-without- bom-or-fail. Dans tous les cas, le chargement échouera probablement, à moins que la ressource n'utilise U+FFFD dans son nom.

De la manière dont il est actuellement décrit, nous lançons une exception si le tableau d'octets de nom d'import/export ne parvient pas à décoder en UTF-8 dans une chaîne JS. Après cela, vous avez une chaîne JS et la recherche d'importation est définie en termes de Get .

Pour vérifier ma compréhension, si nous faisions https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail, cela signifierait-il qu'après une validation réussie, vérifier l'égalité des points de code et des séquences équivaudrait à vérifier l'égalité des séquences d'octets ?

Oui.

Après la discussion ci-dessus, je prends en charge la validation UTF-8 pour les noms d'import/export dans la spécification de base.

Plus précisément, ce serait utf-8-decode-without-bom-or-fail , et l'égalité de séquence de points de code (afin que les moteurs puissent faire l'égalité de séquence d'octets ), afin que les moteurs évitent les parties effrayantes et coûteuses d'Unicode et de l'internationalisation. Et cela est cohérent avec l'intégration Web. J'ai expérimenté cela et j'ai trouvé que les frais généraux principaux étaient négligeables.

• Re : Les ISA matérielles sont indépendantes de l'encodage : le matériel dont nous parlons ici n'a pas d'import/export en tant que tel, donc l'analogie ne s'applique pas directement. Le seul endroit que je connaisse où un tel matériel utilise des identificateurs de séquence d'octets de toute sorte, le cpuid de x86, spécifie un codage de caractère spécifique : UTF-8.

• Re : Superposition : En tant qu'ingénieurs logiciels, nous savons également que la superposition et la modularisation sont des moyens et non des fins en soi. Par exemple, nous pourrions facilement exclure LEB128 de la spécification de base. Cela permettrait une plus grande stratification et modularisation. LEB128 est sans doute biaisé en faveur des cas d'utilisation du Web.

• Re: "Systèmes embarqués": Un exemple donné est DOS, mais quel serait un exemple de quelque chose qu'une exigence UTF-8 pour les noms d'import/export exigerait d'un système DOS qui serait coûteux ou peu pratique à faire ?

• Re: Islands: WebAssembly spécifie également un endian spécifique, nécessite une prise en charge des virgules flottantes, des unités d'adresse 8 bits et fait d'autres choix, même s'il existe de vrais paramètres où ceux-ci seraient des fardeaux inutiles. WebAssembly fait des choix comme ceux-là lorsqu'il s'attend à ce qu'ils renforcent la plate-forme commune que de nombreuses personnes peuvent partager.

• Re : Structures de données arbitraires dans les noms d'import/export : c'est théoriquement utile, mais cela peut aussi être fait en transformant les données en chaînes. Mangling est moins pratique, mais pas difficile. Il y a donc un compromis là-bas, mais pas un gros (et sans doute, s'il y a un besoin général d'attacher des métadonnées aux importations/exportations, il serait plus agréable d'avoir un mécanisme explicite que d'ajouter des identifiants à des fins supplémentaires.)

• Re : Compatibilité binaire : Je suis également d'accord avec JF que ce changement est toujours faisable. utf-8-decode-without-bom-or-fail ne signifierait aucun changement de comportement silencieux, et à l'heure actuelle, tous les producteurs de wasm connus gardent leur sortie compatible avec l'intégration Web (même s'ils prennent également en charge d'autres intégrations), donc ils ' re restant déjà dans UTF-8.

Un PR faisant une proposition spécifique pour les noms UTF-8 est maintenant publié sous https://github.com/WebAssembly/design/issues/1016.

Avec #1016, c'est maintenant corrigé.