Using ASP to Internationalize Your Web Pages on Windows 2000

  • Article

By John Meade,IIS Technical Writer

On This Page

Overview
Scenario 1: Writing ASP Pages in the Same Language as the Windows Default
Scenario 2: Writing ASP Pages in a Language Different from the Default
Scenario 3: Mixing Languages on a Page Using Response.Write Only
Scenario 4: Writing Unicode Data to the Browser
Scenario 5: Writing ASP Pages with Unrestricted Methods

Overview

You can publish international Web sites by taking advantage of the language-support features included in Windows 2000 and Active Server Pages (ASP). Windows 2000 supports the use of multiple languages on one machine, while ASP supports publishing in multiple languages—you can declare a language for each ASP page or for each ASP application. You can also mix languages on the same ASP page.

By using the Regional Options applet in the Windows 2000 Control Panel, you can change the default language supported by the Windows system you are running on; also, you can use this applet for adding support for many other languages.

ASP supports the @CODEPAGE declarative for specifying the language supported on that page (example: for Japanese, @CODEPAGE=932), and the ASPCodePage property of the metabase for specifying a language across an application. The way the @CODEPAGE declarative works is that during compilation of an ASP page, ASP uses that declarative value to process all literal strings, and, during execution, to process dynamic data (for example, data acquired from a database). Whenever the @CODEPAGE declarative is absent, ASP expects data to be in the Windows 2000 default language. The ASPCodePage property is used programmatically to specify a language for all the pages in an ASP application. ASP will then expect code compatible with that setting from each page of the application.

When you mix languages on the page, you can use the UTF-8 @CODEPAGE setting. UTF-8 enables ASP to correctly process data scripted in multiple languages, using the Response.Write method. Additionally, this setting allows ASP to convert Unicode data retrieved from databases, sending it to the browser as UTF-8 data.

A different kind of problem occurs when you have UTF-8 data and you need to use more than just the Response.Write method to process the data. Converting UTF-8 data to the ANSI format will solve the problem as long as your pages are written in a single language.

This article explains how to take advantage of the Windows 2000 and ASP language-support features mentioned above by describing five scenarios. Each scenario begins with a problem and ends with a solution:

  1. Writing ASP Pages in the Same Language as the Windows Default

  2. Writing ASP Pages in a Language Different from the Default

  3. Mixing Languages on a Page Using Response.Write Only

  4. Writing Unicode Data to the Browser

  5. Writing ASP Pages with Unrestricted Methods

Scenario 1: Writing ASP Pages in the Same Language as the Windows Default

Suppose you need to publish pages with scripts written in the default language set for the machine your site is running on. For example, suppose that your Windows 2000 Server is set to Japanese as the default language (Remember: you can check this in the Regional Options applet of the Control Panel). Suppose further that your page scripts are coded in Japanese, and you are retrieving Japanese-language data dynamically from a database.

In this case, your pages just work with no language-support actions required on your part. Because the language the page uses is the default set in Windows 2000 on the system you are publishing from, no language declaration is required for either your ASP application or your pages. ASP sends data in Japanese to the browser.

Scenario 2: Writing ASP Pages in a Language Different from the Default

Suppose, as in Scenario 1, you are publishing some pages containing hard-coded scripts in Japanese, plus Japanese-language data dynamically acquired from a database. However, this time English is the default language set in Windows 2000 Server. Suppose further that most of your sites need to use English, so that the default language must remain English.

You can handle this situation easily by using the Regional Options applet to add Japanese to the languages supported by Windows 2000 Server on the machine serving your pages. Then, either use a codepage declaration for the Japanese language at the top of each page with Japanese scripts (@CODEPAGE=932) or the ASPCodePage property of the metabase.

The simplest option is to declare the language for each page. In this case, you must declare Japanese on every page using Japanese scripts because the default language is English. Without the declaration, ASP would assume the default language, English, instead of Japanese.

If your ASP application is serving only pages in Japanese, you can declare the laguage for those pages programmatically using the ASPCodePage property of the metabase.

Important: Do not use the ASPCodePage property unless all the pages served in an application are to be processed as the language declared by ASPCodePage. Any pages coded in another language are treated as the language declared in ASPCodePage. ASPCodePage overrides the language default set in Windows 2000 and any @CODEPAGE declaration at the top of the page.

Scenario 3: Mixing Languages on a Page Using Response.Write Only

What if you need to use more than one language on an ASP page? For example, your page might include scripts with both Japanese and Chinese string literals. In these languages, you may also have static HTML segments and dynamic information acquired from a database. Obviously, you cannot simply declare a single language on the whole page, or in the ASP application processing your pages. For instance, if you declare Japanese (@CODEPAGE=932), then your Chinese text will be misinterpreted.

The solution to this problem, provided you comply with one restriction, is to format your pages in UTF-8 (@CODEPAGE=65001), which supports many languages. The restriction is that you may use only the Response.Write method to process UTF-8 data. Methods such as Request.Form, Request.QueryString, Server.URLEncode, and others, do not support UTF-8 encoding. Also, add a Response.Charset method on the second line of your ASP page (Response.Charset="UTF-8") to tell the browser to expect UTF-8 data.

Scenario 4: Writing Unicode Data to the Browser

Suppose you need to process some data formatted in Unicode and stored in a database. ASP does not support data formatted as Unicode on the page. If you were to try to use Unicode string literals, ASP would not be able to correctly process the data.

However, if ASP retrieves Unicode data from a data base, you can write it out to the browser as UTF-8. To accomplish this, declare UTF-8 (@CODEPAGE=65001), and write the Unicode data to the browser using Response.Write, a method that supports UTF-8. As with Scenario 3, add a Response.Charset property on the second line of your ASP page (Response.Charset="UTF-8") to tell the browser to expect UTF-8 data. Because you are using the UTF-8 codepage, you can write string literals in a variety languages on this page.

This is a powerful approach whenever you must process Unicode data in ASP because the Unicode data is converted to UTF-8 without being encountered by any ASP method that cannot interpret it. Meanwhile, the literals and static HTML in various languages work on an ASP page with UTF-8 declared.

Scenario 5: Writing ASP Pages with Unrestricted Methods

If you are using just one language and need to use methods such as Request.Form, Request.QueryString, or any methods other than Response.Write, you can save your ASP pages as plain (ANSI) text, and they should work. All ASP methods support ANSI text. You can include data dynamically required from a database, as well, as long as it is in the same language as the rest of the page.

Remember to declare the correct language (@CODEPAGE=) for the page, and add the language to Windows 2000 using the Regions Options applet.

One problem not covered in this article: You may have data in multiple languages stored in databases and you may need to process the data using diverse methods (other than Response.Write). See the IIS 5.0 product documentation for information on the Session.CodePage property of the metabase.