Argumento a favor de UTF-8: es muy simple. codificador y decodificador en JavaScript. Nuevamente, UTF-8 no es Unicode .

Argumento en contra de UTF-8: es cada vez un poco más complicado que la longitud + bytes, lo que conduce a posibles divergencias de implementación.

Nuevamente, UTF-8 no es Unicode.

¿Qué estás diciendo ? Esta es una frase sin sentido.

Creo que estás tratando de decir que no es necesario buscar una biblioteca de internacionalización. Esto es cierto: exigir que las cadenas estén codificadas en UTF-8 no tiene nada que ver con todas las partes más complicadas de Unicode, como la canonicalización. Esas son herramientas útiles cuando estás haciendo un trabajo de cadenas que interactúa con humanos, pero de la misma manera que una biblioteca de triggers es útil para las personas que hacen matemáticas y no es relevante para decidir cómo codificar números enteros.

Pero UTF-8 es literalmente una codificación Unicode; su declaración no tiene sentido tal como está escrito. ^ _ ^

Pero UTF-8 es literalmente una codificación Unicode; su declaración no tiene sentido tal como está escrito. ^ _ ^

Sí, me refiero específicamente a la codificación de puntos de código que describe UTF-8, no al tratamiento de los puntos de código propiamente dicho (para el propósito de esta propuesta, un punto de código es un entero opaco). Dicho en wasm-isms, UTF-8 es similar a var [u] int, pero más apropiado para los personajes. Además, UTF-8 no es la única codificación Unicode y se puede usar para codificar enteros que no son Unicode. Entonces, UTF-8 no es Unicode.

Una propuesta adicional consideraría los puntos de código individuales y haría algo con ellos. Esta no es esa propuesta.

Y no habría ninguna razón para hacerlo. Ninguna API web ha encontrado la necesidad de realizar una introspección en los puntos de código más allá de la comparación y clasificación de igualdad estrictas, a menos que sea literalmente una API i18n.

Otra opción es la longitud del byte + UTF-8 para cada punto de código ( @jfbastien a menos que esto sea lo que quisiste decir cuando dijiste UTF-8 para cada byte, lo que admito que no tenía sentido para mí). No creo que esto dificultaría más las cosas para un analizador primitivo al que realmente no le importa, al tiempo que permite que una biblioteca Unicode sofisticada tome una matriz de bytes, un desplazamiento y una longitud como entrada y devuelva una cadena.

Estoy de acuerdo con la definición de "puntos de código UTF-8", que son solo números enteros. La especificación binaria debería dejarlo así. Los integradores individuales pueden definir reglas sobre los puntos de código permitidos, la normalización y otros matices. Las herramientas de análisis pueden proporcionar advertencias sobre posibles problemas de compatibilidad.

Creo que las decisiones de manejo de errores también deberían dejarse en manos de los integradores. Un sistema que accedió a las funciones de WASM por índice en lugar de por nombre no necesita que sean válidas (y sería fácil omitirlas con un prefijo de longitud de bytes).

He aquí un intento de resumir los problemas subyacentes y sus razones. Las correcciones y adiciones son bienvenidas.

¿Debería wasm requerir que los identificadores de importación / exportación de módulos sean UTF-8 válidos?

Mi comprensión de las razones en contra es:

• El procesamiento de importaciones y exportaciones se encuentra en la ruta crítica para el inicio de la aplicación, y existe el deseo de evitar cualquier cosa que lo ralentice.
• El invariante amplio "la especificación básica de wasm no interpreta cadenas". La interpretación de cadenas es compleja en general, y existe el deseo de encapsularla y tener invariantes y límites amplios sobre los que se pueda razonar a un alto nivel.
• Los decodificadores de WebAssembly a menudo son sensibles a la seguridad, por lo que existe un deseo general de minimizar la cantidad de código involucrado.
• Es posible que algunos productores de WebAssembly quieran incrustar datos arbitrarios en estos identificadores, y es más conveniente para ellos codificar los datos como quieran en lugar de alterarlos en forma de cadena.

¿Wasm debería recomendar UTF-8 en áreas donde no lo requiere?

La razón sería que incluso si no podemos requerirlo, mencionar UTF-8 puede desalentar incompatibilidades innecesarias entre el ecosistema.

Mi comprensión de la razón en contra es que incluso mencionar UTF-8 comprometería la encapsulación conceptual de las preocupaciones de interpretación de cadenas.

¿Debería wasm especificar UTF-8 para los nombres de sección de nombre?

La razón es: el propósito completo de estos nombres es convertirlos en cadenas para su visualización, lo cual no es posible sin una codificación, por lo que deberíamos especificar UTF-8 para que las herramientas no tengan que adivinar.

Mi comprensión de la razón en contra es: si wasm tiene otras cosas similares a cadenas en otras áreas que no tienen una codificación designada (es decir, importaciones / exportaciones como se discutió anteriormente), entonces, en aras de la coherencia, no debería designar codificaciones para ninguna cadena .

@sunfishcode proporciona un buen resumen, pero quiero agregar tres puntos cruciales.

@jfbastien , sería la más inútil de todas las alternativas restringir la _sintaxis_ binaria_ (una codificación) pero no la _ semántica_ (un conjunto de caracteres) para las cadenas. Entonces, para todos los propósitos prácticos, UTF-8 implica Unicode. Y nuevamente, esto no se trata solo de motores. Si define nombres para que sean Unicode, entonces está forzando eso en todos los ecosistemas de Wasm en todos los entornos. Y eso significa básicamente que se requiere que todos los entornos tengan algún soporte Unicode.

@tabatkins , creo que hay un error de dominio subyacente a su argumento. Ninguna de las cadenas de las que estamos hablando es _de cara al usuario_. Son nombres _dev-enfrentados_. Muchos / la mayoría de los lenguajes de programación no admiten identificadores Unicode ni herramientas. ¿Puede, por ejemplo, gdb manejar identificadores de fuente Unicode? No lo creo. Por lo tanto, es bastante optimista (o más bien poco realista) asumir que todos los consumidores han convergido en Unicode _en este espacio_.

Y finalmente, el desacuerdo no es _si_ Wasm en la Web debería asumir UTF-8, sino _donde_ especificamos eso.

Creo que hay un error de dominio subyacente a su argumento. Ninguna de las cadenas de las que estamos hablando está orientada al usuario. Son nombres orientados a desarrolladores. Muchos / la mayoría de los lenguajes de programación no admiten identificadores Unicode ni herramientas. ¿Puede, por ejemplo, gdb manejar identificadores de fuente Unicode? No lo creo. Por lo tanto, es bastante optimista (o más bien poco realista) asumir que todos los consumidores han convergido en Unicode en este espacio.

"orientado al desarrollador" significa "orientado a la cadena de herramientas arbitraria", lo que significa que debe aceptar la codificación por adelantado, o de lo contrario las herramientas tendrán que hacer la "detección" de codificación (es decir, adivinar, lo cual es especialmente malo cuando aplicado a valores cortos) o tienen información fuera de banda. Los desarrolladores siguen siendo usuarios. ^ _ ^

Si cree que muchas cadenas de herramientas no van a entender Unicode, entonces no estoy seguro de por qué cree que entenderían cualquier otra codificación binaria arbitraria. Si esa es su limitación, simplemente especifique y requiera ASCII, que es 100% compatible en todas partes. Si no está dispuesto a limitarse a ASCII, debe aceptar que existe un único esquema de codificación no ASCII aceptado: UTF-8.

Decir "eh, la mayoría de las cosas probablemente solo sean compatibles con ASCII, pero dejaremos que los desarrolladores pongan lo que quieran allí por si acaso " es lo peor de ambos mundos.

Decir "eh, la mayoría de las cosas probablemente solo sean compatibles con ASCII, pero dejaremos que los desarrolladores pongan lo que quieran allí por si acaso" es lo peor de ambos mundos.

@tabatkins , nadie propone lo anterior. Como dije, la pregunta no es _si_ sino _ dónde_ definir tales asuntos específicos de plataforma / entorno. Se supone que Wasm se puede incrustar en la gama más amplia y heterogénea de entornos, algunos mucho más ricos que otros (por ejemplo, JS _does_ admite identificadores Unicode). En consecuencia, desea permitir la elección por plataforma. Por lo tanto, pertenece a las especificaciones de la API de la plataforma, no a la especificación principal.

¡No hay elección que hacer, aunque! Si su entorno de incrustación no admite no ASCII, simplemente no utilice no ASCII en sus cadenas . (Y si este es el caso, aún necesita garantía de codificación; ¡UTF-16 no es compatible con ASCII, por ejemplo!)

Si su entorno admite no ASCII, necesita saber qué codificación usar y la elección correcta en todas las situaciones es UTF-8.

¿Qué entorno imagina en el que es beneficioso no conocer la codificación de sus cadenas?

sería la más inútil de todas las alternativas restringir la sintaxis binaria (una codificación) pero no la semántica (un juego de caracteres) para las cadenas. Entonces, para todos los propósitos prácticos, UTF-8 implica Unicode.

No, absolutamente no lo hace. Por ejemplo, es perfectamente razonable (a) restringir simultáneamente una cadena a los caracteres ASCII y (b) dictar que está codificada en UTF-8. El uso de caracteres ASCII no implica una codificación, o de lo contrario, ¡todas las codificaciones serían compatibles con ASCII! (Por ejemplo, UTF-16 no lo es). Por lo tanto, aún debe especificar algo; UTF-8, al ser "compatible con ASCII", está bien para esto.

Nuevamente, si está de acuerdo con restringir estos nombres solo a ASCII, entonces es razonable exigir que la codificación sea US-ASCII. Si desea que sea posible ir más allá de ASCII, entonces es razonable exigir que la codificación sea UTF-8. Obligar cualquier otra cosa, o no exigir nada en absoluto (y obligar a todos los consumidores a adivinar o usar información fuera de banda), son las únicas posibilidades irrazonables.

Y nuevamente, esto no se trata solo de motores. Si define nombres para que sean Unicode, entonces está forzando eso en todos los ecosistemas de Wasm en todos los entornos. Y eso significa básicamente que se requiere que todos los entornos tengan algún soporte Unicode.

Nuevamente, parece que estás hablando de bibliotecas de internacionalización. Lo que estamos discutiendo es únicamente cómo decodificar secuencias de bytes de nuevo en cadenas; eso requiere solo conocimiento de cómo decodificar UTF-8, que es extremadamente trivial y extremadamente rápido.

A menos que esté realizando una manipulación de cadenas amigable para los humanos, todo lo que necesita es la capacidad de comparar cadenas por punto de código y posiblemente ordenar cadenas por punto de código, ninguno de los cuales requiere ningún "soporte Unicode". Esto es todo lo que utiliza la tecnología web existente, por ejemplo, y no veo ninguna razón por la que los entornos Wasm, en general, necesitarían hacer algo más complicado que esto.

Estoy a favor de exigir utf8 para All The Strings. La decodificación / codificación utf8 pura parece una carga implícita bastante baja (en comparación con todo lo demás) para entornos no web. Además, por lo que he visto, el tiempo dedicado a validar utf8 para importaciones / nombres será insignificante en comparación con el tiempo dedicado a todo lo demás, por lo que no creo que haya un argumento de rendimiento aquí.

Hablando en términos prácticos, incluso si no ordenáramos utf8 en la especificación central de wasm, tendrías un mal momento interoperando con cualquier cosa si tu cadena de herramientas personalizada no usara utf8 a menos que seas una isla total y luego tal vez solo digas "A la mierda" y haz tu propia cosa que no sea utf8 de todos modos ... porque entonces a quién le importa.

Sin embargo, lo que

@lukewagner No creo que el # 984 esté bloqueado en esto. 😄

Supongo que estas en lo correcto.

¿Qué entorno imagina en el que es beneficioso no conocer la codificación de sus cadenas?

@tabatkins , parece que todavía no he sido lo suficientemente claro. No imagino un entorno así. Sin embargo, imagino un amplio espectro de entornos con requisitos incompatibles. No todo es un subconjunto de UTF-8, por ejemplo, Latin1 todavía tiene un uso bastante extendido. Puede que no le importe, pero no es el trabajo de la especificación básica de Wasm poner piedras innecesarias en el camino de la diversidad del entorno.

lo pasaría mal interoperando con cualquier cosa si su cadena de herramientas personalizada no usara utf8 a menos que sea una isla total

@lukewagner , de hecho espero que Wasm se use en una variedad de "continentes" que potencialmente tienen poca superposición. Y donde lo hagan, puede especificar la interoperabilidad (en la práctica, las codificaciones de nombres probablemente serán el menor problema para compartir módulos entre diferentes plataformas, son bibliotecas de host). Incluso las islas totales no son poco realistas, especialmente con los sistemas integrados (que también tienden a tener poco uso para Unicode).

Una de las partes más difíciles de implementar un motor WebAssembly no basado en navegador es hacer que las cosas funcionen como lo hace en el navegador (principalmente las partes JS). Espero que si la codificación no se estandariza, terminaremos con un estándar de facto en el que todos copian lo que se hace para el objetivo web. Esto solo hará que sea más difícil encontrar información sobre cómo decodificar estas cadenas.

Puede ser útil permitir que algunos entornos restrinjan aún más el contenido permitido, pero no requerir UTF-8 solo resultará en más dificultades.

@ MI3Guy , la contrapropuesta es especificar la codificación UTF-8 como parte de la API de JS. Entonces, si está construyendo una incrustación de JS, entonces se define como UTF-8 de cualquier manera y no hace ninguna diferencia para usted. (Sin embargo, también queremos permitir otras API de incrustación que no sean web ni JavaScript).

Derecha. Mi punto es que si no está haciendo una incrustación de JS, se ve obligado a emular mucho de lo que hace el incrustador de JS para utilizar la cadena de herramientas de WebAssembly.

Varuint para el número de puntos de código + UTF-8 para cada punto de código.

Solo me gustaría hablar en contra de esta opción. Complica las cosas, no se aplica y no se puede aplicar a secciones específicas del usuario, y no proporciona ningún beneficio que pueda ver; para saber el número de puntos de código en una cadena UTF-8, en la práctica siempre terminas escaneando la cadena en busca de codificaciones no válidas, por lo que también podría contar los puntos de código mientras lo hace.

No todo es un subconjunto de UTF-8, por ejemplo, Latin1 todavía tiene un uso bastante extendido. Puede que no le importe, pero no es el trabajo de la especificación básica de Wasm poner piedras innecesarias en el camino de la diversidad del entorno.

Correcto; UTF-8 se diferencia de prácticamente todas las codificaciones una vez que abandona el rango ASCII. Aunque no estoy seguro de cuál es tu punto con esto. En realidad, usar la codificación Latin-1 es malo precisamente porque hay muchas otras codificaciones que se ven iguales pero codifican letras diferentes . Si intentó usar el nombre "æther" en su código Wasm y lo codificó en Latin-1, entonces alguien más (justificadamente) intenta leer el nombre con una cadena de herramientas UTF-8, obtendrá un error de decodificación. O tal vez la otra persona estaba cometiendo un error similar, pero usó la codificación Windows-1250 en su lugar (destinada a los idiomas de Europa Central / Oriental); obtendrían la palabra sin sentido "ćther".

Realmente no estoy seguro de qué tipo de "diversidad" estás tratando de proteger aquí. Literalmente, no hay ningún beneficio al usar cualquier otra codificación, y hay toneladas de desventajas. Cada carácter que puede codificar en otra codificación está presente en Unicode y se puede codificar en UTF-8, pero lo contrario casi nunca es cierto. Actualmente no existen herramientas relevantes que no puedan manejar UTF-8; la tecnología tiene literalmente dos décadas .

Sigo diciéndoles que los estándares web resolvieron esta cuestión hace años, no porque Wasm sea una especificación web que deba seguir las reglas web, sino porque la codificación de texto es un problema del ecosistema con el que casi todo el mundo tiene los mismos problemas, y la web ya se ha ocupado con el dolor de hacer esto mal, y ha aprendido a hacerlo bien. No hay ninguna virtud en volver a equivocarse en Wasm; cada entorno que tiene que codificar texto va directamente a UTF-8 desde el principio, o comete los mismos errores y sufre el mismo dolor que todos los demás, y finalmente se establece en UTF-8. (O, en casos raros, desarrolla un entorno suficientemente aislado que pueden estandarizar en una codificación diferente, y solo rara vez pagan el precio de comunicarse con el entorno exterior. Pero estandarizan en una codificación , que es el punto de todo esto).

Entonces, si está construyendo una incrustación de JS, entonces se define como UTF-8 de cualquier manera y no hace ninguna diferencia para usted. (Sin embargo, también queremos permitir otras API de incrustación que no sean web ni JavaScript).

Este problema no tiene nada que ver con la Web o JS. Cada parte del ecosistema quiere una codificación de texto consistente y conocida, y hay una única que es ampliamente aceptada en todos los entornos de programación, países e idiomas: UTF-8.

Voto por 'Hacer varuint para la longitud (en bytes) + UTF-8 para cada byte'. Suponiendo que esa no sea una opción controvertida, casi todas las implementaciones de cadenas almacenan cadenas como "número de unidades de código" en lugar de "número de puntos de código", porque es más simple, entonces no es la pregunta real "si la validación falla si una cadena no lo es ¿válido UTF-8 "?

Como señalé en el n. ° 970, el UTF-8 no válido se puede redirigir a UTF-16, por lo que si se permite el UTF-8 no válido, el software que no quiere almacenar los bytes originales no tiene por qué hacerlo. Por otro lado, verificar si UTF-8 es válido no es difícil (aunque debemos responder: ¿deben aceptarse secuencias demasiado largas? ¿Caracteres sustitutos?)

En general, me inclino a decir que ordenemos UTF-8. En el extraño caso de que alguien tenga bytes que no puedan traducir a UTF-8 (quizás porque se desconoce la codificación), se pueden transcribir bytes arbitrarios a UTF-8.

Realmente no estoy seguro de qué tipo de "diversidad" estás tratando de proteger aquí.

@tabatkins , sí, ese parece ser el núcleo del malentendido.

Es importante darse cuenta de que WebAssembly, a pesar de su nombre, no se limita a la web. Somos muy cautelosos al definirlo en capas adecuadas, de modo que cada capa sea lo más utilizable posible.

En particular, su _core_ no es en realidad una tecnología web _ en absoluto_. En su lugar, trate de pensar en ello como un _Virtual ISA _. Esta abstracción es útil en un amplio espectro de entornos diferentes, desde muy ricos (la web) hasta muy rudimentarios (sistemas integrados), que no necesariamente tienen nada que ver entre sí, pueden ser en gran medida incompatibles y tener restricciones conflictivas ( que Wasm no está en condiciones de cambiar).

Como tal, no tiene más sentido imponer Unicode en _core_ Wasm de lo que tendría, por ejemplo, imponer Unicode en todos los literales de cadena en el lenguaje de programación C. Solo obligaría a algunos clientes potenciales a violar esta parte del estándar. ¿Cuál es la ganancia?

Sin embargo, habrá capas de especificaciones adicionales además de esta especificación principal que definen su incrustación y API en entornos _concrete_ (como JavaScript). Tiene mucho sentido arreglar las codificaciones de cadenas en ese nivel y, por supuesto, deberíamos hacerlo.

PD: Un lema que define el alcance de Wasm es que es una abstracción sobre hardware común, no una abstracción sobre lenguajes de programación comunes. Y el hardware es independiente de las preocupaciones del software, como las codificaciones de cadenas. Para eso están las ABI.

@ rossberg-cromo

Como tal, no tiene más sentido imponer Unicode en el núcleo de Wasm de lo que tendría, por ejemplo, imponer Unicode en todos los literales de cadena en el lenguaje de programación C. Solo obligaría a algunos clientes potenciales a violar esta parte del estándar. ¿Cuál es la ganancia?

Estoy 100% de acuerdo. Sin embargo, este problema no se trata de Unicode, se trata únicamente de UTF-8, una codificación para enteros, sin exigir que los enteros se interpreten como Unicode.

No entiendo si estamos de acuerdo en eso. ¿Podrías aclarar: estás de acuerdo con UTF-8, y si no, por qué?

@jfbastien , ¿sería más productivo requerir la conformidad UTF-8 para todos los literales de cadena C?

Como señalé anteriormente, para mí no tiene sentido restringir la codificación pero no el juego de caracteres. Eso es como definir sintaxis sin semántica. ¿Por qué posiblemente harías eso? Obtiene cero en términos de interoperabilidad, pero sigue erigiendo obstáculos artificiales para entornos que no usan UTF-8 (que solo los entornos Unicode lo hacen de todos modos).

@jfbastien , ¿sería más productivo requerir la conformidad UTF-8 para todos los literales de cadena C?

No entiendo, ¿puedes aclarar?

Como señalé anteriormente, para mí no tiene sentido restringir la codificación pero no el juego de caracteres. Eso es como definir sintaxis sin semántica. ¿Por qué posiblemente harías eso? Obtiene cero en términos de interoperabilidad, pero sigue erigiendo obstáculos artificiales para entornos que no usan UTF-8 (que solo los entornos Unicode lo hacen de todos modos).

Creo que el meollo de la discusión.

@tabatkins se refirió a los precedentes exactamente a esto:

Nuevamente, parece que estás hablando de bibliotecas de internacionalización. Lo que estamos discutiendo es únicamente cómo decodificar secuencias de bytes de nuevo en cadenas; eso requiere solo conocimiento de cómo decodificar UTF-8, que es extremadamente trivial y extremadamente rápido.

A menos que esté realizando una manipulación de cadenas amigable para los humanos, todo lo que necesita es la capacidad de comparar cadenas por punto de código y posiblemente ordenar cadenas por punto de código, ninguno de los cuales requiere ningún "soporte Unicode". Esto es todo lo que utiliza la tecnología web existente, por ejemplo, y no veo ninguna razón por la que los entornos Wasm, en general, necesitarían hacer algo más complicado que esto.

Así que estoy de acuerdo: esta propuesta es, en sus palabras, "definir sintaxis sin semántica". Eso es algo muy común de hacer. De hecho, ¡la especificación actual de longitud + bytes de WebAssembly ya hace esto!

Me gustaría entender cuál es el obstáculo. Realmente no veo uno.

Es importante darse cuenta de que WebAssembly, a pesar de su nombre, no se limita a la web.

Acabo de afirmar en el comentario inmediatamente anterior que esto no tiene nada que ver con la web. Sigues tratando de usar este argumento y realmente me confunde. Lo que estoy diciendo no tiene nada que ver con la web; Simplemente estoy señalando la experiencia de la web como un ejemplo importante de lecciones aprendidas.

Como tal, no tiene más sentido imponer Unicode en el núcleo de Wasm de lo que tendría, por ejemplo, imponer Unicode en todos los literales de cadena en el lenguaje de programación C. Solo obligaría a algunos clientes potenciales a violar esta parte del estándar. ¿Cuál es la ganancia?

Usted no está haciendo el punto que creo que estás cometiendo - C tiene un sistema incorporado en la codificación, como literales de cadena utilizan la codificación ASCII. (Si desea algo más, debe hacerlo a mano escapando de las secuencias de bytes apropiadas). En C ++ más actual, puede tener literales de cadena UTF-16 y UTF-8, y aunque todavía puede poner bytes arbitrarios en la cadena con \x escapa, el \u escapa al menos verificar que el valor sea un punto de código válido.

Todo esto es necesario, porque no hay un mapeo inherente de caracteres a bytes . Eso es lo que hace una codificación. Una vez más, no tener una codificación específica solo significa que los usuarios del idioma, cuando reciben secuencias de bytes de otras partes, tienen que adivinar la codificación para convertirlas nuevamente en texto.

Obtiene cero en términos de interoperabilidad, pero sigue erigiendo obstáculos artificiales para entornos que no usan UTF-8 (que solo los entornos Unicode lo hacen de todos modos).

Puede usted por favor seleccione un entorno en el que los personajes existencia usos que no están incluidos en Unicode? Sigues tratando de defender esta posición desde un punto de vista teórico de pureza / diversidad ambiental, pero literalmente el objetivo de Unicode es incluir a todos los personajes . Es el único conjunto de caracteres que puede ser un argumento remotamente creíble para hacerlo, y cuando usa el conjunto de caracteres Unicode, UTF-8 es la codificación universal preferida.

¿Qué diversidad estás intentando proteger? Sería genial ver incluso un solo ejemplo. : /

@tabatkins :

Es importante darse cuenta de que WebAssembly, a pesar de su nombre, no es
limitado a la web.

Acabo de afirmar en el comentario inmediatamente anterior que esto no tiene nada
que ver con la web. Sigues intentando usar este argumento, y es realmente
Me confunde. Lo que estoy diciendo no tiene nada que ver con la web; Soy simplemente
señalando la experiencia de la web como un ejemplo importante de lecciones aprendidas.

Lo que estoy tratando de enfatizar es que Wasm debería ser aplicable a tantos
plataformas como sea posible, modernas o no. Sigues discutiendo desde el final feliz
del espectro donde todo es Unicode y / o UTF-8, y todo
else está en desuso.

Usted no está haciendo el punto que se piensa están haciendo - C tiene una

codificación incorporada, ya que los literales de cadena utilizan la codificación ASCII. (Si quieres
cualquier otra cosa tiene que hacerlo a mano escapando del byte apropiado
secuencias.) En C ++ más actual, puede tener cadenas UTF-16 y UTF-8
literales, y aunque todavía puede poner bytes arbitrarios en la cadena con
\ x escapa, \ u escapa al menos verificar que el valor sea válido
punto de código.

No, eso es incorrecto. La especificación C no requiere ASCII. Ni siquiera
requieren compatibilidad con ASCII. Permite una fuente casi arbitraria
conjuntos de caracteres "y los literales de cadena pueden contener cualquier carácter del
colocar. No hay restricciones con respecto a la codificación, es completamente
definido por la implementación. Ha habido implementaciones de C ejecutándose en
Plataformas EBCDIC, y eso todavía es compatible con el estándar actual. GCC
puede procesar fuentes en cualquier codificación iconv (de las cuales hay alrededor de 140
además de UTF-8), por ejemplo, UTF-16, que es popular en Asia. C ++ no es diferente.

(Eso también debería responder a la pregunta de @jfbastien ).

Todo esto es necesario, porque no hay un mapeo inherente decaracteres a bytes . Eso es lo que hace una codificación. Una vez más, no tener un
codificación especificada solo significa que los usuarios del idioma, cuando reciben
secuencias de bytes de otras partes, tiene que adivinar la codificación para girar
volverlos al texto.

Nuevamente: esto _será_ convenientemente especificado por entorno. Cuando alguien
recibe un módulo Wasm de otra persona que opera en el mismo ecosistema
entonces no hay problema. Ningún desarrollador de JS necesitará preocuparse.

Sin embargo, si alguien está recibiendo un módulo de _ otro ecosistema_ entonces
hay muchas otras fuentes de incompatibilidad de las que preocuparse, p. ej.
expectativas sobre API, bibliotecas integradas, etc. Ambas partes necesitarán
Sea explícito acerca de sus supuestos de interoperabilidad de todos modos. Ponerse de acuerdo en un nombre
la codificación será el menor de sus problemas.

Obtienes cero en términos de interoperabilidad, pero aún así erizas obstáculos artificiales para

entornos que no utilizan UTF-8 (que solo los entornos Unicode hacen
de todas formas).

Puede usted por favor seleccione un entorno en el que la existencia usos
caracteres que no están incluidos en Unicode? Sigues intentando defender esto
posición desde un punto de vista teórico de pureza / diversidad ambiental, pero
literalmente, el objetivo de Unicode es incluir todos lospersonajes . Es el único conjunto de caracteres que puede hacer un
argumento creíble para hacerlo, y cuando está utilizando el carácter Unicode
, UTF-8 es la codificación universal preferida.

¿Qué diversidad estás intentando proteger? Sería genial ver incluso
un solo ejemplo. : /

Por ejemplo, aquí hay una lista de sistemas operativos integrados: https://en.wikipedia.org/wiki/
Categoría: Embedded_operating_systems
Es probable que algunos de ellos usen UTF-8, otros no. Algunos pueden encontrar un uso para Wasm,
lo más probable es que no lo haga. Pero no hay ningún beneficio para nosotros en hacerlo menos
conveniente para ellos.

Una entrada de esa lista con la que probablemente todavía esté familiarizado es DOS. Como
por mucho que a todos nos guste que muera, los sistemas DOS todavía están activos y utilizan
OEM.

@jfbastien :

Así que estoy de acuerdo: esta propuesta es, en sus palabras, "definir la sintaxis sin
semántica ". Eso es algo muy común. De hecho, WebAssembly
¡La especificación de longitud actual + bytes ya hace esto!

Las raras ocurrencias de tal cosa de las que soy consciente tienen que ver con
proporcionando una trampilla de escape para el comportamiento específico de la implementación. Esa es
también el único caso de uso razonable. Sin embargo, eso no tiene sentido aquí. Si tu
desea proporcionar una escotilla de escape para las cuerdas, entonces, ¿por qué molestarse en requerir
UTF-8, en lugar de permitir cualquier "sintaxis" de cadena de bytes? Esa es la sintaxis sin
la semántica como un impedimento, no un habilitador.

Me gustaría entender cuál es el obstáculo. Realmente no veo uno.
>
Que algunos clientes no pueden simplemente usar todos los valores de bytes, sino que deben pasar por
codificaciones UTF redundantes que no tienen uso en su ecosistema. Que todos
las herramientas en sus cadenas de herramientas también tendrán que preocuparse por ello. Eso es
crea casos de error adicionales (valores fuera de rango) que no
de lo contrario existen para ellos.

Permítanme preguntar al revés: ¿Cuál es el beneficio (en sus ecosistemas)?
Realmente no veo uno.

@tabatkins
Quiero asegurarme de que entiendo dónde está la línea divisoria.
Para que quede claro, está sugiriendo ÚNICAMENTE la codificación utf-8 de puntos de código, independientemente de si no son válidos en combinación (eso se puede hacer en 10 líneas de código).
Las mayúsculas en negrita, por ejemplo, podrían usarse en la especificación para indicar: ¿Está haciendo algo mal si cree que necesita una biblioteca de internacionalización para implementar Wasm?

Los objetivos de esto serían:

• Asegúrese de que cualquier wasm válido que termine en la web pueda al menos mostrar caracteres de tofu para cosas no válidas.
• Fomente que las herramientas que generan wasm (incluso en contextos fuera de la web) prefieran unicode sobre otras codificaciones cuando necesiten ir más allá de ascii. (Un golpe suave en esta dirección ya que no ocurre la validación completa).

¿Preguntas?

• ¿Existe algún peligro de que esto se convierta en un requisito progresivo para una mayor validación? Creo que mi principal preocupación en este espacio sería que siempre será una carga irrazonable tragar, digamos, la UCI como una dependencia.

• Supongo que esto implica el objetivo de fomentar activamente codificaciones como Latin1 que chocan con UTF-8. Es decir, las cadenas de herramientas que lo emiten no serían compatibles, las implementaciones que lo aceptan de manera similar.

• Creo que la web históricamente ha tenido problemas para unificar este espacio debido al uso superpuesto de bits de regiones que anteriormente codificaban islas. Por otro lado, mi impresión es que UTF-8 establece las cosas de tal manera que los costos de la transición son asumidos de manera desproporcionada por personas que no pertenecen a ASCII, y que algunas regiones tienen más cosas que hacer. Me imagino que la transición Unicode es una inevitabilidad práctica (y casi completo). ¿Existe algún documento / entidad centralizada que podamos señalar que aborde cómo se han resuelto algunos de los problemas políticos y regionales en torno a Unicode en la web?

@ rossberg-cromo

• Veo la inconsistencia lógica en validar algunos aspectos de una codificación pero no otros. Por otro lado, mi impresión es que utf8 es omnipresente en este punto (y que un pequeño empujón en las herramientas + validación tiene un bajo costo). ¿Su principal incomodidad es agregar la validación utf-8 básica a la especificación, la inconsistencia o algo más?

Para que quede claro, está sugiriendo ÚNICAMENTE la codificación utf-8 de puntos de código, independientemente de si no son válidos en combinación (eso se puede hacer en 10 líneas de código).

Sí, aunque no creo que haya combinaciones inválidas; solo hay algunos puntos de código individuales (los reservados para los sustitutos UTF-16) que técnicamente no son válidos para codificar como UTF-8. Dicho esto, si se desea un control total de bytes, la codificación WTF-8 sí existe, pero deberíamos ser muy explícitos sobre "sí, queremos permitir que estas cadenas contengan datos arbitrarios que no sean cadenas" como objetivo si vamos por ese camino. El formato WTF-8 (y WTF-16) solo está destinado a proporcionar una especificación formal para entornos que tienen restricciones de compatibilidad con versiones anteriores para hacer cumplir la forma correcta de UTF- *.

Las mayúsculas en negrita, por ejemplo, podrían usarse en la especificación para indicar: ¿Está haciendo algo mal si cree que necesita una biblioteca de internacionalización para implementar Wasm?

Sí, i18n no se requiere de ninguna manera, forma o forma. CSS por defecto es UTF-8, por ejemplo, y solo hace comparación / clasificación de puntos de código sin formato cuando permite cosas fuera del rango ASCII. Tampoco hay razón para que Wasm vaya más allá de esto.

¿Existe algún peligro de que esto se convierta en un requisito progresivo para una mayor validación? Creo que mi principal preocupación en este espacio sería que siempre será una carga irrazonable tragar, digamos, la UCI como una dependencia.

Hasta ahora, la plataforma web nunca ha necesitado imponer una validación adicional a los nombres desnudos. Mi experiencia sugiere que nunca será necesario.

Supongo que esto implica el objetivo de animar activamente codificaciones como Latin1 que chocan con UTF-8. Es decir, las cadenas de herramientas que lo emiten no serían compatibles, las implementaciones que lo aceptan de manera similar.

Sí, con el cambio a "des alentadora" en sus palabras. ^ _ ^ El punto es que los productores y consumidores pueden codificar y decodificar de manera confiable cadenas hacia / desde secuencias de bytes sin tener que adivinar qué está haciendo el otro punto final. Este ha sido un dolor terrible para todos los entornos que lo han encontrado, y ahora hay una solución ampliamente adoptada.

Creo que la web históricamente ha tenido problemas para unificar este espacio debido al uso superpuesto de bits de regiones que anteriormente codificaban islas. Por otro lado, mi impresión es que UTF-8 establece las cosas de tal manera que los costos de la transición son asumidos de manera desproporcionada por personas que no pertenecen a ASCII, y que algunas regiones tienen más cosas que hacer. Me imagino que la transición Unicode es una inevitabilidad práctica (y casi completo). ¿Existe algún documento / entidad centralizada que podamos señalar que aborde cómo se han resuelto algunos de los problemas políticos y regionales en torno a Unicode en la web?

Sí, definitivamente tuvo problemas en la transición; Todavía se requiere HTML para predeterminar Latin-1 debido a la compatibilidad con versiones anteriores, y todavía hay algunos pequeños grupos de contenido web que prefieren una codificación específica del idioma (principalmente Shift-JIS, una codificación en japonés). Pero la gran mayoría del mundo cambió durante las últimas dos décadas, y la transición se considera más o menos completa ahora.

El "UTF-8 carga a las personas que no pertenecen al ASCII" ha sido un rumor pernicioso, pero casi completamente falso durante mucho tiempo. La mayoría de los idiomas europeos incluyen la mayor parte del alfabeto ASCII en primer lugar, por lo que la mayor parte de su texto es secuencias de un solo byte y termina siendo más pequeño que UTF-16. Lo mismo se aplica a los sistemas de escritura como Pinyin. Los lenguajes CJK ocupan principalmente la región UTF-8 de 3 bytes, pero también incluyen grandes cantidades de caracteres ASCII, particularmente en lenguajes de marcado o lenguajes de programación, por lo que también, en general, vea tamaños codificados más pequeños o similares para UTF-8 como para UTF-16 o sus codificaciones especializadas.

Es solo para grandes cantidades de texto sin procesar en CJK o alfabetos no ASCII como el cirílico que vemos que UTF-8 realmente ocupa más espacio que una codificación especializada. Sin embargo, estas eran preocupaciones a principios de los megabytes y un ligero aumento en el tamaño de los archivos de texto era realmente capaz de ser significativo. Esto no ha sido una preocupación durante casi 20 años; la diferencia de tamaño es absolutamente intrascendente ahora.

Wrt a "la transición Unicode", que ya ha sucedido de manera bastante universal. Un formato de texto que no requiere codificarse con UTF-8 en estos días está cometiendo un error terrible y ahistórico.

No estoy seguro de ningún documento específico que describa estas cosas, pero apuesto a que existen en alguna parte. ^ _ ^

Si el objetivo es mantener la especificación binaria lo más pura posible, eliminemos los nombres por completo. Todas sus referencias internas se basan en índice, de todos modos.

En su lugar, agregue una sección personalizada obligatoria a la especificación de JavaScript que requiere UTF-8. Otros entornos, como el mainframe de la era soviética al que se refiere @ rossberg-chromium, pueden definir su propia sección personalizada. Un solo archivo WASM podría admitir ambas plataformas proporcionando ambas secciones personalizadas. Sería relativamente sencillo para las herramientas personalizadas generar la sección faltante de una plataforma oscura al convertir una más popular.

Si el objetivo es mantener la especificación binaria lo más pura posible, eliminemos los nombres por completo. Todas sus referencias internas se basan en índice, de todos modos.

Esa es una reelaboración de cómo funciona la importación / exportación. No está sobre la mesa y debería sugerirse en una edición diferente a esta.

@bradnelson , AFAICS, prescribiendo una codificación específica pero sin juego de caracteres
combina lo peor de ambos mundos: impone costos en términos de
restricciones, complejidad y gastos generales sin beneficio real en términos de
interoperabilidad. Supongo que todavía estoy confundido sobre cuál sería el punto.

@ rossberg-chromium El principal beneficio que se busca aquí es aliviar las herramientas y bibliotecas de la carga de adivinar.

Dado que el beneficio principal que se busca aquí es aliviar las herramientas y bibliotecas de la carga de adivinar, cualquiera de las variantes anteriores que se están discutiendo (UTF-8 frente a WTF-8, etc.) sería mejor que nada porque incluso en el peor de los casos, "Estoy seguro de que no puedo transcodificar estos bytes literalmente" es mejor que "estos bytes parecen ser windows-1252; tal vez lo intente". Se sabe que adivinar es propenso a errores, y el beneficio principal que se busca aquí es aliviar las herramientas y bibliotecas de la carga de adivinar.

@sunfishcode , ¿cómo? Todavía estoy perdido.

Así que aquí hay un escenario concreto. Supongamos que estamos en diferentes plataformas y estoy tratando de pasarle un módulo. Supongamos, en aras del argumento, que mi plataforma usa EBCDIC y la suya ASCII. Totalmente legítimo según la propuesta actual. Sin embargo, mi módulo será completamente inútil para usted y su cadena de herramientas.

Ambas codificaciones son de 7 bits, por lo que UTF-8 ni siquiera entra en la imagen.

Entonces, ¿qué aportaría UTF-8 a la mesa? Bueno, podría "decodificar" cualquier cadena desconocida que obtenga. Pero por lo que sé, el resultado es _sólo otra gota binaria opaca_ de valores de 31 bits. No proporciona ninguna información. No tengo idea de cómo relacionarlo con mis propias cuerdas.

Entonces, ¿por qué me tomaría la molestia de decodificar una cadena desconocida? Bueno, ¡yo no lo haría! También podría trabajar con el blob binario original de valores de 8 bits y ahorrar espacio y ciclos. Sin embargo, la especificación aún requeriría que pase ciclos para validar la codificación de forma vacía.

Teniendo en cuenta todo eso, ¿qué ganarían Wasm o herramientas (centrales) al adoptar esta propuesta en particular?

AFAICS, prescribiendo una codificación específica pero sin juego de caracteres
combina lo peor de ambos mundos: impone costos en términos de
restricciones, complejidad y gastos generales sin beneficio real en términos de
interoperabilidad. Supongo que todavía estoy confundido sobre cuál sería el punto.

Definitivamente estamos imponiendo un conjunto de caracteres: el conjunto de caracteres Unicode. JF estaba expresando las cosas de manera muy confusa antes, no prestes atención. Eso no significa que debamos agregar controles a Wasm para hacer cumplir esto; Los decodificadores suelen ser lo suficientemente robustos para tratar con caracteres no válidos. (La web, por ejemplo, normalmente los reemplaza con CARÁCTER DE REEMPLAZO U + FFFD).

Así que aquí hay un escenario concreto. Supongamos que estamos en diferentes plataformas y estoy tratando de pasarle un módulo. Supongamos, en aras del argumento, que mi plataforma usa EBCDIC y la suya ASCII. Totalmente legítimo según la propuesta actual. Sin embargo, mi módulo será completamente inútil para usted y su cadena de herramientas.

Debe dejar de fingir que los sistemas antiguos de varias décadas no solo son relevantes, sino tan relevantes que justifican la toma de decisiones que van en contra de todo lo que hemos aprendido sobre la codificación del dolor durante esas mismas décadas. No está ayudando a nadie con esta insistencia en que Web Assembly se contorsiona para maximizar la conveniencia al charlar con mainframes antiguos, mientras ignora el beneficio de que todos los demás en el mundo puedan comunicar datos textuales de manera confiable. Simplemente dañará el lenguaje y hará que el 99,9% (como una estimación muy conservadora) de la vida de los usuarios sea más difícil.

Muchos sistemas diferentes pasaron por todo este lío. Las guerras de codificación no fueron divertidas; desperdiciaron mucho dinero y mucho tiempo y resultaron en una gran cantidad de texto corrupto. Terminamos esas guerras, aunque. Unicode fue creado y promulgado, y se convirtió en el conjunto de caracteres dominante en todo el mundo, hasta el punto de que todos los demás conjuntos de caracteres son literalmente nada más que curiosidades históricas en este momento. Todavía tenemos peleas a fuego lento de bajo nivel sobre si usar UTF-16 o UTF-8, pero al menos esos dos suelen ser fáciles de diferenciar (mire la lista de materiales o busque una preponderancia de bytes nulos) y UTF general -8 domina cómodamente.

Su insistencia en codificar la libertad ignora toda esta historia, todas las lecciones aprendidas en las dos décadas desde que se introdujo Unicode. Ignora toda la experiencia y conocimientos que se han invertido en el diseño de sistemas modernos, que han tenido el efecto de hacer que los problemas de codificación sean invisibles para la mayoría de los usuarios, porque los sistemas pueden contar con que todo se codifica de una manera particular. Va a crear problemas serios, perniciosos y costosos si persiste en esto, un mojibake a la vez.

@ rossberg-cromo

Así que aquí hay un escenario concreto. Supongamos que estamos en diferentes plataformas y estoy tratando de pasarle un módulo. Supongamos, en aras del argumento, que mi plataforma usa EBCDIC y la suya ASCII. Totalmente legítimo según la propuesta actual. Sin embargo, mi módulo será completamente inútil para usted y su cadena de herramientas.

Entonces, ¿qué aportaría UTF-8 a la mesa? Bueno, podría "decodificar" cualquier cadena desconocida que obtenga. Pero por lo que sé, el resultado es solo otra gota binaria opaca de valores de 31 bits. No proporciona ninguna información. No tengo idea de cómo relacionarlo con mis propias cuerdas.

UTF-8 le diría exactamente cómo relacionarlo con sus propias cadenas. Ese es exactamente el problema que resuelve. (WTF-8 también lo haría cuando puede, y le diría sin ambigüedades cuando no puede).

¿Te refieres a una estructura de datos arbitraria transformada en forma de cadena y luego codificada como UTF-8? Es cierto que no podría exigirlo, pero al menos podría mostrar sin ambigüedades el nombre destrozado como una cadena, lo cual es una mejora con respecto a no tener nada para algunos casos de uso.

¿Te refieres a la discusión anterior sobre el uso de UTF-8 como una codificación de enteros opacos y no Unicode? Creo que la discusión se ha vuelto algo confusa. Es tentador llamar "sintaxis" a la codificación y "semántica" a la internacionalización, pero eso oculta una distinción útil: UTF-8 aún puede decir que una determinada secuencia de bytes significa "Ö" sin decir qué tienen que ver los consumidores con esa información. Usado de esta manera, es una codificación de Unicode, pero no requiere el tipo de costo que se sugirió anteriormente con "Soporte Unicode".

Entonces, ¿por qué me tomaría la molestia de decodificar una cadena desconocida? ¡Bueno, yo no lo haría! También podría trabajar con el blob binario original de valores de 8 bits y ahorrar espacio y ciclos. Sin embargo, la especificación aún requeriría que pase ciclos para validar la codificación de forma vacía.

Ahora he creado un SpiderMonkey con validación UTF-8 completa de los identificadores de importación / exportación de wasm, incluidos los demasiado largos y los sustitutos. No pude detectar una diferencia de rendimiento en WebAssembly.validate , ya sea en AngryBots o en un pequeño caso de prueba compilado con emscripten que, sin embargo, tiene 30 importaciones.

La especificación es un compromiso entre múltiples preocupaciones. Aprecio la preocupación por el tiempo de inicio, por lo que ahora realicé algunos experimentos y lo medí. Animo a otros a hacer sus propios experimentos.

Además, UTF-8 no es la única codificación Unicode y se puede usar para codificar enteros que no son Unicode. Entonces, UTF-8 no es Unicode.

¿Qué enteros puede codificar UTF-8 que no forman parte de Unicode (es decir, fuera del rango U + 0000 a U + 10FFFF)? Esa afirmación parece falsa.

Si no valida sus caracteres, puede codificar cualquier entero de 21 bits.

No estoy muy seguro de por qué no validaríamos ...

@flagxor https://encoding.spec.whatwg.org/ describe las diversas codificaciones expuestas en la web. Tenga en cuenta que ninguno de ellos sale del conjunto de caracteres Unicode, pero obviamente no todos son compatibles entre sí en bytes.

¿Qué haría la "validación"? ¿Hacer que su programa wasm no sea válido? No creo que haya consecuencias reales que se puedan imponer razonablemente.

Por ejemplo, usar un escape no válido en CSS solo coloca un U + FFFD en su hoja de estilo, no hace nada extraño.

@annevk :

Además, UTF-8 no es la única codificación Unicode y se puede usar para codificar enteros que no son Unicode. Entonces, UTF-8 no es Unicode.

¿Qué enteros puede codificar UTF-8 que no forman parte de Unicode (es decir, fuera del rango U + 0000 a U + 10FFFF)? Esa afirmación parece falsa.

Como mínimo: U + FFFE y U + FFFF no son caracteres en Unicode. Unicode nunca utilizará los puntos de código (los valores enteros) para codificar caracteres, pero se pueden codificar en UTF-8.

Sin embargo, siguen siendo puntos de código Unicode. No me centraría demasiado en los "personajes".

La decodificación de

Como tal, no tiene más sentido imponer Unicode en el núcleo de Wasm de lo que tendría, por ejemplo, imponer Unicode en todos los literales de cadena en el lenguaje de programación C. Solo obligaría a algunos clientes potenciales a violar esta parte del estándar. ¿Cuál es la ganancia?

Puede tener en cuenta que C11 agregó los tipos char16_t y char32_t , así como un prefijo u para literales de cadena codificados en UTF-16, un prefijo U para Literales de cadena codificados en UCS-4 y un prefijo u8 para literales de cadena codificados en UTF-8. No profundicé lo suficiente como para encontrar la razón fundamental para agregarlos, pero supongo que "lidiar con Unicode en C / C ++ estándar es una pesadilla" es al menos parte de la motivación.

@tabatkins , @sunfishcode , está bien, entonces no estás hablando de lo mismo. Pero AFAICT @jfbastien ha estado declarando explícita y repetidamente que su propuesta se trata de especificar UTF-8 sin el juego de caracteres Unicode.

Esa es también la única interpretación bajo la cual se sostiene la afirmación de bajo costo.

Porque si realmente _suponemos que UTF-8 implica Unicode, entonces este requisito ciertamente es mucho más caro que la codificación / decodificación UTF-8 para cualquier herramienta en cualquier sistema que aún no hable (un subconjunto de) Unicode - ellos Necesitaría incluir una capa de transcodificación completa.

@tabatkins , el núcleo Wasm estará integrado en sistemas preexistentes, a veces por otras razones además de la portabilidad, que no tiene poder para cambiar o imponer nada. Si enfrentan los problemas que usted describe, entonces existen independientemente de Wasm. _No_ podemos solucionar _sus_ problemas.

El resultado probable de _tratar_ de imponer Unicode a todos ellos sería que algunos potenciales simplemente violarían esa parte de la especificación, volviéndola completamente discutible (o peor, ignorarían Wasm por completo).

Si OTOH lo especificamos en una capa adecuada, entonces no corremos ese riesgo, sin perder nada en la práctica.

Porque si realmente asumimos que UTF-8 implica Unicode, entonces este requisito ciertamente es mucho más caro que la codificación / decodificación UTF-8 para cualquier herramienta en cualquier sistema que aún no hable (un subconjunto de) Unicode - ellos Necesitaría incluir una capa de transcodificación completa.

¿Qué plataformas existen que usan un juego de caracteres nativo que no es Unicode, ni ASCII, no tienen facilidades para convertir esos caracteres a / desde Unicode y necesitarían usar identificadores que no son ASCII en Wasm? (Me refiero a que realmente existe, no a una hipotética organización rusa que decida usar Wasm en DOS).

@rocallahan Creo que @ rossberg-chromium está preocupado (o al menos yo lo estaría) con dispositivos como sistemas integrados, que no querrían el costo adicional de una biblioteca ICU completa. Se verían obligados a aceptar la hinchazón, no realizar una validación completa o no aceptar archivos wasm que contengan caracteres no ascii (sobre los que es posible que no tengan control).

Además, estrictamente hablando, estos dispositivos a menudo incluyen hardware que tiene conjuntos de caracteres no estándar como:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(Que tiene un juego de caracteres ascii + latin1 + japonés mezclado tonto)
Pero la preocupación es qué estás obligado a validar, que es relevante independientemente.

@tabatkins, aunque pensé que ha indicado que la intención es:

• Exigir UTF-8 + Unicode como la única interpretación "correcta" de los bytes
• Indique explícitamente que Unicode no tiene que validar para que el módulo se valide (para ahorrar el costo)

Creo que @ rossberg-chromium está preocupado (o al menos yo lo estaría) con dispositivos como sistemas integrados, que no querrían el costo adicional de una biblioteca ICU completa. Se verían obligados a aceptar la hinchazón, no realizar una validación completa o no aceptar archivos wasm que contengan caracteres no ascii (sobre los que es posible que no tengan control).

Como se ha dicho repetidamente, esto es una pista falsa. No es necesario hacer nada relacionado con la UCI de forma remota; la web definitivamente no lo hace. Deje de difundir esta información incorrecta.

La "validación completa" es una operación extremadamente trivial, que se realiza automáticamente como parte de una operación de decodificación UTF-8 conforme.

Al conversar con @tabatkins , una cosa que creo que es crucial tener claro aquí:
Se REQUIERE un decodificador Unicode conforme para permitir combinaciones arbitrarias de modificadores, puntos de código no asignados, etc. Por lo tanto, una mezcla perdida de modificadores, etc., incluso aunque no se traduzca en algo sensato, debe ser permitida por Unicode. Un decodificador que rechaza combinaciones sin sentido no sería compatible.

Por lo tanto, el requisito de decodificar UTF-8 correctamente, tiene un alcance nítido para ser algo que puede hacer en un puñado de líneas de código, es una operación exacta y es esencialmente equivalente a especificar una interpretación unicode + utf-8 de los bytes.

Si. Analizar UTF-8 es extremadamente trivial; las únicas complicaciones son el puñado de puntos de código que no puede codificar en UTF-8, que un decodificador compatible en su lugar analizará como uno o más caracteres U + FFFD.

Pero esa es una operación que debe realizar el endpoint . Wasm no tiene que preocuparse por nada de esto; Los decodificadores compatibles pueden manejar cualquier patrón de bits arbitrario que les arroje. (Simplemente decidirán que la mayor parte de un patrón de bits basura son caracteres U + FFFD). Todo lo que he estado pidiendo, todo este tiempo, es un requisito de conformidad a nivel de autor de que estas cadenas se codifiquen con UTF-8. Si viola eso, su cadena de herramientas puede marcarlo como un error, pero no hay nada que Wasm deba hacer.

Esto es similar a, por ejemplo, CSS que define una gramática para lo que constituye una hoja de estilo válida, pero aún acepta técnicamente cualquier patrón arbitrario de bits.

Además, estrictamente hablando, estos dispositivos a menudo incluyen hardware que tiene conjuntos de caracteres no estándar como:

La existencia de tales conjuntos de caracteres es irrelevante para Wasm a menos que espere que las personas escriban identificadores Wasm en los (rangos no ASCII de) ellos.

Correcto, todos los medios de "usar UTF-8" son https://encoding.spec.whatwg.org/#utf -8-decoder. La UCI ni siquiera se acerca a un requisito.

El 25 de febrero de 2017 a las 01:13, Brad Nelson [email protected] escribió:

Al chatear con @tabatkins https://github.com/tabatkins , una cosa
que creo que es crucial tener claro aquí:
Se REQUIERE un decodificador Unicode conforme para permitir arbitrarias
combinaciones de modificadores, puntos de código no asignados, etc. Así que una mezcla extraviada de
modificadores, etc., incluso a pesar de que no se traduce en algo sensible, es
requerido para ser permitido por Unicode. Un decodificador que rechazaba tonterías
combinaciones no cumplirían.

Por lo tanto, el requisito de decodificar UTF-8 correctamente tiene un alcance nítido para ser
algo que puede hacer en un puñado de líneas de código, es una operación exacta,
y es esencialmente equivalente a especificar un unicode + utf-8
interpretación de los bytes.

Para aclarar lo que dije. No discuto que la UCI completa probablemente no sería
necesario (aunque, por ejemplo, ordenar nombres por puntos de código suena mal
usabilidad).

Sin embargo, la afirmación de que solo queda una decodificación trivial no es correcta
tampoco, porque no se detiene con la validación. Plataformas no Unicode
se vería obligado a realizar la transcodificación para manejar realmente sus cadenas.
Además, tendrían que lidiar con el problema de los personajes que
no se puede mapear (en ninguna dirección), por lo que aún tendría compatibilidad
problemas en general, simplemente pateó la lata por el camino.

>

Además, estrictamente hablando, estos dispositivos a menudo incluyen hardware que tiene
conjuntos de caracteres no estándar como:

La existencia de tales conjuntos de caracteres es irrelevante para Wasm a menos que usted
espere que las personas escriban identificadores Wasm en los (rangos no ASCII de) ellos.

@rocallahan https://github.com/rocallahan , aún deben poder
tomar Unicode arbitrario. Pero, ¿qué harían con él? Si un Wasm
implementación en una plataforma de este tipo restringida a ASCII, entonces sería
violando la especificación propuesta. (También consideraría que implica que
los caracteres no ASCII de alguien son irrelevantes a priori pueden ser culturalmente
cuestionable. Eso debería ser de ellos para decidir).

Además, tendrían que lidiar con el problema de los personajes que no se pueden mapear (en ninguna dirección), por lo que aún tendría problemas de compatibilidad en general, simplemente pateó la lata en el camino.

¿Es esta una preocupación teórica?

Y si es una preocupación razonable, debemos sopesar una vez más el (costo de ocurrencia *) de lidiar con eso con el costo de prácticamente todos los demás usuarios de Wasm en el mundo que no pueden depender de una codificación y tienen que lidiar con el El mismo infierno de codificación que tuvo que atravesar la plataforma web y, finalmente, se corrigió lo mejor que pudo.

Las plataformas que no son Unicode se verían obligadas a realizar transcodificaciones para manejar realmente sus cadenas.

Sin embargo, ¿en qué casos las cadenas de Wasm deben interoperar con las cadenas de la plataforma? Por lo que puedo decir, solo estamos hablando de la codificación de cadenas en los metadatos de Wasm, no de la codificación de cadenas manipuladas por el código del módulo real. (Si eso está mal, me disculpo ...) Entonces solo puedo pensar en algunos casos posibles en los que podría ser necesaria la interoperabilidad / transcodificación:

• Un módulo Wasm importa un identificador de plataforma
• La plataforma importa un identificador Wasm
• Puede extraer nombres de Wasm e imprimirlos o guardarlos utilizando cadenas de plataforma, por ejemplo, para volcar un seguimiento de pila.

¿Derecha?

Para los sistemas embebidos hipotéticos que no son Unicode, para los dos primeros casos, el consejo es simple: limite los identificadores importados a través del límite de la plataforma a ASCII, entonces la transcodificación requerida es trivial. Los módulos Wasm aún podrían usar nombres Unicode completos internamente y para vincularse entre sí.

Para el tercer problema: si tiene un mundo cerrado de módulos Wasm, puede limitar sus identificadores a ASCII. De lo contrario, en la práctica encontrará identificadores UTF8 y será mejor que pueda transcodificarlos, ¡y se alegrará de la especificación UTF8 obligatoria!

lo que implica que los caracteres no ASCII de alguien son irrelevantes a priori

Ese es un argumento de hombre de paja. La posición aquí es "si desea identificadores que no sean ASCII, use Unicode o implemente la transcodificación hacia / desde Unicode", y no ha atraído críticas como "culturalmente cuestionable" en otras especificaciones, AFAIK.

>

Y si es una preocupación razonable, debemos sopesar una vez más la (ocurrencia

• costo) de lidiar con eso contra el costo de prácticamente todos los demásusuario de Wasm en el mundo no puede depender de una codificación, y
  tener que lidiar con la misma codificación: el infierno de la plataforma web tuvo que pasar,
  y finalmente arreglado tan bien como pudo.

@tabatkins , no, de nuevo (y de alguna manera siento que he repetido este 100
veces ya): cada especificación de incrustación _will_ especificará una codificación y
conjunto de caracteres. En todas las plataformas puede confiar en esto. Tu solo correras
en la codificación de preguntas si trataste de interoperar entre dos
ecosistemas, que ya serán incompatibles por razones más profundas que
instrumentos de cuerda. Y esto solo afectaría la interoperabilidad con plataformas que de otro modo
excluir por completo. Así que _no pierdes nada_ pero ganas la habilidad de usar
Wasm en plataformas más diversas.

Sois ingenieros de software. Como tal, asumo que entiendes y aprecias
el valor de la modularización y la estratificación, para separar preocupaciones y maximizar
reutilizar. Eso también se aplica a las especificaciones.

>

Las plataformas que no son Unicode se verían obligadas a realizar la transcodificación para
manejar sus cuerdas.

¿En qué casos las cadenas de Wasm deben interoperar con las cadenas de la plataforma,
¿aunque? Por lo que puedo decir, solo estamos hablando de la codificación de
cadenas en los metadatos de Wasm, no la codificación de cadenas manipuladas por
código de módulo real. (Si eso está mal, me disculpo ...) Entonces solo puedo pensar
de algunos casos posibles en los que podría ser necesaria la interoperabilidad / transcodificación:

• Un módulo Wasm importa un identificador de plataforma
• La plataforma importa un identificador Wasm
• Puede extraer nombres de Wasm e imprimirlos o guardarlos usando la plataforma
  cadenas, por ejemplo, para volcar un seguimiento de pila.

¿Derecha?

Si. En otras palabras, cada vez que realmente necesite _usar_ una cadena.

Para sistemas embebidos hipotéticos que no son Unicode, para los dos primeros casos,
el consejo es simple: limite los identificadores importados a través de la plataforma
límite a ASCII, entonces la transcodificación requerida es trivial. Módulos Wasm
aún podría usar nombres Unicode completos internamente y para vincularse entre sí.

Para el tercer problema: si tiene un mundo cerrado de módulos Wasm,
puede limitar sus identificadores a ASCII. Si no, entonces en la práctica
encontrar identificadores UTF8 y será mejor que pueda transcodificarlos, y
¡Te alegrarás de la especificación UTF8 obligatoria!

¡Según la propuesta, no se le permitiría limitar nada a ASCII! Para
Permitir que la especificación principal debería ser más permisiva. Entonces estas haciendo
mi punto.

cada especificación de incrustación _will_ especificará una codificación y un juego de caracteres. En todas las plataformas puede confiar en esto. Solo se encontrará con preguntas de codificación si intenta interoperar entre dos ecosistemas no relacionados, que ya serán incompatibles por razones más profundas que las cadenas.

¿Qué pasa con las herramientas de procesamiento de Wasm, como los desmontadores? ¿No sería valioso poder escribir un desensamblador que funcione con cualquier módulo Wasm independientemente de las variantes de "especificaciones de incrustación"?

¡Según la propuesta, no se le permitiría limitar nada a ASCII!

Según la propuesta, los módulos Wasm no se limitarían a ASCII, pero si un implementador optara por definir todos sus identificadores fuera de los módulos Wasm ASCII (por ejemplo, ¡como lo hacen casi todas las bibliotecas del sistema!), Eso estaría fuera del alcance de Wasm. Especificaciones.

Si un implementador eligió imprimir solo caracteres ASCII en un seguimiento de pila y reemplazar todos los caracteres Unicode que no son ASCII con ? o similar, eso tiene que estar permitido por la especificación, ya que en la práctica siempre existen caracteres Unicode que no de todos modos no tengo una fuente.

Habiendo dicho todo eso, definir un subconjunto de Wasm en el que todos los nombres de Wasm sean ASCII sería bastante inofensivo, ya que dichos módulos de Wasm serían procesados ​​correctamente por herramientas que tratan los nombres de Wasm como UTF8.

Sois ingenieros de software. Como tal, supongo que comprende y aprecia el valor de la modularización y las capas para separar preocupaciones y maximizar la reutilización. Eso también se aplica a las especificaciones.

Sí, soy ingeniero de software. También soy ingeniero de especificaciones, por lo que entiendo el valor de la coherencia y el establecimiento de normas que hacen que el ecosistema funcione mejor. Los conjuntos de caracteres y las codificaciones son uno de los temas en los que el valor de permitir la modularización y la elección se ve ampliamente superado por el valor de la coherencia y la previsibilidad. Tenemos décadas literales de evidencia de esto. Esto es por qué sigo repitiendo a mí mismo - que está haciendo caso omiso de la historia y la recomendación de muchos expertos, varios de los cuales han aparecido en este mismo hilo, y muchos más que estoy representando las opiniones de, cuando insisten en que necesitamos Permitir la libertad en este sentido.

Después de leer todo este hilo (largo), creo que la única forma de resolver esta discusión es especificar explícitamente que la sección de nombres que estamos describiendo en formato binario y que estamos mejorando en https://github.com/WebAssembly/design/pull / 984 es una codificación UTF-8 , y yo propondría que simplemente llamemos a esa sección "nombres-utf8" . Eso hace que la codificación sea explícita, y casi con certeza todas las herramientas que quieren manipular binarios WASM en todas las plataformas relevantes hoy quieren hablar UTF-8 de todos modos. Se les podría perdonar por hablar solo en UTF-8.

Soy sensible a las preocupaciones de @ rossberg-chromium por otras plataformas y, hasta cierto punto, estoy de acuerdo. Sin embargo, esto se puede solucionar fácilmente. Como alguien sugirió anteriormente en el hilo, esos sistemas son más que bienvenidos para agregar una sección de "nombres ascii" no estándar o cualquier otra codificación que utilice su ecosistema. Con nombres explícitos, resulta obvio qué herramientas funcionan con qué secciones. Para los módulos que solo funcionan en DOS, esto resultaría obvio por la presencia de secciones específicas de DOS. En mi opinión, sería un desastre interpretar los nombres de estos binarios como si tuvieran una codificación diferente.

(Por cierto, esto se basa en historias de guerra sobre un sistema que accidentalmente perdió las codificaciones de las cadenas de contenido subido por el usuario y nunca pudo recuperarlas. El sistema sufrió una muerte espasmódica y espantosa. Literalmente, se perdieron millones de dólares .)

Incluso podríamos adoptar un estándar de nomenclatura para las secciones de nombres (je), de modo que todas sean "\

@titzer Sí, las secciones personalizadas son la solución aquí para plataformas exóticas o especializadas que no quieren tener nada que ver con UTF8. Sin embargo, dudaría en prescribir en la especificación: si una plataforma es tan específica en su modo de operación que ni siquiera puede molestarse en asignar puntos de código UTF-8 a su preferencia nativa, es posible que quieran hacerlo mucho más con secciones personalizadas que solo proporcionar nombres en su codificación preferida.

Recomiendo poner un mayor énfasis en el uso de secciones personalizadas para detalles específicos de la plataforma en la especificación, y dejar que las propias especificaciones de la plataforma definan esos detalles. Las cadenas de herramientas comunes de WASM podrían admitirlas a través de algún tipo de arquitectura de complemento.

@titzer Cambiar a utf8-names suena bien. Como beneficio adicional, suavizaría la transición ya que los navegadores podrían admitir fácilmente tanto "nombres" (en el formato antiguo) como "nombres-utf8" (en el formato # 984) para una versión o dos antes de eliminar "nombres" que a su vez elimina mucha urgencia para implementar esto.

Lo siento si esto ya se decidió arriba, pero, para ser claros: ¿hay algún cambio propuesto para los nombres de importación / exportación de lo que está en BinaryEncoding.md ahora?

utf8-names suena bien.

Misma pregunta que @lukewagner sobre importación / exportación.

@lukewagner @jfbastien Buena pregunta. No vi una decisión arriba. Creo que, sobre todo, no queremos cambiar el formato binario del que tenemos ahora. Así que en realidad son las contorsiones mentales que tenemos que atravesar para convencernos de que lo que hicimos es racional :-)

AFAICT actualmente asumimos que las cadenas en la importación / exportación son secuencias de bytes no interpretadas. Esta bien. Creo que es razonable considerar que la codificación de las cadenas utilizadas para la importación / exportación debe ser definida únicamente por el incrustador de una manera que no lo es la sección de nombres; Por ejemplo, JS siempre usa UTF-8. La sección de nombres viene con una codificación explícita en el nombre de la sección de nombres.

Versión corta: la codificación de nombres en declaraciones de importación / exportación es una propiedad del entorno de incrustación, la codificación de nombres en la sección de nombres es explícita por la cadena utilizada para identificar la sección de usuario (por ejemplo, "nombres utf8").

WDYT?

Eso está bien para mí y coincide con lo que teníamos antes de la fusión del # 984 (módulo names => utf8-names ).

Creo que la sección de nombres no es tan importante como la importación / exportación, que es donde ocurren los verdaderos problemas de compatibilidad:

• Carga una sección de nombres mojibaked y obtendrás Error.stack funky y depuración.
• Cargue una importación / exportación mojibaked y nada funciona.

No creo que esto sea realmente un cambio de formato binario, ya que las incrustaciones que todos implementamos ya asumen esto.

Me apoyaría en la recomendación de personas que conocen mejor que yo sobre este tema antes de cerrar.

Deberá decidir cómo decodificar UTF-8. ¿Reemplaza las secuencias erróneas con U + FFFD o se detiene en el primer error? Es decir, desea https://encoding.spec.whatwg.org/#utf -8-decode-without-bom o https://encoding.spec.whatwg.org/#utf -8-decode-without- nacer o fallar. De cualquier manera, la carga probablemente fallará, a menos que el recurso use U + FFFD en su nombre.

De la forma en que se describe actualmente, lanzamos una excepción si la matriz de bytes de nombre de importación / exportación no se puede decodificar como UTF-8 en una cadena JS. Después de eso, tiene una cadena JS y la búsqueda de importación se define en términos de Get .

Para verificar mi comprensión, si hiciéramos https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail, eso significaría que, después de una validación exitosa, verificar la igualdad de secuencia de punto de código sería equivalente a comprobar la igualdad de secuencia de bytes?

Si.

Después de la discusión anterior, apoyo la validación de UTF-8 para nombres de importación / exportación en la especificación principal.

Específicamente, esto sería utf-8-decode-without-bom-or-fail , e igualdad de secuencia de puntos de código (para que los motores puedan hacer la igualdad de secuencias de bytes ), por lo que los motores evitarían las partes aterradoras y costosas de Unicode y la internacionalización. Y esto es consistente con la incrustación web. Experimenté con esto y encontré la sobrecarga principal insignificante.

• Re: Las ISA de hardware son independientes de la codificación: el hardware del que estamos hablando aquí no tiene importaciones / exportaciones como tal, por lo que la analogía no se aplica directamente. El único lugar que conozco donde dicho hardware usa identificadores de secuencia de bytes de cualquier tipo, el cpuid de x86, especifica una codificación de caracteres específica: UTF-8.

• Re: estratificación: como ingenieros de software, también sabemos que la estratificación y la modularización son medios, no fines en sí mismos. Por ejemplo, podríamos descartar claramente LEB128 de la especificación principal. Eso proporcionaría más capas y modularización. Se podría decir que LEB128 está sesgado hacia los casos de uso web.

• Re: "Sistemas integrados": Un ejemplo dado es DOS, pero ¿cuál sería un ejemplo de algo que un requisito UTF-8 para los nombres de importación / exportación requeriría que un sistema DOS hiciera y que sería costoso o poco práctico para hacerlo?

• Re: Islands: WebAssembly también especifica un endianness específico, requiere soporte de punto flotante, unidades de dirección de 8 bits y toma otras decisiones, aunque hay configuraciones reales donde esas serían cargas innecesarias. WebAssembly toma decisiones como esas cuando espera que fortalezcan la plataforma común que muchas personas pueden compartir.

• Re: Estructuras de datos arbitrarias en nombres de importación / exportación: esto es teóricamente útil, pero también se puede hacer mediante la transformación de datos en cadenas. Destrozar es menos conveniente, pero no difícil. Entonces, hay una compensación allí, pero no una gran (y posiblemente, si existe una necesidad general de adjuntar metadatos a las importaciones / exportaciones, sería mejor tener un mecanismo explícito que cargar identificadores con propósitos adicionales).

• Re: compatibilidad binaria: también estoy de acuerdo con JF en que este cambio aún es factible. utf-8-decode-without-bom-or-fail no significaría ningún cambio de comportamiento silencioso, y en este momento, todos los productores de wasm conocidos mantienen su salida compatible con la incrustación web (incluso si también admiten otras incrustaciones), por lo que ' ya estás dentro de UTF-8.

Un RP que hace una propuesta específica para nombres UTF-8 ahora se publica como https://github.com/WebAssembly/design/issues/1016.

Con # 1016, esto ahora está arreglado.