Argumento para UTF-8: é muito simples. codificador e decodificador em JavaScript. Novamente, UTF-8 não é Unicode .

Argumento contra UTF-8: é sempre um pouco mais complicado do que comprimento + bytes, levando a possíveis divergências de implementação.

Novamente, UTF-8 não é Unicode.

O que você está mesmo dizendo ? Esta é uma frase sem sentido.

Acho que você está tentando dizer que não há necessidade de puxar uma biblioteca de internacionalização. Isso é verdade - exigir que as strings sejam codificadas em UTF-8 não tem nada a ver com todas as partes mais complicadas do Unicode, como a canonização. Essas são ferramentas úteis quando você está fazendo trabalho com strings que interage com humanos, mas da mesma forma que uma biblioteca trigonométrica é útil para quem faz matemática, e não é relevante para decidir como codificar inteiros.

Mas UTF-8 é literalmente uma codificação Unicode; sua declaração não tem sentido como está escrita. ^ _ ^

Mas UTF-8 é literalmente uma codificação Unicode; sua declaração não tem sentido como está escrita. ^ _ ^

Sim, estou me referindo especificamente à codificação de codepoint que UTF-8 descreve, não ao tratamento de codepoints adequado (para o propósito desta proposta, um codepoint é um inteiro opaco). Colocado em wasm-isms, UTF-8 é semelhante a var [u] int, mas mais apropriado para caracteres. Além disso, UTF-8 não é a única codificação Unicode e pode ser usado para codificar inteiros não Unicode. Portanto, UTF-8 não é Unicode.

Uma outra proposta seria olhar para pontos de código individuais e fazer algo com eles. Esta não é essa proposta.

E não haveria razão para isso. Nenhuma API da Web encontrou a necessidade de fazer uma introspecção nos pontos de código além da comparação e classificação de igualdade estrita, a menos que seja literalmente uma API i18n.

Outra opção é o comprimento do byte + UTF-8 para cada ponto de código ( @jfbastien, a menos que seja isso o que você quis dizer quando disse UTF-8 para cada byte, o que admito não fazer sentido para mim). Não acho que isso tornaria as coisas mais difíceis para um analisador primitivo que realmente não se importa, enquanto permite que uma biblioteca Unicode sofisticada pegue uma matriz de bytes, deslocamento e comprimento como entrada e retorne uma string.

Concordo com a definição de "pontos de código UTF-8", que são apenas números inteiros. A especificação binária deve deixar por isso mesmo. Embedders individuais podem definir regras em torno de pontos de código permitidos, normalização e outras nuances. As ferramentas de análise podem fornecer avisos sobre possíveis problemas de compatibilidade.

Acho que as decisões de tratamento de erros também devem ser deixadas para os incorporadores. Um sistema que acessa as funções WASM por índice em vez de nome não precisa que sejam válidas (e seria fácil pular com um prefixo de comprimento de byte).

Aqui está uma tentativa de resumir as questões subjacentes e suas razões. Correções e acréscimos são bem-vindos.

Os identificadores de importação / exportação do módulo wasm require devem ser UTF-8 válidos?

Meu entendimento dos motivos contra é:

• O processamento de importações e exportações é o caminho crítico para a inicialização do aplicativo, e há um desejo de evitar qualquer coisa que possa retardá-lo.
• O amplo invariante "a especificação do core wasm não interpreta strings". A interpretação de strings é complexa em geral, e há um desejo de encapsulá-la e ter amplos invariantes e limites sobre os quais se pode raciocinar em alto nível.
• Os decodificadores WebAssembly costumam ser sensíveis à segurança, portanto, há um desejo geral de minimizar a quantidade de código envolvida.
• Alguns produtores do WebAssembly podem querer incorporar dados arbitrários a esses identificadores, e é mais conveniente para eles codificar os dados como quiserem, em vez de mutilá-los na forma de string.

O wasm deveria recomendar o UTF-8 em áreas onde ele não é necessário?

A razão para isso seria que, mesmo que não possamos exigir, mencionar o UTF-8 pode desencorajar incompatibilidades desnecessárias entre o ecossistema.

Meu entendimento da razão contra é que mesmo a menção do UTF-8 comprometeria o encapsulamento conceitual das questões de interpretação de strings.

O wasm deve especificar UTF-8 para nomes de seção de nome?

O motivo para isso é: Todo o propósito desses nomes é ser convertido em strings para exibição, o que não é possível sem uma codificação, portanto, devemos apenas especificar UTF-8 para que as ferramentas não precisem adivinhar.

Meu entendimento do motivo contra é: Se o wasm tem outras coisas semelhantes a strings em outras áreas que não têm uma codificação designada (ou seja, importações / exportações conforme discutido acima), então, para fins de consistência, ele não deve designar codificações para quaisquer strings .

@sunfishcode fornece um bom resumo, mas quero acrescentar três pontos cruciais.

@jfbastien , seria a mais inútil de todas as alternativas restringir _sintaxe_ binária (uma codificação), mas não _semantics_ (um conjunto de caracteres) para strings. Portanto, para todos os fins práticos, UTF-8 implica Unicode. E, novamente, não se trata apenas de motores. Se você definir os nomes como Unicode, estará forçando isso em todos os ecossistemas Wasm em todos os ambientes. E isso significa que todos os ambientes devem ter algum suporte Unicode.

@tabatkins , acho que há um erro de domínio subjacente ao seu argumento. Nenhuma das strings de que estamos falando é _ voltada para o usuário_. Eles são nomes voltados para _dev_. Muitas / a maioria das linguagens de programação não suportam identificadores Unicode, nem ferramentas. Por exemplo, gdb pode lidar com identificadores de origem Unicode? Acho que não. Portanto, é bastante otimista (ou melhor, irrealista) assumir que todos os consumidores convergiram para o Unicode _neste espaço_.

E, finalmente, a discordância não é _seu_ Wasm na Web deveria assumir UTF-8, mas _onde_ especificamos isso.

Acho que há um erro de domínio subjacente ao seu argumento. Nenhuma das strings de que estamos falando é voltada para o usuário. Eles são nomes voltados para o desenvolvedor. Muitas / a maioria das linguagens de programação não suportam identificadores Unicode, nem ferramentas. Por exemplo, gdb pode lidar com identificadores de origem Unicode? Acho que não. Portanto, é bastante otimista (ou melhor, irreal) assumir que todos os consumidores convergiram para o Unicode neste espaço.

"voltado para dev" significa "voltado para o conjunto de ferramentas arbitrário", o que significa que você precisa concordar com a codificação antecipada, ou então as ferramentas terão que fazer a "detecção" de codificação (ou seja, adivinhar, o que é especialmente ruim quando aplicado a valores curtos) ou tem informações fora de banda. Devs ainda são usuários. ^ _ ^

Se você acha que muitos conjuntos de ferramentas não vão entender Unicode, então não tenho certeza porque você acha que eles entenderiam qualquer outra codificação binária arbitrária. Se essa for a sua limitação, basta especificar e exigir ASCII, que é 100% compatível em todos os lugares. Se você não está disposto a se limitar ao ASCII, então, você precisa aceitar que existe um único esquema de codificação não ASCII aceito - UTF-8.

Dizer "eh, a maioria das coisas provavelmente só oferece suporte a ASCII, mas vamos deixar os desenvolvedores colocarem o que quiserem lá para o caso " é o pior dos dois mundos.

Dizer "eh, a maioria das coisas provavelmente só oferece suporte a ASCII, mas vamos deixar os desenvolvedores colocarem o que quiserem lá para o caso" é o pior dos dois mundos.

@tabatkins , ninguém está propondo o acima. Como eu disse, a questão não é _se_, mas _onde_ definir tais questões específicas de plataforma / ambiente. Supõe-se que o Wasm possa ser incorporado na mais ampla e heterogênea gama de ambientes, alguns muito mais ricos do que outros (por exemplo, JS _não suporta identificadores Unicode). Conseqüentemente, você deseja permitir a escolha por plataforma. Portanto, ele pertence às especificações da API da plataforma, não às especificações principais.

Não há escolha a fazer, tho! Se o seu ambiente de incorporação não suporta não-ASCII, você simplesmente não usa não-ASCII em suas strings . (E se for esse o caso, você ainda precisa de garantia de codificação - UTF-16 não é compatível com ASCII, por exemplo!)

Se o seu ambiente oferece suporte não-ASCII, você precisa saber qual codificação usar e a escolha correta em todas as situações é UTF-8.

Que ambiente você está imaginando onde é uma vantagem não saber a codificação de suas strings?

Seria a mais inútil de todas as alternativas restringir a sintaxe binária (uma codificação), mas não a semântica (um conjunto de caracteres) para strings. Portanto, para todos os fins práticos, UTF-8 implica Unicode.

Não, absolutamente não. Por exemplo, é perfeitamente razoável (a) restringir simultaneamente uma string aos caracteres ASCII e (b) ditar que ela está codificada em UTF-8. Usar caracteres ASCII não implica em codificação, ou então todas as codificações seriam compatíveis com ASCII! (Por exemplo, UTF-16 não é.) Portanto, você ainda precisa especificar algo; UTF-8, sendo "compatível com ASCII", é adequado para isso.

Novamente, se você concordar em restringir esses nomes apenas para ASCII, é razoável exigir que a codificação seja US-ASCII. Se você quiser que seja possível ir além do ASCII, é razoável exigir que a codificação seja UTF-8. Exigir qualquer outra coisa ou não exigir nada (e forçar todos os consumidores a adivinhar ou usar informações fora da banda) são as únicas possibilidades irracionais.

E, novamente, não se trata apenas de motores. Se você definir os nomes como Unicode, estará forçando isso em todos os ecossistemas Wasm em todos os ambientes. E isso significa que todos os ambientes devem ter algum suporte Unicode.

Novamente, parece que você está falando sobre bibliotecas de internacionalização. O que estamos discutindo é apenas como decodificar sequências de bytes em strings; isso requer apenas conhecimento de como decodificar UTF-8, o que é extremamente trivial e extremamente rápido.

A menos que você esteja fazendo uma manipulação de string amigável, tudo que você precisa é a capacidade de comparar strings por ponto de código e, possivelmente, classificar as strings por ponto de código, nenhum dos quais requer qualquer "suporte Unicode". Isso é tudo o que a tecnologia da Web existente usa, por exemplo, e não vejo nenhuma razão para que os ambientes Wasm, em geral, precisem fazer algo mais complicado do que isso.

Sou a favor da obrigatoriedade de utf8 para All The Strings. A decodificação / codificação UTF8 pura parece uma carga de impl bem baixa (em comparação com tudo o mais) para ambientes não-web. Além disso, pelo que vi, o tempo gasto na validação de utf8 para importações / nomes será insignificante em comparação com o tempo gasto em todo o resto, então não acho que haja um argumento de desempenho aqui.

Em termos práticos, mesmo se não determinássemos o utf8 na especificação principal do wasm, você teria um mau tempo interoperando com qualquer coisa se o seu conjunto de ferramentas personalizado também não usasse utf8, a menos que você seja uma ilha total e então talvez você apenas diga "dane-se" e faça sua própria coisa não utf8 de qualquer maneira ... porque então quem se importa.

O que eu realmente gostaria de fazer, porém, é resolver # 984, que parece bloquear isso ...

@lukewagner Não acho que # 984 esteja bloqueado nisso. 😄

Acho que você está certo.

Que ambiente você está imaginando onde é uma vantagem não saber a codificação de suas strings?

@tabatkins , parece que ainda não fui claro o suficiente. Não imagino tal ambiente. No entanto, imagino um amplo espectro de ambientes com requisitos incompatíveis. Nem tudo é um subconjunto de UTF-8, por exemplo, Latin1 ainda está em uso bastante difundido. Você pode não se importar, mas não é função da especificação principal do Wasm colocar pedras desnecessárias no caminho da diversidade ambiental.

você teria um mau momento interoperando com qualquer coisa se seu conjunto de ferramentas personalizado também não usasse utf8, a menos que você seja uma ilha total

@lukewagner , eu realmente espero que o Wasm seja usado em uma variedade de "continentes" que potencialmente têm pouca sobreposição. E onde eles fazem, você pode especificar interoperabilidade (na prática, codificações de nomes provavelmente serão o menor problema para compartilhar módulos entre plataformas diferentes - são bibliotecas de host). Mesmo ilhas totais não são irrealistas, especialmente sistemas embarcados errados (que também tendem a ter pouco uso para Unicode).

Uma das partes mais difíceis de implementar um mecanismo WebAssembly não baseado em navegador é fazer as coisas funcionarem da maneira que funcionam no navegador (principalmente as partes JS). Espero que, se a codificação não for padronizada, acabaremos com um padrão de fato em que todos copiam o que é feito para o destino da web. Isso apenas resultará em ser mais difícil encontrar informações sobre como decodificar essas strings.

Pode haver valor em permitir que alguns ambientes restrinjam ainda mais o conteúdo permitido, mas não exigir UTF-8 apenas resultará em mais dificuldade.

@ MI3Guy , a contraproposta é especificar a codificação UTF-8 como parte da API JS. Portanto, se você está construindo uma incorporação de JS, ela está definida como UTF-8 de qualquer maneira e não faz diferença para você. (No entanto, também queremos permitir outras APIs de incorporação que não sejam da Web nem de JavaScript.)

Direito. Meu ponto é que se você não está fazendo uma incorporação JS, você é forçado a emular muito do que o incorporador JS faz para usar a cadeia de ferramentas WebAssembly.

Faça varuint para o número de pontos de código + UTF-8 para cada ponto de código.

Eu só gostaria de falar contra essa opção. Isso complica as coisas, não pode e não pode se aplicar a seções específicas do usuário e não oferece nenhum benefício que eu possa ver - a fim de saber o número de pontos de código em uma string UTF-8, na prática, você sempre acaba varrendo a string para codificações inválidas, então você também pode contar pontos de código enquanto estiver nisso.

Nem tudo é um subconjunto de UTF-8, por exemplo, Latin1 ainda está em uso bastante difundido. Você pode não se importar, mas não é função da especificação principal do Wasm colocar pedras desnecessárias no caminho da diversidade ambiental.

Correto; UTF-8 difere de praticamente todas as codificações, uma vez que você sai da faixa ASCII. Não tenho certeza de qual é o seu ponto com isso, tho. Na verdade, usar a codificação Latin-1 é ruim precisamente porque existem muitas outras codificações que parecem iguais, mas codificam letras diferentes . Se você tentou usar o nome "æther" em seu código Wasm e codificou-o em Latin-1, então outra pessoa (justificadamente) tentou ler o nome com um conjunto de ferramentas UTF-8 e obterá um erro de decodificação. Ou talvez a outra pessoa estivesse cometendo um erro semelhante, mas usou a codificação Windows-1250 (destinada aos idiomas da Europa Central / Oriental) - ela receberia a palavra sem sentido "ćther".

Eu realmente não tenho certeza que tipo de "diversidade" você está tentando proteger aqui. Não há literalmente nenhum benefício em usar qualquer outra codificação e muitas desvantagens. Cada caractere que você pode codificar em outra codificação está presente em Unicode e pode ser codificado em UTF-8, mas o inverso quase nunca é verdadeiro. Não há ferramentas relevantes hoje que não consigam lidar com UTF-8; a tecnologia tem literalmente duas décadas .

Eu continuo dizendo que os padrões da web resolveram essa questão anos atrás, não porque Wasm seja uma especificação da web que precisa seguir as regras da web, mas porque a codificação de texto é um problema de ecossistema com o qual quase todo mundo tem os mesmos problemas, e a web já lidou com a dor de errar, e aprendeu a fazer isso da maneira certa. Não há nenhuma virtude em errar novamente em Wasm; todo ambiente que precisa codificar texto vai direto para UTF-8 desde o início ou comete os mesmos erros e sofre a mesma dor que todos os outros sofrem e, então, eventualmente, escolhe UTF-8. (Ou, em casos raros, desenvolve um ambiente suficientemente isolado que pode padronizar em uma codificação diferente e só raramente paga o preço de se comunicar com o ambiente externo. Mas eles padronizam em uma codificação , que é o ponto de tudo isso.)

Portanto, se você está construindo uma incorporação de JS, ela está definida como UTF-8 de qualquer maneira e não faz diferença para você. (No entanto, também queremos permitir outras APIs de incorporação que não sejam da Web nem de JavaScript.)

Esse problema não tem nada a ver com a Web ou JS. Cada parte do ecossistema deseja uma codificação de texto conhecida e consistente, e há uma única que é amplamente aceita em ambientes de programação, países e linguagens: UTF-8.

Eu voto para 'Do varuint for length (in bytes) + UTF-8 for each byte'. Assumindo que não seja uma escolha controversa - praticamente toda implementação de string armazena strings como "número de unidades de código" em vez de "número de pontos de código", porque é mais simples - então não é a verdadeira questão "se a validação falhar se uma string não for UTF-8 "válido?

Como indiquei em # 970, UTF-8 inválido pode ser enviado para UTF-16, portanto, se UTF-8 inválido for permitido, o software que não deseja armazenar os bytes originais não precisa. Por outro lado, verificar se UTF-8 é válido não é difícil (embora devamos responder - sequências muito longas devem ser aceitas? Caracteres substitutos?)

No geral, estou inclinado a dizer que vamos aprovar o UTF-8. No caso estranho de alguém ter bytes que eles não podem traduzir para UTF-8 (talvez porque a codificação seja desconhecida), bytes arbitrários podem ser transliterados para UTF-8.

Eu realmente não tenho certeza que tipo de "diversidade" você está tentando proteger aqui.

@tabatkins , sim, esse parece ser o cerne do mal-entendido.

É importante perceber que WebAssembly, apesar do nome, não se limita à web. Temos muito cuidado ao defini-lo em camadas adequadas, de modo que cada camada seja o mais amplamente utilizável possível.

Mais notavelmente, seu _cerne_ não é realmente uma tecnologia da web _de modo algum_. Em vez disso, tente pensar nisso como um _ ISA virtual _. Essa abstração é útil em um amplo espectro de ambientes diferentes, desde muito ricos (a web) a muito rudimentares (sistemas incorporados), que não necessariamente têm nada a ver uns com os outros, podem ser incompatíveis e ter restrições conflitantes ( que Wasm não está em posição de mudar).

Como tal, não faz mais sentido impor Unicode em _core_ Wasm do que, digamos, impor Unicode em todos os literais de string na linguagem de programação C. Você apenas coagiria alguns clientes em potencial a violar esta parte do padrão. Qual é o ganho?

Haverá, no entanto, camadas de especificações adicionais sobre esta especificação principal que definem sua incorporação e API em ambientes _concrete_ (como JavaScript). Faz todo o sentido corrigir as codificações de string nesse nível e, por suposto, devemos fazê-lo.

PS: Um slogan que define o escopo do Wasm é que ele é uma abstração sobre hardware comum, não uma abstração sobre linguagens de programação comuns. E o hardware é agnóstico em relação a questões de software, como codificação de strings. É para isso que servem os ABIs.

@rossberg-chromium

Como tal, não faz mais sentido impor Unicode no Wasm principal do que, digamos, impor Unicode em todos os literais de string na linguagem de programação C. Você apenas coagiria alguns clientes em potencial a violar esta parte do padrão. Qual é o ganho?

Eu concordo 100%. Essa questão não é sobre Unicode, porém, é puramente sobre UTF-8, uma codificação para inteiros, sem obrigar que os inteiros sejam interpretados como Unicode.

Não entendo se concordamos com isso. Você poderia esclarecer: você está bem com UTF-8 e, se não, por quê?

@jfbastien , seria mais produtivo exigir conformidade com UTF-8 para todos os literais de string C?

Como observei anteriormente, não faz sentido para mim restringir a codificação, mas não o conjunto de caracteres. É como definir sintaxe sem semântica. Por que você faria isso? Você ganha zero em termos de interoperabilidade, mas ainda ergue obstáculos artificiais para ambientes que não usam UTF-8 (o que apenas os ambientes Unicode usam).

@jfbastien , seria mais produtivo exigir conformidade com UTF-8 para todos os literais de string C?

Eu não entendo, você pode esclarecer?

Como observei anteriormente, não faz sentido para mim restringir a codificação, mas não o conjunto de caracteres. É como definir sintaxe sem semântica. Por que você faria isso? Você ganha zero em termos de interoperabilidade, mas ainda ergue obstáculos artificiais para ambientes que não usam UTF-8 (o que apenas os ambientes Unicode usam).

Acho que é o ponto crucial da discussão.

@tabatkins mencionou precedentes exatamente para isso:

Novamente, parece que você está falando sobre bibliotecas de internacionalização. O que estamos discutindo é apenas como decodificar sequências de bytes em strings; isso requer apenas conhecimento de como decodificar UTF-8, o que é extremamente trivial e extremamente rápido.

A menos que você esteja fazendo uma manipulação de string amigável, tudo que você precisa é a capacidade de comparar strings por ponto de código e, possivelmente, classificar as strings por ponto de código, nenhum dos quais requer qualquer "suporte Unicode". Isso é tudo o que a tecnologia da Web existente usa, por exemplo, e não vejo nenhuma razão para que os ambientes Wasm, em geral, precisem fazer algo mais complicado do que isso.

Portanto, concordo: esta proposta é, em suas palavras, "definir sintaxe sem semântica". Isso é uma coisa muito comum de se fazer. Na verdade, a especificação atual de comprimento + bytes do WebAssembly já faz isso!

Eu gostaria de entender qual é o obstáculo. Eu realmente não vejo um.

É importante perceber que WebAssembly, apesar do nome, não se limita à web.

Acabei de declarar no comentário imediatamente anterior que isso não tem nada a ver com a web. Você continua tentando usar esse argumento, e isso está realmente me confundindo. O que estou dizendo não tem nada a ver com a web; Estou apenas apontando a experiência da web como um exemplo importante de lições aprendidas.

Como tal, não faz mais sentido impor Unicode no Wasm principal do que, digamos, impor Unicode em todos os literais de string na linguagem de programação C. Você apenas coagiria alguns clientes em potencial a violar esta parte do padrão. Qual é o ganho?

Você não está fazendo o ponto que você acha que você está fazendo - C tem um built-in de codificação, como strings literais usar a codificação ASCII. (Se você quiser qualquer outra coisa, terá que fazer isso manualmente escapando das sequências de bytes apropriadas.) Em C ++ mais atuais, você pode ter strings literais UTF-16 e UTF-8, e enquanto você ainda pode colocar bytes arbitrários na string com \x escapa, o \u escapa pelo menos verificar se o valor é um ponto de código válido.

Tudo isso é necessário, porque não há mapeamento inerente de caracteres para bytes . É isso que uma codificação faz . Novamente, não ter uma codificação especificada significa apenas que os usuários da linguagem, quando recebem sequências de bytes de outras partes, precisam adivinhar a codificação para transformá-los novamente em texto.

Você ganha zero em termos de interoperabilidade, mas ainda ergue obstáculos artificiais para ambientes que não usam UTF-8 (o que apenas os ambientes Unicode usam).

Você pode agradar a ponto a um ambiente em que a existência caracteres usos que não estão incluídos no Unicode? Você continua tentando defender esta posição do ponto de vista teórico de pureza / diversidade do ambiente, mas literalmente todo o ponto do Unicode é incluir todos os personagens . É o único conjunto de caracteres que pode ser um argumento remotamente confiável para isso, e quando você está usando o conjunto de caracteres Unicode, UTF-8 é a codificação universal preferida.

Que diversidade você está tentando proteger? Seria ótimo ver até mesmo um único exemplo. : /

@tabatkins :

É importante perceber que WebAssembly, apesar do nome, não é
limitado à web.

Acabei de afirmar no comentário imediatamente anterior que isso não tem nada
a ver com a web. Você continua tentando usar este argumento, e é realmente
me confundindo. O que estou dizendo não tem nada a ver com a web; Eu sou meramente
apontando para a experiência da web como um exemplo importante de lições aprendidas.

O que estou tentando enfatizar é que Wasm deve ser aplicável a tantos
plataformas possíveis, modernas ou não. Você continua discutindo desde o final feliz
do espectro onde tudo é Unicode e / ou UTF-8, e tudo
else está apenas obsoleto.

Você não está fazendo o ponto que você acha que você está fazendo - C tem um

codificação embutida, já que os literais de string usam a codificação ASCII. (Se você quiser
qualquer outra coisa que você tem que fazer manualmente, escapando do byte apropriado
sequências.) Em C ++ mais atuais, você pode ter strings UTF-16 e UTF-8
literais, e embora você ainda possa colocar bytes arbitrários na string com
\ x escapa, o \ u escapa, pelo menos, verifique se o valor é válido
codepoint.

Não, isso está incorreto. A especificação C não requer ASCII. Nem mesmo
requerem compatibilidade com ASCII. Permite fonte quase arbitrária
conjuntos de caracteres "e literais de string podem conter qualquer caractere do
definir. Não há restrições quanto à codificação, é inteiramente
definido pela implementação. Houve implementações de C rodando em
Plataformas EBCDIC, e que ainda é suportado pelo padrão atual. GCC
pode processar fontes em qualquer codificação iconv (das quais existem cerca de 140
além de UTF-8), por exemplo, UTF-16, que é popular na Ásia. C ++ não é diferente.

(Isso também deve responder à pergunta de

Tudo isso é necessário, porque não há mapeamento inerente decaracteres em bytes . É isso que uma codificação faz . Novamente, não tendo um
codificação especificada significa apenas que os usuários da linguagem, quando recebem
sequências de bytes de outras partes, tem que adivinhar a codificação para transformar
de volta ao texto.

Novamente: isto _será_ especificado de forma adequada por ambiente. Quando alguem
recebe um módulo Wasm de outra pessoa operando no mesmo ecossistema
então não há problema. Nenhum desenvolvedor de JS precisará se preocupar.

Se, no entanto, alguém está recebendo um módulo de _outro ecossistema_, então
existem muitas outras fontes de incompatibilidade com as quais se preocupar, por exemplo,
expectativas sobre API, bibliotecas integradas, etc. Ambas as partes precisarão
seja explícito sobre suas premissas de interoperabilidade de qualquer maneira. Concordando em um nome
a codificação será o menor de seus problemas.

Você ganha zero em termos de interoperabilidade, mas ainda ergue obstáculos artificiais para

ambientes que não usam UTF-8 (que apenas ambientes Unicode usam
qualquer forma).

Você pode agradar a ponto a um ambiente em que a existência usos
caracteres que não estão incluídos no Unicode? Você continua tentando defender isso
posição do ponto de vista teórico de pureza / diversidade ambiental, mas
literalmente, todo o ponto do Unicode é incluir todos ospersonagens . É o único conjunto de caracteres que pode fazer um remotamente
argumento confiável para fazer isso, e quando você estiver usando o caractere Unicode
definido, UTF-8 é a codificação universal preferida.

Que diversidade você está tentando proteger? Seria ótimo ver até
um único exemplo. : /

Por exemplo, aqui está uma lista de sistemas operacionais incorporados: https://en.wikipedia.org/wiki/
Categoria: Embedded_operating_systems
Alguns deles provavelmente usam UTF-8, outros não. Alguns podem encontrar um uso para Wasm,
provavelmente não. Mas não há benefício para nós em torná-lo menos
conveniente para eles.

Uma entrada dessa lista com a qual você provavelmente ainda está familiarizado é o DOS. Como
por mais que gostemos que morra, os sistemas DOS ainda são ativos e usam
OEM.

@jfbastien :

Portanto, concordo: esta proposta é, em suas palavras, "definir sintaxe sem
semântica ". Isso é muito comum. Na verdade, o WebAssembly
comprimento atual + especificação de bytes já faz isso!

As raras ocorrências de tal coisa de que estou ciente têm a ver com
fornecendo uma saída de emergência para o comportamento específico da implementação. Isso é
também o único caso de uso razoável. Isso não faz sentido aqui, no entanto. Se você
deseja fornecer tal saída de emergência para cordas, então por que se preocupar em exigir
UTF-8, em vez de permitir qualquer string de byte "sintaxe"? Isso é sintaxe sem
semântica como um desabilitador, não um habilitador.

Eu gostaria de entender qual é o obstáculo. Eu realmente não vejo um.
>
Que alguns clientes não podem simplesmente usar todos os valores de byte, mas têm que passar por
codificações UTF redundantes que não têm uso em seu ecossistema. Isso tudo
as ferramentas em suas cadeias de ferramentas também terão que se preocupar com isso. É isso
cria casos de erro adicionais (valores fora do intervalo) que não
caso contrário, existe para eles.

Deixe-me perguntar o contrário: qual é o benefício (em seus ecossistemas)?
Eu realmente não vejo um.

@tabatkins
Quero ter certeza de que entendi onde está a linha divisória.
Para deixar claro, você está sugerindo SOMENTE a codificação utf-8 de pontos de código, independentemente de eles serem inválidos em combinação (isso pode ser feito em 10 linhas de código).
As letras maiúsculas em negrito podem, por exemplo, ser usadas na especificação para indicar: Você está fazendo algo errado se acha que precisa de uma biblioteca de internacionalização para implementar o Wasm?

Os objetivos disso seriam:

• Certifique-se de que qualquer wasm válido que acabe na web possa pelo menos exibir caracteres de tofu para coisas inválidas.
• Incentive as ferramentas que geram wasm (mesmo em contextos fora da web) a preferir unicode a outras codificações quando precisarem ir além do ascii. (Uma pancada suave nesta direção, já que a validação total não acontece).

Perguntas?

• Existe algum perigo de que isso se torne um requisito rastejante para mais validação? Acho que minha principal preocupação neste espaço seria sempre ser um fardo irracional engolir, digamos, a UTI como uma dependência.

• Presumo que isso implique o objetivo de encorajar ativamente codificações como Latin1 que colidem com UTF-8. Ou seja, conjuntos de ferramentas que o emitem seriam incompatíveis, implementações que o aceitam de forma semelhante.

• Eu groco que a web tem historicamente problemas para unificar esse espaço devido ao uso sobreposto de bits de regiões que anteriormente eram ilhas de codificação. Por outro lado, minha impressão é que o UTF-8 configura coisas de tal forma que os custos da transição são desproporcionalmente suportados por pessoas não ASCII, e que algumas regiões têm mais preparação. Eu imagino que a transição unicode seja uma inevitabilidade prática (e quase completo). Existe algum documento / entidade centralizado que podemos apontar para que aborda como algumas das questões políticas e regionais em torno do Unicode foram resolvidas na web?

@rossberg-chromium

• Vejo a inconsistência lógica na validação de alguns aspectos de uma codificação, mas não de outros. Por outro lado, minha impressão é que utf8 é generalizado neste ponto (e que um pequeno empurrão nas ferramentas + validação tem baixo custo). O seu principal desconforto é adicionar a validação utf-8 básica às especificações, a inconsistência ou outra coisa?

Para deixar claro, você está sugerindo SOMENTE a codificação utf-8 de pontos de código, independentemente de eles serem inválidos em combinação (isso pode ser feito em 10 linhas de código).

Sim, embora eu não acredite que existam combinações inválidas; existem apenas alguns pontos de código individuais (aqueles reservados para substitutos UTF-16) que são tecnicamente inválidos para codificar como UTF-8. Dito isso, se o controle total de bytes for desejável, a codificação WTF-8 existe, mas devemos ser muito explícitos sobre "sim, queremos permitir que essas strings contenham dados arbitrários não-string nelas às vezes" como um objetivo se nós vamos por ali. O formato WTF-8 (e WTF-16) destina-se apenas a fornecer uma especificação formal para ambientes que têm restrições de compatibilidade retroativa na imposição de UTF- * de boa formação.

As letras maiúsculas em negrito podem, por exemplo, ser usadas na especificação para indicar: Você está fazendo algo errado se acha que precisa de uma biblioteca de internacionalização para implementar o Wasm?

Sim, o i18n não é obrigatório de forma alguma. O padrão do CSS é UTF-8, por exemplo, e apenas faz comparação / classificação bruta de pontos de código quando permite coisas fora do intervalo ASCII. Não há razão para Wasm ir além disso, também.

Existe algum perigo de que isso se torne um requisito rastejante para mais validação? Acho que minha principal preocupação neste espaço seria sempre ser um fardo irracional engolir, digamos, a UTI como uma dependência.

A plataforma da web nunca precisou impor validação adicional em nomes simples até agora. Minha experiência sugere que nunca será necessário.

Suponho que isso implique o objetivo de codificações encorajadoras ativamente como Latin1 que colidem com UTF-8. Ou seja, conjuntos de ferramentas que o emitem seriam incompatíveis, implementações que o aceitam de forma semelhante.

Sim, com a mudança para "dis couraging" em suas palavras. ^ _ ^ O ponto principal é que produtores e consumidores podem codificar e decodificar strings de / para sequências de bytes de maneira confiável, sem ter que adivinhar o que o outro terminal está fazendo. Isso tem sido uma dor horrível para todos os ambientes que já o encontraram, e agora há uma solução amplamente adotada para isso.

Eu groco que a web tem historicamente problemas para unificar esse espaço devido ao uso sobreposto de bits de regiões que anteriormente eram ilhas de codificação. Por outro lado, minha impressão é que o UTF-8 configura coisas de tal forma que os custos da transição são desproporcionalmente suportados por pessoas não ASCII, e que algumas regiões têm mais preparação. Eu imagino que a transição unicode seja uma inevitabilidade prática (e quase completo). Existe algum documento / entidade centralizado que podemos apontar para que aborda como algumas das questões políticas e regionais em torno do Unicode foram resolvidas na web?

Sim, definitivamente teve problemas na transição; Ainda é necessário que o HTML seja o padrão para Latin-1 devido ao back-compat, e ainda existem alguns pequenos grupos de conteúdo da web que preferem uma codificação específica do idioma (principalmente Shift-JIS, uma codificação do idioma japonês). Mas a grande maioria do mundo mudou nas últimas duas décadas, e a transição é considerada mais ou menos completa agora.

O "UTF-8 sobrecarrega os não-ASCII" tem sido um boato pernicioso, mas quase totalmente falso, por um longo tempo. A maioria dos idiomas europeus inclui a maior parte do alfabeto ASCII em primeiro lugar, então a maior parte do texto é sequências de um byte e termina menor que UTF-16. O mesmo se aplica a sistemas de escrita como o Pinyin. Os idiomas CJK ocupam principalmente a região UTF-8 de 3 bytes, mas também incluem grandes quantidades de caracteres ASCII, particularmente em linguagens de marcação ou de programação, portanto, também, em geral, consulte tamanhos codificados menores ou semelhantes para UTF-8 como para UTF-16 ou suas codificações especializadas.

É apenas para grandes quantidades de texto bruto em alfabetos CJK ou não ASCII, como o cirílico, que vemos o UTF-8 realmente ocupar mais espaço do que uma codificação especializada. Essas eram preocupações, no entanto, no início dos anos 90 , quando a capacidade do disco rígido era medida em megabytes e um pequeno aumento no tamanho dos arquivos de texto era realmente significativo. Isso não tem sido uma preocupação por quase 20 anos; a diferença de tamanho é totalmente irrelevante agora.

Em relação à "transição Unicode", isso já aconteceu de forma bastante universal. Um formato de texto que não exige a codificação UTF-8 atualmente está cometendo um erro terrível, a-histórico.

Não tenho certeza de nenhum documento específico que descreva essas coisas, mas aposto que eles existem em algum lugar. ^ _ ^

Se o objetivo é manter a especificação binária o mais pura possível, vamos remover os nomes por completo. Todas as suas referências internas são baseadas em índice, de qualquer maneira.

Em vez disso, adicione uma seção personalizada obrigatória à especificação JavaScript que requer UTF-8. Outros ambientes, como o mainframe da era soviética ao qual @rossberg-chromium está se referindo, podem definir sua própria seção personalizada. Um único arquivo WASM pode suportar ambas as plataformas, fornecendo ambas as seções customizadas. Seria relativamente simples para ferramentas personalizadas gerar uma seção ausente de uma plataforma obscura convertendo uma mais popular.

Se o objetivo é manter a especificação binária o mais pura possível, vamos remover os nomes por completo. Todas as suas referências internas são baseadas em índice, de qualquer maneira.

Isso é um retrabalho de como funciona a importação / exportação. Não está sobre a mesa e deve ser sugerido em uma edição diferente desta.

@bradnelson , AFAICS, prescrevendo uma codificação específica, mas nenhum conjunto de caracteres
combina o pior dos dois mundos: impõe custos em termos de
restrições, complexidade e sobrecarga sem nenhum benefício real em termos de
interoperabilidade. Acho que ainda estou confuso sobre qual seria o ponto.

@rossberg-chromium O principal benefício buscado aqui é aliviar as ferramentas e bibliotecas do fardo de adivinhação.

Uma vez que o principal benefício buscado aqui é aliviar as ferramentas e bibliotecas da carga de adivinhação, qualquer uma das variantes acima sendo discutidas (UTF-8 vs. WTF-8 etc.) seria melhor do que nada, porque mesmo no pior dos casos, "Tenho certeza de que não consigo transcodificar esses bytes literalmente" é melhor do que "esses bytes parecem ser windows-1252; talvez eu tente isso". A adivinhação é conhecida por ser propensa a erros, e o principal benefício buscado aqui é aliviar as ferramentas e bibliotecas do fardo da adivinhação.

@sunfishcode , como? Eu ainda estou perdida.

Portanto, aqui está um cenário concreto. Suponha que estejamos em plataformas diferentes e estou tentando passar um módulo para você. Suponha, para fins de argumentação, que minha plataforma use EBCDIC e a sua ASCII. Totalmente legítimo sob a proposta atual. Ainda assim, meu módulo será completamente inútil para você e sua cadeia de ferramentas.

Ambas as codificações são de 7 bits, então UTF-8 nem mesmo entra em cena.

Então, o que o UTF-8 traria para a mesa? Bem, eu poderia "decodificar" qualquer string desconhecida que conseguir. Mas, pelo que sei, o resultado é _apenas outro blob binário opaco_ de valores de 31 bits. Não fornece nenhuma informação. Não tenho ideia de como relacionar isso às minhas próprias cordas.

Então, por que eu me daria ao trabalho de decodificar uma string desconhecida? Bem, _Eu não_! Eu poderia muito bem trabalhar com o blob binário original de valores de 8 bits e economizar espaço e ciclos. A especificação ainda exigiria que eu gastasse ciclos para validar a codificação de forma vazia, no entanto.

Considerando tudo isso, o que o Wasm (principal) ou as ferramentas ganhariam ao adotar essa proposta em particular?

AFAICS, prescrevendo uma codificação específica, mas nenhum conjunto de caracteres
combina o pior dos dois mundos: impõe custos em termos de
restrições, complexidade e sobrecarga sem nenhum benefício real em termos de
interoperabilidade. Acho que ainda estou confuso sobre qual seria o ponto.

Definitivamente, estamos impondo um conjunto de caracteres - o conjunto de caracteres Unicode. JF estava formulando as coisas de maneira muito confusa antes, não preste atenção. Isso não significa que precisamos adicionar verificações ao Wasm para realmente aplicar isso; decodificadores são normalmente robustos o suficiente para lidar com caracteres inválidos. (A web, por exemplo, normalmente apenas os substitui por U + FFFD REPLACEMENT CHARACTER.)

Portanto, aqui está um cenário concreto. Suponha que estejamos em plataformas diferentes e estou tentando passar um módulo para você. Suponha, para fins de argumentação, que minha plataforma use EBCDIC e a sua ASCII. Totalmente legítimo sob a proposta atual. Ainda assim, meu módulo será completamente inútil para você e sua cadeia de ferramentas.

Você precisa parar de fingir que sistemas antigos de várias décadas não são apenas relevantes, mas tão relevantes que justificam a tomada de decisões que vão contra tudo o que aprendemos sobre a codificação da dor ao longo dessas mesmas décadas. Você não está ajudando ninguém com essa insistência de que o Web Assembly se contorce para maximizar a conveniência ao conversar com mainframes antigos, enquanto ignora o benefício de todas as outras pessoas no mundo serem capazes de comunicar dados textuais de maneira confiável. Você só vai prejudicar a linguagem e tornar 99,9% (uma estimativa muito conservadora) da vida dos usuários mais difícil.

Muitos sistemas diferentes passaram por toda essa bagunça. As guerras de codificação não eram divertidas; eles desperdiçaram muito dinheiro e muito tempo e resultaram em muito texto corrompido. Terminamos essas guerras, tho. O Unicode foi criado, promulgado e se tornou o conjunto de caracteres dominante em todo o mundo, a ponto de todos os outros conjuntos de caracteres serem literalmente nada mais do que curiosidades históricas neste ponto. Ainda temos brigas ferozes de baixo nível sobre se devemos usar UTF-16 versus UTF-8, mas pelo menos esses dois são geralmente fáceis de distinguir (veja o BOM ou procure uma preponderância de bytes nulos) e UTF geral -8 domina facilmente.

Sua insistência em codificar a liberdade ignora toda essa história, todas as lições aprendidas nas duas décadas desde que o Unicode foi introduzido. Ele ignora toda a experiência e conhecimento adquiridos no projeto de sistemas modernos, que tiveram o efeito de tornar os problemas de codificação invisíveis para a maioria dos usuários, porque os sistemas podem contar com tudo sendo codificado de uma maneira particular. Você criará problemas sérios, perniciosos e caros se persistir nisso, um mojibake de cada vez.

@rossberg-chromium

Portanto, aqui está um cenário concreto. Suponha que estejamos em plataformas diferentes e estou tentando passar um módulo para você. Suponha, para fins de argumentação, que minha plataforma use EBCDIC e a sua ASCII. Totalmente legítimo sob a proposta atual. Ainda assim, meu módulo será completamente inútil para você e sua cadeia de ferramentas.

Então, o que o UTF-8 traria para a mesa? Bem, eu poderia "decodificar" qualquer string desconhecida que conseguir. Mas, pelo que sei, o resultado é apenas outro blob binário opaco de valores de 31 bits. Não fornece nenhuma informação. Não tenho ideia de como relacionar isso às minhas próprias cordas.

UTF-8 diria exatamente como relacioná-lo com suas próprias strings. Esse é exatamente o problema que ele resolve. (O WTF-8 também faria isso quando pudesse e diria sem ambigüidade quando não pudesse.)

Você quer dizer uma estrutura de dados arbitrária mutilada em forma de string e, em seguida, codificada como UTF-8? É verdade que você não seria capaz de decifrá-lo, mas poderia pelo menos exibir sem ambigüidade o nome mutilado como uma string, o que é uma melhoria em relação a não ter nada para alguns casos de uso.

Você quer dizer a discussão acima sobre o uso de UTF-8 como uma codificação de inteiros opacos e não Unicode? Acho que a discussão ficou um pouco confusa. É tentador chamar a codificação de "sintaxe" e a internacionalização de "semântica", mas isso obscurece uma distinção útil: o UTF-8 ainda pode dizer que uma certa sequência de bytes significa "Ö" sem dizer o que os consumidores têm a ver com essa informação. Usado dessa forma, é uma codificação de Unicode, mas não requer o tipo de custo que "Suporte a Unicode" foi usado para sugerir acima.

Então, por que eu me daria ao trabalho de decodificar uma string desconhecida? Bem, eu não faria isso! Eu poderia muito bem trabalhar com o blob binário original de valores de 8 bits e economizar espaço e ciclos. A especificação ainda exigiria que eu gastasse ciclos para validar a codificação de forma vazia, no entanto.

Agora eu construí um SpiderMonkey com validação UTF-8 completa de identificadores de importação / exportação wasm, incluindo overlong e surrogates. Não consegui detectar uma diferença de desempenho em WebAssembly.validate , seja no AngryBots ou em um pequeno caso de teste compilado em emscripten que, no entanto, tem 30 importações.

A especificação é um compromisso entre várias preocupações. Agradeço a preocupação com o tempo de inicialização, então agora conduzi alguns experimentos e o medi. Eu encorajo outros a fazerem seus próprios experimentos.

Além disso, UTF-8 não é a única codificação Unicode e pode ser usado para codificar inteiros não Unicode. Portanto, UTF-8 não é Unicode.

Quais inteiros podem ser codificados em UTF-8 que não fazem parte do Unicode (ou seja, fora do intervalo U + 0000 a U + 10FFFF)? Essa afirmação parece falsa.

Se você não validar seus caracteres, poderá codificar qualquer número inteiro de 21 bits.

Não tenho certeza porque não validaríamos ...

@flagxor https://encoding.spec.whatwg.org/ descreve as várias codificações expostas na web. Observe que nenhum deles sai do conjunto de caracteres Unicode, mas obviamente não são todos compatíveis com bytes uns com os outros.

O que a "validação" faria? Tornar seu programa wasm inválido? Não acho que haja consequências reais que possam ser razoavelmente impostas.

Por exemplo, usar um escape inválido em CSS apenas coloca um U + FFFD em sua folha de estilo, não faz nada de estranho.

@annevk :

Além disso, UTF-8 não é a única codificação Unicode e pode ser usado para codificar inteiros não Unicode. Portanto, UTF-8 não é Unicode.

Quais inteiros podem ser codificados em UTF-8 que não fazem parte do Unicode (ou seja, fora do intervalo U + 0000 a U + 10FFFF)? Essa afirmação parece falsa.

No mínimo: U + FFFE e U + FFFF são não caracteres em Unicode. Os pontos de código (os valores inteiros) nunca serão usados ​​pelo Unicode para codificar caracteres, mas podem ser codificados em UTF-8.

Eles ainda são pontos de código Unicode. Eu não me concentraria muito em "personagens".

A decodificação do

Como tal, não faz mais sentido impor Unicode no Wasm principal do que, digamos, impor Unicode em todos os literais de string na linguagem de programação C. Você apenas coagiria alguns clientes em potencial a violar esta parte do padrão. Qual é o ganho?

Você pode notar que C11 adicionou char16_t e char32_t tipos, bem como um prefixo u para literais de string codificados em UTF-16, um prefixo U para Literais de string codificados em UCS-4 e um prefixo u8 para literais de string codificados em UTF-8. Não cavei fundo o suficiente para encontrar a justificativa para adicioná-los, mas presumo que "lidar com Unicode em C / C ++ padrão é um pesadelo" é pelo menos parte da motivação.

@tabatkins , @sunfishcode , ok, então você não está falando sobre a mesma coisa. Mas AFAICT @jfbastien tem declarado explícita e repetidamente que sua proposta é sobre especificar UTF-8 sem o conjunto de caracteres Unicode.

Essa também é a única interpretação sob a qual a alegação de baixo custo se mantém.

Porque se nós realmente _do_ assumirmos que UTF-8 implica Unicode, então esse requisito certamente é muito mais caro do que apenas codificação / decodificação UTF-8 para qualquer ferramenta em qualquer sistema que ainda não fale (um subconjunto de) Unicode - eles precisaria incluir uma camada de transcodificação completa.

@tabatkins , o core Wasm será embutido em sistemas pré-existentes - às vezes por outras razões além da portabilidade - que não tem poder para alterar ou impor nada. Se eles enfrentam os problemas que você descreve, eles existem independentemente de Wasm. _Nós_ não podemos consertar _seus_ problemas.

O resultado provável de _tentar_ impor o Unicode a todos eles seria que alguns deles simplesmente violariam essa parte da especificação, tornando-a inteiramente discutível (ou pior, eles desconsiderariam Wasm por completo).

Se o OTOH o especificarmos em uma camada adequada, não corremos esse risco - sem perder nada na prática.

Porque se realmente assumirmos que UTF-8 implica Unicode, então esse requisito certamente é muito mais caro do que apenas codificação / decodificação UTF-8 para qualquer ferramenta em qualquer sistema que ainda não fale (um subconjunto de) Unicode - eles precisaria incluir uma camada de transcodificação completa.

Quais plataformas existem que usam um conjunto de caracteres nativos que não é Unicode, não ASCII, não têm recursos para converter esses caracteres de / para Unicode e precisariam usar identificadores não ASCII no Wasm? (Quero dizer, realmente existe, não alguma organização russa hipotética que decide usar Wasm no DOS.)

@rocallahan Eu acredito que @rossberg-chromium está preocupado (ou pelo menos eu estaria) com dispositivos como sistemas embarcados, que não iriam querer o custo adicional de uma biblioteca de UTI completa. Eles seriam forçados a aceitar o inchaço, não fazer a validação completa ou não aceitar arquivos wasm contendo caracteres não ASCII (sobre os quais eles podem não ter controle).

Além disso, estritamente falando, esses dispositivos geralmente incluem hardware que tem conjuntos de caracteres não padrão, 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 tem um conjunto de caracteres mistos ascii + latin1 + japonês pateta)
Mas a preocupação é o que você é obrigado a validar, o que é relevante de qualquer maneira.

Embora eu ache que

• Exigir UTF-8 + Unicode como a única interpretação "correta" dos bytes
• Afirme explicitamente que o Unicode não tem que validar para o módulo validar (para economizar o custo)

Eu acredito que @rossberg-chromium está preocupado (ou pelo menos eu estaria) com dispositivos como sistemas embarcados, que não iriam querer o custo adicional de uma biblioteca de UTI completa. Eles seriam forçados a aceitar o inchaço, não fazer a validação completa ou não aceitar arquivos wasm contendo caracteres não ASCII (sobre os quais eles podem não ter controle).

Como afirmado repetidamente, isso é uma pista falsa. Não há necessidade de fazer nada relacionado à UTI remotamente; a web definitivamente não faz isso. Por favor, pare de espalhar esta informação incorreta.

A "validação total" é uma operação extremamente trivial, feita automaticamente como parte de uma operação de decodificação UTF-8 em conformidade.

No bate-papo com @tabatkins , uma coisa que eu acho que é crucial deixar claro aqui:
Um decodificador Unicode em conformidade é NECESSÁRIO para permitir combinações arbitrárias de modificadores, pontos de código não alocados, etc. Portanto, uma mistura perdida de modificadores etc., mesmo que não seja convertido em algo sensato, deve ser permitida pelo Unicode. Um decodificador que rejeitasse combinações sem sentido seria incompatível.

Portanto, o requisito para decodificar corretamente o UTF-8 tem um escopo definido para ser algo que você pode fazer em um punhado de linhas de código, é uma operação exata e é essencialmente equivalente a especificar uma interpretação unicode + utf-8 dos bytes.

sim. Analisar UTF-8 é extremamente trivial; as únicas complicações são o punhado de pontos de código que você não tem permissão para codificar em UTF-8, que um decodificador compatível irá analisar como um ou mais caracteres U + FFFD.

Mas essa é uma operação que o endpoint deve fazer. Wasm não precisa se preocupar com nada disso; decodificadores compatíveis podem lidar com qualquer padrão de bits arbitrário que você jogue com eles. (Eles apenas decidirão que a maior parte do padrão de bits de lixo são caracteres U + FFFD.) Tudo o que venho pedindo, todo esse tempo, é um requisito de conformidade em nível de autor para que essas strings sejam codificadas com UTF-8. Se você violar isso, seu conjunto de ferramentas pode sinalizar como um erro, mas não há nada que o próprio Wasm precise fazer.

Isso é semelhante a, por exemplo, CSS definir uma gramática para o que constitui uma folha de estilo válida, mas ainda aceitar tecnicamente qualquer padrão arbitrário de bits.

Além disso, estritamente falando, esses dispositivos geralmente incluem hardware que tem conjuntos de caracteres não padrão, como:

A existência de tais conjuntos de caracteres é irrelevante para o Wasm, a menos que você espere que as pessoas escrevam identificadores do Wasm (intervalos não ASCII) deles.

Certo, todos os meios de "usar UTF-8" são https://encoding.spec.whatwg.org/#utf -8-decoder. A UTI não chega nem perto de ser uma exigência.

Em 25 de fevereiro de 2017 às 01:13, Brad Nelson [email protected] escreveu:

Ao conversar com @tabatkins https://github.com/tabatkins , uma coisa
que eu acho que é crucial deixar claro aqui:
Um decodificador Unicode em conformidade é NECESSÁRIO para permitir
combinações de modificadores, pontos de código não alocados, etc. Portanto, uma mistura perdida de
modificadores etc, mesmo que não renderize em algo sensato, é
requerido para ser permitido pelo Unicode. Um decodificador que rejeitava absurdos
as combinações não seriam compatíveis.

Portanto, o requisito para decodificar corretamente UTF-8 tem um escopo definido para ser
algo que você pode fazer em um punhado de linhas de código, é uma operação exata,
e é essencialmente equivalente a especificar um unicode + utf-8
interpretação dos bytes.

Para esclarecer o que eu disse. Eu não contesto que a UTI cheia provavelmente não seria
necessário (embora, por exemplo, classificar os nomes por pontos de código soe mal
usabilidade).

No entanto, a alegação de que apenas a decodificação trivial permanece não é correta
também, porque não para com a validação. Plataformas não Unicode
seriam forçados a realizar a transcodificação para realmente lidar com suas strings.
Além disso, eles teriam que lidar com o problema dos personagens que
não pode ser mapeado (em nenhuma direção), então você ainda terá compatibilidade
questões em geral, apenas chutou a lata no caminho.

>

Além disso, estritamente falando, esses dispositivos muitas vezes incluem hardware que tem
conjuntos de caracteres não padrão como:

A existência de tais conjuntos de caracteres é irrelevante para Wasm, a menos que você
espera que as pessoas escrevam identificadores Wasm nos (intervalos não ASCII deles).

@rocallahan https://github.com/rocallahan , eles ainda devem ser capazes de
aceitar Unicode arbitrário. Mas o que eles fariam com isso? Se um Wasm
implementação em tal plataforma restrita a ASCII, então seria
violando a especificação proposta. (Eu também consideraria isso implicando que
os caracteres não ASCII de alguém são irrelevantes a priori podem ser culturalmente
questionável. Isso deve ser decidido por eles.)

Além disso, eles teriam que lidar com o problema de personagens que não podem ser mapeados (em qualquer direção), então você ainda teria problemas de compatibilidade em geral, bastando chutar a lata no caminho.

Esta é uma preocupação teórica?

E se for uma preocupação razoável, devemos mais uma vez pesar o (custo de ocorrência *) de lidar com isso contra o custo de praticamente todos os outros usuários do Wasm no mundo não sendo capazes de depender de uma codificação, e tendo que lidar com o mesma codificação - inferno que a plataforma da web teve que passar e, eventualmente, consertou o melhor que pôde.

As plataformas não Unicode seriam forçadas a realizar a transcodificação para realmente lidar com suas strings.

Em que casos as strings Wasm precisam interoperar com as strings da plataforma? Pelo que posso dizer, estamos falando apenas sobre a codificação de strings nos metadados Wasm, não a codificação de strings manipuladas pelo código do módulo real. (Se estiver errado, peço desculpas ...) Então, só consigo pensar em alguns casos possíveis em que a interoperabilidade / transcodificação pode ser necessária:

• Um módulo Wasm importa um identificador de plataforma
• A plataforma importa um identificador Wasm
• Você pode extrair os nomes do Wasm e imprimi-los ou salvá-los usando strings de plataforma, por exemplo, para despejar um rastreamento de pilha.

Direito?

Para sistemas embarcados não Unicode hipotéticos, para os primeiros dois casos, o conselho é simples: limite os identificadores importados através do limite da plataforma para ASCII, então a transcodificação necessária é trivial. Módulos Wasm ainda podem usar nomes Unicode completos internamente e para vincular uns aos outros.

Para o terceiro problema --- se você tiver um mundo fechado de módulos Wasm, você pode limitar seus identificadores para ASCII. Se não, então na prática você encontrará identificadores UTF8 e é melhor você ser capaz de transcodificá-los, e você ficará satisfeito com a especificação UTF8!

implicando que os caracteres não ASCII de alguém são irrelevantes a priori

Esse é um argumento de espantalho. A posição aqui é "se você quiser identificadores não ASCII, use Unicode ou implemente a transcodificação de / para Unicode" e não atraiu críticas como "culturalmente questionável" em outras especificações, AFAIK.

>

E se for uma preocupação razoável, devemos mais uma vez pesar a (ocorrência

• custo) de lidar com isso contra o custo de praticamente todos os outrosusuário do Wasm no mundo não podendo depender de uma codificação, e
  tendo que lidar com o mesmo inferno de codificação que a plataforma da web teve que passar,
  e, eventualmente, consertado da melhor maneira possível.

@tabatkins , não, de novo (e de alguma forma eu sinto que repeti 100
vezes): cada especificação de incorporação _will_ especificará uma codificação e
conjunto de caracteres. Em todas as plataformas, você pode confiar nisso. Você só correria
em questões de codificação, se você tentou interoperar entre dois não relacionados
ecossistemas - que já serão incompatíveis por razões mais profundas do que
cordas. E isso afetaria apenas a interoperabilidade com plataformas que, de outra forma,
excluir inteiramente. Então você _não perde nada_, mas ganha a capacidade de usar
Wasm em plataformas mais diversas.

Vocês são engenheiros de software. Como tal, suponho que você entenda e aprecie
o valor da modularização e da disposição em camadas, para separar as preocupações e maximizar
reuso. Isso também se aplica às especificações.

>

As plataformas não Unicode seriam forçadas a realizar a transcodificação para realmente
lidar com suas cordas.

Em quais casos as strings Wasm precisam interoperar com as strings da plataforma,
no entanto? Pelo que eu posso dizer, estamos falando apenas sobre a codificação de
strings nos metadados Wasm, não a codificação de strings manipuladas por
código do módulo real. (Se estiver errado, peço desculpas ...) Então eu só posso pensar
de alguns casos possíveis em que a interoperabilidade / transcodificação pode ser necessária:

• Um módulo Wasm importa um identificador de plataforma
• A plataforma importa um identificador Wasm
• Você deve extrair os nomes do Wasm e imprimi-los ou salvá-los usando a plataforma
  strings, por exemplo, para despejar um rastreamento de pilha.

Direito?

sim. Em outras palavras, toda vez que você realmente precisa _usar_ uma string.

Para sistemas embarcados não-Unicode hipotéticos, para os primeiros dois casos,
o conselho é simples: limite os identificadores importados pela plataforma
limite para ASCII, então a transcodificação necessária é trivial. Módulos Wasm
ainda pode usar nomes Unicode completos internamente e para vincular uns aos outros.

Para o terceiro problema --- se você tem um mundo fechado de módulos Wasm, você
podem limitar seus identificadores a ASCII. Se não, então na prática você
encontrar identificadores UTF8 e é melhor você ser capaz de transcodificá-los, e
você ficará satisfeito com a especificação UTF8 obrigatória!

De acordo com a proposta, você não teria permissão para limitar nada a ASCII! Para
permitir que a especificação principal precisaria ser mais permitida. Então você está fazendo
meu ponto.

cada especificação de incorporação _will_ especificará uma codificação e um conjunto de caracteres. Em todas as plataformas, você pode confiar nisso. Você só se depararia com questões de codificação se tentasse interoperar entre dois ecossistemas não relacionados - que já são incompatíveis por razões mais profundas do que strings.

E as ferramentas de processamento do Wasm, como desmontadores? Não seria valioso poder escrever um desmontador que funcionasse com qualquer módulo Wasm, independentemente das variantes de "especificação de incorporação"?

De acordo com a proposta, você não teria permissão para limitar nada a ASCII!

De acordo com a proposta, os módulos Wasm não seriam limitados a ASCII, mas se um implementador escolher fazer todos os seus identificadores definidos fora dos módulos Wasm ASCII (por exemplo, como quase todas as bibliotecas do sistema realmente fazem!), Isso estaria fora do escopo do Wasm spec.

Se um implementador optou por imprimir apenas caracteres ASCII em um rastreamento de pilha e substituir todos os caracteres Unicode não ASCII por ? ou similar, isso deve ser permitido pela especificação, já que na prática sempre existem caracteres Unicode que você usa não tem uma fonte de qualquer maneira.

Tendo dito tudo isso, definir um subconjunto de Wasm em que todos os nomes de Wasm são ASCII seria bastante inofensivo, uma vez que tais módulos de Wasm seriam processados ​​corretamente por ferramentas que tratam nomes de Wasm como UTF8.

Vocês são engenheiros de software. Como tal, suponho que você compreenda e aprecie o valor da modularização e da disposição em camadas, para separar interesses e maximizar a reutilização. Isso também se aplica às especificações.

Sim, sou engenheiro de software. Também sou um engenheiro de especificações, então entendo o valor da consistência e do estabelecimento de normas que fazem o ecossistema funcionar melhor. Conjuntos de caracteres e codificações são um dos assuntos em que o valor de permitir a modularização e a escolha é amplamente superado pelo valor da consistência e previsibilidade. Temos décadas literais de evidências disso. É por isso que continuo me repetindo - você está ignorando a história e as recomendações de muitos especialistas, vários dos quais apareceram neste tópico, e muitos mais dos quais estou representando as opiniões, quando você insiste que precisamos permitir liberdade a este respeito.

Depois de ler todo este (longo) tópico, acho que a única maneira de resolver essa discussão é especificar explicitamente que a seção de nomes que estamos descrevendo no formato binário e que está sendo aprimorada em https://github.com/WebAssembly/design/pull / 984 é uma codificação UTF-8 , e eu proporia que simplesmente chamássemos essa seção de "nomes-utf8" . Isso torna a codificação explícita e quase certamente todas as ferramentas que desejam manipular binários WASM em todas as plataformas relevantes hoje em dia desejam falar UTF-8 de qualquer maneira. Eles poderiam ser perdoados por falar apenas UTF-8.

Estou ciente das preocupações de @rossberg-chromium com outras plataformas e, até certo ponto, concordo. No entanto, isso pode ser facilmente corrigido. Como alguém sugeriu anteriormente no tópico, esses sistemas são mais do que bem-vindos para adicionar uma seção "nomes ascii" não padrão ou qualquer outra codificação que seu ecossistema use. Com nomes explícitos, fica óbvio quais ferramentas funcionam com quais seções. Para módulos que funcionam apenas no DOS, isso se tornaria óbvio pela presença de seções específicas do DOS. IMO, seria um desastre interpretar os nomes desses binários como tendo uma codificação diferente.

(A propósito, isso é informado por histórias de guerra sobre um sistema que acidentalmente perdeu as codificações das strings do conteúdo enviado pelo usuário e nunca poderia recuperá-las. O sistema teve uma morte horrível e espasmódica. Literalmente, milhões de dólares foram perdidos .)

Poderíamos até adotar um padrão de nomenclatura para as seções de nomes (heh), de modo que todas sejam "\

@titzer Sim, seções personalizadas são a solução aqui para plataformas exóticas ou especializadas que não querem ter nada a ver com UTF8. Eu hesitaria em prescrever na especificação, no entanto: se uma plataforma é tão específica em seu modo de operação que nem mesmo se dá ao trabalho de mapear pontos de código UTF-8 para sua preferência nativa, eles podem querer fazer muito mais com seções personalizadas do que apenas fornecer nomes em sua codificação preferida.

Eu recomendo colocar uma ênfase maior no uso de seções personalizadas para detalhes específicos da plataforma na especificação e deixar que as próprias especificações da plataforma definam esses detalhes. Conjuntos de ferramentas WASM comuns podem suportá-los por meio de algum tipo de arquitetura de plug-in.

@titzer Mudar para utf8-names parece bom. Como um bônus, isso suavizaria a transição, já que os navegadores poderiam facilmente oferecer suporte a "nomes" (no formato antigo) e "nomes-utf8" (no formato # 984) para um ou dois lançamentos antes de descartar "nomes" que por sua vez remove muita urgência para implementá-lo.

Desculpe se isso já foi decidido acima, mas, para ser claro: há alguma alteração proposta para os nomes de importação / exportação do que está em BinaryEncoding.md agora?

utf8-names parece bom.

Mesma pergunta que @lukewagner na importação / exportação.

@lukewagner @jfbastien Boa pergunta. Eu não vi uma decisão acima. Acho que acima de tudo não queremos mudar o formato binário que temos agora. Então, na verdade, são todas as contorções mentais que temos que passar para nos convencer de que o que fizemos é racional :-)

AFAICT, atualmente assumimos que as strings em importação / exportação são sequências de bytes não interpretadas. Isso é bom. Acho que é razoável considerar a codificação de strings usadas para importação / exportação como definida exclusivamente pelo incorporador de uma forma que a seção de nomes não é; Por exemplo, JS sempre usa UTF-8. A seção de nomes vem com uma codificação explícita na seção de nomes.

Versão resumida: a codificação de nomes em declarações de importação / exportação é uma propriedade do ambiente de incorporação, a codificação de nomes na seção de nomes é explícita pela string usada para identificar a seção do usuário (por exemplo, "utf8-nomes").

WDYT?

Isso está bom para mim e corresponde ao que tínhamos antes de # 984 mesclar (módulo names => utf8-names ).

Acho que a seção de nomes não é tão importante quanto importar / exportar, que é onde ocorrem os verdadeiros problemas de compatibilidade:

• Carregue uma seção de nomes com mojibak e você obterá Error.stack e depuração funky.
• Carregue uma importação / exportação com mojibak e nada funciona.

Não acho que seja realmente uma mudança de formato binário, uma vez que os embeddings que todos implementamos já assumem isso.

Eu me apoiaria na recomendação de pessoas que sabem melhor do que eu sobre este assunto antes de encerrar.

Você precisará decidir como decodificará UTF-8. Você substitui sequências erradas por U + FFFD ou interrompe no primeiro erro? Ou seja, você quer https://encoding.spec.whatwg.org/#utf -8-decode-without-bom ou https://encoding.spec.whatwg.org/#utf -8-decode-without- bom ou falha. De qualquer forma, o carregamento provavelmente falhará, a menos que o recurso use U + FFFD em seu nome.

Da maneira como está atualmente descrito, lançamos uma exceção se a matriz de bytes do nome de importação / exportação não for decodificada como UTF-8 em uma string JS. Depois disso, você tem uma string JS e a pesquisa de importação é definida em termos de Get .

Para verificar meu entendimento, se fizéssemos https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail, isso significaria que, após a validação bem-sucedida, verificar a igualdade de sequência de pontos de código seria equivalente a verificar a igualdade de seqüência de bytes?

sim.

Após a discussão acima, apóio a validação de UTF-8 para nomes de importação / exportação na especificação principal.

Especificamente, isso seria utf-8-decode-without-bom-or-fail e igualdade de sequência de ponto de código (para que os mecanismos possam fazer igualdade de sequência de bytes ), os mecanismos evitariam as partes assustadoras e caras do Unicode e da internacionalização. E, isso é consistente com a incorporação da Web. Eu experimentei isso e descobri que a sobrecarga principal é insignificante.

• Re: Hardware ISAs são agnósticos quanto à codificação: o hardware do qual estamos falando aqui não tem importações / exportações como tal, então a analogia não se aplica diretamente. O único lugar que conheço onde tal hardware usa identificadores de sequência de bytes de qualquer tipo, o cpuid do x86, especifica uma codificação de caractere específica: UTF-8.

• Re: Camadas: Como engenheiros de software, também sabemos que as camadas e a modularização são meios, não fins em si mesmas. Por exemplo, poderíamos fatorar claramente o LEB128 da especificação principal. Isso proporcionaria maior disposição em camadas e modularização. LEB128 é indiscutivelmente inclinado para casos de uso da web.

• Re: "Sistemas incorporados": um exemplo dado é o DOS, mas o que seria um exemplo de algo que um requisito UTF-8 para importar / exportar nomes exigiria que um sistema DOS fizesse e que seria caro ou impraticável para fazer?

• Re: Islands: WebAssembly também especifica um endianness específico, requer suporte de ponto flutuante, unidades de endereço de 8 bits e faz outras escolhas, embora existam configurações reais onde essas seriam cargas desnecessárias. O WebAssembly faz escolhas como essas quando espera que elas fortaleçam a plataforma comum que muitas pessoas podem compartilhar.

• Re: Estruturas de dados arbitrárias em nomes de importação / exportação: isso é teoricamente útil, mas também pode ser feito por meio da transformação de dados em strings. A mutilação é menos conveniente, mas não difícil. Portanto, há uma compensação aí, mas não uma grande (e, sem dúvida, se houver uma necessidade geral de anexar metadados a importações / exportações, seria melhor ter um mecanismo explícito do que sobrecarregar identificadores com finalidades adicionais).

• Re: Compatibilidade binária: também concordo com JF que essa mudança ainda é viável. utf-8-decode-without-bom-or-fail significaria nenhuma mudança silenciosa de comportamento e, neste momento, todos os produtores wasm conhecidos mantêm sua saída compatível com a incorporação da Web (mesmo que também suportem outras incorporações), então eles ' já estou dentro do UTF-8.

Um PR fazendo uma proposta específica para nomes UTF-8 agora está postado como https://github.com/WebAssembly/design/issues/1016.

Com o # 1016, isso foi corrigido.