MACROMEDIA COLDFUSION MX 61-DEVELOPING COLDFUSION MX, Develop Manual

Page: 383 / 860

Handling data in ColdFusion MX 383
General character encoding issues
Applications developed for earlier versions of ColdFusion that assumed that the character length
of a string was the same as the byte length might produce errors in ColdFusion MX. The byte
length of a string depends on the character encoding.
Locale-specific content
The following sections provide information on how to handle locale-specific content in pages that
support multiple locales, and how to handle euro values.
Generating multi-locale content
In an application that supports users in multiple locales and produces output that is specific to
multiple locales, you call the
SetLocale
function in every request to set the locale for that specific
request. When processing has completed, the locale should be set back to its previous value. One
useful technique is to save the user’s desired locale in a Session variable once the user has selected
it, and use the Session variable value to set the locale for each user request during the session.
Supporting the euro
The euro is the currency of many European countries, and ColdFusion supports the reading and
writing of correctly formatted euro values. Unlike other supported currencies, the euro is not tied
to any single country (or locale). The
LSCurrencyFormat
and
LSParseCurrency
functions rely
on the underlying JVM for their operations, and the rules used for currencies depend on the
JVM. For Sun JVMs, the 1.3 releases did not support euros and used the older country-specific
currencies. The 1.4 releases use euros for all currencies that are in the euro zone as of 2002. If you
are using a JVM that does not support the euro, use the
LSEuroCurrencyFormat
and
LSParseEuroCurrency
functions to format and parse euro values in locales that use euros as their
currency.
Input data from URLs and HTML forms
A web application server receives character data from request URL parameters or as form data.
The HTTP 1.1 standard only allows US-ASCII characters (0-127) for the URL specification and
for message headers. This requires a browser to encode the non-ASCII characters in the URL,
both address and parameters, by escaping (URL encoding) the characters using the “%xx”
hexadecimal format. URL encoding, however, does not determine how the URL is used in a web
document. It only specifies how to encode the URL.
Form data uses the message headers to specify the encoding used by the request (Content headers)
and the encoding used in the response (Accept headers). Content negotiation between the client
and server uses this information.
This section contains suggestions on how you can handle both URL and form data entered in
different character encodings.