ANSI C UTF-8 problema

Question

Primero desarrollo una biblioteca de plataforma independiente utilizando ANSI C (no C++ y ninguna biblioteca no estándar como MS CRT o glibc, ...).

Después de algunas búsquedas, descubrí que una de las mejores formas de internacionalización en ANSI C es usar codificación UTF-8.

en UTF-8:

• strlen (s): siempre cuenta el número de bytes .
• mbstowcs (NULL, s, 0): Se puede contar el número de caracteres.

Pero tengo algunos problemas cuando quiero acceder aleatoriamente a los elementos (caracteres) de una cadena utf-8.

En la codificación ASCII:

char get_char(char* assci_str, int n) 
{ 
    // It is very FAST. 
    return assci_str[n]; 
} 

En UTF-16/32 de codificación:

wchar_t get_char(wchar_t* wstr, int n) 
{ 
    // It is very FAST. 
    return wstr[n]; 
} 

Y aquí mi problema en la codificación UTF-8:

// What is the return type? 
// Because sizeof(utf-8 char) is 8 or 16 or 24 or 32. 
/*?*/ get_char(char* utf8str, int n) 
{ 
    // I can found Nth character of string by using for. 
    // But it is too slow. 
    // What is the best way? 
} 

Gracias.

Answer 1

Quizás esté pensando en esto un poco erróneamente. UTF-8 es una codificación que es útil para serializar datos, p. escribiéndolo en un archivo o la red. Sin embargo, es una codificación muy poco trivial, y una cadena de puntos de código Unicode puede terminar en cualquier número de bytes codificados.

Lo que probablemente deba hacer, si desea manejar texto (dada su descripción), es almacenar primas, cadenas de ancho fijo internamente. Si va a Unicode (lo cual debería), necesita 21 bits por punto de código, por lo que el tipo integral más cercano es uint32_t. En resumen, almacena todas tus cadenas internamente como matrices de enteros. Luego puede acceder aleatoriamente a cada punto de código.

Codifique solamente a UTF-8 cuando está escribiendo en un archivo o consola, y decodifique desde UTF-8 al leer.

Por cierto, un punto de código Unicode todavía está muy lejos de un carácter. El concepto de un personaje está a muy alto nivel para tener una mecánica general simple. (Por ejemplo, "a" + "tumba de acento": dos puntos de código, ¿cuántos caracteres?)

Answer 2

Simplemente no puede. Si necesita muchas de estas consultas, puede crear un índice para la cadena UTF-8, o convertirlo a UTF-32 por adelantado. UTF-32 es una mejor representación en memoria, mientras que UTF-8 es bueno en el disco.

Por cierto, el código que listó para UTF-16 tampoco es correcto. Es posible que desee cuidar a los personajes sustitutos.

Answer 3

¿Qué desea contar? Como ha notado Kerrek SB, puede haber descompuesto los glifos, es decir, "é" puede representarse como un solo carácter (LATIN SMALL LETTER E WITH ACUTE U + 00E9), o como dos caracteres (LATIN SMALL LETER E U + 0065 COMBINING ACUTE ACCENT U + 0301). Unicode ha compuesto y descompuesto formas de normalización.

Lo que usted está probablemente interesado en el recuento no es caracteres, pero racimos de grafema. Necesita una biblioteca de nivel superior para manejar esto, y para tratar con formularios de normalización, colación adecuada (dependiente de la localidad), línea de corte adecuada, plegado de casos adecuado (por ejemplo, alemán ß-> SS), compatibilidad bidireccional adecuada, etc. .. Real I18N es complejo.

Answer 4

Al contrario de lo que otros han dicho, realmente no veo beneficio al usar UTF-32 en lugar de UTF-8: Al procesar texto, los conglomerados de grafemas (o 'caracteres percibidos por el usuario') son mucho más útiles que Unicode caracteres (es decir, puntos de código sin procesar), por lo que incluso UTF-32 debe tratarse como una codificación de longitud variable.

Si no desea utilizar una biblioteca dedicada, sugiero usar UTF-8 como en disco, representación endian-agnostic y UTF-8 modificado (que difiere de UTF-8 codificando el carácter cero como dos -byte sequence) como representación en memoria compatible con ASCIIZ.

La información necesaria para dividir cadenas en clústeres de grafema se puede encontrar en annex 29 y character database.