Globalization Plan - Character Encoding

As briefly mentioned above, character encoding is an issue when discussing adding additional locales. However, all available documentation from Macromedia or otherwise recommends using Unicode and, in particular, using ColdFusion's default UTF-8 Unicode encoding, which uses variable length encoding to limit bandwidth. Macromedia also recommends that your pages be encoded with a byte-order mark (BOM) that indicates that the page has been encoded in UTF-8 (this is supported by Dreamweaver, via the Page Properties Document Encoding property, and Eclipse, though it appears may not be a default in either). If this is not done, a cfprocessingdirective tag is necessary to establish the page encoding at the beginning of every page that has non-default encoding.For forms, Macromedia recommends setting an enctype=multipart/form-data: charset=utf-8 in order that non-standard character data is properly sent across a post and correctly handled by ColdFusion MX. Alternatively, for ColdFusion MX 7, they recommend using the setEncoding function on form as well as URL data.

On the database end, table columns must be set to use SQL's Unicode data types when necessary (i.e. nchar, nvarchar, ntext). When passing Unicode text to the database, it must be prefaced by an N as in: WHERE name = N'Brian' In order to use the cfqueryparam tag, the datasource needs to be enabled for Unicode support by checking the String Format attribute under the Advanced Options for that dsn in the ColdFusion Administrator. Microsoft SQL can handle collation (sorting) of Unicode data (when it will not fall within the standard collation) at both the database level and by using the collate clause.