#!/usr/bin/perl
use strict;
use warnings;
use HTML::Entities qw(encode_entities);

my $str = ".@\n";
print encode_entities($str);
print encode_entities($str, '<>&".@');
__END__
.@
&#46;&#64;
[download]

As the example shows, you can force HTML::Entities to encode them, if you wish.

Note that the only chars that need escaping in HTML are <>&, and " in attributes.

Perl script uses HTML::Entities to encode form input for sql sanitization on fields like fname, lname, email, address1, etc.

update: s/quiote/quote/;

Yes, I took that advice to heart - using placeholders also. Is there some harm also encoding entities will cause?

Hmm.. if you're also using place holders or quote, it probably won't matter as far as security goes, but it does make it harder to search the database or interact with the DB using anything but your code (I tend to do quite a lot of inspecting using hand-written SQL during development).

Oh and it'll take more space to encode everything (which may make certain columns unexpectedly too small if someone enters a character you're escaping).

So it probably won't cause serious harm, it does IMO make it harder to develop and test. I wouldn't do it.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Yes, if the output from your database ever needs to be anything other than HTML, you'll need to remember to decode it explicitly at that time. The best rule to follow, I've found, is to keep the raw text in the DB, then encode it appropriately at time of output, for the relevant output format in question.

encode_entities($a, "\000-\377");
[download]

...not on the list...

Hmmm - so why is that when I do:

foreach $val (keys %char2entity) {
    print "<br>$val => $char2entity{$val}\n";
}
[download]

...
<br>@ => &#64;
...
<br>. => &#46;
[download]

Answer to my own question - no, I don't think %char2entity is the list of characters to encode by default.

If I take Anonymous Monk's suggestion:

encode($string, \000-\377)
[download]

Where do you get your information from?

<humour>A guy in the back alley. I give him the password "monk" and $20 and he spills the beans....</humour>

No - um, nowhere except in the documentation and the trials described above. The documentation says

The module can also export the %char2entity and the %entity2char hashes, which contain the mapping from all characters to the corresponding entities (and vice versa, respectively).

Which I took to mean "all characters that will be encoded by default". Then observed that encode_entities('@') does not encode @. So I wondered if that was because @ was not in the %char2entity hash, working on the assumption that %char2entity is the list of chars to encode by default. Using help from this board, I exported %char2entity and printed it out

use HTML::Entities;
use HTML::Entities qw( %char2entity %entity2char ); #thanks ikegami

foreach $val (keys %char2entity) {
    print "<br>$val => $char2entity{$val}\n";
}
[download]

and found that @ IS in the %char2entity hash. Then trying your suggestion (assuming this is the same Anonymous Monk) of

encode_entities($a, "\000-\377");
[download]

found that simply telling the module which characters to encode results in them being encoded, even though that command does not supply any new information about code-character mapping. The module, therefore, must already have that information, and it occurs to me that maybe that's the reason not all chars are encoded by default even though %char2entity contains a full set of char-entity relations - becase %char2entity is just a reference hash, NOT the list of chars to be encoded by deafult.