Tome un vistazo al siguiente código C# (función extraído de la función BuildProtectedURLWithValidity
en http://wmsauth.org/examples):codificación utilizada en el elenco de char a byte
byte[] StringToBytesToBeHashed(string to_be_hashed) {
byte[] to_be_hashed_byte_array = new byte[to_be_hashed.Length];
int i = 0;
foreach (char cur_char in to_be_hashed)
{
to_be_hashed_byte_array[i++] = (byte)cur_char;
}
return to_be_hashed_byte_array;
}
Mi pregunta es: Lo que hace el casting de bytes a Char en términos de codificación?
Supongo que realmente no hace nada en términos de Codificación, pero eso significa que la Codificación.Default es la que se utiliza, por lo que el byte a devolver dependerá de cómo el marco codificará la cadena subyacente en el sistema operativo específico?
Y además, ¿es el parche realmente más grande que un byte (supongo que 2 bytes) y realmente omitirá el primer byte?
Estaba pensando en la sustitución de todo esto por:
Encoding.UTF8.GetBytes(stringToBeHashed)
¿Qué opinas?
Tal vez en un ambiente extraño que tira, pero creo que en la mayoría de los entornos que el caso no arroja. He probado en mi local "Microsoft (R) Visual C# Compiler versión 4.6.1590.0" y en repl.it: https://repl.it/Irlw/1. Y ambos devuelven el éxito en ambos casos (sin excepción, como muestra su resultado). –
@Mariano Desanze, no puedo hablar sobre Mono, pero ¿cómo puede MS convertirlo sin error si su propia fuente de referencia muestra claramente que el carácter de entrada es [comparado] (https://referencesource.microsoft.com/#mscorlib/ system/convert.cs, fc990bd1275d43d6) (en la línea 725) a 'Byte.MaxValue' antes de la conversión, y se lanza una excepción si el valor del carácter no cabe en un byte. Mi entorno no es extraño, es simple-vainilla .NET 3.5. Descarte silencioso del byte superior es una mala idea –
Entendido: Tenía la opción * Comprobar la desbordamiento/subdesbordamiento aritmético * en SharpDevelop. ¡Así que el resultado de esta conversión es ambivalente, es decir, depende de la configuración del compilador! –