|
|
Publicado en 31/7/2023 18:36:01
|
|
|
|
Una mañana soleada, estaba sentado frente a mi portátil reestructurando algo de código en C#. Todo va bien y será un día productivo. Luego añadí demasiados signos iguales a la cadena literal constante, y todo explotó. La productividad ha desaparecido. La tranquila reconstrucción del domingo ha quedado atrás. Incluso el sol decidió esconderse tras las nubes.
Después de pasar 30 o 40 minutos intentando averiguar qué estaba haciendo mal, me di cuenta de que no era culpa mía. Es Microsoft. Al parecer, me topé con un error antiguo en la función de decodificación de Base64.Convert.FromBase64StringEste bug existe desde que se introdujo .NET 1.1 en 2003. ¡Uau! Eso es viejo. Y no es muy difícil de reproducir. Buen trabajo:
Técnicamente, esto es ilegal, Base64. La versión legal es "abc=". Nótese que solo hay un carácter de relleno =. La codificación Base64 representa cada 6 bits de entrada binaria en un carácter ASCII. Esto significa que cada 4 caracteres en una cadena codificada en Base64 representa 3 bytes. Cuando los datos codificados no son múltiplos de 3 bytes, el codificador Base64 añade un carácter de relleno para que Base64 sea un múltiplo de 4 caracteres. Esto generará una cadena Base64 que se rellenará correctamente con "abc=". Añadir otro = lo invalidará.
Base64 "abc=" se decodifica como dos bytes [105, 183]. Así es. Añadir otro personaje de relleno al final no debería cambiar realmente el valor codificado. Es como añadir un espacio al final de una frase. Sí, está ahí, pero no cambia el significado de la frase. Pero .NET no lo cree. "abc==" se decodifica como un byte [109]. No solo se acortó, lo cual fue raro porque hicimos la entrada más larga. También se ha vuelto diferente. El primer byte va de 105 a 109. Y tampoco hizo una excepción. Si añades otro = obtienes una excepción. ¡Asombroso!
Código:
Salida:
'abc=' -> [105, 183]
'abc==' -> [109]
Al principio no me lo creía y empecé a investigar. Busqué un tiempo en Google y no encontré mucho. Luego publiqué en StackOverflow y tampoco tuve mucha suerte. Una vez que entendí qué pasaba, incluso tuve que responder a mis propias preguntas. Después de buscar un tiempo en GitHub, me topé con una corrección hecha en .NET Core en julio de 2018. Así que la última versión de .NET Core gestiona correctamente este problema y lanza una excepción:
Excepción no gestionada: System.FormatException: La entrada no es una cadena válida en base 64 ya que contiene un carácter no base 64, más de dos caracteres de relleno o un carácter ilegal entre los rellenar personajes.
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
en System.Convert.FromBase64String(String s)
en Program.DecodeAndPrint(String base64) en ./base64/Program.cs:line 13
en Program.Main() en ./base64/Program.cs:línea 8
Convert.FromBase64() tiene un error sutil donde el segundo carácter rellenado ilegalmente al final de la cadena hace que la decodificación "tenga éxito" al eliminar el penúltimo carácter.
Estamos en . Este error se corrigió inadvertidamente cuando la API se optimizó en NetCore 2.1. Añadir pruebas a los errores de registro y asegurarnos de no retroceder.
La solución alternativa en .NET 4.7.2 es rellenar la cadena mal poblada con algo así:
Texto original en:El inicio de sesión del hipervínculo es visible.
|
Anterior:Azure DevOps (viii) compila ASP.NET proyectos MVC usando Pipelines BuildPróximo:Se utiliza un nuevo temporizador en .NET 6, PeriodicTimer,
|
Propietario|
Publicado en 31/7/2023 18:39:50
|
