为什么我得到一个不同的结果具有相同HtmlDe code()函数? [英] Why I get a different result with the same HtmlDecode() function?

查看:115
本文介绍了为什么我得到一个不同的结果具有相同HtmlDe code()函数?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是我的code:

string myText = "Wählen Sie bitte";
string myTextDecoded = HttpUtility.HtmlDecode(myText);
Response.Write(myTextDecoded);
ddAdulti.Items.Add(new ListItem(myTextDecoded, ""));

在它打印,在我的html文件第一种情况(回复于):

in first case (Response.Write) it prints, on my html document :

Wählen Sie bitte

这是正确的!但在选择框中的选项,它打印,在我的html文件:

which is correct! But on the select box's option it prints, on my html document :

Wählen Sie bitte

这是错误的(我去code吧...具有相同的功能)。

which is wrong (I've decode it...with the same function).

为什么这种行为?

推荐答案

根据您更新后的问题,我将做一个关于你的理解可能不正确的假设。

Based on your updated question, I'm going to make a potentially incorrect assumption about your understanding.

我猜你看的HTML源代码,而不是理解为什么字符串连接codeD在一个地方,unen codeD中的其他。的解释是相当简单:服务器端控件会自动连接$ C C的内容的,而的Response.Write $写入原始输出。还有一个原因:服务器端控件通常包含的用户输入的是本质上的不安全的,所以它会自动的连接coded到prevent的跨站点脚本攻击,或者在较恶毒的情况下,用户输入的只是打破你的页面。

I'm guessing that you're looking at the HTML source and not understanding why the string is encoded in one place and unencoded in the other. The explanation is rather straightforward: server-side controls automatically encode their content while Response.Write writes raw output. There's a reason for this: server side controls often contain user input which is inherently unsafe, so it's automatically encoded to prevent cross-site scripting attacks, or in the less nefarious cases, user input merely breaking your page.

举例来说,想象一下,如果该列表的没有的EN code的内容,你这样做:

By way of example, imagine if the list didn't encode the content and you did this:

ddAdulti.Items.Add(new ListItem("</select>", ""));
ddAdulti.Items.Add(new ListItem("An actual valid value", ""));

最终的结果将是你的标记会是这个样子:

The net result would be that your markup would look something like this:

<select>
    <option></select></option>
    <option>An actual valid value</option>
</select>

正如你所看到的,这显然打破。你最终的内容取决于跨preting的浏览器,但很可能是一个空的下拉列表中。

As you can see, that's clearly broken. What you end up with depends on the interpreting browser, but is most likely an empty dropdown list.

现在,由于控制的执行的EN code的内容,标记最终被:

Now, since the controls do encode their content, the markup ends up being:

<select>
    <option>&lt;/select&gt;</option>
    <option>An actual valid value</option>
</select>

和工作的事情了好听。 : - )

and things work out nicely. :-)

它发生,我认为从我的例子,它可能并不清楚为什么你会看到有像'a'的角色行为。这是因为许多的字符编码的不支持umlauted字母,因此对于控制作家,它可能是最容易简单地连接code中的7位ASCII字符集以外的所有字符。 : - )

It occurs to me that from my example, it's probably not clear why you're seeing the behavior with a character like 'ä'. That's because many character encodings don't support umlauted letters, so for the control writers, it's probably easiest to simply encode all characters outside the 7-bit ASCII character set. :-)

这已经成为明显,我认为原来的职位并没有提供真正的问题。显然,什么markzzz正在试图做的是从数据库中获取unen codeD的 HTML 的,并显示为,是为客户端。目前市场上已经存在的WebForms控制这样: LiteralControl 。它会显示任何你在坚持下来,unen codeD。

It's becoming clear to me that the original post doesn't actually describe the real problem. Apparently, what markzzz is trying to do is fetch unencoded HTML from the database and display it as-is for the client. There already exists a WebForms control for doing this: LiteralControl. It will display whatever you stick in it, unencoded.

这是说,没有办法,我知道要嵌入在的DropDownList - 看看我是如何呈现的HTML将打破解释。但是,如果您只是想显示的项目清单,但不一定是一个下拉列表,您可以使用 LiteralControl A 直放站在或一些这样的。

That said, there is no way that I know to embed that inside a DropDownList -- see my explanation of how the rendered HTML would break. However, if you merely want to display a list of items, but not necessarily a dropdown list, you can use a LiteralControl inside a Repeater or some such.

这篇关于为什么我得到一个不同的结果具有相同HtmlDe code()函数?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆