> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/es/articulos-en-profundidad/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 y texto multilingüe: una introducción

## Unicode y OpenType: caracteres y glifos

Los motores TeX modernos, es decir, XeTeX y LuaTeX, han evolucionado a partir del motor TeX original de Knuth en gran medida debido a la necesidad de seguir el ritmo de los avances en el panorama tecnológico, especialmente Unicode (para el texto) y OpenType (para las fuentes). Hoy en día, mediante el uso de paquetes como [fontspec](https://ctan.org/pkg/fontspec?lang=en) y [unicode-math](https://ctan.org/pkg/unicode-math?lang=en), los usuarios de LaTeX pueden acceder a capacidades de composición tipográfica extremadamente sofisticadas proporcionadas por las fuentes OpenType, incluida la composición tipográfica multilingüe avanzada y la composición tipográfica matemática basada en OpenType ([pionero de Microsoft](https://blogs.msdn.microsoft.com/murrays)).

Sin embargo, para sacar el máximo partido al uso de fuentes OpenType con XeTeX/LuaTeX, puede ser útil familiarizarse con una serie de temas/conceptos de fondo, especialmente para solucionar problemas o para allanar el camino hacia trabajos más avanzados/complejos. Por ejemplo, podrías leer que los motores XeTeX y LuaTeX usan “entrada UTF-8” o que son “compatibles con Unicode”, y una lectura adicional sobre las fuentes OpenType podría tratar o mencionar temas como “codificación Unicode”, “funciones de fuente” de OpenType, “glifos”, “identificadores de glifo”, “nombres de glifo” y así sucesivamente. Nuestro objetivo es ofrecer una introducción a estos términos/temas y construir un marco básico para mostrar cómo se relacionan y, con suerte, proporcionar apoyo para trabajos posteriores o la resolución de problemas.

Los temas que pretendemos cubrir se dividen bastante claramente en dos áreas principales: *Unicode* que, en efecto, habita en el mundo del texto/caracteres y de la codificación de texto y *OpenType* cuyo mundo es el de las fuentes y los glifos; pero, por supuesto, esos dos mundos están interconectados y hay cierto solapamiento, incluso en este primer artículo.

### ¿Qué temas vamos a discutir?

El enfoque principal de este artículo es algunos temas relacionados con Unicode: empezando con una discusión sobre qué se entiende por “carácter” y pasando a presentar escrituras/idiomas, la codificación Unicode y UTF-8, junto con un ejemplo de trabajo con archivos de texto multilingües. Un artículo de seguimiento ampliará este texto para cubrir temas de fondo relacionados con la tecnología de fuentes OpenType. Claramente, dentro de los límites de una entrada de blog no es posible intentar una “inmersión profunda” en todas las áreas que esperamos discutir: nuestro objetivo declarado es proporcionar el marco general que muestre cómo se relacionan y trabajan juntos algunos conceptos clave. Empezaremos con el concepto más básico: el de *carácter*.

## El carácter: un bloque básico de construcción

Una idea/concepto fundamental que está en el corazón de nuestras discusiones (y de Unicode) es el significado de “carácter”: es una de esas palabras cuyo significado suele darse por supuesto a través de su uso en el trabajo diario y las conversaciones. Sin embargo, desde la perspectiva de Unicode, la composición tipográfica y las tecnologías de fuentes, necesitamos ser un poco más precisos y definir qué se entiende por “un carácter”. Por ejemplo, podría resultarnos bastante natural pensar en **a** y *a* como diferentes “caracteres”: ‘a en negrita’ y ‘a en cursiva’. Pero no es así: son simplemente distintas representaciones visuales del mismo carácter fundamental, al que Unicode da el nombre oficial [LETRA MINÚSCULA LATINA A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [define un carácter](http://www.unicode.org/glossary/#character) como:

> “El componente más pequeño del lenguaje escrito que tiene valor semántico; se refiere al significado y/o forma abstractos, en lugar de a una forma específica...”

que distingue claramente entre la *aspecto visual* específica *y su*.

significado *script*Puedes pensar en un carácter como la unidad fundamental, o bloque de construcción, de un idioma o, más correctamente, una *y su* —un tema que discutimos más abajo. Lo que un carácter realmente parece cuando se muestra usando una fuente particular no es relevante para la definición de carácter de Unicode: solo la *función y propósito* de cada carácter como uno de un conjunto de bloques de construcción a partir de los cuales se construyen en última instancia las escrituras/idiomas.

### Escritura e idioma

Vale la pena mencionar brevemente dos conceptos importantes: *las escrituras* y *idiomas*. El sitio web de Unicode ofrece una útil [definición de una escritura](https://www.unicode.org/standard/supported.html):

> “El Estándar Unicode codifica escrituras en lugar de idiomas. Cuando los sistemas de escritura de más de un idioma comparten conjuntos de símbolos gráficos que históricamente tienen derivaciones relacionadas, la unión de todos esos símbolos gráficos se trata como una sola colección de caracteres para la codificación y se identifica como una sola escritura.”

Usando un [ejemplo de Wikipedia](https://en.wikipedia.org/wiki/Script_\(Unicode\)), la escritura latina está compuesta por una [colección de caracteres](http://unicode.org/charts/) que se usan en múltiples idiomas: inglés, francés, alemán, italiano, etc. Por supuesto, no todos los caracteres definidos dentro de la escritura latina son usados por todos los idiomas basados en la escritura latina—por ejemplo, el alfabeto inglés no contiene los caracteres acentuados presentes en otros idiomas europeos como el francés o el alemán.

### Fuentes OpenType: escrituras e idiomas

En este punto pasaremos de Unicode a las fuentes OpenType porque los conceptos de escritura e idioma también desempeñan un papel extremadamente importante dentro de la tecnología de fuentes OpenType.

Un conjunto de idiomas que usan la misma [script](http://www.unicode.org/glossary/#script) puede tener diferentes tradiciones tipográficas cuando se trata de mostrar (componer tipográficamente) texto escrito en un idioma particular. Un buen ejemplo se encuentra en el idioma turco y el [comportamiento de la i sin punto](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (véanse las notas de esa página sobre las ligaduras). Las “reglas” tipográficas relacionadas con escrituras/idiomas están incorporadas en la funcionalidad de las fuentes OpenType mediante el uso de las llamadas etiquetas de escritura e idioma *etiquetas* que se utilizan para identificar reglas que deben aplicarse a combinaciones concretas de escritura/idioma. Naturalmente, el conjunto de escrituras/idiomas admitidos por cada fuente OpenType variará según las decisiones tomadas por los creadores de la fuente y el motivo de su producción. El software de composición tipográfica sofisticado, como XeTeX o LuaTeX, puede aprovechar esas reglas (integradas en las fuentes OpenType) permitiendo a los usuarios aplicarlas selectivamente al texto de entrada al componer texto en un idioma particular; por ejemplo, usando el paquete de LaTeX [paquete fontspec](https://ctan.org/pkg/fontspec?lang=en).

#### Mirando dentro de una fuente OpenType: escrituras/idiomas

Para aclararlo mejor, aquí hay una captura de pantalla que muestra la fuente OpenType gratuita [Scheherazade](http://software.sil.org/scheherazade/download/) abierta dentro del software (también gratuito) de [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) de edición de fuentes. En esta imagen puedes ver las escrituras, idiomas y funciones tipográficas que están integradas en Scheherazade; usando VOLT puedes añadir funciones y capacidades adicionales a Scheherazade, pero eso queda muy fuera del alcance de este artículo.

![La fuente OpenType (de sabor TrueType) Scheherazade abierta dentro de Microsoft VOLT](/files/2ce942c6a73e26214c29cff6b22584361b489c6d)

A partir de esta captura puedes ver que Scheherazade admite las escrituras árabe y latina y proporciona además compatibilidad especializada para varios idiomas que usan la escritura árabe, mediante las llamadas funciones OpenType, que se enumeran en el recuadro con borde verde de arriba. No entraremos en los detalles específicos de estas funciones, pero la idea aquí es que las fuentes OpenType de alta calidad incorporan mucha inteligencia, listas para ser usadas por software de composición tipográfica capaz de aprovechar las reglas tipográficas integradas en las fuentes.

El lector interesado puede consultar el registro de etiquetas de OpenType para ver las [etiquetas de escritura](https://www.microsoft.com/typography/otspec/scripttags.htm) y [etiquetas de idioma](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) actualmente usadas dentro de la especificación OpenType.

### De vuelta a los caracteres: diferentes roles de los caracteres

El conjunto de caracteres que componen los elementos fundamentales de una escritura (o idioma) no desempeña todos el mismo papel. Por ejemplo, en la mayoría de los idiomas hay caracteres para *puntuación*, caracteres para *dígitos* numéricos, así como caracteres que pensamos como *letras* del alfabeto, que para algunas escrituras también existen en formas mayúsculas y minúsculas. El concepto de carácter es bastante amplio y el Estándar Unicode incluye caracteres especializados que *no están diseñados para ser mostrados* pero cuya función es “controlar la interpretación o visualización del texto”. Por ejemplo, al componer algo de texto árabe puedes querer forzar, o impedir, el comportamiento de unión de ciertos caracteres; el estándar Unicode proporciona caracteres de control especiales para hacer esto: los llamados [UNIÓN DE ANCHO CERO](https://en.wikipedia.org/wiki/Zero-width_joiner) y el [NO UNIÓN DE ANCHO CERO](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Esos caracteres no están destinados a mostrarse y el software los “absorbe” mientras procesa el texto para producir los efectos visuales deseados.

A todos los caracteres especificados dentro del estándar Unicode se les asigna un conjunto de propiedades que, en efecto, describe la función y propósito de cada carácter en la codificación Unicode; nombres de caracteres, como LETRA MINÚSCULA LATINA A, son solo un elemento de la lista de propiedades de un carácter. Estas propiedades se describen completamente en la [Base de datos de caracteres Unicode (UCD)](http://www.unicode.org/reports/tr44/) y se utilizan ampliamente en operaciones informatizadas de procesamiento de texto, como búsqueda, ordenación, corrección ortográfica, etc. Los archivos de datos que enumeran las propiedades de los caracteres Unicode también están [disponibles para descarga](http://www.unicode.org/Public/UCD/latest/).

Entre las propiedades asignadas a cada carácter, la más importante para nuestra discusión es un *identificador numérico* asignado por su codificación Unicode, un tema al que ahora pasamos.

### Caracteres: números y codificaciones

Es una obviedad, pero las computadoras y otros dispositivos digitales se dedican a almacenar y procesar datos numéricos: entonces, ¿cómo se relaciona esto con el texto? Cuando escribes texto usando un teclado de computadora, o tocando la pantalla de un dispositivo móvil, las pulsaciones se convierten en números que representan la cadena de caracteres que estás tecleando.

En algún momento puedes querer transferir ese texto (una secuencia de números) por correo electrónico, un mensaje de texto o mediante comunicación en línea como un tuit o una publicación en alguna forma de red social. Claramente, el dispositivo en el que compusiste el texto y el/los dispositivo(s) usados por su(s) destinatario(s) deben, de alguna manera, ponerse de acuerdo sobre qué números representan qué caracteres. Si no, tu texto podría no mostrarse correctamente en el dispositivo del destinatario.

Para que las comunicaciones globales de hoy funcionen, los dispositivos que envían y reciben necesitan alguna “convención mutuamente acordada” mediante la cual un conjunto determinado de números representa un conjunto específico de caracteres. Esta convención se llama *codificación*: un conjunto de números usados para representar un conjunto particular de caracteres y la codificación Unicode es ahora el *de facto* estándar mundial.

## Unicode: bits y bytes para almacenar texto

Unicode es un estándar enorme que cubre muchísimo más que la simple codificación de texto, pero aquí nos estamos centrando solo en la codificación que proporciona.

#### ¿Bits, bytes y cuántos caracteres?

Hemos mencionado que los dispositivos almacenan y representan texto como números—más concretamente, los caracteres se almacenarán como enteros: números enteros. Para entender las implicaciones de esto para la codificación Unicode, necesitamos hacer una *muy* breve, *muy* revisión básica de cómo las computadoras almacenan enteros (no pretendemos adentrarnos en la informática).

Para resumir una historia muy larga, los dispositivos de escritorio o de mano actuales almacenan enteros en “bloques” discretos que pueden tener 1, 2, 4 u 8 bytes de longitud. Cada una de estas unidades de almacenamiento puede almacenar enteros hasta un valor positivo máximo basado en el número total de bits contenidos en cada unidad:

* 1 byte (8 bits): el entero positivo máximo es 255;
* 2 bytes (16 bits): el entero positivo máximo es 65535;
* 4 bytes (32 bits): el entero positivo máximo es 4,294,967,295;
* 8 bytes (64 bits): el entero positivo máximo es 18,446,744,073,709,551,615.

En la práctica, el estándar Unicode usa números en el rango de 0 a 1,114,111 para codificar todos los caracteres del mundo, de modo que solo necesita 21 bits para codificar el rango completo. Podemos verlo observando que las unidades de almacenamiento que contienen n bits pueden representar cualquier entero positivo desde 0 hasta un valor máximo de $$2^n -1$$; por consiguiente:

* el valor máximo que puede almacenarse en 20 bits es $$2^{20} -1 = 1,048,575$$ (demasiado pequeño);
* el valor máximo que puede almacenarse en 21 bits es $$2^{21} -1 = 2,097,151$$ (suficientemente grande).

Hemos señalado que las computadoras almacenan datos (números) en unidades de 1, 2, 4 (u 8) bytes, así que ¿cuán grande debe ser la unidad de almacenamiento si tenemos que almacenar valores hasta el valor máximo Unicode de 1,114,111? Claramente, una unidad de almacenamiento del tamaño de un byte puede contener un valor máximo de 255 y 2 bytes pueden almacenar 65535: ninguno de los dos es suficiente para almacenar el rango completo de caracteres codificados por Unicode. La siguiente opción disponible son unidades de almacenamiento cuyo tamaño es de 4 bytes, que pueden almacenar enteros de hasta un máximo de 4,294,967,295, mucho más de lo que realmente necesitaríamos. Así que, si elegimos 4 bytes como nuestra unidad de almacenamiento, ciertamente tenemos espacio de sobra para almacenar todos los valores Unicode, almacenándose cada carácter como un entero que requiere 4 bytes (32 bits). Sin embargo, usar 4 bytes para almacenar todo es un enorme despilfarro de espacio porque incluso los valores Unicode más grandes necesitan un máximo de 21 bits, lo que, si se almacenaran usando 32 bits, significaría que 11 de esos 32 bits nunca se usarían.

**Nota**: Aunque el rango Unicode se extiende de 0 a 1,114,111, no todos los valores de ese rango se usan realmente: por razones técnicas, algunos valores se consideran inválidos para su uso real como caracteres Unicode.

### Entonces, ¿qué es UTF-8?

Si lees sobre XeTeX o LuaTeX, casi seguro encontrarás explicaciones que afirman que esos motores TeX leen textos y archivos de entrada de LaTeX en “formato UTF-8”. Entonces, ¿qué es el “formato UTF-8” y cómo se relaciona con Unicode? En la terminología de Unicode, cada uno de sus 1,114,112 valores (que van de 0 a 1,114,111) usados para codificar los caracteres del mundo se llama [punto de código](http://www.unicode.org/glossary/#code_point).

Hemos visto que, *en teoría*, necesitaríamos almacenar todo nuestro texto codificado en Unicode usando 4 bytes por carácter para representar el rango completo de puntos de código Unicode. Sin embargo, en la práctica, algunas personas bastante ingeniosas inventaron una forma sencilla de representar un único número Unicode (punto de código) como una *secuencia* de números más pequeños, y cada uno de esos números más pequeños se almacena en un solo byte: un proceso que *transforma* un único entero (más grande) en una secuencia de otros más pequeños (del tamaño de un byte). Debido a esta transformación, los caracteres de nuestro archivo de texto ya no están cada uno representados por un único valor numérico: cada carácter pasa a ser una *secuencia multibyte*—cualquier cosa de 1 a 4 bytes consecutivos en el archivo de texto puede representar un único carácter Unicode individual (es decir, el valor de su punto de código).

UTF significa *Formato de transformación Unicode* y la palabra clave aquí es *Transformación*. En esencia, puedes pensar en UTF-8 como una “receta” o algoritmo para convertir (transformar) un único valor de punto de código Unicode en una secuencia de 1 a 4 partes del tamaño de un byte. A medida que aumenta el valor del punto de código Unicode, también aumenta el número de bytes individuales necesarios para representarlo en formato UTF-8.

Hay razones técnicas e históricas para crear UTF-8 y la historia detrás de la invención de UTF-8 está [registrada en un fascinante correo electrónico de 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), que, al principio del correo, contiene la línea:

> “No es cierto. UTF-8 fue diseñado, delante de mis ojos, sobre un mantel de papel en un restaurante de Nueva Jersey una noche de septiembre de 1992, más o menos.”

#### Un ejemplo: la letra árabe ل

Tomemos como ejemplo la letra árabe ل (nombre Unicode LETRA ÁRABE LAM), a la que se le asigna el valor de punto de código Unicode 1604 (decimal) o 0644 (hexadecimal): su representación en UTF-8 es la *secuencia de dos bytes* D9 84 (hex) o, en decimal, 217 132. Al usar UTF-8 como formato para almacenar texto, en lugar de un archivo de texto que contenga el número único 1604 para representar ل, se convierte en dos valores del tamaño de un byte: 217 y 132; el carácter ل se almacena como una *secuencia de dos bytes*. Los lectores que quieran explorar el algoritmo UTF-8 con más detalle pueden encontrar una explicación exhaustiva, y código C, en mi [sitio web personal de este autor](http://www.readytext.co.uk/?p=1284).

Cuando una pieza de software (p. ej., XeTeX o LuaTeX) lee texto en formato UTF-8, ese software necesita determinar el valor Unicode de cada carácter presente en ese archivo, así que utiliza un algoritmo para *revertir* el proceso de transformación UTF-8. Mediante ese “algoritmo inverso” los dos bytes (217 y 132) se recombinan para generar el entero 1604, que luego puede reconocerse como el valor de punto de código Unicode para la letra árabe ل.

Así, en conclusión, UTF-8 realmente es solo un formato de datos intermedio usado para el almacenamiento y la transmisión de texto codificado en Unicode.

**Nota**: Algunos sistemas eligen usar/almacenar texto usando 32 bits por carácter, esto se llama [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—también existe [UTF-16](https://en.wikipedia.org/wiki/UTF-16) pero UTF-8 es la forma más común de almacenar texto codificado en Unicode.

## Archivos TeX multilingües: XeTeX y LuaTeX

Tanto XeTeX como LuaTeX son capaces de una composición tipográfica multilingüe muy sofisticada, aunque sus mecanismos para lograrlo son bastante diferentes y reflejan la filosofía de diseño/desarrollo de cada motor. No exploraremos esto en profundidad, pero simplemente señalaremos que el motor XeTeX contiene componentes de software (integrados en su ejecutable) que no están presentes en LuaTeX, sobre todo software para un proceso llamado *la composición de glifos OpenType* (por ejemplo, mediante una biblioteca llamada [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

En cambio, LuaTeX adopta un enfoque diferente: en lugar de integrar capacidades directamente en el propio motor TeX, LuaTeX ofrece una colección extremadamente rica de comandos (primitivas TeX) y una muy potente [API basada en Lua](/latex/es/articulos-en-profundidad/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) mediante la cual los desarrolladores pueden construir soluciones igualmente avanzadas para la composición tipográfica multilingüe. Aunque la filosofía de LuaTeX puede implicar trabajo adicional para los desarrolladores de paquetes de LaTeX, proporciona mucha flexibilidad adicional porque las soluciones no están “codificadas de forma rígida” en el propio motor LuaTeX, sino que se construyen a partir de código TeX y Lua, o de plugins escritos en C/C++.

**Aparte**: Los lectores que deseen explorar más a fondo el fascinante, pero complejo, mundo de la composición de glifos OpenType pueden interesarse en leer sobre la excelente biblioteca de código abierto llamada [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—usada por muchas aplicaciones, incluyendo Firefox, Chrome y LibreOffice y, por supuesto, por XeTeX. El autor de este artículo ha usado HarfBuzz para crear [plugins de LuaTeX para hacer composición tipográfica árabe](http://www.readytext.co.uk/?p=3186).

Hoy en día es común (p. ej., en las redes sociales) transmitir texto que contiene caracteres de múltiples idiomas y un archivo de texto UTF-8 que almacena texto multilingüe puede contener fácilmente caracteres cuya representación en UTF-8 mide 1, 2, 3 o 4 bytes de longitud. Así que, en efecto, un archivo de texto UTF-8 es solo un flujo de bytes individuales, pero cada carácter real en ese archivo podría ser cualquier cosa de 1 a 4 bytes de longitud: los caracteres individuales se han convertido en *secuencias multibyte*.

Para explorar más a fondo algunos aspectos clave del trabajo con texto multilingüe (composición tipográfica) usaremos un ejemplo que contiene la escritura árabe porque el árabe nos brinda margen para abordar múltiples conceptos.

#### Aparte: la escritura árabe

El [La escritura árabe](https://en.wikipedia.org/wiki/Arabic_script) se escribe en un estilo cursivo que se lee y escribe de derecha a izquierda. Cada letra árabe puede, potencialmente, adoptar una de 4 formas diferentes según:

* si se muestra como un carácter único, aislado y autónomo (aislado), que no está unido a nada más;
* si aparece dentro de una palabra—al principio, en el medio o al final de una palabra: se denomina *iniciales*, *mediales* y *final* respectivamente.

Cada carácter de la escritura árabe tiene su propio conjunto de reglas de unión y puede, o no, cambiar de forma/apariencia cuando tiene otro carácter a su izquierda, a su derecha o a su izquierda y derecha. Los lectores interesados en explorar esto más a fondo pueden encontrar una [lista completa en Wikipedia](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Ejemplo: texto árabe e inglés en UTF-8

Supongamos que creamos un archivo de texto UTF-8 que contiene una sola línea de texto en inglés y árabe: This is العَرَبِيَّة text!

Esta línea de texto contiene 3 caracteres de espacio, 11 caracteres en inglés (escritura latina) y 12 caracteres árabes (aunque eso puede no ser inmediatamente obvio/aparente). Cuando se guarda como un archivo de texto UTF-8 ocupa 38 bytes de almacenamiento, resultantes de lo siguiente:

* **Escritura latina**: espacios más texto en inglés: 14 ✕ 1 byte por carácter = 14 bytes;
* **La escritura árabe**: 12 caracteres árabes ✕ 2 bytes por carácter = 24 bytes.

Un total de 14 + 24 = 38 bytes.

#### Profundizando

Si guardamos nuestro texto de ejemplo en un archivo UTF-8 llamado `arabic.txt` y lo abrimos en un editor hexadecimal, podemos examinarlo para ver los bytes reales que contiene. A partir del estudio de la siguiente captura de pantalla anotada, puedes ver que el texto árabe se almacena como 2 bytes por carácter:

![Un archivo de texto UTF-8 que contiene texto en inglés y árabe abierto en un editor hexadecimal.](/files/28221ead79a67596054b984f65a6cd270959b877)

Un archivo de texto UTF-8 que contiene texto en inglés y árabe abierto en un editor hexadecimal. Puedes ver claramente que los caracteres de la escritura latina requieren un solo byte, pero los caracteres de la escritura árabe se almacenan usando dos bytes por carácter.

Puedes sacar un par de observaciones de esta captura de pantalla:

* el texto árabe se almacena en una secuencia de izquierda a derecha y los caracteres son las versiones crudas, sin formar, aisladas de las letras y vocales árabes;
* no hay información adicional después de la escritura latina “This is ” para informar a ningún software que lea este archivo que el siguiente carácter está en la escritura árabe.

Si estás componiendo un documento multilingüe (por ejemplo, que contiene inglés y árabe), entonces durante la lectura/procesamiento del archivo de texto de entrada (como un flujo de bytes) XeTeX o LuaTeX deben poder detectar el inicio y el final de cada carácter y leer el número correcto de bytes necesario para invertir la transformación UTF-8 y generar el punto de código Unicode correspondiente. Es el propio algoritmo UTF-8 el que permite al software hacer esto: permite detectar el primer byte de cada carácter individual y cuántos bytes deben leerse para calcular el punto de código Unicode correspondiente. UTF-8 es fácil de usar, pero realmente muy ingenioso.

#### Orden lógico, orden de visualización y composición de glifos OpenType

Si miras de cerca el árabe de arriba (العَرَبِيَّة) puede ser difícil ver que nuestro archivo de texto sí contiene 12 caracteres árabes individuales, especialmente si no estás familiarizado con la escritura árabe. Sin embargo, si cuentas cuidadosamente los caracteres árabes mostrados en el lado derecho de la captura anterior puedes ver que hay 12 en total.

En el caso de idiomas de escritura compleja, como el árabe, lo que nuestro archivo de texto *almacena* y lo que tú *ves en pantalla* son visiblemente *muy* ¡distintos, de hecho! Lo que ves al ver ese texto en, por ejemplo, un navegador, es (según la fuente utilizada):

![Imagen de texto árabe compuesto tipográficamente](/files/244edc1f7b47edd1f4b14630d3d76fc9fc1ba523)

Pero, como muestra la captura anterior, lo que realmente contiene el archivo de texto UTF-8 es esto:

![Imagen de texto árabe no compuesto tipográficamente (caracteres aislados)](/files/42e92037347995345af2b13c4d690699e98cdf70)

Incluso si no estás familiarizado con la naturaleza cursiva de la escritura árabe, puedes ver claramente que “algo” ha sucedido durante el proceso de transferir los caracteres árabes contenidos en un archivo de texto hasta la composición tipográfica y/o la visualización en pantalla (como glifos). Si estás acostumbrado a usar TeX/LaTeX con idiomas de escritura simple, por ejemplo idiomas basados en el latín, ¡esto puede ser muy confuso!

Aquí intervienen algunos conceptos importantes porque los archivos de texto Unicode se dedican a almacenar... bueno, texto (Unicode), y los sistemas de composición tipográfica y visualización se dedican a usar fuentes y glifos (OpenType):

* el archivo de texto guardó los caracteres árabes en un orden de izquierda a derecha, pero el árabe se lee/muestra de derecha a izquierda: los archivos de texto almacenan texto en el llamado *orden lógico*;
* el archivo de texto contiene caracteres individuales que se ven muy diferentes a la visualización real presentada en la pantalla: el archivo de texto contiene los caracteres árabes en su forma aislada, no unida.

#### ¿Qué está pasando?

Dentro de un archivo de texto, el árabe se almacena como una secuencia de caracteres de forma aislada de izquierda a derecha: si lo piensas, el archivo de texto almacena el texto árabe en el orden/secuencia *en que fue escrito* (la *orden lógico*). Es solo cuando ese texto se procesa para su visualización, o se compone tipográficamente, que se muestra en su orden de lectura correcto, al que a menudo se llama el *orden visual* o *orden de visualización*; además, las formas aisladas de los caracteres árabes se *forman* en sus versiones de visualización tipográficamente correctas. Una forma de pensar en esto es que un archivo de texto simple tiene que almacenar texto (caracteres Unicode) en la forma más básica posible: caracteres de texto crudos, sin formar e individuales—la tarea del software del sistema es renderizar esos caracteres para su visualización basándose en el sistema operativo, las fuentes y el software de composición/renderizado disponibles en el dispositivo de visualización.

Cuando el texto árabe de ese archivo se compone tipográficamente/se muestra, pasa por un proceso llamado *formado*. Los caracteres árabes individuales se convierten en glifos formados que representan correctamente la variante de cada carácter requerida según las reglas de unión de la escritura y el sistema de escritura árabes. Además, el software de composición tipográfica de alta calidad (que usa buenas fuentes OpenType) añadirá más procesamiento aplicando una mayor sofisticación tipográfica mediante un proceso llamado *la composición de glifos OpenType*—un proceso que abarca una amplia gama de operaciones tipográficas que pueden incluir:

* reemplazar múltiples glifos individuales por un único glifo de ligadura compleja (muy común en árabe), o
* operaciones de posicionamiento que, por ejemplo, ajustan las posiciones de las vocales árabes según qué glifo tengan encima o debajo.

![Imagen que muestra la transformación que sufre el texto árabe cuando se compone tipográficamente](/files/4c6ee9a5cfb90b58d5ffb63d285fce1d5cd00bab)

La diferencia entre el orden lógico y el orden visual (de visualización). En este gráfico puedes ver que los caracteres árabes almacenados en un archivo de texto se reordenan y se dan forma cuando se muestran o se componen tipográficamente.

Los diseñadores y creadores de fuentes OpenType avanzadas invierten muchísimo tiempo y conocimientos para ofrecer las sofisticadas capacidades tipográficas integradas en sus fuentes.

Para desactivar la formación tipográfica aplicada al texto árabe podemos usar el excelente y gratuito, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) editor de texto Unicode (solo para Windows) que te permite desactivar la formación tipográfica para ver los caracteres sin procesar, individuales y no unidos (sin dar forma) que están realmente presentes en el archivo de texto—véase la mitad inferior de esta captura combinada:

![Imagen que muestra la capacidad del editor de texto BabelPad para desactivar la formación tipográfica OpenType](/files/9ca6cbebba4fe346e831e898fede9fe90258b936)

Uso del editor de texto Unicode BabelPad para activar la formación tipográfica OpenType (figura superior) o desactivarla (figura inferior). Desactivar la formación tipográfica OpenType facilita mucho la edición de texto árabe.

Los conceptos de orden lógico y orden de visualización, junto con los procesos de formación tipográfica, pueden resultar bastante confusos cuando los encuentras por primera vez al editar o componer textos multilingües que contienen escrituras complejas como el árabe: con suerte, lo anterior ha ayudado a evitar algo de la confusión inicial.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/es/articulos-en-profundidad/51-unicode-utf-8-and-multilingual-text-an-introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.