Unicode en Microsoft Windows


Microsoft fue una de las primeras empresas en implementar Unicode en sus productos. Windows NT fue el primer sistema operativo que usó "caracteres anchos" en las llamadas al sistema . Usando el esquema de codificación UCS-2 al principio, se actualizó a UTF-16 a partir de Windows 2000 , lo que permite una representación de planos adicionales con pares sustitutos. Sin embargo, Microsoft no admitió UTF-8 hasta 2017. En Windows 11 , se requieren algunos archivos del sistema para usar UTF-8. [1]

Las versiones actuales de Windows y todas las anteriores a Windows XP y Windows NT anteriores (3.x, 4.0) se envían con bibliotecas del sistema que admiten la codificación de cadenas de dos tipos: "Unicode" de 16 bits ( UTF-16 desde Windows 2000 ) y un ( a veces multibyte) llamada " página de códigos " (o denominada incorrectamente como página de códigos ANSI ). Las funciones de 16 bits tienen nombres con el sufijo 'W' (de "ancho" ) como SetWindowTextW. Las funciones orientadas a la página de códigos usan el sufijo 'A' para "ANSI" como SetWindowTextA(algunas otras convenciones se usaron para las API que se copiaron de otros sistemas,_wfopen/fopenwcslen/strlen). Esta división fue necesaria porque muchos lenguajes, incluido C , no proporcionaban una forma clara de pasar cadenas de 8 y 16 bits a la misma función.

Las funciones 'A' se implementan como contenedores que traducen el texto utilizando la página de códigos actual a UTF-16 y luego llaman a las funciones 'W' correspondientes. [ cita requerida ] Las funciones 'A' que devuelven cadenas hacen la conversión opuesta, convirtiendo los caracteres que no existen en la configuración regional actual en '?'.

Microsoft intentó admitir Unicode de forma "portátil" al proporcionar un interruptor "UNICODE" al compilador, que cambia las llamadas "genéricas" sin sufijo de la interfaz 'A' a la 'W' y convierte todas las constantes de cadena en versiones UTF-16 "anchas". . [2] [3] Esto en realidad no funciona porque no traduce UTF-8 fuera de las constantes de cadena, lo que da como resultado un código que intenta abrir archivos pero no se compila. [ cita requerida ]

Anteriormente, e independientemente del modificador "UNICODE", Windows también proporcionaba el modificador API de conjuntos de caracteres multibyte (MBCS). [4] Esto cambia algunas funciones que no funcionan en MBCS, como strrevuna compatible con MBCS, como _mbsrev. [5] [6]

En Windows CE , UTF-16 se usaba casi exclusivamente, y faltaba la API 'A' en su mayoría. [7] Un conjunto limitado de ANSI API está disponible en Windows CE 5.0, para usar en un conjunto reducido de configuraciones regionales que pueden construirse selectivamente en la imagen de tiempo de ejecución. [8]