Office-it.orG » Javascript

How to Prevent Spam Bots From Collecting Email Addresses

Hii Hiong Ching — Mon, 23 Jun 2008 08:11:11 +0000

As I mentioned before in How to Include Subject, CC, BCC, and Email Body in Email Links, you are creating a risk to get spam if you simply placing email addresses on a page without encoding them.

Some websites using “[at]” to replace “@” and email will look as “name [at] domain.com”. This is a good idea for personal websites since nobody challenge you. In commercial, many clients wouldn’t allow you to use “name [at] domain.com” this format. They are not web designer and they don’t understand how spam prevention works, or even care for that matter.

I have this method originally from david walsh blog. Its author have a quick PHP script that you can use when putting raw email addresses on a page:

The Function

function encode_email($e)
{
	for ($i = 0; $i < strlen($e); $i++) { $output .= '&#'.ord($e[$i]).';'; }
	return $output;
}

Usage

echo(encode_email('email@office-it.org'));

The above function takes a string input (the email address), loops through each character replacing the letter with the character’s ASCII value, and returns the encoded email address. That’s all you need to do!

Another method (much simple) is found at SOLMETRA. It is a tiny JavaScript code which will encode email for you.

The disadvantage for second method is if you have a page with hundreds of addresses, the page download will be bloated.

I am not guarantee methods above is bulletproof solution, but it is, at least, a basic protection.

New-Window Links in a Standards-Compliant World

Hii Hiong Ching — Fri, 01 Feb 2008 02:43:55 +0000

Much to the chagrin of Web designers everywhere, the HTML 4.0 Strict and XHTML 1.0 Strict recommendations of the W3C no longer include the target attribute of the tag. The Transitional versions of the specifications still include it, but by definition, these specs are on the way out.

Whatever your personal feelings on the practice, the most common application for this attribute — opening a link in a new browser window with target=”_blank” — is still useful on today’s Internet. So if the standards say we shouldn’t use it, how should we go about creating new-window links, while following the latest Web standards?

You can read the original articles from here: http://www.sitepoint.com/article/standards-compliant-world/

The Complete Script

Here is the complete script. Notice the last line, which assigns the externalLinks function to the window’s onload event handler. This triggers the function when the document has finished loading.

function externalLinks() {
 if (!document.getElementsByTagName) return;
 var anchors = document.getElementsByTagName("a");
 for (var i=0; i
As this is the kind of script you'll want to deploy across your entire site, you should copy this code into a separate file (e.g. external.js), and then load it in every page on your site with the following code, which should appear in the  tag of each document:


For these links, we set the rel attribute to external.
Before:
external link

After:
external link

So, now that we have our new-window links marked up in a standards-compliant way and javascript will cause them to actually open in a new window.

Still wondering which javascript library to use?

Hii Hiong Ching — Sun, 23 Dec 2007 09:08:12 +0000

If you are still wondering which javascript library (Prototype, MooTools, JQuery) to use, you can run the speed/validity selectors test for frameworks from Slickspeed.

http://mootools.net/slickspeed/

Every framework runs in its own iFrame, thus no conflicts can happen. Tests are run selector by selector, with an interval to prevent the browser from freeezing.

Tests are run in a neutral environment, no library or framework is included in the main javascript test, to avoid favoritism.