Microsoft fue una de las primeras empresas en implementar Unicode en sus productos. Windows NT fue el primer sistema operativo que utilizó "caracteres anchos" en las llamadas del sistema . Utilizando en un principio el esquema de codificación UCS-2 (ahora obsoleto) , se actualizó a la codificación de ancho variable UTF-16 a partir de Windows 2000 , lo que permitió una representación de planos adicionales con pares sustitutos. Sin embargo, Microsoft no admitió UTF-8 en su API hasta mayo de 2019.
Antes de 2019, Microsoft enfatizaba UTF-16 (es decir, -W API), pero desde entonces ha recomendado usar UTF-8 (al menos en algunos casos), [1] en Windows y Xbox (y en otros de sus productos), incluso afirma "UTF-8 es la página de códigos universal para la internacionalización [y] UTF-16 [... es] una carga única que Windows coloca en el código que apunta a múltiples plataformas. [..] Windows [está] avanzando para admitir UTF-8 para eliminar esta carga única [lo que resulta] en menos problemas de internacionalización en aplicaciones y juegos". [2]
Una gran cantidad de documentación de Microsoft utiliza la palabra "Unicode" para referirse explícitamente a la codificación UTF-16. Cualquier otra codificación, incluida UTF-8, no es "Unicode" en el lenguaje obsoleto de Microsoft (mientras que UTF-8 y UTF-16 son ambas Unicode según el estándar Unicode , o codificaciones/"formatos de transformación" de este).
Las versiones actuales de Windows y todas las anteriores a Windows XP y Windows NT (3.x, 4.0) se entregan con bibliotecas de sistema que admiten la codificación de cadenas de dos tipos: "Unicode" de 16 bits ( UTF-16 desde Windows 2000 ) y una codificación (a veces multibyte) llamada " página de códigos " (o incorrectamente denominada 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(se usaron otras convenciones para las API que se copiaron de otros sistemas, como _wfopen/fopeno wcslen/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.
Microsoft intentó soportar Unicode de manera "portable" al proporcionar un modificador "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 a versiones UTF-16 "anchas". [3] [4] 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 que no se compila. [ cita requerida ]
Anteriormente, e independientemente del modificador "UNICODE", Windows también proporcionaba el modificador API de conjuntos de caracteres multibyte (MBCS). [5] Esto cambia algunas funciones que no funcionan en MBCS, como strrevpor una que admita MBCS, como _mbsrev. [6] [7]
En Windows CE (ahora descontinuado) , se usaba casi exclusivamente UTF-16, y la API "A" estaba prácticamente ausente. [8] Un conjunto limitado de API ANSI está disponible en Windows CE 5.0, para usar en un conjunto reducido de configuraciones regionales que pueden crearse selectivamente en la imagen de tiempo de ejecución. [9]
En 2001, Microsoft lanzó un suplemento especial para los antiguos sistemas Windows 9x de Microsoft . Incluye una biblioteca de vínculos dinámicos, 'unicows.dll' (solo 240 KB) que contiene la versión de 16 bits (las que tienen la letra W al final) de todas las funciones básicas de la API de Windows. Es simplemente una capa de traducción: SetWindowTextWsimplemente convertirá su entrada utilizando la página de códigos actual y llamará a SetWindowTextA.
Microsoft Windows ( Windows XP y posteriores) tiene una página de códigos designada para UTF-8 , la página de códigos 65001 [10] o CP_UTF8. Durante mucho tiempo, fue imposible establecer la página de códigos de configuración regional en 65001, lo que dejaba esta página de códigos solo disponible para a) funciones de conversión explícitas como MultiByteToWideChar y/o b) el comando de consola Win32chcp 65001 para traducir stdin/out entre UTF-8 y UTF-16. Esto significaba que las funciones "estrechas", en particular fopen(las que abren archivos), no podían ser llamadas con cadenas UTF-8 y, de hecho, no había forma de abrir todos los archivos posibles fopensin importar en qué configuración regional se estableciera y/o qué bytes se pusieran en la cadena, ya que ninguna de las configuraciones regionales disponibles podía producir todos los caracteres UTF-16 posibles. Este problema también se aplicaba a todas las demás API que toman o devuelven cadenas de 8 bits, incluidas las de Windows como SetWindowText.
Los programas que querían usar UTF-8, en particular el código destinado a ser portable a otros sistemas operativos, necesitaban una solución alternativa para esta deficiencia. La solución alternativa habitual era agregar nuevas funciones para abrir archivos que convierten UTF-8 a UTF-16 usando MultiByteToWideChar y llamar a la función "wide" en lugar de fopen. [11] Docenas de bibliotecas multiplataforma agregaron funciones contenedoras para hacer esta conversión en Windows (y pasar UTF-8 sin cambios en otros), un ejemplo es una adición propuesta a Boost , Boost.Nowide . [12] Otra solución alternativa popular fue convertir el nombre al nombre de archivo equivalente 8.3 , esto es necesario si el fopenestá dentro de una biblioteca. Ninguna de estas soluciones alternativas se considera buena, ya que requieren cambios en el código que funciona en sistemas que no son Windows.
En abril de 2018 (o posiblemente en noviembre de 2017 [13] ), con la compilación interna 17035 (compilación nominal 17134) para Windows 10, apareció una casilla de verificación "Beta: usar Unicode UTF-8 para compatibilidad con idiomas en todo el mundo" para configurar la página de códigos de configuración regional en UTF-8. [a] Esto permite llamar a funciones "estrechas", incluidas fopeny SetWindowTextA, con cadenas UTF-8. Sin embargo, se trata de una configuración de todo el sistema y un programa no puede asumir que está configurada.
En mayo de 2019, Microsoft agregó la capacidad de que un programa configure la página de códigos en UTF-8, [1] [14] lo que permite que los programas escritos para usar UTF-8 puedan ser ejecutados por usuarios no expertos.
A partir de 2019 [actualizar], Microsoft recomienda a los programadores que utilicen UTF-8 (por ejemplo, en lugar de cualquier otra codificación de 8 bits), [1] en Windows y Xbox , y puede recomendar su uso en lugar de UTF-16, incluso afirmando que "UTF-8 es la página de códigos universal para la internacionalización [y] UTF-16 [..] es una carga única que Windows coloca en el código que apunta a múltiples plataformas". [2] Microsoft parece estar haciendo la transición a UTF-8, afirmando que anteriormente enfatizó su alternativa, y en Windows 11 algunos archivos del sistema deben usar UTF-8 y no requieren una marca de orden de bytes. [15] El Bloc de notas ahora puede reconocer UTF-8 sin la marca de orden de bytes, y se le puede indicar que escriba UTF-8 sin una marca de orden de bytes. [ cita requerida ] Algunos otros productos de Microsoft utilizan UTF-8 internamente, incluidos Visual Studio [ cita requerida ] y SQL Server 2019 , y Microsoft afirma un aumento del 35 % en la velocidad gracias al uso de UTF-8 y una "reducción de casi el 50 % en los requisitos de almacenamiento". [16]
Antes de 2019, los compiladores de Microsoft no podían producir constantes de cadena UTF-8 a partir de archivos fuente UTF-8. Esto se debe a que convertían todas las cadenas a la página de códigos de configuración regional (que no podía ser UTF-8). En un momento dado, el único método para solucionar este problema era desactivar UNICODE y no marcar el archivo de entrada como UTF-8 (es decir, no utilizar un BOM ). [17] Esto haría que el compilador pensara que tanto la entrada como las salidas estaban en la misma configuración regional de un solo byte y dejaría las cadenas intactas. En los sistemas modernos, configurar la página de códigos a UTF-8 ayuda. [ cita requerida ]
A partir de la versión 1903 de Windows (actualización de mayo de 2019), puede usar la propiedad ActiveCodePage en el manifiesto appxmanifest para aplicaciones empaquetadas, o el manifiesto de fusión para aplicaciones no empaquetadas, para forzar a un proceso a usar UTF-8 como la página de códigos del proceso. [...]CP_ACPequivale aCP_UTF8solo si se ejecuta en la versión 1903 de Windows (actualización de mayo de 2019) o superior y la propiedad ActiveCodePage descrita anteriormente está configurada en UTF-8. De lo contrario, respeta la página de códigos del sistema heredado. Recomendamos usarCP_UTF8explícitamente.
Al operar en UTF-8, puede garantizar la máxima compatibilidad [..] Windows opera de forma nativa en UTF-16 (o WCHAR), que requiere conversiones de páginas de códigos mediante MultiByteToWideChar y WideCharToMultiByte. Esta es una carga única que Windows impone al código que se dirige a múltiples plataformas. [..] El Kit de desarrollo de juegos de Microsoft (GDK) y Windows en general están avanzando para admitir UTF-8 para eliminar esta carga única de Windows en el código que se dirige o intercambia con múltiples plataformas y la web. Además, esto da como resultado menos problemas de internacionalización en aplicaciones y juegos y reduce la matriz de prueba que se requiere para hacerlo bien.
Nuestras aplicaciones utilizan páginas de códigos DBCS de Windows con las versiones "A" de las funciones de Windows.
Windows CE está basado en Unicode. Es posible que deba volver a compilar el código fuente que se escribió para una aplicación basada en Windows NT.
Asegúrate de que LayoutModification.json use codificación UTF-8.
Por ejemplo, cambiar un tipo de datos de columna existente de NCHAR(10) a CHAR(10) mediante una intercalación habilitada para UTF-8 se traduce en una reducción de casi el 50 % en los requisitos de almacenamiento. [..] En el rango ASCII, al realizar operaciones de E/S de lectura/escritura intensivas en UTF-8, medimos una mejora de rendimiento promedio del 35 % con respecto a UTF-16 utilizando tablas agrupadas con un índice no agrupado en la columna de cadena y una mejora de rendimiento promedio del 11 % con respecto a UTF-16 utilizando un montón.