Fase 3 · SE-015 · Clase

Texto, Unicode, codificaciones y mojibake

Una clase de la Parte 01 — Computadores y representación de información. Comprende el mecanismo, úsalo para decidir y conserva evidencia revisable.

Contenido desarrollado como parte del recorrido completo de las Partes 00–05.
Vienes deBits, bytes, bases numéricas y representación
Construyes ahoraTexto, Unicode, codificaciones y mojibake
Conecta conEnteros, coma flotante, precisión y errores numéricos

← SE-014 · ↑ Parte 01 · 📚 Índice completo · SE-016 →

Punto profesional y fundamento pedagógico

Punto profesional. La clase existe para distinguir carácter, punto de código, unidades de código, bytes y glifo al diagnosticar texto.

Por qué aparece aquí. Se sitúa después de Bits, bytes, bases numéricas y representación y antes de Enteros, coma flotante, precisión y errores numéricos: convierte el conocimiento anterior en una decisión observable que la clase siguiente podrá reutilizar. La continuidad se comprueba en el artefacto, no por compartir vocabulario.

Error conceptual que debe corregir. Tratar Unicode como una codificación única o suponer que toda corrupción es reversible.

Secuencia de aprendizaje. Conserva primero los bytes originales; luego predice puntos de código, UTF-8 y longitudes NFC/NFD de la entrada. Reproduce un mojibake en una copia, reconstruye la transformación y pide a otra persona que determine qué casos son reversibles. La recuperación se evalúa por la cadena causal, no porque el texto vuelva a verse bien.

Evidencia de aprendizaje. Text-lab.md con code points, hex, normalización y un fallo de decodificación reproducible. Debe contener predicción previa, observación, explicación causal, contraejemplo, criterio de aceptación y una nota de qué dato haría cambiar la conclusión.

Límite de la conclusión. Unicode no determina por sí solo tipografía, shaping ni bidi.

Trazabilidad fuente → afirmación

Fuente primaria u oficialAfirmación que respaldaLo que no prueba
The Unicode Standard 18.0define el modelo y las propiedades Unicode vigentesNo demuestra por sí sola que el artefacto del estudiante sea correcto.
Unicode UTF FAQexplica UTF-8, UTF-16 y BOMNo demuestra por sí sola que el artefacto del estudiante sea correcto.
Unicode Normalization Annex #15define las formas de normalizaciónNo demuestra por sí sola que el artefacto del estudiante sea correcto.

Antes de empezar

SE-014 mostró que los bits necesitan un contrato. Ahora el analizador local de eventos debe conservar Matrícula José ✓. La pantalla parece mostrar “caracteres”, pero el sistema intercambia bytes. Construirás la cadena carácter → punto de código → codificación → bytes y la usarás para provocar y reparar mojibake de forma explicada.

Prerrequisitos

Bits, bytes y hexadecimal de SE-014; Python 3.11+; archivos desechables.

Problema auténtico

Un CSV correcto llega como Matrícula. Reemplazar visualmente í por í puede corromper otros datos porque el síntoma procede de decodificar UTF-8 como otra codificación y volver a serializar. Se necesita reconstruir la transformación.

Objetivos observables

Distinguirás carácter, grafema, punto y unidad de código; explicarás UTF-8; demostrarás ida y vuelta; compararás normalizaciones; y diagnosticarás mojibake conservando bytes.

Temas y por qué importan

TemaMecanismoPor qué importa
Modelo Unicodeasigna puntos de código a caracteres abstractospermite intercambio entre escrituras
UTF-8transforma puntos en bytes únicossostiene archivos y protocolos modernos
Normalizacióncompara secuencias equivalentes según formaevita claves visualmente iguales pero distintas
Mojibakebytes se decodifican con contrato incorrectopermite reparar causa, no apariencia

Mapa conceptual

Mapa visualRelaciones que debes poder explicar
Carácter abstracto íPunto U+00ED
Punto U+00EDUTF-8
UTF-8Bytes C3 AD
Ver la notación fuente del diagrama
flowchart LR
 C[Carácter abstracto í] --> P[Punto U+00ED]
 P --> E[UTF-8]
 E --> B[Bytes C3 AD]
 B -->|UTF-8| C
 B -->|Windows-1252| X[Texto mojibake í]

La última flecha muestra el mecanismo del síntoma. El dibujo simplifica grafemas: lo visible puede contener varios puntos de código.

Conceptos y decisiones

1. Texto visible no equivale a una unidad técnica

Un carácter abstracto pertenece al repertorio Unicode. Un punto de código es su número. Una unidad de código es una unidad de una forma como UTF-16. Un grafema es una unidad que una persona percibe como carácter y puede reunir varios puntos. Por eso len() depende del modelo del lenguaje y no siempre cuenta símbolos percibidos.

2. Unicode es repertorio; UTF-8 es una forma de codificación

Unicode asigna puntos de código. UTF-8 los transforma en secuencias de uno a cuatro bytes y conserva ASCII como bytes iguales. Es reversible para secuencias válidas. El orden de bytes del procesador no altera UTF-8 porque se interpreta byte a byte. Un BOM en UTF-8 puede actuar como firma, no como indicador de endianess.

3. Codificar y decodificar son operaciones inversas bajo el mismo contrato

text.encode('utf-8') produce bytes; data.decode('utf-8') produce texto. Sin una codificación declarada, los bytes no contienen una etiqueta universal. Las políticas strict, replace o ignore cambian si el error se detiene, se hace visible o se pierde. Ignorar puede ser aceptable en visualización no crítica, pero es peligroso para identidades o registros auditables.

4. Normalización trata equivalencias, no apariencia universal

é puede ser U+00E9 o e más un acento combinante. NFC y NFD transforman entre formas canónicas; NFKC/NFKD aplican compatibilidad y pueden cambiar distinciones significativas. Normalizar ayuda a comparar, pero no reemplaza reglas de dominio ni resuelve caracteres visualmente similares de escrituras diferentes.

5. Mojibake conserva un rastro causal

Si bytes UTF-8 C3 AD se decodifican como Windows-1252 aparecen í. Si ese texto se guarda en UTF-8, nace una segunda capa. Reparar exige conocer o inferir con evidencia la cadena; aplicar sustituciones globales puede dañar texto legítimo. Se conserva copia, se prueba en muestra y se valida round-trip.

Caso conductor: confirmar una matrícula sin perder el nombre

El analizador local de eventos serializa JSON con UTF-8 y declara el encoding al abrir archivos. Guarda texto normalizado solo si el dominio lo exige y conserva el original cuando la forma importa. El laboratorio compara José, Jose\u0301 y ✓; registra puntos, nombres Unicode, bytes y longitud en cada nivel.

Definiciones de trabajo

  • punto de código: valor del espacio Unicode;
  • codificación: transformación entre texto modelado y unidades binarias;
  • grafema: unidad aproximada percibida por una persona;
  • normalización: conversión a una forma Unicode definida;
  • mojibake: texto ilegible por interpretación incompatible de bytes.

Glosario

Code unit es unidad de una forma de codificación. BOM es U+FEFF al inicio bajo ciertos protocolos. Replacement character U+FFFD hace visible una decodificación no recuperada.

Ejemplo mínimo

'í'.encode('utf-8').hex() devuelve c3ad. Decodificar esos bytes como latin-1 crea dos puntos de código; volver a codificar no recupera significado sin conocer el error.

Ejemplo profesional

Una importación recibe CSV sin charset. En vez de probar hasta “verse bien”, se obtiene metadato del productor, se conserva original, se valida muestra multilingüe y se rechazan secuencias inválidas con informe de fila.

Práctica guiada

Usa como base el laboratorio ejecutable de la Parte 01; trabaja sobre una copia o conserva tus salidas en el directorio work/SE-015/.

  1. Crea unicode_probe.py con unicodedata.name, normalize, encode y decode.
  2. Inspecciona Matrícula José ✓ y la forma descompuesta de é.
  3. Demuestra UTF-8 → latin-1/Windows-1252 → mojibake sin sobrescribir el original.
  4. Compara NFC, NFD y longitudes; explica qué cambia y qué no.
  5. Prueba strict y replace con bytes inválidos.
  6. Entrega text-cases.json, observations.md y procedimiento de recuperación.

Ejercicios

  1. Explica por qué “Unicode de 16 bits” es incorrecto.
  2. Diseña un contrato para CSV con encoding y política de error.
  3. Analiza cuándo NFKC dañaría una identidad o código.

Reto verificable

Otra persona debe reconstruir bytes originales de dos casos y decir cuál no puede repararse sin información adicional. No aprueba una tabla de reemplazos visuales.

Preguntas frecuentes

¿UTF-8 representa todos los caracteres Unicode?

Sí, salvo puntos sustitutos que no son valores escalares codificables.

¿Normalizar arregla mojibake?

No. Opera sobre texto ya decodificado; el error de encoding requiere reconstruir bytes.

Fallo controlado y diagnóstico

Decodifica bytes UTF-8 con una codificación incompatible. Captura bytes antes y después, explica cada transformación y recupera solo desde una copia verificable.

Errores comunes y cómo corregirlos

SíntomaCausaCorrección
len() se interpreta como caracteres visiblespuntos y grafemas confundidosdeclara la unidad que cuentas
texto “arreglado” con reemplazosse atacó aparienciareconstruye codificación y conserva original
errors='ignore' en datos críticospérdida silenciosausa strict y ruta de cuarentena
normalización universaldominio no consideradoelige forma y campos con criterio explícito

Entorno y archivos clave

Python 3.11+, unicodedata, pathlib; unicode_probe.py, text-cases.json, observations.md. Limpieza local por directorio.

Seguridad, ética y accesibilidad

No uses nombres reales. Conservar correctamente una escritura es una cuestión de identidad e inclusión. No uses transliteración como sustituto automático del original.

Transferencia

Repite con emoji compuesto y una escritura no latina; identifica puntos, grafema y bytes.

Evaluación y evidencia

Se exige cadena reversible, normalización explicada, error controlado y política de entrada.

Fuentes

Límites y siguiente paso

No cubre segmentación completa ni seguridad de identificadores. SE-016 estudia números y precisión.


← SE-014 · ↑ Parte 01 · SE-016 →