encoding_rs
1.0.0
coding_rs Uma implementação das (partes não Javascript de) o padrão de codificação escrito em ferrugem.
O padrão de codificação define o conjunto compatível com a Web de codificações de caracteres, o que significa que essa caixa pode ser usada para decodificar o conteúdo da Web. O coding_rs é usado em Gecko, começando com o Firefox 56. Devido à sobreposição notável entre as codificações herdadas na web e as codificações legadas usadas nas janelas, essa caixa também pode ser útil para situações não relacionadas à Web; Veja abaixo os links para caixas adjacentes.
Além disso, o módulo mem fornece várias operações para lidar com o texto em RAM (em oposição aos dados que vêm ou indo para um limite de IO). O módulo mem é um módulo em vez de uma caixa separada devido a eficiências de detalhes da implementação interna.
Devido ao caso de uso de lagartixas, o Coding_RS suporta a decodificação e a codificação do UTF-16, além de apoiar o caso usual de uso de ferrugem de decodificação e codificação do UTF-8. Além disso, a API foi projetada para ser amigável para acomodar o lado C ++ da Gecko.
Especificamente, o coding_rs faz o seguinte:
u16 / char16_t ).u16 / char16_t ) em uma sequência de bytes em um caractere definido por padrão codificando que codifica como se os substitutos solitários tivessem sido substituídos pelo caractere de substituição antes de executar o codificação. (UTF-16 de Gecko é potencialmente inválido.)document.characterSet . Além disso, encoding_rs::mem faz o seguinte:
std::io Notavelmente, a lista de recursos acima não inclui a capacidade de embrulhar um std::io::Read , decodificá-lo no UTF-8 e apresentar o resultado via std::io::Read . O encoding_rs_io Crate fornece essa capacidade.
no_std A caixa funciona em um ambiente no_std . Por padrão, o recurso alloc , que pressupõe que um alocador esteja presente está ativado. Para um ambiente sem alocador, os recursos padrão (ou seja, alloc ) podem ser desligados. Isso torna a parte da API que retorna Vec / String / Cow Inconomable.
Para decodificar as codificações de caracteres que ocorrem em email, use o charset Crate em vez de usar esta diretamente. (Ele envolve esta caixa e adiciona a decodificação UTF-7.)
Para mapeamentos de e para os identificadores da página de código do Windows, use o caixote codepage .
Esta caixa não suporta codificações de bytes de bytes que não são necessárias pela plataforma da web, mas a caixa oem_cp faz.
Normalizar o texto no formulário de normalização do Unicode C antes de codificar o texto em uma codificação herdada minimiza caracteres não aplicáveis. O texto pode ser normalizado para o Formulário de Normalização Unicode C usando a caixa icu_normalizer .
A exceção é o Windows-1258, que depois de normalizar para a normalização do unicode, o Formulário C requer que as marcas de tom sejam decompostas para minimizar caracteres não aplicáveis. As marcas de tom vietnamita podem ser decompostas usando a caixa detone .
Tl; dr: (Apache-2.0 OR MIT) AND BSD-3-Clause para a combinação de código e dados.
Consulte o arquivo chamado Copyright.
O código não-teste que não é gerado a partir dos dados do WhatWG nesta caixa está no Apache-2.0 ou no MIT. O código de teste está em CC0.
Esta caixa contém código/dados gerados a partir de dados fornecidos pelo WhatWG. O Whatwg Upstream alterou sua licença para partes das especificações incorporadas ao código-fonte do CC0 para a cláusula BSD-3 entre a versão inicial desta caixa e a versão atual deste caixote. As lendas do licenciamento na fonte foram atualizadas para as partes do código gerado que foram alteradas desde a alteração da licença a montante.
A documentação da API gerada está disponível online.
Há um artigo longo sobre o design e os internos da caixa.
Uma camada de FFI para Coding_RS está disponível como uma caixa separada. A caixa vem com um invólucro C ++ de demonstração usando os tipos de biblioteca padrão C ++ e GSL.
As ligações para o módulo mem estão na caixa coding_c_mem.
Para o contexto de lagartixa, há um invólucro C ++ usando os tipos MFBT/XPOM.
Há um artigo sobre os invólucros C ++.
Atualmente, existem esses recursos de carga opcionais:
simd-accel Ativa a aceleração SIMD usando o recurso de biblioteca padrão portable_simd dependente noturno.
Esse é um recurso de inscrição, porque ativar esse recurso opta pelas garantias de Rust de compiladores futuros compilando código antigo (também conhecido como. "História de estabilidade").
Atualmente, isso não foi testado como uma melhoria, exceto por esses alvos, e é esperado que o recurso simd-accel divulgue a construção de outros alvos:
Se você usar ferrugem noturna, usa alvos cujo primeiro componente é um dos itens acima e está preparado para revisar sua configuração ao atualizar a ferrugem , você deve ativar esse recurso. Caso contrário, não ative esse recurso.
Usado pelo Firefox.
serde Permite o suporte para serializar e desserializar os campos de estrutura do tipo &'static Encoding usando Serde.
Não usado pelo Firefox.
fast-legacy-encodeUma opção de captura-tudo para ativar as opções de codificação mais rápidas do Legacy. Não afeta a velocidade de decodificação ou a velocidade do codificador UTF-8.
Atualmente, esta opção é equivalente a permitir as seguintes opções:
fast-hangul-encodefast-hanja-encodefast-kanji-encodefast-gb-hanzi-encodefast-big5-hanzi-encodeAdiciona 176 kb ao tamanho binário.
Não usado pelo Firefox.
fast-hangul-encodeAlterações que codificam sílabas hangul pré-compostas em Euc-KR da pesquisa binária sobre as tabelas otimizadas para decodificar para procurar por índice, fazendo com que o texto coreano codifique cerca de 4 vezes mais rápido que sem essa opção.
Adiciona 20 kb ao tamanho binário.
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
fast-hanja-encodeAlterações codificadas de hanja em euc-kr a partir de pesquisa linear sobre a tabela otimizada para decodificar a procurar por índice. Como o Hanja está praticamente ausente no texto coreano moderno, essa opção não afeta o perfoma no caso comum e faz principalmente sentido se você quiser fazer com que seu aplicativo seja uma negação de serviço de agaist resiliente por alguém que se alimenta intencionalmente muito com ele para codificar a EUC-KR.
Adiciona 40 kb ao tamanho binário.
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
fast-kanji-encode Alterações codificadas de kanji em shift_jis, euc-jp e iso-2022-jp a partir de pesquisa linear nas tabelas otimizadas para decodificar a pesquisa, fazendo com que o texto limpo japonês coda para codificações legadas 30 a 50 vezes mais rápida que, sem essa opção (cerca de 2 vezes, com less-slow-kanji-encode ).
Tem precedência sobre less-slow-kanji-encode .
Adiciona 36 kb ao tamanho binário (24 kb em comparação com o less-slow-kanji-encode ).
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
less-slow-kanji-encodeTorna Jis x 0208 Nível 1 Kanji (o kanji mais comum em shift_jis, euc-jp e ISO-2022-jp) codificam menos lento (pesquisa binária em vez de pesquisa linear), tornando as codificações de texto simples japonês às codificações legadas 14 a 23 vezes mais rápida.
Adiciona 12 kb ao tamanho binário.
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
fast-gb-hanzi-encode Alterações codificantes de hanzi nos ideógrafos unificados do CJK bloqueiam em GBK e GB18030 da pesquisa linear em uma parte que as tabelas otimizadas otimizadas, seguidas de uma pesquisa binária em outra parte da opção de decodificar as tabelas otimizadas para o otimizado. less-slow-gb-hanzi-encode ).
Tem precedência sobre o less-slow-gb-hanzi-encode .
Adiciona 36 kb ao tamanho binário (24 kb em comparação com o less-slow-gb-hanzi-encode ).
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
less-slow-gb-hanzi-encodeFaz o GB2312 Nível 1 Hanzi (o hanzi mais comum em GB18030 e GBK) codifica menos lento (pesquisa binária em vez de pesquisa linear), tornando o codificação simplificada de texto simples chinês para as codificações legadas cerca de 40 vezes mais que sem essa opção.
Adiciona 12 kb ao tamanho binário.
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
fast-big5-hanzi-encode As alterações que codificam o hanzi nos ideografias unificadas do CJK bloqueiam no BIG5 de pesquisa linear em uma parte que as tabelas otimizadas para decodificar a procurar por índice, tornando o texto liso tradicional chinês codifica o BIG5 105 a 125 vezes mais rápido que sem essa opção (cerca de 3 vezes mais rápido que com less-slow-big5-hanzi-encode ).
Tem precedência sobre less-slow-big5-hanzi-encode .
Adiciona 40 kb ao tamanho binário (20 kb em comparação com o less-slow-big5-hanzi-encode ).
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
less-slow-big5-hanzi-encodeFaz o big5 nível 1 hanzi (o hanzi mais comum no BIG5) codificar menos lento (pesquisa binária em vez de pesquisa linear), tornando o codificação tradicional de texto simples chinês ao BIG5 cerca de 36 vezes mais rápido que sem essa opção.
Adiciona 20 kb ao tamanho binário.
Não afeta a velocidade de decodificação.
Não usado pelo Firefox.
Para a decodificação para o UTF-16, o objetivo é ter um desempenho tão bom quanto o antigo UCONV de Gecko. Para decodificar para o UTF-8, o objetivo é ter um desempenho tão bom quanto a enferrujada. Esses objetivos foram alcançados.
A codificação para UTF-8 deve ser rápida. (UTF-8 a UTF-8 Encode deve ser equivalente a memcpy e UTF-16 para UTF-8 deve ser rápido.)
A velocidade é não-gol ao codificar para as codificações legadas. Por padrão, a codificação para as codificações do Legacy não deve ser otimizada para velocidade às custas do tamanho do código, desde que a submissão de formulários e a análise de URL em Gecko não se torne notavelmente muito lenta no uso do mundo real.
No interesse do tamanho binário, por padrão, o coding_rs não possui tabelas de dados específicas para codificar além de 32 bits de dados específicos de codificação para cada codificação de bytes. Portanto, os codificadores pesquisam as tabelas de dados otimizadas para decodificar. Esta é uma pesquisa linear na maioria dos casos. Como resultado, por padrão, a codificação codificada para o Legacy varia de lento para extremamente lento em relação a outras bibliotecas. Ainda assim, com cargas de trabalho realistas, isso parecia rápido o suficiente para não ser devastamente lento ao Raspberry Pi 3 (que levou um telefone para testar) nos casos de uso do codificador exposto na Web.
Consulte os recursos de carga acima para, opcionalmente, fazer com que o CJK Legacy codifique rapidamente.
Uma estrutura para medir o desempenho está disponível separadamente.
É um objetivo suportar a mais recente ferrugem estável, a mais recente ferrugem noturna e a versão de Rust usada para o Firefox todas as noites.
No momento, não há um compromisso firme em apoiar uma versão mais antiga do que o exigido pelo Firefox, e não há compromisso de tratar as mudanças de MSRV como semvermelhadas, porque essa caixa depende do cfg-if , o que não parece tratar as mudanças de MSRV como semver que a quebra de semver
A partir de 2024-11-01, o MSRV parece ser a ferrugem 1.40.0 para usar a caixa e 1,42.0 para que os testes de documentos passem sem erros sobre o alocador global. Com o recurso simd-accel , o MSRV é ainda maior.
Uma camada de compatibilidade que implementa a API de codificação de ferrugem na parte superior do coding_rs é fornecida como uma caixa separada (não pode ser carregada para Crates.io). A camada de compatibilidade foi originalmente escrita com a Assução de que o Firefox precisaria, mas atualmente não é usado no Firefox.
Para regenerar o código gerado:
https://github.com/hsivonen/encoding_c ao lado do diretório encoding_rs .https://github.com/hsivonen/codepage ao lado do diretório encoding_rs .https://github.com/whatwg/encoding ao lado do diretório encoding_rs .1d519bf8e5555cef64cf3a712485f41cd1a6a990 DO REPAÇÃO encoding . (Nota: f381389 foi a revisão da encoding usada antes da alteração da licença de repo de encoding .)encoding_rs como o diretório de trabalho, o Run python generate-encoding-data.py . usize em vez de u8 por vez). alloc (com menor superfície da API). std::simdunsafe por tipos maiores que u8 / u16 para align_to . portable_simd noturno da biblioteca padrão em vez da caixa packed_simd . Afeta apenas o recurso noturno opcional simd-accel .unsafe .rust-version à Cargo.toml .packed_simd em vez de packed_simd_2 novamente agora que as atualizações estão de volta sob o nome packed_simd . Afeta apenas o recurso noturno opcional simd-accel .build.rs . (Essa remoção deve resolver falsos positivos relatados por alguns produtos antivírus. Isso pode quebrar algumas configurações de construção que optaram por não ser as garantias da Rust contra a futura quebra de construção.)no_std .no_std (com alloc ).simd-accel .packed_simd para packed_simd_2 .cfg-if para 1.0.cfg-if atualizada para a edição 2018 sem um semver interrupção.Decoder::latin1_byte_compatible_up_to não retornar None em mais casos para tornar o método realmente útil. Embora isso possa ser argumentado como uma mudança de ruptura devido à mudança de semântica da correção de bugs, ele não quebra os chamadores que precisavam lidar com o caso None de uma maneira razoável de qualquer maneira.convert_str_to_utf16 .mem::convert_utf8_to_utf16_without_replacement .mem::utf8_latin1_up_to e mem::str_latin1_up_to .Decoder::latin1_byte_compatible_up_to .bincode (dependência do dev) para 1.0.simd para packed_simd .simd-accel (release somente readme).clippy:: dos nomes de fiapos clippy.static ao definir outro static ).is_single_byte() na Encoding .mem::decode_latin1() e mem::encode_latin1_lossy() .--features simd-accel Trabalha com compilador de canal estável para simplificar o sistema de construção do Firefox.is_foo_bidi() não tratar U+Feff (Largura zero Space in-Break AKA.is_foo_bidi() relatam true se a entrada contiver formulários de apresentações hebraicas (que são da direita para a esquerda, mas não em um bloco da direita para a esquerda).convert_utf16_to_latin1_lossy .mem afirmam que a entrada está no intervalo u+0000 ... u+00ff (inclusive).mem fornece conversões de Latin1 e UTF-16 para UTF-8, que podem lidar com o espaço de saída insuficiente. A idéia é usá-los primeiro com uma alocação arredondada para o tamanho do balde Jemalloc e fazer a pior alocação apenas se o Jemalloc arredondando fosse insuficiente como o primeiro palpite.simd-accel introduzida na versão 0.8.1 nas conversões entre UTF-16 e Latin1 no módulo mem .#[inline(never)] que não foi feita para liberação.mem para aumentar o desempenho ao converter buffers longos.mem .mem .replacement uma etiqueta da codificação de substituição. (Mudança de especificações.)Encoding::for_name() . ( Encoding::for_label(foo).unwrap() agora está próximo o suficiente após a mudança de rótulo acima.)parallel-utf8 .&'static Encoding .Encoder::has_pending_state() public.simd para 0.2.0.7F corretamente no ISO-2022-JP.Hash para Encoding .InputEmpty sobre OutputFull ao codificar com a substituição e o buffer de saída passado é muito curto ou o espaço restante no buffer de saída é muito pequeno após uma substituição.PartialEq e Eq para os tipos CoderResult , DecoderResult e EncoderResult .Encoder::encode_from_utf16 . (Devido a uma supervisão, faltava a correção que Encoder::encode_from_utf8 já tinha.)#[must_use] .parallel-utf8 ).simd-accel for usado.Encoding de const para static para tornar os referentes exclusivos entre caixas que usam as referências.Encoding FOO_INIT não referenciadas para permitir que caixas estrangeiras inicializem matrizes static com referências à Encoding de instâncias, mesmo sob as restrições de Rust que proíbem a inicialização das &'static Encoding com &'static Encoding statics de codificação estática.const para funcionar, para que o uso cruzado mantenha os referentes únicos.Cow S dos métodos não transmitidos apenas em ferrugem para codificar e decodificar.Encoding::for_bom() retorna o comprimento do nascimento.simd-accel . (Requer ferrugem noturna.)Encoder.encode_from_utf8_to_vec_without_replacement() . Adicionar Encoding.is_ascii_compatible() .
Adicionar Encoding::for_bom() .
Make == para Encoding a comparação de nomes de uso em vez da comparação de ponteiros, porque os usos das constantes de codificação em diferentes caixas resultam em diferentes endereços e a constante não pode ser transformada em estática sem quebrar outras coisas.
A versão inicial.
