Otro detalle sencillo pero interesante, del estilo del que comentaba ayer, que me ha surgido últimamente.

Si codificas desde ASP una cadena como URL (es decir, sustituyes los caracteres no ASCII por su representación en forma '%CC', siendo CC el código que lo representa) obtienes cadenas que puedes pasar por GET a un navegador sin problemas de mala codificación de caracteres. Esta es la teoría. En la práctica depende.

El otro día estaba llamando desde ASP 3.0 clásico a una página escrita en ASP.NET 1.1 a la que le paaba desde ASP3 un parámetro con un texto mediante GET. Al recoger el valor del parámetro en la página ASPX los caracteres especiales, cómo tildes o 'eñes' desaparecían o estaban cambiados y eso que antes de hacer la llamada a la ASPX codificaba con Server.URLEncode la cadena que estaba pasando. Era raro, porque en ASPX lo único que hacía era leer el valor del primer parámetro del Querystring.

Usando un decompilador vi que lo que ocurría es que ASPX decodifica los parámetros del QueryString partiendo de la base de que están codificados como UTF-8. Sin embargo ASP3 los codifica como UTF-7. Es decir, que al deshacer la codificación con Server.UrlDecode, ASPX estaba haciéndolo mal.

Es un problema tonto pero bastante peliagudo :-(

La solución, extraer "a pelo" la parte de parámetros de la URL actual (muy fácil con una expresión regular o directamente buscando la interrogación de la URL), y decodificar su contenido usando UTF-7 así:

public static string URLDecode(string url)
  {
   return HttpUtility.UrlDecode(url, Encoding.UTF7);
  }

Con esto solucioné el problema y la comunicación entre ambas aplicaciones se realizó perfectamente. Espero que este detalle le pueda servir a alguien más.

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA