c++ - rusia - Verificar si hay UTF8 no válido

manual de programacion android pdf (2)

Buena respuesta, estoy sacando otra versión de esto por diversión.

UTF-8 usa un esquema general de Prosser y Thompson para codificar números grandes en secuencias de un solo byte. Este esquema en realidad puede representar 2 ^ 36 valores, pero para Unicode solo necesitamos 2 ^ 21. Así es como funciona. Deje que N sea el número que desea codificar (por ejemplo, un punto de código Unicode):

Si N <128, solo un byte 0nnnnnnn . El bit más alto es cero.
De lo contrario, varios bytes. El primer byte comienza con tantos como bytes hay en la secuencia, seguido por un cero, y luego los bits de datos; los bytes sucesivos comienzan con 10 seguidos por seis bits de datos. Ejemplos:
Secuencia de 3 bytes: 1110xxxx 10xxxxxx 10xxxxxx .
Secuencia de 5 bytes: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx .
Secuencia de 7 bytes: 11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx .

Una secuencia de kbyte se ajusta a 5 k + 1 bit (cuando k > 1), por lo que puede determinar cuántos bytes necesita para obtener N. Para decodificar, lea un byte; si su bit superior es cero, almacene su valor como está; de lo contrario, use el primer byte para calcular cuántos bytes hay en la secuencia y procesarlos todos.

Para Unicode a partir de hoy solo necesitamos como máximo k = 4 bytes.

Estoy convirtiendo del formato UTF8 al valor real en hexadecimal. Sin embargo, hay algunas secuencias inválidas de bytes que necesito atrapar. ¿Hay una forma rápida de verificar si un personaje no pertenece a UTF8 en C ++?

Siga las tablas en el estándar Unicode , capítulo 3. (Utilicé la versión Unicode 5.1.0 del capítulo (p103); era la Tabla 3-7 en la p94 de la versión Unicode 6.0.0, y estaba en p95 en el Unicode Versión 6.3 - y está en p125 de la versión Unicode 8.0.0)

Los bytes 0xC0, 0xC1 y 0xF5..0xFF no pueden aparecer en UTF-8 válido. Las secuencias válidas están documentadas; todos los demás son inválidos.

Tabla 3-7. Secuencias de bytes UTF-8 bien formadas

Code Points First Byte Second Byte Third Byte Fourth Byte U+0000..U+007F 00..7F U+0080..U+07FF C2..DF 80..BF U+0800..U+0FFF E0 A0..BF 80..BF U+1000..U+CFFF E1..EC 80..BF 80..BF U+D000..U+D7FF ED 80..9F 80..BF U+E000..U+FFFF EE..EF 80..BF 80..BF U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF

Tenga en cuenta que las irregularidades están en el segundo byte para ciertos rangos de valores del primer byte. El tercer y cuarto bytes, cuando es necesario, son consistentes. Tenga en cuenta que no todos los puntos de código dentro de los rangos identificados como válidos han sido asignados (y algunos son explícitamente ''no caracteres''), por lo que aún se necesita más validación.

Los puntos de código U + D800..U + DBFF son para substitutos altos UTF-16 y U + DC00..U + DFFF son para sustitutos bajos UTF-16; esos no pueden aparecer en UTF-8 válido (usted codifica los valores fuera de BMP - Basic Multilingual Plane - directamente en UTF-8), que es por qué ese rango se marca como inválido.

Otros rangos excluidos (byte inicial C0 o C1, o byte inicial E0 seguido de 80..9F, o byte inicial F0 seguido de 80..8F) son codificaciones no mínimas. Por ejemplo, C0 80 codificaría U + 0000, pero eso está codificado por 00, y UTF-8 define que la codificación no mínima C0 80 no es válida. Y el punto máximo del código Unicode es U + 10FFFF; Las codificaciones UTF-8 que comienzan desde F4 90 hacia arriba generan valores que están fuera de rango.