BEA WebLogic User Manual page 113

Part IV Presentation of Mobile Content
How Content Gets Encoded
Content is encoded/decoded by the content editor (such as a text editor or database), server, JSP
file and display device.
Errors will occur if the same encoding / decoding algorithm is not consistently used along the
supply chain from creating content to delivering it to the end device.
Text Editors and Databases
Character encoding begins when a file is created and stored. Text editors such as Microsoft
Notepad, Macromedia Dreamweaver, Adobe GoLive, CoffeeCup store the content with a default
encoding. When writing data to a database, a servlet must use the same encoding as the data
stored in the database.
Usually, you can specify the default encoding to be used when saving and opening files. For
example, in Macromedia Dreamweaver, select the Preferences | Fonts | Encoding option and
specify the Default encoding to be used. For example, Western (Latin 1) or Japanese (Shift JIS).
Each component in the content supply chain is responsible for encoding / decoding the content
and for passing on the Content-Type header (if present) to the next component in the chain.
Content Supply Chain
Servers
The preferred method of indicating the encoding is by using the charset parameter of the Content-
Type HTTP header. For example, to specify that an HTML document uses ISO-8859-1, a server
would send the following header:
Content-Type: text/html; charset=ISO-8859-1
Configuring an application server to use a particular encoding depends on the individual server.
For example, if you are using the Apache server, you can add a file named .htaccess to any
directory to set the Content-Type of files in that directory and any sub-directories.
BEA WebLogic Mobility Server User Guide - 109