Specials es un bloque corto de caracteres Unicode ubicado al final del plano multilingüe básico , en U+FFF0–FFFF. De estos 16 puntos de código , cinco se han asignado desde Unicode 3.0:
U+FFFE <no carácter- FFFE> y U+FFFF <no carácter- FFFF> son caracteres no válidos , lo que significa que están reservados pero no causan texto Unicode mal formado. Las versiones del estándar Unicode desde la 3.1.0 a la 6.3.0 afirmaban que estos caracteres nunca deberían intercambiarse, lo que llevó a algunas aplicaciones a utilizarlos para adivinar la codificación del texto al interpretar la presencia de cualquiera de ellos como una señal de que el texto no es Unicode. Sin embargo, la Corrigendum #9 especificó posteriormente que los caracteres no válidos no son ilegales y, por lo tanto, este método de verificación de la codificación del texto es incorrecto. [3] Un ejemplo de un uso interno de U+FFFE es el algoritmo CLDR ; este algoritmo Unicode extendido asigna el carácter no válido a un peso primario mínimo y único. [4]
El carácter U+FEFF ZERO WIDTH NO-BREAK SPACE de Unicode se puede insertar al comienzo de un texto Unicode para indicar su orden de bytes : un programa que lea dicho texto y encuentre 0xFFFE sabría entonces que debe cambiar el orden de bytes para todos los caracteres siguientes.
Su nombre de bloque en Unicode 1.0 era Special . [5]
El carácter de reemplazo � (que suele aparecer como un rombo negro con un signo de interrogación blanco) es un símbolo que se encuentra en el estándar Unicode en el punto de código U+FFFD de la tabla Specials . Se utiliza para indicar problemas cuando un sistema no puede representar un flujo de datos con los símbolos correctos. [6]
Por ejemplo, un archivo de texto codificado en ISO 8859-1 que contiene la palabra alemana für contiene los bytes 0x66 0xFC 0x72. Si este archivo se abre con un editor de texto que asume que la entrada es UTF-8 , el primer y tercer bytes son codificaciones UTF-8 válidas de ASCII , pero el segundo byte ( 0xFC) no es válido en UTF-8. El editor de texto podría reemplazar este byte con el carácter de reemplazo para producir una cadena válida de puntos de código Unicode para mostrar, de modo que el usuario vea "für".
Un editor de texto mal implementado puede eliminar el carácter de reemplazo cuando el usuario guarda el archivo; los datos del archivo se convertirán en 0x66 0xEF 0xBF 0xBD 0x72. Si el archivo se vuelve a abrir utilizando ISO 8859-1, mostrará "f�r" (esto se llama mojibake ). Dado que el reemplazo es el mismo para todos los errores, es imposible recuperar el carácter original. Un diseño que es mejor (pero más difícil de implementar) es preservar los bytes originales, incluidos los errores, y solo convertir al reemplazo cuando se muestra el texto. Esto permitirá que el editor de texto guarde la secuencia de bytes original, mientras sigue mostrando una indicación de error al usuario.
En un tiempo, el carácter de reemplazo se usaba a menudo cuando no había un glifo disponible en una fuente para ese carácter, como en la sustitución de fuentes . Sin embargo, la mayoría de los sistemas de representación de texto modernos usan en su lugar el carácter .notdef de una fuente , que en la mayoría de los casos es un cuadro vacío, o "?" o "X" en un cuadro [7] (este navegador muestra �), a veces llamado " tofu ". No existe un punto de código Unicode para este símbolo.
Por lo tanto, el carácter de reemplazo ahora solo se ve en caso de errores de codificación. Algunos programas de software traducen bytes UTF-8 no válidos a caracteres coincidentes en Windows-1252 (ya que esa es la fuente más común de estos errores), de modo que el carácter de reemplazo nunca se ve.
Los siguientes documentos relacionados con Unicode registran el propósito y el proceso de definición de caracteres específicos en el bloque Especiales:
{{cite web}}: CS1 maint: estado de la URL ( enlace )