Add Character Sets to CFPOP With JCharset

This is a follow-up post to Fixing CFPOP.

If you’re using the CFPOP tag to handle any volume of email you will eventually come across character encoding issues. It’s only a matter of time! These limitations tend to be with the underlying JVM and not with ColdFusion itself (which is unusual). The good news is that the fix is quite easy.

Grab JCharset and place the extracted .jar file in one of the following spots in your CF install path:

CF8: /runtime/lib/
CF10: /jre/lib/ext/

Restart CF.

So… is it working?

In order to find out if you have JCharset in the right place, download the “CharsetTB” script from

Once the CF service is restarted this file will list all of the character sets ColdFusion has access to. If you can find “UTF-7” in this listing: Good news – you placed JCharset in the correct directory! If it isn’t in the list, try another directory where CF will pick up the JAR when restarted.

Another ColdFusion SerializeJSON Bug

Adobe recently released ColdFusion 10 Hotfix 11 and it fixed Bug #3338825! I am positively ecstatic because invalid JSON causes me a lot trouble. This hotfix even addresses two other JSON serialization issues and so it appears to be good news all around.

However, it did not address Bug #3337394 in which the string “No” is turned into a boolean false. (“Yes” also returns a boolean true for good measure). This bug is still considered “Unverified” although it was filed in September 2012 (Test case below)

A colleague came across another SerializeJSON() bug today that I thought I’d share because I seem to spend a lot of my workday Regexing the input to or output from this function to clean up what it incorrectly handles. [It can’t handle the truth!]

It’s filed as Bug #3596207 and this is its test case showing a numeric string with a trailing period being returned as an integer with a trailing decimal point:

SerializeJSON({a: "1."});

Output (not valid JSON)


Expected Output


Test Case Showing Both Issues

SerializeJSON({a: "1.", b: "no", c: "yes"});

Output (not valid JSON)


Intended Output


Adobe has made some good progress with the latest hotfix but there are some serious bugs left in functions that have been neglected for some time now. SerializeJSON(), for instance, debuted in CF8 almost six years ago and after that amount of time these very basic serialization test cases should not fail.

Fixing CFPOP

Some of my ColdFusion projects involve receiving A LOT of email via CFPOP. It’s perfect for the job about 95% of the time. However, that remaining 5% failure rate reveals glaring inadequacies that I have spent significant amounts of time trying to work around.

I generally use CFPOP in a try/catch and fall back to either of the following solutions for troublesome messages.

If you’re running CF on a 32bit Windows server… $40 makes all your CFPOP troubles go away in an instant. The CFX_POP3 custom tag is an absolute bargain because it works with rare character sets, poorly named attachments, special characters, etc. Not once have I seen it fail for attachment filename or character encoding issues.

1. Only runs on 32bit Windows servers
2. Seems to choke on large attachments (10MB+)

The POP CFC project is run by the creator of the CFX_POP3 tag and it contains some handy functions that use underlying Java methods for getting mail from a server and parsing through it. These functions are great for processing messages with oddly-named file attachments that will break CFPOP.

1. Supports the same character sets as CFPOP.

If you’re using CFPOP or POP CFC, I highly recommend setting up JCharset to allow processing of some of the more “unique” character sets out there. I’ll go over that in more detail in a future post.

Corrupted Queries in ColdFusion 7

For some time now I’ve had an application running on Coldfusion 7 that will randomly throw exceptions because of poorly formed SQL in seemingly random queries. I could not explain the malformed SQL from looking at the queries – they were always fine. Also, the horribly mangled SQL I would see in the exception logs could not possibly have been generated by any conditional logic in the query. Here is an example:

<cffunction name="getUsers" access="public" output="false" returntype="query">
  <cfargument name="username" type="string" required="false" default="">
  <cfset var local = StructNew()>
  <cfquery name="local.qryUsers" datasource="dsn">
    SELECT usr.username
    FROM users usr
    WHERE 1 = 1
    <cfif Len(arguments.username)>
      AND usr.username = <cfqueryparam value="#arguments.username#" cfsqltype="cf_sql_varchar">
    ORDER BY usr.username ASC
  <cfreturn local.qryUsers>

The above function would run fine 99% of the time until the SQL generated would cause an exception. The SQL from the previous cfquery that caused the exception would end up resembling something like this:

ELECT usr.username
FROM users usr
1 = 1

Needless to say it has become completely and utterly mangled – and with no way to account for it! Where has half the query run off to?! It was likely only a matter of time until a completely malformed query executed and resulted in data loss or corruption. So… what was the solution to this craziness?

My initial hypothesis was that SQL statements sometimes band together and run away at the thought of being transported to the database server for execution. This may very well have been true! Adobe could not be reached for questioning on this topic but they did release a hotfix that erected a 12 foot high fence around the edges of cfquery in order to prevent any bits from falling out or otherwise escaping at inopportune times.


The hotfix is available here.