Comments on: Convert Facebook e-mail images to actual e-mail links

By: Katie Gilgen

Katie Gilgen — Tue, 13 Jan 2009 00:07:03 +0000

Hey when do u get out of clases at end of day i can’t ever find u?

By: Elliot

Elliot — Thu, 08 Nov 2007 05:19:07 +0000

I’ve also noticed the problem with recognizing “r.”, which would seem to be due to the period being placed underneath the tip of the r… causing both to be incorrectly read.

Also “-” isnt being read.

BTW if anyone else is looking to port this to java, BufferedImage.getRaster().getDataBuffer() is what you are looking for to replace the canvas method. =)

By: bookerface

bookerface — Thu, 13 Sep 2007 16:14:35 +0000

It will be interesting to see if you can get it to actually create an image from a miniaturised text logo then parse the result into a link, using examples generated here: tinyurl.com/247tyb
If not, expect facebook to switch to this method of obfuscation.

By: Percy

Percy — Thu, 13 Sep 2007 13:40:00 +0000

Thanks for providing it. In my first test it failed with and @pfizer.com address. It returned @pfizecom (no r, no period).

Great for all other cases I’ve tested though.

By: Axel Hecht

Axel Hecht — Thu, 13 Sep 2007 06:22:04 +0000

I guess somewhere on http://developer.mozilla.org/en/docs/Safely_accessing_content_DOM_from_chrome might be the right hint on how to get the image data.

By: Fredrik

Fredrik — Tue, 11 Sep 2007 21:16:33 +0000

Nit: “entries in uMap” should of course be “entries in rMaps”.

Another thing. By comparing arrays instead of strings (meaning having every rMaps[i].map as an array) you’d, first of all, compare 25% fewer items, since comparing commas in the string would be avoided. You’d also save on lots of string conversions, since getImageData returns an array in the first place.

By: Adam Dempsey

Adam Dempsey — Tue, 11 Sep 2007 20:29:06 +0000

Great job! Now I’m glad I didn’t spend too long working on it myself!

By: Fredrik

Fredrik — Tue, 11 Sep 2007 18:31:01 +0000

Carrying over some thoughts I had, posting here instead of in Gerv’s blog.

As it is now, you’re comparing the entire string to match a character |uMap.toString() == map|, which is unnecessary. You only need to compare a string long enough to be completely unambiguous in relation to all other characters.

That is, the entries in uMap needn’t be as long as they are to still decode the character properly. That can save quite some time since comparing strings are O(length).

Potentially, one could even make a sort of decoding tree, to feed column for column of image data into, and when it has been unambiguously decoded, you reach the leaf, which is the amount to skip forward, and the character itself.