encoding_rs
1.0.0
Encoding_rs Una implementación de las (partes no javascript de) el estándar de codificación escrito en óxido.
El estándar de codificación define el conjunto de codificaciones de caracteres compatibles con la web, lo que significa que esta caja puede usarse para decodificar contenido web. Encoding_RS se usa en gecko comenzando con Firefox 56. Debido a la notable superposición entre las codificaciones heredadas en la web y las codificaciones heredadas utilizadas en las ventanas, esta caja también puede ser útil para situaciones no relacionadas con la WEB; Vea a continuación los enlaces a cajas adyacentes.
Además, el módulo mem proporciona varias operaciones para tratar el texto en RAM (a diferencia de los datos que provienen o van a un límite de IO). El módulo mem es un módulo en lugar de una caja separada debido a la eficiencia de los detalles de implementación interna.
Debido al caso de uso de gecko, la codificación_rs admite la decodificación y la codificación de UTF-16, además de admitir el caso de uso de óxido habitual de decodificar y codificar desde UTF-8. Además, la API ha sido diseñada para ser amigable con FFI para acomodar el lado C ++ de Gecko.
Específicamente, Encoding_RS hace lo siguiente:
u16 / char16_t ).u16 / char16_t ) en una secuencia de bytes en un carácter de codificación definido por estándar de codificación como si los sustitutos solitarios hubieran sido reemplazados con el carácter de reemplazo antes de realizar la codificación. (El UTF-16 de Gecko es potencialmente inválido).document.characterSet . Además, encoding_rs::mem hace lo siguiente:
std::io En particular, la lista de características anterior no incluye la capacidad de envolver un std::io::Read , decodificarla en UTF-8 y presentar el resultado a través de std::io::Read . La caja encoding_rs_io proporciona esa capacidad.
no_std La caja funciona en un entorno no_std . De manera predeterminada, la función alloc , que supone que un asignador está presente está habilitado. Para un entorno sin alocator, las características predeterminadas (es decir, alloc ) se pueden apagar. Esto hace que la parte de la API que devuelve Vec / String / Cow no esté disponible.
Para la decodificación de codificaciones de caracteres que ocurren en el correo electrónico, use la caja charset en lugar de usar esta directamente. (Envuelve esta caja y agrega decodificación UTF-7).
Para las asignaciones hacia y desde los identificadores de la página del código de Windows, use la caja codepage .
Esta caja no admite codificaciones DOS de un solo byte que la plataforma web no requiere, pero la caja oem_cp sí.
Normalizar el texto en unicode Normalización C antes de codificar el texto en una codificación heredada minimiza los caracteres inapropiables. El texto se puede normalizar al formulario de normalización C de unicode utilizando la caja de icu_normalizer .
La excepción es Windows-1258, que después de normalizar al formulario de normalización de Unicode requiere que las marcas de tono se descompusieran para minimizar los caracteres inapropiables. Las marcas de tono vietnamitas se pueden descomponer utilizando la caja detone .
TL; DR: (Apache-2.0 OR MIT) AND BSD-3-Clause para el código y la combinación de datos.
Consulte el archivo llamado Copyright.
El código de no prueba que no se genera a partir de los datos de WhatWG en esta caja está bajo Apache-2.0 o MIT. El código de prueba está en CC0.
Esta caja contiene código/datos generados a partir de datos con suministro de WhatWG. El WhatWG Upstream cambió su licencia para partes de especificaciones incorporadas en el código fuente de CC0 a la cláusula BSD-3 entre la versión inicial de esta caja y la versión actual de esta caja. Las leyendas de licencias en la fuente se han actualizado para las partes del código generado que han cambiado desde el cambio de licencia aguas arriba.
La documentación de API generada está disponible en línea.
Hay una redacción de forma larga sobre el diseño y las partes internas de la caja.
Una capa FFI para coding_rs está disponible como una caja separada. La caja viene con un envoltorio de demostración C ++ utilizando la biblioteca estándar C ++ y los tipos GSL.
Los enlaces para el módulo mem se encuentran en la caja coding_c_mem.
Para el contexto de gecko, hay un envoltorio C ++ usando los tipos MFBT/XPCOM.
Hay un artículo sobre los envoltorios C ++.
Actualmente hay estas características de carga opcionales:
simd-accel Habilita la aceleración SIMD utilizando la función de biblioteca estándar portable_simd dependiente de la noche.
Esta es una característica de suscripción, ya que habilitar esta función opta por las garantías de Rust de futuros compiladores que compilan el código antiguo (también conocido como "historia de estabilidad").
Actualmente, esto no se ha probado que sea una mejora, excepto estos objetivos y se espera que la función simd-accel rompa la compilación en otros objetivos:
Si usa óxido nocturno, usa objetivos cuyo primer componente es uno de los anteriores, y está preparado para tener que revisar su configuración al actualizar el óxido , debe habilitar esta función. De lo contrario, no habilite esta función.
Utilizado por Firefox.
serde Permite el soporte para la serialización y la deserialización &'static Encoding utilizando SERDE.
No utilizado por Firefox.
fast-legacy-encodeUna opción de atrapar para habilitar las opciones de codificación de Legacy más rápido. No afecta la velocidad de decodificación o la velocidad de codificación UTF-8.
En la actualidad, esta opción es equivalente a habilitar las siguientes opciones:
fast-hangul-encodefast-hanja-encodefast-kanji-encodefast-gb-hanzi-encodefast-big5-hanzi-encodeAgrega 176 kb al tamaño binario.
No utilizado por Firefox.
fast-hangul-encodeCambios que codifican las sílabas Hangul precompuestas en EUC-KR de la búsqueda binaria a través de las tablas optimizadas de decodificación para buscar en el índice haciendo que el texto simple coreano codifique aproximadamente 4 veces más rápido que sin esta opción.
Agrega 20 kb al tamaño binario.
No afecta la velocidad de decodificación.
No utilizado por Firefox.
fast-hanja-encodeCambios de codificación de Hanja en EUC-KR de la búsqueda lineal sobre la tabla optimizada decodificada para buscar por índice. Dado que Hanja está prácticamente ausente en el texto coreano moderno, esta opción no afecta el rendimiento en el caso común y principalmente tiene sentido si desea hacer que su aplicación sean resistentes a la negación del servicio de Agaist al alimentarlo intencionalmente mucho de Hanja para codificar en EUC-KR.
Agrega 40 kb al tamaño binario.
No afecta la velocidad de decodificación.
No utilizado por Firefox.
fast-kanji-encode Cambios de codificación de Kanji en shift_jis, EUC-JP e ISO-2022-JP de la búsqueda lineal a través de las tablas optimizadas de decodificación para buscar índice haciendo que el texto sencillo japonés se codifique a codificaciones heredadas de 30 a 50 veces más rápidas que sin esta opción (aproximadamente 2 veces más rápido que con less-slow-kanji-encode ).
Tiene prioridad sobre less-slow-kanji-encode .
Agrega 36 kb al tamaño binario (24 kb en comparación con less-slow-kanji-encode ).
No afecta la velocidad de decodificación.
No utilizado por Firefox.
less-slow-kanji-encodeHace JIS X 0208 Nivel 1 Kanji (el kanji más común en shift_jis, EUC-JP e ISO-2022-JP) codifica menos lento (búsqueda binaria en lugar de búsqueda lineal) haciendo que el texto simple japonés codice las codificaciones heredadas 14 a 23 veces más rápidas que sin esta opción.
Agrega 12 kb al tamaño binario.
No afecta la velocidad de decodificación.
No utilizado por Firefox.
fast-gb-hanzi-encode Cambios de codificación de Hanzi en el bloqueo de ideografías unificadas de CJK en GBK y GB18030 de la búsqueda lineal en una parte Las tablas de decodificación optimizadas seguidas de una búsqueda binaria en otra parte de las tablas optimizadas de decodificación a la búsqueda de índice mediante el índice que se encoge de texto liso simplificado a las encuestas heredadas 100 a 110 veces tan rápido como sin esta opción (aproximadamente 2.5 veces tan rápido con un índice que hace un índice de texto liso simplificado a las codificaciones heredadas de 100 a 110 veces tan rápido como sin esta opción (aproximadamente 2.5 veces tan rápido con un índice simplificado. less-slow-gb-hanzi-encode ).
Tiene prioridad sobre less-slow-gb-hanzi-encode .
Agrega 36 kb al tamaño binario (24 kb en comparación con less-slow-gb-hanzi-encode ).
No afecta la velocidad de decodificación.
No utilizado por Firefox.
less-slow-gb-hanzi-encodeHace GB2312 Nivel 1 Hanzi (el Hanzi más común en GB18030 y GBK) codifica menos lento (búsqueda binaria en lugar de búsqueda lineal) que hace que el texto simple simplificado se codifique a las codificaciones heredadas aproximadamente 40 veces más que sin esta opción.
Agrega 12 kb al tamaño binario.
No afecta la velocidad de decodificación.
No utilizado por Firefox.
fast-big5-hanzi-encode Los cambios en la codificación de Hanzi en los ideógrafos unificados de CJK bloquean en Big5 desde la búsqueda lineal en una parte Las tablas optimizadas de decodificación para buscar índice haciendo que el texto sin formato tradicional chino se codifique a Big5 105 a 125 veces más rápido que sin esta opción (aproximadamente 3 veces más rápido que con less-slow-big5-hanzi-encode ).
Tiene prioridad sobre less-slow-big5-hanzi-encode .
Agrega 40 kb al tamaño binario (20 kb en comparación con less-slow-big5-hanzi-encode ).
No afecta la velocidad de decodificación.
No utilizado por Firefox.
less-slow-big5-hanzi-encodeHace que el Hanzi de nivel 1 Big5 (el Hanzi más común en Big5) codifique menos lento (búsqueda binaria en lugar de búsqueda lineal) haciendo que la codificación tradicional china se codifique a Big5 aproximadamente 36 veces más rápido que sin esta opción.
Agrega 20 kb al tamaño binario.
No afecta la velocidad de decodificación.
No utilizado por Firefox.
Para la decodificación a UTF-16, el objetivo es realizar al menos tan bien como el antiguo UConv de Gecko. Para la decodificación a UTF-8, el objetivo es realizar al menos tan bien como la codificación de óxido. Se han logrado estos objetivos.
La codificación a UTF-8 debe ser rápida. (La codificación UTF-8 a UTF-8 debe ser equivalente a memcpy y UTF-16 a UTF-8 debería ser rápido).
La velocidad no es un objetivo al codificar a las codificaciones heredadas. De manera predeterminada, la codificación a las codificaciones heredadas no debe optimizarse para la velocidad a expensas del tamaño del código, siempre y cuando el envío de formularios y el análisis de URL en gecko no se vuelvan notablemente demasiado lentos en el uso del mundo real.
En aras del tamaño binario, por defecto, Coding_RS no tiene tablas de datos específicas de codificación más allá de 32 bits de datos específicos de codificación para cada codificación de un solo byte. Por lo tanto, los codificadores buscan las tablas de datos optimizadas por decodificación. Esta es una búsqueda lineal en la mayoría de los casos. Como resultado, de forma predeterminada, la codificación a las codificaciones heredadas varía de lento a extremadamente lento en relación con otras bibliotecas. Aún así, con cargas de trabajo realistas, esto parecía lo suficientemente rápido como para no ser visiblemente lento en Raspberry Pi 3 (que se mantuvo en un teléfono para probar) en los casos de uso del codificador expuestos a la web.
Consulte las características de carga anteriores para hacer que CJK Legacy codifique rápidamente.
Un marco para medir el rendimiento está disponible por separado.
Es un objetivo apoyar el último óxido estable, la última óxido nocturno y la versión de Rust que se usa para Firefox por la noche.
En este momento, no existe un compromiso firme de admitir una versión más antigua de lo requerido por Firefox, y no hay compromiso de tratar los cambios de MSRV como ruptura de Semver, porque esta caja depende de cfg-if , que no parece tratar los cambios de MSRV como la ruptura de Semver, por lo que sería inútil para esta caja tratar los cambios de MSRV como el semilla.
A partir de 2024-11-01, MSRV parece ser Rust 1.40.0 para usar la caja y 1.42.0 para que las pruebas DOC pasen sin errores sobre el asignador global. Con la función simd-accel , el MSRV es aún más alto.
Se proporciona una capa de compatibilidad que implementa la API que codifica el óxido en la parte superior del coding_rs como una caja separada (no se puede cargar en cajas.io). La capa de compatibilidad se escribió originalmente con la asupción de que Firefox la necesitaría, pero actualmente no se usa en Firefox.
Para regenerar el código generado:
https://github.com/hsivonen/encoding_c junto al directorio encoding_rs .https://github.com/hsivonen/codepage junto al directorio encoding_rs .https://github.com/whatwg/encoding junto al directorio encoding_rs .1d519bf8e5555cef64cf3a712485f41cd1a6a990 del repositorio encoding . (Nota: f381389 fue la revisión de encoding utilizada antes del cambio de la licencia de repo encoding ).encoding_rs como directorio de trabajo, ejecute python generate-encoding-data.py . usize en lugar de u8 a la vez). alloc (con una superficie API menor). std::simdunsafe de corte por tipos más grandes que u8 / u16 a align_to . portable_simd de la biblioteca estándar en lugar de la caja packed_simd . Solo afecta la función Opcional nocturna simd-accel .unsafe .rust-version a Cargo.toml .packed_simd en lugar de packed_simd_2 nuevamente ahora que las actualizaciones están de vuelta bajo el nombre packed_simd . Solo afecta la función Opcional nocturna simd-accel .build.rs eliminado. (Esta eliminación debe resolver los falsos positivos informados por algunos productos antivirus. Esto puede romper algunas configuraciones de compilación que hayan optado por las garantías de Rust en las roturas futuras de construcción).no_std .no_std (con alloc ).simd-accel .packed_simd a packed_simd_2 .cfg-if a 1.0.cfg-if actualizado a la edición 2018 sin un descanso de Semver.Decoder::latin1_byte_compatible_up_to no devuelve None en más casos para que el método sea realmente útil. Si bien se podría argumentar que esto es un cambio de ruptura debido a que la corrección de errores cambia la semántica, no rompe las personas que llaman que tuvieron que manejar el caso None de una manera razonable de todos modos.convert_str_to_utf16 .mem::convert_utf8_to_utf16_without_replacement .mem::utf8_latin1_up_to y mem::str_latin1_up_to .Decoder::latin1_byte_compatible_up_to .bincode (Dev Dependency) a 1.0.simd a packed_simd .simd-accel (lanzamiento de solo lectura).clippy:: prefijo de los nombres de pelusa de clippy.static al definir otra static ).is_single_byte() en Encoding .mem::decode_latin1() y mem::encode_latin1_lossy() .--features simd-accel funcionan con un compilador de canal estable para simplificar el sistema de compilación de Firefox.is_foo_bidi() no tratar U+FEFF (espacio sin descanso de ancho cero, también conocido como.is_foo_bidi() hicieron el informe true si la entrada contiene formularios de presentaciones hebreas (que son de derecha a izquierda pero no en un bloqueo de carretera de derecha a izquierda).convert_utf16_to_latin1_lossy .mem afirman que la entrada está en el rango U+0000 ... U+00ff (inclusive).mem proporcione conversiones de Latin1 y UTF-16 a UTF-8 que pueden lidiar con un espacio de salida insuficiente. La idea es usarlos primero con una asignación redondeada al tamaño del cubo de Jemalloc y hacer la peor asignación de casos solo si el redondeo de Jemalloc era insuficiente como la primera suposición.simd-accel específica introducida en la versión 0.8.1 en las conversiones entre UTF-16 y LATIN1 en el módulo mem .#[inline(never)] que no fue para la liberación.mem para aumentar el rendimiento al convertir buffers largos.mem .mem .replacement una etiqueta de la codificación de reemplazo. (Cambio de especificaciones).Encoding::for_name() . ( Encoding::for_label(foo).unwrap() ahora está lo suficientemente cerca después del cambio de etiqueta anterior).parallel-utf8 .&'static Encoding .Encoder::has_pending_state() público.simd a 0.2.0.7F correctamente en ISO-2022-JP.Hash para Encoding .InputEmpty sobre OutputFull cuando codifica con reemplazo y el búfer de salida que pasa es demasiado corto o el espacio restante en el búfer de salida es demasiado pequeño después de un reemplazo.PartialEq y Eq para los tipos de CoderResult , DecoderResult y EncoderResult .Encoder::encode_from_utf16 . (Debido a una supervisión, carecía de la solución que Encoder::encode_from_utf8 ya tenía).#[must_use] .parallel-utf8 ).simd-accel .Encoding de const a static para hacer que los referentes sean únicos en las cajas que usan las referencias.Encoding de FOO_INIT de tipo referencia para permitir que las cajas extranjeras inicialicen las matrices static con referencias a instancias Encoding incluso bajo las limitaciones de Rust que prohíben la inicialización de elementos de matriz tipo &'static Encoding con statics &'static Encoding .const para que funcione para que el uso de redes cruzados mantenga los referentes únicos.Cow de los métodos de no transmitir solo de óxido para codificar y decodificar.Encoding::for_bom() Devuelve la longitud de la nacimiento.simd-accel . (Requiere óxido nocturno).Encoder.encode_from_utf8_to_vec_without_replacement() . Agregar Encoding.is_ascii_compatible() .
Agregar Encoding::for_bom() .
Make == para Encoding la comparación de nombre de uso en lugar de comparación de puntero, porque los usos de las constantes de codificación en diferentes cajas dan como resultado diferentes direcciones y la constante no se puede convertir en estadísticas sin romper otras cosas.
El lanzamiento inicial.
