When to use HTML encode and when not to?

[Darrel]

How does HTML.encode work?

I'm trying to save text in a hidden form field into a SQL DB. The tedt is
HTML (from a WYSIWYG editor...X-standard).

One problem I have is that stray apostrophe's in the HTML text are throwing
a SQL error. Html.encode doesn't seem to do anything with these, eh?

Secondly, does HTMLencode also encode already encoded items?

For instance, if I have text in my editor that contains an HTML entity like
< and then I run THAT through HTML.encode, will that decode along with
the html when I use HTML.decode?

-Darrel

 

[Lucas Tam]

How does HTML.encode work?

It converts reserved HTML characters into their HTML safe equivalent.

I'm trying to save text in a hidden form field into a SQL DB. The tedt
is HTML (from a WYSIWYG editor...X-standard).

Don't HTML encode the text.

One problem I have is that stray apostrophe's in the HTML text are
throwing a SQL error. Html.encode doesn't seem to do anything with
these, eh?

Nope - you can use SQL parameters to avoid this error, or you can write
your own SQL delimiting function (just double up all single quotes).

Secondly, does HTMLencode also encode already encoded items?

Yes, but since the first pass would have converted everything into HTML
safe equivalents, the second pass does nothing.

For instance, if I have text in my editor that contains an HTML entity
like < and then I run THAT through HTML.encode, will that decode
along with the html when I use HTML.decode?

If you run < through HTML encode you'll get < as there are no
reserved characters to encode.

 

[Nicole Calinoiu]

Don't HTML encode the text.

Sorry, but that's simply not the case. In general, all text that is not
hard-coded at design-time should be HTML-encoded. If it isn't, the text
could end up altering the page in such a way as to change its behaviour.
This isn't simply a matter of ensuring expected functionality. It's also a
security issue due to the potential for script and HTML injection.

That said, the built-in ASP.NET controls will perform some HTML-encoding for
you (e.g.: in a multi-line textbox that will render as a textarea element),
but not all that is necessary, so you should always ensure that your code
performs the encoding if the framework code doesn't.

Yes, but since the first pass would have converted everything into HTML
safe equivalents, the second pass does nothing.

Nope. It will re-encode, as in the example below.

If you run < through HTML encode you'll get < as there are no
reserved characters to encode.

The ampersand is a reserved chacter. If you HTML-encode "<", you'll get
"<".

 

[Guest]

Please google sql injection attacks. It sounds like your app is vulnerable
to them. This doesn't answer your question, but it looks like other people
already have.

 

[Kevin Spencer]

Server.HTMLEncode(string) encodes the given string as HTML. So, for example,
if you use Server.HtmlEncode("<!--some text -->"), it encodes it as
"&LT;!--some text--&GT;" so that when it appears in an HTML document, it
appears as "<!--some text-->". This is because some text characters are
treated differently by HTML documents, since HTML documents are pure text.
The example, above, if not Html-Encoded, would not appear in the document at
all, as the angle brackets and other symbols create an HTML comment. So, as
far as Server.HtmlEncode, and when to use it, use it when displaying text in
HTML.

The single quote issue has nothing to do with HTML. It has to do with the
SQL language. The single quote is a text delimiter in SQL. To escape it,
double it. Example:

SELECT * FROM MyTable WHERE LastName = 'O''Malley'

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living