c# - dotnetbrowser - WebUtility.HtmlDecode vs HttpUtilty.HtmlDecode

chromium.net control

Question

Estaba usando WebUtilty.HtmlDecode para decodificar HTML. Resulta que no se decodifica correctamente, por ejemplo, – se supone que debe decodificar a un carácter "-", pero WebUtilty.HtmlDecode no lo decodifica. HttpUtilty.HtmlDecode , sin embargo, lo hace.

Debug.WriteLine(WebUtility.HtmlDecode("–"));
Debug.WriteLine(HttpUtility.HtmlDecode("–"));
> –
> –

La documentación para ambos es la misma: convierte una cadena que ha sido codificada en HTML para la transmisión HTTP en una cadena descodificada.

¿Por qué son diferentes, cuál debería estar usando y qué cambiará si cambio a WebUtility.HtmlDecode para que "-" decodifique correctamente?

Answer 1

La implementación de los dos métodos es diferente en Windows Phone.

WebUtility.HtmlDecode:

public static void HtmlDecode(string value, TextWriter output)
{
if (value != null)
{
if (output == null)
{
throw new ArgumentNullException("output");
}
if (!StringRequiresHtmlDecoding(value))
{
output.Write(value);
}
else
{
int length = value.Length;
for (int i = 0; i < length; i++)
{
bool flag;
uint num4;
char ch = value[i];
if (ch != ''&'')
{
goto Label_01B6;
}
int num3 = value.IndexOfAny(_htmlEntityEndingChars, i + 1);
if ((num3 <= 0) || (value[num3] != '';''))
{
goto Label_01B6;
}
string entity = value.Substring(i + 1, (num3 - i) - 1);
if ((entity.Length <= 1) || (entity[0] != ''#''))
{
goto Label_0188;
}
if ((entity[1] == ''x'') || (entity[1] == ''X''))
{
flag = uint.TryParse(entity.Substring(2), NumberStyles.AllowHexSpecifier, NumberFormatInfo.InvariantInfo, out num4);
}
else
{
flag = uint.TryParse(entity.Substring(1), NumberStyles.Integer, NumberFormatInfo.InvariantInfo, out num4);
}
if (flag)
{
switch (_htmlDecodeConformance)
{
case UnicodeDecodingConformance.Strict:
flag = (num4 < 0xd800) || ((0xdfff < num4) && (num4 <= 0x10ffff));
goto Label_0151;
case UnicodeDecodingConformance.Compat:
flag = (0 < num4) && (num4 <= 0xffff);
goto Label_0151;
case UnicodeDecodingConformance.Loose:
flag = num4 <= 0x10ffff;
goto Label_0151;
}
flag = false;
}
Label_0151:
if (!flag)
{
goto Label_01B6;
}
if (num4 <= 0xffff)
{
output.Write((char) num4);
}
else
{
char ch2;
char ch3;
ConvertSmpToUtf16(num4, out ch2, out ch3);
output.Write(ch2);
output.Write(ch3);
}
i = num3;
goto Label_01BD;
Label_0188:
i = num3;
char ch4 = HtmlEntities.Lookup(entity);
if (ch4 != ''/0'')
{
ch = ch4;
}
else
{
output.Write(''&'');
output.Write(entity);
output.Write('';'');
goto Label_01BD;
}
Label_01B6:
output.Write(ch);
Label_01BD:;
}
}
}
}

HttpUtility.HtmlDecode:

public static string HtmlDecode(string html)
{
if (html == null)
{
return null;
}
if (html.IndexOf(''&'') < 0)
{
return html;
}
StringBuilder sb = new StringBuilder();
StringWriter writer = new StringWriter(sb, CultureInfo.InvariantCulture);
int length = html.Length;
for (int i = 0; i < length; i++)
{
char ch = html[i];
if (ch == ''&'')
{
int num3 = html.IndexOfAny(s_entityEndingChars, i + 1);
if ((num3 > 0) && (html[num3] == '';''))
{
string entity = html.Substring(i + 1, (num3 - i) - 1);
if ((entity.Length > 1) && (entity[0] == ''#''))
{
try
{
if ((entity[1] == ''x'') || (entity[1] == ''X''))
{
ch = (char) int.Parse(entity.Substring(2), NumberStyles.AllowHexSpecifier, CultureInfo.InvariantCulture);
}
else
{
ch = (char) int.Parse(entity.Substring(1), CultureInfo.InvariantCulture);
}
i = num3;
}
catch (FormatException)
{
i++;
}
catch (ArgumentException)
{
i++;
}
}
else
{
i = num3;
char ch2 = HtmlEntities.Lookup(entity);
if (ch2 != ''/0'')
{
ch = ch2;
}
else
{
writer.Write(''&'');
writer.Write(entity);
writer.Write('';'');
continue;
}
}
}
}
writer.Write(ch);
}
return sb.ToString();
}

Curiosamente, WebUtility no existe en WP7. Además, la implementación WP8 de WebUtility es idéntica a la del escritorio. La implementación de escritorio de HttpUtility.HtmlDecode es solo una envoltura alrededor de WebUtility.HtmlDecode . Por último, pero no menos importante, Silverlight 5 tiene la misma implementación de HttpUtility.HtmlDecode que Windows Phone, y no implementa WebUtility.

A partir de ahí, puedo aventurar una conjetura: dado que el tiempo de ejecución de Windows Phone 7 se basa en Silverlight, WP7 se heredó de la versión de Silverlight de HttpUtility.HtmlDecode y WebUtility no estaba presente. Luego vino WP8, cuyo tiempo de ejecución se basa en WinRT. WinRT trajo WebUtility, y la versión anterior de HttpUtility.HtmlDecode se mantuvo para garantizar la compatibilidad con las aplicaciones WP7 heredadas.

En cuanto a cuál debe usar ... Si desea apuntar a WP7, no tiene más remedio que usar HttpUtility.HtmlDecode . Si está apuntando a WP8, simplemente elija el método cuyo comportamiento se adapte mejor a sus necesidades. WebUtility es probablemente la opción a prueba de futuro, en caso de que Microsoft decida abandonar el tiempo de ejecución de Silverlight en una próxima versión de Windows Phone. Pero me gustaría simplemente optar por la opción práctica de elegir HttpUtility para no tener que preocuparme por apoyar manualmente el ejemplo que ha puesto en su pregunta.

Answer 2

Los métodos hacen exactamente lo mismo . Además, si intentas descompilarlos, las implementaciones parecen que una se acaba de copiar de otra.

La diferencia es solo uso previsto . HttpUtility se encuentra en el ensamblado de System.Web y se espera que se use en las aplicaciones ASP.net que se crean sobre este ensamblaje. WebUtility se encuentra en el ensamblaje del System que hacen referencia casi todas las aplicaciones y se proporciona para fines más generales o para uso del cliente.

Answer 3

Solo para notificar a otros que encontrarán esto en la búsqueda. Use cualquier función mencionada en la pregunta, pero nunca use Windows.Data.Html.HtmlUtilities.ConvertToText(string input) . Es 70 veces más lento que WebUtilty.HtmlDecode y produce fallos! Crash será nombrado como mshtml!IEPeekMessage en el DevCenter. Parece que esta función llama a InternetExplorer para convertir la cadena. Sólo evítalo.