UTF-7, UTF-8, UTF-16 y UTF-32 son simplemente formatos de transformación algorítmica de la misma codificación (puntos de código) de los caracteres. Son codificaciones de un sistema de codificación de caracteres.
También son algorítmicamente más fáciles de navegar hacia adelante y hacia atrás que la mayoría de los esquemas anteriores para tratar con conjuntos de caracteres de más de 256 caracteres.
Esto es muy diferente de la codificación de glifos generalmente específica del país y, a veces, del proveedor. Solo en japonés, hubo una tonelada de variaciones de JIS solo, por no mencionar EUC-JP y la transformación orientada a la página de códigos de JIS que las máquinas DOS / Windows usaron llamada Shift-JIS. (Hasta cierto punto, hubo transformaciones algorítmicas de estos, pero no fueron particularmente simples y hubo diferencias específicas de proveedores en los caracteres disponibles. Multiplique esto por un par de cientos de países y la evolución gradual de sistemas de fuentes más sofisticados (después de la pantalla verde era), y tuviste una verdadera pesadilla.
¿Por qué necesitarías estas formas de transformación de Unicode? Debido a que muchos sistemas heredados asumieron secuencias de caracteres de 7 bits de rango ASCII, por lo que necesitaba una solución limpia de 7 bits que pasaba los datos sin daños a través de esos sistemas, entonces necesitaba UTF-7. Luego había sistemas más modernos que podían manejar conjuntos de caracteres de 8 bits, pero los nulos generalmente tenían significados especiales para ellos, por lo que UTF-16 no funcionaba para ellos. 2 bytes podrían codificar todo el plano multilingüe básico de Unicode en su primera encarnación, por lo que UCS-2 parecía un enfoque razonable para los sistemas que iban a ser "conscientes de Unicode desde cero" (como Windows NT y Java VM); luego, las extensiones más allá de eso requerían caracteres adicionales, lo que resultó en la transformación algorítmica de los 21 bits de codificaciones que estaban reservadas por el estándar Unicode, y nacieron pares sustitutos; Eso requería UTF-16. Si tenía alguna aplicación en la que la consistencia del ancho de caracteres fuera más importante que la eficiencia del almacenamiento, UTF-32 (una vez llamado UCS-4) era una opción.
UTF-16 es lo único que es remotamente complejo de tratar, y se mitiga fácilmente por el pequeño rango de caracteres que se ven afectados por esta transformación y el hecho de que las secuencias de 16 bits principales están perfectamente en un rango totalmente distinto de las secuencias de 16 bits finales. También es un mundo más fácil que tratar de avanzar y retroceder en muchas de las primeras codificaciones de Asia Oriental, donde necesitabas una máquina de estados (JIS y EUC) para lidiar con las secuencias de escape, o posiblemente retroceder varios caracteres hasta encontrar algo garantizado Sólo ser un byte principal (Shift-JIS). UTF-16 tenía algunas ventajas en los sistemas que también podían realizar secuencias de 16 bits de manera eficiente.
A menos que tuvieras que vivir las docenas (cientos, realmente) de diferentes codificaciones, o tuvieras que construir sistemas que admitieran múltiples idiomas en diferentes codificaciones a veces incluso en el mismo documento (como WorldScript en las versiones anteriores de MacOs), Usted podría pensar en los formatos de transformación Unicode como una complejidad innecesaria. Pero es una reducción dramática en la complejidad con respecto a las alternativas anteriores, y cada formato resuelve una restricción técnica real. También son realmente convertibles entre sí de manera eficiente, y no requieren tablas de búsqueda complejas.