encoding_rs
1.0.0
coding_rs Eine Implementierung der (nicht-JavaScript-Teile) des in Rost geschriebenen Codierungsstandards.
Der Codierungsstandard definiert den Webkompatible-Satz von Zeichencodierungen, was bedeutet, dass diese Kiste zum Dekodieren von Webinhalten verwendet werden kann. Coding_rs wird in Gecko verwendet, beginnend mit Firefox 56. Aufgrund der bemerkenswerten Überlappung zwischen den Legacy Codings im Web und den an Fenstern verwendeten Legacy-Codierungen kann diese Kiste auch für nicht-gewebbezogene Situationen von Nutzen sein. Links zu benachbarten Kisten finden Sie unten.
Darüber hinaus bietet das mem Modul verschiedene Operationen für den Umgang mit In-RAM-Text (im Gegensatz zu Daten, die von oder zu einer IO-Grenze stammen oder an eine IO-Grenze gehen). Das mem -Modul ist aufgrund interner Implementierungsdetails ein Modul anstelle einer separaten Kiste.
Aufgrund des Gecko-Anwendungsfalls unterstützt Coding_rs die Dekodierung und Codierung von UTF-16 und unterstützt den üblichen Rost-Anwendungsfall der Dekodierung und Codierung von UTF-8. Zusätzlich wurde die API als ffi-freundlich ausgelegt, um die C ++-Seite von Gecko aufzunehmen.
Insbesondere macht Coding_rs Folgendes::
u16 / char16_t ) codiert.u16 / char16_t ) in eine Abfolge von Bytes in einem kodierenden Standard-Zeichen-Codierung, als ob die einzelnen Ersatzteile durch das Ersatzcharakter vor der Ausführung ersetzt worden wären. (Geckos UTF-16 ist potenziell ungültig.)document.characterSet geeignet sind. Zusätzlich macht encoding_rs::mem Folgendes::
std::io Insbesondere enthält die obige Funktionsliste nicht die Fähigkeit, ein std::io::Read zu wickeln, in UTF-8 zu dekodieren und das Ergebnis über std::io::Read zu präsentieren. Die encoding_rs_io -Kiste bietet diese Fähigkeit.
no_std -Umgebung Die Kiste funktioniert in einer no_std -Umgebung. Standardmäßig ist die alloc -Funktion, die davon ausgeht, dass ein Allokator vorhanden ist. Für eine No-Allocator-Umgebung können die Standardfunktionen (dh alloc ) ausgeschaltet werden. Dies macht den Teil der API, der Vec / String / Cow nicht verfügbar zurückgibt.
Verwenden Sie für die Dekodierung von Charaktercodierungen, die in E -Mails auftreten, die charset -Kiste, anstatt diese direkt zu verwenden. (Es wickelt diese Kiste um und fügt UTF-7-Dekodierung hinzu.)
Verwenden Sie die Kennzeichnung von Windows -Code -Seiten für die Zuordnungen an und von Windows codepage -Seitenkennungen.
Diese Kiste unterstützt keine Single-Byte-DOS-Codierungen, die von der Webplattform nicht erforderlich sind, sondern die oem_cp Kiste.
Die Normalisierung des Textes in Unicode -Normalisierungsformular C vor dem Codieren von Text in eine ältere Codierung minimiert ungünstige Zeichen. Der Text kann unter Verwendung der icu_normalizer -Kiste auf die Unicode -Normalisierungsform C normalisiert werden.
Die Ausnahme lautet Windows-1258, die nach der Normalisierung der Unicode-Normalisierungsform. C-Markierungen müssen zersetzt werden, um unerträgliche Zeichen zu minimieren. Vietnamesische Tonmarken können mit der detone -Kiste zersetzt werden.
TL; DR: (Apache-2.0 OR MIT) AND BSD-3-Clause für die Code- und Datenkombination.
Bitte beachten Sie die Datei mit dem Namen Copyright.
Der Nicht-Test-Code, der nicht aus den whatWG-Daten in dieser Kiste generiert wird, befindet sich unter Apache-2.0 oder MIT. Der Testcode erfolgt unter CC0.
Diese Kiste enthält Code/Daten, die aus whatwg-unterstützten Daten generiert wurden. Der Whatwg-Upstream änderte seine Lizenz für Teile der in den Quellcode von CC0 auf BSD-3-Klausel eingebauten Spezifikationen zwischen der anfänglichen Veröffentlichung dieser Kiste und der vorliegenden Version dieser Kiste. Die In-Source-Lizenzlegenden wurden für die Teile des generierten Codes aktualisiert, die sich seit der Änderung der Upstream-Lizenz geändert haben.
Generierte API -Dokumentation ist online verfügbar.
Es gibt eine Langform über das Design und die Innenstadt der Kiste.
Eine FFI -Ebene für Coding_Rs ist als separate Kiste verfügbar. Die Kiste verfügt über eine Demo C ++ - Wrapper unter Verwendung der C ++ - Standardbibliothek und GSL -Typen.
Die Bindungen für das mem -Modul befinden sich in der Kiste coding_c_mem.
Für den Gecko -Kontext gibt es einen C ++ - Wrapper mit den MFBT/XPCOM -Typen.
Es gibt einen Artikel über die C ++-Wrapper.
Derzeit gibt es diese optionalen Frachtfunktionen:
simd-accel Ermöglicht die SIMD-Beschleunigung mithilfe der abhängigen Funktion portable_simd Standard Library.
Dies ist eine Opt-In-Funktion, da es sich um die Möglichkeit, diese Funktion von Rusts Garantien für zukünftige Compiler zu ermöglichen , den alten Code zusammenzustellen (auch bekannt als "Stabilitätsgeschichte").
Derzeit wurde dies bis auf diese Ziele nicht als Verbesserung getestet, und es wird erwartet, dass die simd-accel Funktion den Aufbau auf anderen Zielen brechen wird:
Wenn Sie nächtliche Rost verwenden, verwenden Sie Ziele, deren erste Komponente eines der oben genannten ist, und Sie sind bereit , Ihre Konfiguration beim Aktualisieren von Rost überarbeiten zu müssen . Sie sollten diese Funktion aktivieren. Andernfalls aktivieren Sie diese Funktion nicht .
Von Firefox verwendet.
serde Ermöglicht die Unterstützung der Serialisierung und Deserialisierung &'static Encoding von Strukturen mit SERDE.
Nicht von Firefox verwendet.
fast-legacy-encodeEine Option Catch-All, um die schnellsten Legacy-Encode-Optionen zu aktivieren. Wirkt sich nicht auf die Dekodierung der Geschwindigkeit oder der UTF-8-Enkodierung der Geschwindigkeit aus.
Gegenwärtig entspricht diese Option den folgenden Optionen:
fast-hangul-encodefast-hanja-encodefast-kanji-encodefast-gb-hanzi-encodefast-big5-hanzi-encodeFügt der binären Größe 176 kb hinzu.
Nicht von Firefox verwendet.
fast-hangul-encodeÄnderungen, die vor komponierte Hangul-Silben in EUC-KR codieren, von der binären Suche über die decodoptimierten Tabellen bis hin zur Suche durch Index, sodass koreanische Klartext etwa viermal so schnell wie ohne diese Option codiert.
Fügt der binären Größe 20 kb hinzu.
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
fast-hanja-encodeÄnderungen, die von Hanja in EUC-KR codieren, von der linearen Suche über die decodoptimierte Tabelle bis hin zur Suche nach Index. Da Hanja im modernen koreanischen Text praktisch nicht vorhanden ist, wirkt sich diese Option in dem gemeinsamen Fall nicht auf die Performance aus und macht hauptsächlich Sinn, wenn Sie Ihre Anwendung widerstandsfähige agaistische Denialverweigerung durch jemanden machen möchten, der absichtlich viel Hanja füttert, um sie in EUC-KR zu kodieren.
Fügt der binären Größe 40 kb hinzu.
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
fast-kanji-encode Änderungen, die die Kodierung von Kanji in Shift_JIS, EUC-JP und ISO-2022-JP von der linearen Suche über die decodoptimierten Tabellen bis hin zur Suche durch Index machen, indem der japanische Klartext 30- bis 50-mal so schnell wie ohne diese Option (ungefähr 2-mal so schnell wie bei less-slow-kanji-encode ) eingestuft wird.
Nimmt Vorrang vor less-slow-kanji-encode .
Fügt der binären Größe 36 kb hinzu (24 kb im Vergleich zu less-slow-kanji-encode ).
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
less-slow-kanji-encodeMacht JIS X 0208 Level 1 Kanji (die häufigste Kanji in Shift_JIS, EUC-JP und ISO-2022-JP) weniger langsam (binäre Suche anstelle von linearer Suche), wodurch japanische Einfach-Text-Encodes zu Legacy-Encodings 14 bis 23 Mal so schnell wie schnell wie ohne diese Option.
Fügt der binären Größe 12 kb hinzu.
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
fast-gb-hanzi-encode Änderungen, die die Codierung von Hanzi in den einheitlichen CJK-Ideografien in GBK und GB18030 von linearer Suche über einen Teil blockieren. less-slow-gb-hanzi-encode ).
Nimmt Vorrang vor less-slow-gb-hanzi-encode .
Fügt der binären Größe 36 kb hinzu (24 kb im Vergleich zu less-slow-gb-hanzi-encode ).
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
less-slow-gb-hanzi-encodeErstellt GB2312 Level 1 Hanzi (die häufigste Hanzi in GB18030 und GBK), die weniger langsame (binäre Suche anstelle von linearer Suche) codiert, und macht eine vereinfachte chinesische Klartext-Enkodierung in die Legacy-Encodings etwa 40 Mal so schnell wie ohne diese Option.
Fügt der binären Größe 12 kb hinzu.
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
fast-big5-hanzi-encode Änderungen, die die Codierung von Hanzi in den CJK Unified Ideographs in Big5 aus linearer Suche über einen Teil der decodoptimierten Tabellen blockieren, durch Index, indem traditionelle chinesische Klartext-Encodes für Big5 105 bis 125-mal so schnell wie ohne diese Option (etwa 3 mal so schnell wie bei less-slow-big5-hanzi-encode ).
Nimmt Vorrang vor less-slow-big5-hanzi-encode .
Fügt der binären Größe 40 kb hinzu (20 kb im Vergleich zu less-slow-big5-hanzi-encode ).
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
less-slow-big5-hanzi-encodeErstellt Big5 Level 1 Hanzi (die häufigste Hanzi in Big5), die weniger langsam (binäre Suche anstelle von linearer Suche) codiert, wodurch die traditionelle chinesische Klartext-Codierung nach Big5 etwa 36 Mal so schnell so schnell wie ohne diese Option.
Fügt der binären Größe 20 kb hinzu.
Wirkt sich nicht auf die Dekodierung der Geschwindigkeit aus.
Nicht von Firefox verwendet.
Für die Dekodierung von UTF-16 ist es das Ziel, mindestens genauso gut wie Geckos alter UCONV zu erzielen. Für die Dekodierung von UTF-8 ist es das Ziel, mindestens ebenso wie Rost-Codierung zu funktionieren. Diese Ziele wurden erreicht.
Die Codierung von UTF-8 sollte schnell sein. (UTF-8 bis UTF-8-Encode sollte dem memcpy und UTF-16 zu UTF-8 entsprechen.)
Geschwindigkeit ist ein Nichtgänger, wenn es um Legacy-Codierungen kodiert. Standardmäßig sollte die Codierung von Legacy-Codierungen auf Kosten der Codegröße nicht für die Geschwindigkeit optimiert werden, solange die Einreichung von Formular und die URL-Parsen in Gecko in der realen Verwendung nicht zu langsam zu langsam werden.
Im Interesse der binären Größe hat Coding_rs standardmäßig keine codierenden Datentabellen über 32 Bits von Encodespezifischen Daten für jede Einzel-Byte-Codierung hinaus. Daher durchsuchen Encoder die decodoptimierten Datentabellen. Dies ist in den meisten Fällen eine lineare Suche. Infolgedessen variieren standardmäßig die Codierung für Legacy -Codierungen von langsam bis zu extrem langsam im Verhältnis zu anderen Bibliotheken. Trotzdem schien dies bei realistischen Arbeitsbelastungen schnell genug zu sein, um bei Raspberry Pi 3 (die für ein Telefon zum Testen für ein Telefon zur Verfügung stand) nicht zu sein.
Die obigen Frachtfunktionen finden Sie optional, um CJK Legacy zu schnell zu erstellen.
Ein Rahmen für die Messung der Leistung ist separat verfügbar.
Es ist ein Ziel, den neuesten stabilen Rost, den neuesten nächtlichen Rost und die Version von Rust zu unterstützen, die für Firefox Nightly verwendet wird.
Zu diesem Zeitpunkt gibt es keine feste Verpflichtung, eine Version zu unterstützen, die von Firefox älter ist, und es gibt keine Verpflichtung zur Behandlung von MSRV-Änderungen als Semver-Breaking, da diese Kiste von cfg-if abhängt, die MSRV-Veränderungen nicht als Semver-Break zu behandeln scheint, weshalb es für diese Kiste, MSRV-Veränderungen zu behandeln, als Semver-Breaking nutzlos wäre.
Ab 2024-11-01 scheint MSRV Rost 1.40.0 für die Verwendung der Kiste und 1.42.0 zu sein, damit DOC-Tests ohne Fehler über den globalen Allocator bestehen können. Mit der simd-accel -Funktion ist die MSRV sogar noch höher.
Eine Kompatibilitätsschicht, die die Rost-kodierende API über Coding_rs implementiert, wird als separate Kiste bereitgestellt (kann nicht in Kisten hochgeladen werden.io). Die Kompatibilitätsschicht wurde ursprünglich mit der Assupion geschrieben, dass Firefox sie benötigen würde, aber sie wird derzeit nicht in Firefox verwendet.
Um den generierten Code zu regenerieren:
https://github.com/hsivonen/encoding_c neben dem Verzeichnis encoding_rs .https://github.com/hsivonen/codepage neben dem Verzeichnis encoding_rs .https://github.com/whatwg/encoding neben dem Verzeichnis encoding_rs .1d519bf8e5555cef64cf3a712485f41cd1a6a990 des encoding . (Hinweis: f381389 war die Überarbeitung der encoding , die von der Änderung der encoding der Repo -Lizenz verwendet wurde.)encoding_rs als Arbeitsverzeichnis rennen Sie python generate-encoding-data.py . usize anstelle von u8 ). alloc funktioniert (mit einer geringeren API -Oberfläche). std::simdunsafe Slice -Zugriff nach größeren Typen als u8 / u16 auf align_to . portable_simd in der Standardbibliothek anstelle der Kiste packed_simd . Beeinflusst nur die optionale Nightly-Funktion simd-accel .unsafe .rust-version in Cargo.toml hinzugefügt.packed_simd anstelle von packed_simd_2 erneut, da die Updates wieder unter dem Namen packed_simd liegen. Beeinflusst nur die optionale Nightly-Funktion simd-accel .build.rs . (Diese Entfernung sollte falsch -positive Aspekte auflösen, die einige Antivirenprodukte gemeldet haben. Dies kann einige Build -Konfigurationen brechen, die sich aus Rusts Garantien gegen zukünftige Bruchbauteile ausgetauscht haben.)no_std -Unterstützung eingeführt wurde.no_std -Umgebung (mit alloc ) funktioniert.simd-accel -Funktion gebrochen hat.packed_simd auf packed_simd_2 .cfg-if Abhängigkeit auf 1.0.cfg-if auf Ausgabe 2018 ohne Semver-Pause aktualisiert wurde.Decoder::latin1_byte_compatible_up_to None mehr Fällen zurück, um die Methode tatsächlich nützlich zu machen. Dies könnte jedoch als eine brechende Veränderung aufgrund der Änderung der Semantik des Fehlers behoben werden, aber es brechen keine Anrufer, die den None sowieso auf vernünftige Weise bearbeiten mussten.convert_str_to_utf16 .mem::convert_utf8_to_utf16_without_replacement hinzugefügt.mem::utf8_latin1_up_to und mem::str_latin1_up_to hinzugefügt.Decoder::latin1_byte_compatible_up_to hinzugefügt.bincode (Dev Dependenty) auf 1.0.simd -Kiste auf packed_simd .simd-accel (README-Release) an.clippy:: Präfix aus Clippy -Lint -Namen.static zu beziehen, wenn sie eine andere static definieren).is_single_byte() bei Encoding .mem::decode_latin1() und mem::encode_latin1_lossy() hinzugefügt.--features simd-accel -Arbeit mit dem Stall-Kanal-Compiler, um das Firefox-Build-System zu vereinfachen.is_foo_bidi() nicht u+feff (null breite no-brütungsraum aka. Byte order mark) als rechts nach links.is_foo_bidi() true wenn die Eingabe hebräische Präsentationsformen enthält (die Recht zu links sind, jedoch nicht in einem Block von Recht nach links).convert_utf16_to_latin1_lossy hinzugefügt wurde, zeiträgeriges Debug -Behauptung entfernt.mem -Modul, dass der Eingang im Bereich U+0000 ... u+00ff (einschließlich) liegt.mem Modul bieten Konvertierungen von Latin1 und UTF-16 zu UTF-8, die mit unzureichendem Ausgangsraum umgehen können. Die Idee ist, sie zuerst mit einer auf Jemalloc-Eimergröße abgerundeten Zuweisung zu verwenden und nur dann die Worst-Case-Zuweisung durchzuführen, wenn die Jemalloc-Rundung als erste Vermutung nicht ausreicht.simd-accel -spezifische Speicherbeschäftigung in Version 0.8.1 in Konvertierungen zwischen UTF-16 und Latein1 im mem Modul.#[inline(never)] Annotation, die nicht zur Veröffentlichung gedacht war.mem Modul, um die Leistung bei der Konvertierung langer Puffer zu erhöhen.mem -Modul hinzu.mem -Moduls beeinflussen kann.replacement Sie ein Etikett der Ersatzcodierung. (Spezifische Änderung.)Encoding::for_name() . ( Encoding::for_label(foo).unwrap() ist jetzt nach der obigen Etikettänderung nahe genug.)parallel-utf8 -Frachtfunktion.&'static Encoding hinzu.Encoder::has_pending_state() öffentlich.simd -Kistenabhängigkeit auf 0.2.0.7F korrekt in ISO-2022-JP.Hash für Encoding implementieren.OutputFull InputEmpty der Codierung mit dem Ersatz an, und der eingegebene Ausgangspuffer ist zu kurz oder der verbleibende Speicherplatz im Ausgangspuffer ist nach einem Ersatz zu klein.PartialEq und Eq für die Typen CoderResult , DecoderResult und EncoderResult ab.Encoder::encode_from_utf16 . (Aufgrund eines Versehens fehlte es den Fix, den Encoder::encode_from_utf8 bereits hatte.)#[must_use] .parallel-utf8 ).simd-accel verwendet wird.Encoding von const zu static um die Referenten über Kisten einzigartig zu machen, die die Überweisungen verwenden.FOO_INIT -nicht referenzverzögerten Encoding , damit Fremdkisten static Arrays mit Verweisen auf Encoding auch unter Rusts Einschränkungen initialisieren, die die Initialisierung der &'static Encoding von Array -Elementen mit &'static Encoding von typen statics verbieten.const in die Funktionsweise ändert, damit die Cross-Nutzung die Referenten einzigartig hält.Cow von Rost-Nur-nicht-Streaming-Methoden für Encode und Dekodierung zurück.Encoding::for_bom() gibt die Länge der BOM zurück.simd-accel Feature-Flag hinzu. (Benötigt Nachtrost.)Encoder.encode_from_utf8_to_vec_without_replacement() . Add Encoding.is_ascii_compatible() .
Fügen Sie Encoding::for_bom() .
Make == Für Encoding anstelle des Zeigervergleichs, da die Verwendung der Codierungskonstanten in verschiedenen Kisten zu unterschiedlichen Adressen führt und die Konstante nicht in Statik verwandelt werden kann, ohne andere Dinge zu brechen.
Die erste Veröffentlichung.
