winapi - codificacion - encoding utf 8 c#

¿Cómo maneja Windows wchar_t los caracteres Unicode fuera del plano multilingüe básico?

Question

He consultado varios otros aquí y en otros lugares (ver a continuación), pero todavía no tengo una respuesta clara a esta pregunta: ¿cómo maneja Windows wchar_t los caracteres unicode fuera del plano multilingüe básico?

Es decir:

• muchos programadores parecen sentir que UTF-16 es dañino porque es un código de longitud variable.
• wchar_t tiene 16 bits de ancho en Windows , pero tiene 32 bits de ancho en Unix / MacOS
• Las API de Windows usan caracteres anchos, no Unicode.

Entonces, ¿qué hace Windows cuando quiere codificar algo como Character (U + 2008A) Han Character en Windows?

Answer 1

Windows solía usar UCS-2 pero adoptó UTF-16 con Windows 2000. Las API wchar_t de Windows ahora producen y consumen UTF-16.

No todos los programas de terceros manejan esto correctamente y, por lo tanto, pueden tener problemas con los datos fuera del BMP.

Además, tenga en cuenta que UTF-16, al ser una codificación de longitud variable, no cumple con los requisitos C o C ++ para una codificación utilizada con wchar_t. Esto causa algunos problemas, como algunas funciones estándar que toman un único wchar_t, como wctomb, no puede manejar caracteres que vayan más allá del BMP en Windows y Windows define algunas funciones adicionales que usan un tipo más amplio para poder manejar caracteres individuales. fuera del BMP. Olvidé la función que era, pero me encontré con una función de Windows que devolvía int en lugar de wchar_t (y no era uno donde EOF era un resultado posible).

Answer 2

La implementación de wchar_t bajo Windows stdlib es UTF-16-inconsciente: solo conoce unidades de código de 16 bits.

De modo que puede colocar una secuencia sustituta UTF-16 en una cadena, y puede elegir tratarla como un solo carácter usando un procesamiento de nivel superior. La implementación de cadenas no hará nada para ayudarte ni para obstaculizarte; le permitirá incluir cualquier secuencia de unidades de código en su cadena, incluso aquellas que serían inválidas cuando se interpretara como UTF-16.

Muchas de las funciones de nivel superior de Windows sí admiten caracteres creados a partir de substitutos UTF-16, por lo que puede llamar a un archivo 𐐀.txt y verlo renderizar correctamente y editarse correctamente (tomando una sola pulsación de tecla, no dos, para pasar el personaje) en programas como Explorer que admiten el diseño de texto complejo (normalmente utilizando la biblioteca Uniscribe de Windows).

Pero todavía hay lugares donde se puede ver el UTF-16-inconsciencia brillar, como el hecho de que puede crear un archivo llamado 𐐀.txt en la misma carpeta que 𐐨.txt , donde la insensibilidad a mayúsculas de otro modo no lo permitiría, o el hecho de que puede crear [U+DC01][U+D801].txt programáticamente.

Así es como los pedantes pueden tener un buen argumento largo y básicamente sin sentido sobre si Windows "admite" cadenas UTF-16 o solo UCS-2.