visual texto reemplazar por obtener las funcion delimitan convertir codigo caracteres caracter cadenas cadena asc c++ visual-studio winapi character-encoding

c++ - texto - Conjuntos de caracteres de Visual Studio ''No establecido'' vs ''Conjunto de caracteres de múltiples bytes''



obtener codigo ascii de un caracter en visual basic (2)

En la referencia se afirma que:

Por definición, el conjunto de caracteres ASCII es un subconjunto de todos los conjuntos de caracteres multibyte. En muchos conjuntos de caracteres multibyte, cada carácter en el rango 0x00 - 0x7F es idéntico al carácter que tiene el mismo valor en el juego de caracteres ASCII. Por ejemplo, en cadenas de caracteres ASCII y MBCS, el carácter NULL de 1 byte (''/ 0'') tiene un valor de 0x00 e indica el carácter nulo de terminación.

Como _MBCS adivinado, habilitando _MBCS Visual Studio también admite el ASCII caracteres ASCII .

En una segunda referencia , el conjunto de caracteres individuales parece ser compatible incluso si habilitamos _MBCS :

Portabilidad MBCS / Unicode: utilizando el archivo de encabezado Tchar.h, puede compilar aplicaciones de un solo byte, MBCS y Unicode desde las mismas fuentes. Tchar.h define las macros con el prefijo _tcs, que se correlacionan con las funciones str, _mbs o wcs, según corresponda. Para compilar MBCS, defina el símbolo _MBCS. Para construir Unicode, defina el símbolo _UNICODE. Por defecto, _MBCS está definido para aplicaciones MFC. Para obtener más información, vea Asignaciones de texto genérico en Tchar.h.

He trabajado con una aplicación heredada y estoy tratando de resolver la diferencia entre las aplicaciones compiladas con el Multi byte character set y las opciones Not Set under the Character Set .

Entiendo que la compilación con el Multi byte character set define _MBCS que permite que se _MBCS páginas de códigos de conjunto de caracteres de varios bytes, y usar Not set no define _MBCS , en cuyo caso solo se permiten páginas de códigos de conjunto de caracteres de un solo byte.

En el caso de que Not Set se use Not Set , asumo que solo podemos usar las páginas de códigos de conjunto de caracteres de un solo byte que se encuentran en esta página: http://msdn.microsoft.com/en-gb/goglobal/bb964654.aspx

Por lo tanto, ¿estoy en lo correcto al pensar que Not Set se usa Not Set , la aplicación no podrá codificar y escribir o leer los idiomas orientales, ya que están definidos en páginas de códigos de conjunto de caracteres de doble byte (y, por supuesto, Unicode)?

A continuación, si se define el juego de Multi byte character , ¿están disponibles las páginas de códigos de juego de caracteres de uno o varios bytes, o solo páginas de códigos de juegos de caracteres de varios bytes? Supongo que debe ser compatible con los idiomas europeos.

Gracias,

Andy

Otras lecturas

Las respuestas en estas páginas no respondieron mi pregunta, pero me ayudaron a comprender: Acerca de la opción "Conjunto de caracteres" en visual studio 2010

Investigación

Por lo tanto, al igual que la investigación de trabajo ... Con mi configuración regional establecido como japonés

Efecto en cadenas codificadas

char *foo = "Jap text: テスト"; wchar_t *bar = L"Jap text: テスト";

Compilando con Unicode

* foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (página de códigos 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 == UTF-16 o UCS-2

Compilación con Multi byte character set

* foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (página de códigos 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 == UTF-16 o UCS-2

Compilando con Not Set

* foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (página de códigos 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 == UTF-16 o UCS-2

Conclusión: la codificación de caracteres no tiene ningún efecto en las cadenas codificadas. Aunque la definición de caracteres como la anterior parece utilizar la página de códigos definidos de configuración regional y wchar_t parece utilizar UCS-2 o UTF-16.

Uso de cadenas codificadas en las versiones W / A de las API de Win32

Entonces, usando el siguiente código:

char *foo = "C://Temp//テスト//テa.txt"; wchar_t *bar = L"C://Temp//テスト//テw.txt"; CreateFileA(bar, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); CreateFileW(foo, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

Compilando con Unicode

Resultado: ambos archivos son creados

Compilación con Multi byte character set

Resultado: ambos archivos son creados

Compilando con Not set

Resultado: ambos archivos son creados

Conclusión: Tanto la versión A como la versión W de la API esperan la misma codificación independientemente del conjunto de caracteres elegido. A partir de esto, tal vez podemos suponer que toda la opción del Character Set hace es cambiar entre la versión de la API. Entonces, la versión A siempre espera cadenas en la codificación de la página de códigos actual y la versión W siempre espera UTF-16 o UCS-2.

Abrir archivos usando las API W y A Win32

Entonces usando el siguiente código:

char filea[MAX_PATH] = {0}; OPENFILENAMEA ofna = {0}; ofna.lStructSize = sizeof ( ofna ); ofna.hwndOwner = NULL ; ofna.lpstrFile = filea ; ofna.nMaxFile = MAX_PATH; ofna.lpstrFilter = "All/0*.*/0Text/0*.TXT/0"; ofna.nFilterIndex =1; ofna.lpstrFileTitle = NULL ; ofna.nMaxFileTitle = 0 ; ofna.lpstrInitialDir=NULL ; ofna.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST ; wchar_t filew[MAX_PATH] = {0}; OPENFILENAMEW ofnw = {0}; ofnw.lStructSize = sizeof ( ofnw ); ofnw.hwndOwner = NULL ; ofnw.lpstrFile = filew ; ofnw.nMaxFile = MAX_PATH; ofnw.lpstrFilter = L"All/0*.*/0Text/0*.TXT/0"; ofnw.nFilterIndex =1; ofnw.lpstrFileTitle = NULL; ofnw.nMaxFileTitle = 0 ; ofnw.lpstrInitialDir=NULL ; ofnw.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST ; GetOpenFileNameA(&ofna); GetOpenFileNameW(&ofnw);

y seleccionando:

  • C: / Temp / テ ス ト / テ openw.txt
  • C: / Temp / テ ス ト / テ openw.txt

Rendimientos:

Cuando se compila con Unicode

* filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 == Shift-Jis (página de códigos 932)
* archivow = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF -16 o UCS-2

Cuando se compila con Multi byte character set

* filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 == Shift-Jis (página de códigos 932)
* archivow = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF -16 o UCS-2

Cuando se compila con Not Set

* filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 == Shift-Jis (página de códigos 932)
* archivow = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF -16 o UCS-2

Conclusión: Nuevamente, la configuración del Character Set no influye en el comportamiento de la API de Win32. La versión A siempre parece devolver una cadena con la codificación de la página de códigos activa y la W siempre devuelve UTF-16 o UCS-2. De hecho, puedo ver esto explicado un poco en esta gran respuesta: https://stackoverflow.com/a/3299860/187100 .

Conculsion definitiva

Hans parece estar en lo cierto cuando dice que la definición realmente no tiene ninguna magia, más allá de cambiar las API de Win32 para usar W o A Por lo tanto, realmente no puedo ver ninguna diferencia entre el Not Set Multi byte character set Not Set y Multi byte character set .

No, esa no es la manera en que funciona. Lo único que sucede es que la macro se define, de lo contrario no tiene un efecto mágico en el compilador. Es muy raro escribir código que use #ifdef _MBCS para probar esta macro.

Casi siempre lo dejas a una función auxiliar para hacer la conversión. Como WideCharToMultiByte (), OLE2A () o wctombs (). ¿Cuáles son las funciones de conversión que siempre tienen en cuenta las codificaciones multibyte, como lo indica la página de códigos? _MBCS es un accidente histórico, relevante solo hace más de 25 años cuando las codificaciones de varios bytes no eran comunes todavía. Al igual que el uso de una codificación no Unicode es un artefacto histórico en estos días también.