c# - ejemplos - representa texto como una secuencia de unidades de codigo utf 16

¿Por qué se bloquea csc.exe la última vez que dejé la codificación de salida como UTF8?

Question

Estoy teniendo estoy teniendo o me he topado con algo muy extraño.

Me pregunto si otros lo han hecho y por qué está sucediendo.

Habiendo ejecutado un programa de una línea con esta línea System.Console.WriteLine(System.Console.OutputEncoding.EncodingName); Veo que la codificación es de Western European (DOS)

Multa

Aquí hay una lista de algunas páginas de códigos 1200 Unicode y 65001 utf-8 y Windows-1252 Western European (Windows) y 850 Western European DOS desde https://msdn.microsoft.com/en-us/library/system.text.encoding (v = vs.110) .aspx

Digamos que escribo un programa C sharp para cambiar la codificación a utf-8

class sdf
{
static void Main(string[] args)
{
System.Console.WriteLine(System.Console.OutputEncoding.EncodingName);
System.Console.OutputEncoding=System.Text.Encoding.GetEncoding(65001);
System.Console.WriteLine(System.Console.OutputEncoding.EncodingName);
}
}

Funciona, imprime

Western European (DOS)
Unicode (UTF-8)

Ahora cuando ejecuto csc nuevamente, el csc falla.

Revisé mi memoria RAM durante 14 horas, 8 pases, con memtest. Corrí chkdsk mi disco duro, todo bien. Y esto definitivamente no es eso, este es un problema de codificación. Lo sé porque si abro un nuevo prompt de cmd, entonces ejecuto csc, no se cuelga.

Entonces, al ejecutar ese programa nítido, cambia el shell de modo que la próxima vez que ejecute csc falle el csc mismo, de esa manera grande.

Si compilo el código a continuación, ejecútelo, luego ejecute csc, luego ejecute csc o csc whatever.cs, obtengo csc bloqueado.

Así que cierre el indicador de cmd, abra uno nuevo.

Esta vez, experimente con comentarios y quite el comentario de la segunda línea del programa

Encuentro que si la segunda línea (la línea que cambia la página de códigos a 850 (DOS Western Europe) está ahí, entonces no se bloqueará la próxima vez que ejecute csc.

Mientras que si comento esa segunda línea, entonces el programa sale con la codificación / página de códigos cambiada a UTF-8, entonces la próxima vez que se ejecute csc, csc falla.

// elimine el comentario de la última línea y luego // se ejecuta pero hace que csc se cuelgue la próxima vez.

class asdf
{
static void Main()
{
System.Console.OutputEncoding = System.Text.Encoding.UTF8; //output and to utf8
System.Console.OutputEncoding=System.Text.Encoding.GetEncoding(850);
}
}

No soy la única persona que se ha topado con algo como esto

aunque no se encontró ninguna explicación allí https://social.msdn.microsoft.com/Forums/vstudio/en-US/0e5f477e-0c32-4e88-acf7-d53d43d5b566/c-command-line-compiler-cscexe-immediately-crashes- when-run-in-code-page-65001-utf8? forum = csharpgeneral

Puedo manejarlo asegurándome de que la última línea configure la página de códigos en 850. Aunque como explicaré, esa es una solución inadecuada.

También me gustaría saber si este es un problema con CSC que otros también tienen. O cualquier otra solución.

adicional

uuu1.cs

// uuu1.cs
class asdf
{
static void Main()
{
System.Console.InputEncoding = System.Text.Encoding.UTF8;
System.Console.OutputEncoding = System.Text.Encoding.UTF8;
// not unicode. UTF8 means redirection will then work
System.Console.WriteLine("ჵ");
// try redirecting too..
// and try checking for csc crash or not
//System.Console.OutputEncoding=System.Text.Encoding.GetEncoding(850);
//System.Console.InputEncoding =System.Text.Encoding.GetEncoding(850);
//problem is that when that is commented, it breaks the redirection
}
}

Agregar la línea / descomentar las últimas líneas, así que tengo

System.Console.OutputEncoding = System.Text.Encoding.GetEncoding (850);

detendría el bloqueo pero es una solución inadecuada, porque, por ejemplo ... Si quiero redirigir la salida de un programa a un archivo, entonces necesito UTF8 desde el principio hasta el final, de lo contrario no funciona

esto funciona con la página de códigos 850 sin comentar

c:/blah>uuu1>r.r<ENTER>
c:/blah>type r.r <ENTER>
c:/blah>ჵ 

Si descomenta las últimas líneas, cambiando así la página de códigos a 850, entonces seguro csc no se bloqueará en la siguiente ejecución, pero la redirección no funciona y rr no contiene ese carácter.

Añadido 2

La respuesta de Han me hace notar otra forma de activar este error

C:/Users/harvey/somecs3>csc<ENTER>
Microsoft (R) Visual C# Compiler version 4.0.30319.18408
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.
warning CS2008: No source files specified
error CS1562: Outputs without source must have the /out option specified
C:/Users/harvey/somecs3>chcp 65001<ENTER>
Active code page: 65001
C:/Users/harvey/somecs3>csc<ENTER> <-- CRASH
C:/Users/harvey/somecs3>

Answer 1

Bueno, encontraste un error en la forma en que el compilador C # trata de tener que enviar texto a la consola cuando se cambia a UTF-8. Tiene un autodiagnóstico para garantizar que la conversión de una cadena codificada en UTF-16 a la página de códigos de salida de la consola funcionó correctamente, y apaga el botón rojo grande cuando no lo hizo. El seguimiento de la pila se ve así:

csc.exe!OnCriticalInternalError() + 0x4 bytes
csc.exe!ConsoleOutput::WideToConsole() + 0xdc51 bytes
csc.exe!ConsoleOutput::print_internal() + 0x2c bytes
csc.exe!ConsoleOutput::print() + 0x80 bytes
csc.exe!ConsoleOutput::PrintString() + 0xb5 bytes
csc.exe!ConsoleOutput::PrintBanner() + 0x50 bytes
csc.exe!_main() + 0x2d0eb bytes 

El código real para WideToConsole () no está disponible, la coincidencia más cercana es esta versión de la distribución SSCLI20:

/*
* Like WideCharToMultiByte, but translates to the console code page. Returns length,
* INCLUDING null terminator.
*/
int ConsoleOutput::WideCharToConsole(LPCWSTR wideStr, LPSTR lpBuffer, int nBufferMax)
{
if (m_fUTF8Output) {
if (nBufferMax == 0) {
return UTF8LengthOfUnicode(wideStr, (int)wcslen(wideStr)) + 1; // +1 for nul terminator
}
else {
int cchConverted = NULL_TERMINATED_MODE;
return UnicodeToUTF8 (wideStr, &cchConverted, lpBuffer, nBufferMax);
}
}
else {
return WideCharToMultiByte(GetConsoleOutputCP(), 0, wideStr, -1, lpBuffer, nBufferMax, 0, 0);
}
}
/*
* Convert Unicode string to Console ANSI string allocated with VSAlloc
*/
HRESULT ConsoleOutput::WideToConsole(LPCWSTR wideStr, CAllocBuffer &buffer)
{
int cch = WideCharToConsole(wideStr, NULL, 0);
buffer.AllocCount(cch);
if (0 == WideCharToConsole(wideStr, buffer.GetData(), cch)) {
VSFAIL("How''d the string size change?");
// We have to NULL terminate the output because WideCharToMultiByte didn''t
buffer.SetAt(0, ''/0'');
return E_FAIL;
}
return S_OK;
}

El bloqueo se produce en algún lugar alrededor de la afirmación VSFAIL (), a juzgar por el código de máquina. Puedo ver la declaración de retorno E_FAIL. Sin embargo, se cambió de la versión que publiqué, se modificó la declaración if () y parece que VSFAIL () se reemplazó por RETAILVERIFY (). Algo se rompió cuando hicieron esos cambios, probablemente en UnicodeToUTF8 () que ahora se llama UTF16ToUTF8 (). Volviendo a enfatizar, la versión que publiqué en realidad no falla, puede verlo usted mismo ejecutando C: / Windows / Microsoft.NET / Framework / v2.0.50727 / csc.exe. Solo la versión v4 de csc.exe tiene este error.

El error real es difícil de extraer del código de máquina, lo mejor es que Microsoft se preocupe por eso. Puede archivar el error en connect.microsoft.com. No veo un informe que se le parezca, bastante notable por cierto. La solución para este error es usar CHCP para cambiar la página de códigos.

Answer 2

Hay diferentes artículos que sugieren el hecho de que Windows Console tiene muchos errores relacionados con Unicode. Artículos como: https://alfps.wordpress.com/2011/12/08/unicode-part-2-utf-8-stream-mode/

Aquí hay una solución que funciona para mí. En lugar de:

csc aaa1.cs

Pruebe esto (que redirigirá la salida CSC a un archivo):

csc /utf8output aaa1.cs > aaa1-compilation.log

Documentación relevante: https://msdn.microsoft.com/en-us/library/d5bxd1x2.aspx

En algunas configuraciones internacionales, la salida del compilador no se puede mostrar correctamente en la consola. En estas configuraciones, use / utf8output y redirija la salida del compilador a un archivo.

agregado por barlop

mirando chat, hemos encontrado que hacer csc uuu1.cs<ENTER> uuu1<ENTER> luego para evitar bloqueos, cada csc que se viene tiene que hacerse con / utf8output Y (por alguna extraña razón desconocida), extrañamente, con un redireccionamiento .. entonces, csc /utf8output uuu1.cs >asdfsdaf

La solución temporal de Han es mejor, solo ejecute chcp 850 (o la página de códigos que use) después de uuu1<ENTER> incluso si chcp dice que es 850, todavía tiene que hacer chcp 850. Entonces csc se ejecutará normalmente.

La razón por la cual, al tener un problema, debe ejecutar chcp 850 incluso si chcp muestra 850, es porque chcp solo le mostrará la codificación de entrada, aunque chcp 850 cambiará tanto la codificación de entrada como la de salida, y queremos que cambio de codificación de salida. Entonces, chcp podría mostrar 850 incluso cuando la codificación de salida es 65001, y el problema es solo cuando la codificación de salida es 65001