encoding_rs
1.0.0
Encoding_rs une implémentation des (parties non javascriptales de) la norme d'encodage écrite en rouille.
La norme d'encodage définit l'ensemble de codages de caractères compatibles Web, ce qui signifie que cette caisse peut être utilisée pour décoder le contenu Web. Encoding_RS est utilisé dans Gecko en commençant par Firefox 56. En raison du chevauchement notable entre les encodages hérités sur le Web et les encodages hérités utilisés sur Windows, cette caisse peut également être utilisée pour des situations non liées au WEB; Voir ci-dessous pour les liens vers des caisses adjacentes.
De plus, le module mem fournit diverses opérations pour traiter le texte en Ram (par opposition aux données qui viennent ou qui vont à une frontière IO). Le module mem est un module au lieu d'une caisse distincte en raison de l'efficacité des détails de la mise en œuvre interne.
En raison du cas d'utilisation de Gecko, Encoding_RS prend en charge le décodage et le codage de l'UTF-16 en plus de soutenir le cas d'utilisation de rouille habituel de décodage et de codage à partir de l'UTF-8. De plus, l'API a été conçue pour être conviviale FFI pour accueillir le côté C ++ de Gecko.
Plus précisément, Encoding_RS fait ce qui suit:
u16 / char16_t ).u16 / char16_t ) dans une séquence d'octets dans un codage de caractère défini standard codant comme si les substances solitaires avaient été remplacées par le caractère de remplacement avant d'effectuer l'encodage. (L'UTF-16 de Gecko est potentiellement invalide.)document.characterSet . De plus, encoding_rs::mem fait ce qui suit:
std::io Notamment, la liste des fonctionnalités ci-dessus n'inclut pas la capacité d'envelopper un std::io::Read , le décoder dans UTF-8 et la présentation du résultat via std::io::Read . La caisse encoding_rs_io fournit cette capacité.
no_std La caisse fonctionne dans un environnement no_std . Par défaut, la fonction alloc , qui suppose qu'un allocateur est présent est activé. Pour un environnement sans allocateur, les fonctionnalités par défaut (c.-à-d. alloc ) peuvent être désactivées. Cela rend la partie de l'API qui renvoie Vec / String / Cow indisponible.
Pour le décodage des encodages de caractères qui se produisent par e-mail, utilisez la caisse charset au lieu d'utiliser celle-ci directement. (Il enveloppe cette caisse et ajoute un décodage UTF-7.)
Pour les mappages vers et depuis les identifiants de la page de code Windows, utilisez la caisse codepage .
Cette caisse ne prend pas en charge les encodages DOS un seul octets qui ne sont pas requis par la plate-forme Web, mais la caisse oem_cp .
Normaliser le texte dans le formulaire de normalisation Unicode C avant le codage du texte dans un encodage hérité minimise les caractères incalculables. Le texte peut être normalisé dans le formulaire de normalisation Unicode C à l'aide de la caisse icu_normalizer .
L'exception est Windows-1258, qui, après la normalisation, le formulaire de normalisation Unicode C nécessite des marques de tonalité pour être décomposées afin de minimiser les caractères non apparables. Les marques de tonalité vietnamiennes peuvent être décomposées à l'aide de la caisse detone .
TL; DR: (Apache-2.0 OR MIT) AND BSD-3-Clause pour le code et la combinaison de données.
Veuillez consulter le fichier nommé Copyright.
Le code non test qui n'est pas généré à partir des données WhatWG dans cette caisse est sous Apache-2.0 ou MIT. Le code de test est sous CC0.
Cette caisse contient du code / des données générées à partir de données fournies par whatwg. Le whatwg en amont a modifié sa licence pour des parties des spécifications incorporées dans le code source de CC0 à la clause BSD-3 entre la version initiale de cette caisse et la version actuelle de cette caisse. Les légendes de l'octroi de licences sur source ont été mises à jour pour les parties du code généré qui ont changé depuis le changement de licence en amont.
La documentation API générée est disponible en ligne.
Il y a un article long sur la conception et les internes de la caisse.
Une couche FFI pour Encoding_RS est disponible en caisse séparée. La caisse est livrée avec un wrapper C ++ de démonstration à l'aide de la bibliothèque standard C ++ et des types GSL.
Les liaisons du module mem sont dans la caisse Encoding_C_Mem.
Pour le contexte Gecko, il y a un wrapper C ++ utilisant les types MFBT / XPCOM.
Il y a un article sur les emballages C ++.
Il existe actuellement ces fonctionnalités de fret en option:
simd-accel Permet l'accélération SIMD à l'aide de la fonction de bibliothèque standard portable_simd dépendant de la nuit.
Il s'agit d'une fonction d'opt-in, car l'activation de cette fonctionnalité se retire des garanties de Rust des futurs compilateurs compilant l'ancien code (aka. "Stability Story").
Actuellement, cela n'a pas été testé comme une amélioration, à l'exception de ces cibles et l'activation de la fonctionnalité simd-accel devrait briser la construction sur d'autres cibles:
Si vous utilisez la rouille nocturne, vous utilisez des cibles dont le premier composant est l'un des éléments ci-dessus, et vous êtes prêt à réviser votre configuration lors de la mise à jour de la rouille , vous devez activer cette fonctionnalité. Sinon, veuillez ne pas activer cette fonctionnalité.
Utilisé par Firefox.
serde Permet la prise en charge des champs de structure de sérialisation et désérialisants &'static Encoding à l'aide de Serde.
Non utilisé par Firefox.
fast-legacy-encodeUne option fourre-tout pour activer les options d'encodage hérité les plus rapides. N'affecte pas la vitesse du décodage ou la vitesse du code UTF-8.
À l'heure actuelle, cette option équivaut à permettre les options suivantes:
fast-hangul-encodefast-hanja-encodefast-kanji-encodefast-gb-hanzi-encodefast-big5-hanzi-encodeAjoute 176 Ko à la taille binaire.
Non utilisé par Firefox.
fast-hangul-encodeModifie le codage des syllabes Hangul précomposées en EUC-KR à partir de la recherche binaire sur les tables optimisées à décodage à la recherche par index, ce qui rend le code de texte en simple coréen environ 4 fois plus rapidement que sans cette option.
Ajoute 20 Ko à la taille binaire.
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
fast-hanja-encodeModifie le codage de Hanja en EUC-KR à partir de la recherche linéaire sur la table optimisée de décodage à la recherche par index. Étant donné que Hanja est pratiquement absent dans le texte coréen moderne, cette option n'affecte pas la perfomance dans le cas commun et a principalement du sens si vous voulez faire du service de service agaist résilient par quelqu'un en lui nourrissant intentionnellement beaucoup de Hanja pour coder en EUC-kr.
Ajoute 40 Ko à la taille binaire.
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
fast-kanji-encode Modifications en codage de Kanji en Shift_Jis, EUC-JP et ISO-2022-JP de la recherche linéaire sur les tables optimisées à la décodage à la recherche par index, ce qui rend le code de texte brut japonais aux encodages hérités 30 à 50 fois plus rapidement que sans cette option (environ 2 fois aussi rapidement qu'avec less-slow-kanji-encode ).
Privance à less-slow-kanji-encode .
Ajoute 36 Ko à la taille binaire (24 Ko par rapport à less-slow-kanji-encode ).
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
less-slow-kanji-encodeFait JIS X 0208 Level 1 Kanji (le Kanji le plus courant dans Shift_Jis, EUC-JP et ISO-2022-JP) encode moins lent (recherche binaire au lieu de la recherche linéaire), ce qui fait du code en texte simple japonais aux encodages hérités 14 à 23 fois plus rapidement que sans cette option.
Ajoute 12 Ko à la taille binaire.
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
fast-gb-hanzi-encode Changes encoding of Hanzi in the CJK Unified Ideographs block into GBK and gb18030 from linear search over a part the decode-optimized tables followed by a binary search over another part of the decode-optimized tables to lookup by index making Simplified Chinese plain-text encode to the legacy encodings 100 to 110 times as fast as without this option (about 2.5 times as fast as with less-slow-gb-hanzi-encode ).
Privance à less-slow-gb-hanzi-encode .
Ajoute 36 Ko à la taille binaire (24 Ko par rapport à less-slow-gb-hanzi-encode ).
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
less-slow-gb-hanzi-encodeFait le GB2312 de niveau 1 Hanzi (le Hanzi le plus courant dans GB18030 et GBK) encode moins lent (recherche binaire au lieu de la recherche linéaire), ce qui rend un encode de texte simple chinois simplifié aux encodages hérités environ 40 fois plus vite que sans cette option.
Ajoute 12 Ko à la taille binaire.
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
fast-big5-hanzi-encode Modifications en codage de Hanzi dans le CJK Les idéographies unifiées se bloquent dans BIG5 à partir de la recherche linéaire sur une partie les tables optimisées à la décodage à la recherche par index, ce qui rend le code de texte en simple chinois traditionnel à BIG5 105 à 125 fois plus vite que sans cette option (environ 3 fois plus vite qu'avec less-slow-big5-hanzi-encode ).
Privance à less-slow-big5-hanzi-encode .
Ajoute 40 Ko à la taille binaire (20 Ko par rapport à less-slow-big5-hanzi-encode ).
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
less-slow-big5-hanzi-encodeFait Big5 Level 1 Hanzi (le Hanzi le plus courant dans BIG5) codera moins lent (recherche binaire au lieu de la recherche linéaire), ce qui rend le code de texte brut chinois traditionnel à Big5 environ 36 fois plus vite que sans cette option.
Ajoute 20 Ko à la taille binaire.
N'affecte pas la vitesse du décodage.
Non utilisé par Firefox.
Pour décoder UTF-16, l'objectif est d'effectuer au moins ainsi que l'ancien UCONV de Gecko. Pour le décodage à UTF-8, l'objectif est de performer au moins et de codage de rouille. Ces objectifs ont été atteints.
L'encodage à UTF-8 doit être rapide. (Le code UTF-8 à UTF-8 devrait être équivalent à memcpy et UTF-16 à UTF-8 doit être rapide.)
La vitesse est un non-Goal lors du codage des encodages hérités. Par défaut, l'encodage des encodages hérités ne doit pas être optimisé pour la vitesse au détriment de la taille du code tant que la soumission de formulaire et l'analyse d'URL dans Gecko ne deviennent pas sensiblement trop lents dans une utilisation réelle.
Dans l'intérêt de la taille binaire, par défaut, Encoding_RS n'a pas de tables de données spécifiques à l'encodage au-delà de 32 bits de données spécifiques au code pour chaque codage à un octet. Par conséquent, les encodeurs recherchent les tables de données optimisées par décodage. Il s'agit d'une recherche linéaire dans la plupart des cas. Par conséquent, par défaut, le code en codages hérités varie du lent à extrêmement lent par rapport aux autres bibliothèques. Pourtant, avec des charges de travail réalistes, cela semblait assez rapide pour ne pas être lent-invitable sur Raspberry Pi 3 (qui représentait un téléphone pour les tests) dans les cas d'utilisation de l'encodeur exposés au Web.
Voir les fonctionnalités de cargaison ci-dessus pour que CJK Legacy codera rapidement.
Un cadre pour mesurer les performances est disponible séparément.
C'est un objectif de soutenir la dernière rouille stable, la dernière rouille nocturne et la version de Rust qui est utilisée pour Firefox tous les soirs.
À l'heure actuelle, il n'y a pas d'engagement ferme à soutenir une version plus ancienne que ce qui est exigé par Firefox, et il n'y a pas d'engagement à traiter les changements de MSRV comme des briseurs de SEMVER, car cette caisse dépend de cfg-if , qui ne semble pas traiter les changements de MSRV comme un coup de brisé.
En 2024-11-01, MSRV semble être Rust 1.40.0 pour l'utilisation de la caisse et 1.42.0 pour les tests DOC pour passer sans erreurs sur l'allocateur global. Avec la fonction simd-accel , le MSRV est encore plus élevé.
Une couche de compatibilité qui implémente l'API codant pour la rouille sur le dessus de Encoding_RS est fournie comme une caisse séparée (ne peut pas être téléchargée sur Crates.io). La couche de compatibilité a été à l'origine écrite avec l'assurance selon laquelle Firefox en aurait besoin, mais elle n'est pas actuellement utilisée dans Firefox.
Pour régénérer le code généré:
https://github.com/hsivonen/encoding_c à côté du répertoire encoding_rs .https://github.com/hsivonen/codepage à côté du répertoire encoding_rs .https://github.com/whatwg/encoding à côté du répertoire encoding_rs .1d519bf8e5555cef64cf3a712485f41cd1a6a990 du encoding Repo. (Remarque: f381389 a été la révision de encoding utilisé avant le changement de licence de repos encoding .)encoding_rs en tant que répertoire de travail, exécutez python generate-encoding-data.py . usize au lieu de u8 à la fois). alloc (avec une surface d'API moindre). std::simdunsafe par des types plus grands que u8 / u16 sur align_to . portable_simd de la bibliothèque standard au lieu de la caisse packed_simd . Affecte uniquement la fonctionnalité nocturne en option simd-accel .unsafe .rust-version à Cargo.toml .packed_simd au lieu de packed_simd_2 maintenant que les mises à jour sont de retour sous le nom packed_simd . Affecte uniquement la fonctionnalité nocturne en option simd-accel .build.rs . (Cette suppression devrait résoudre les faux positifs rapportés par certains produits antivirus. Cela peut casser certaines configurations de construction qui se sont retirées des garanties de Rust contre la rupture future.)no_std .no_std (avec alloc ).simd-accel .packed_simd à packed_simd_2 .cfg-if à 1.0.cfg-if Mise à jour de l'édition 2018 sans pause Semver.Decoder::latin1_byte_compatible_up_to en retourner dans None autres cas pour rendre la méthode réellement utile. Bien que cela puisse être considéré comme un changement de rupture en raison du changement de sémantique de correction de bogue, il ne casse pas les appelants qui ont dû gérer le cas None de manière raisonnable de toute façon.convert_str_to_utf16 .mem::convert_utf8_to_utf16_without_replacement .mem::utf8_latin1_up_to et mem::str_latin1_up_to .Decoder::latin1_byte_compatible_up_to .bincode (Dev Dependency) à 1.0.simd à packed_simd .simd-accel (version ReadMe uniquement).clippy:: des noms de peluches Clippy.static lors de la définition d'une autre static ).is_single_byte() en Encoding .mem::decode_latin1() et mem::encode_latin1_lossy() .--features simd-accel fonctionnent avec un compilateur à canal stable pour simplifier le système de construction Firefox.is_foo_bidi() ne traite pas U + FEFF (espace de non-pause de largeur zéro aka. Marque de commande d'octet) comme droit à gauche.is_foo_bidi() Signaler true si l'entrée contient des formulaires de présentations hébreu (qui sont du droit à gauche mais pas dans un bloc de droite à lambeaux).convert_utf16_to_latin1_lossy .mem affirment que l'entrée est dans la plage U + 0000 ... U + 00FF (inclusive).mem fournir des conversions de Latin1 et UTF-16 à UTF-8 qui peuvent gérer un espace de sortie insuffisant. L'idée est de les utiliser d'abord avec une allocation arrondi à la taille du seau Jemalloc et de ne faire la pire allocation des cas que si le mondage Jemalloc était insuffisant comme première supposition.simd-accel , introduite dans la version 0.8.1 dans les conversions entre UTF-16 et Latin1 dans le module mem .#[inline(never)] qui n'était pas destinée à la libération.mem pour augmenter les performances lors de la conversion de tampons longs.mem .mem .replacement une étiquette de l'encodage de remplacement. (Spec change.)Encoding::for_name() . ( Encoding::for_label(foo).unwrap() est maintenant assez proche après le changement d'étiquette ci-dessus.)parallel-utf8 .&'static Encoding .Encoder::has_pending_state() .simd à 0.2.0.7F correctement dans ISO-2022-JP.Hash pour Encoding .InputEmpty OutputFull lors de la sortie lors du codage avec remplacement et le tampon de sortie passé est trop court ou l'espace restant dans le tampon de sortie est trop petit après un remplacement.PartialEq et Eq pour les types de CoderResult , DecoderResult et EncoderResult .Encoder::encode_from_utf16 . (En raison d'une surveillance, il manquait le correctif que Encoder::encode_from_utf8 avait déjà.)#[must_use] .parallel-utf8 ).simd-accelEncoding de const à static pour rendre les référents uniques sur les caisses qui utilisent les références.Encoding FOO_INIT de non-référence pour permettre aux caisses étrangères d'initialiser les tableaux static avec des références à des instances Encoding même sous les contraintes de Rust qui interdisent l'initialisation des éléments de tableau de type codage &'static Encoding avec &'static Encoding statics .const pour fonctionner afin que l'utilisation croisée de la croisement maintient les référents uniques.Cow S des méthodes de non-diffusion en rouille uniquement pour coder et décoder.Encoding::for_bom() renvoie la longueur du bom.simd-accel . (Nécessite de la rouille nocturne.)Encoder.encode_from_utf8_to_vec_without_replacement() . Ajouter Encoding.is_ascii_compatible() .
Ajouter Encoding::for_bom() .
Make == pour Encoding de la comparaison du nom d'utilisation au lieu de la comparaison du pointeur, car les utilisations des constantes de codage dans différentes caisses entraînent différentes adresses et la constante ne peut pas être transformée en statistique sans casser d'autres choses.
La version initiale.
