For most of the Turkish ASP developers, nationalizing the session is a common problem. Because, hosting is an expensive service in Turkey, and most of the developers hire hosting or dedicated servers from abroad, especially from American companies. But here the problem comes: International hosting companies has different customers from different countries. This forces them to use common regional setting, like currency format or date format. But for developers, this causes a problem when it comes to display a date on their pages, coming from server variables or database, or store a date value on database.
On ASP pages, the LCID variable saves us - the developers. With LCID property, you can switch to the desired regional settings for a session or page response. So, when we print the date coming from a server variable or function (like now()) or from database, it just prints in our regional format according to the LCID setting. Also, same problem arises when writing a date field to a database, the date value will be written according to our regional setting that we set for a session.
Before we proceed to codng part, here are the LCID values of ASP for countries:
http://msdn2.microsoft.com/en-us/library/ms912047.aspx
We can set the LCID property of our session in two ways:
1- Modifying session's LCID property at the top of the page (In page directives):
The code to modify the LCID property is like follows:
<%@ LANGUAGE="VBSCRIPT" LCID=1055 %>
' Continuing the asp code
' ...
It is a good practice to have a "setting file" having the settings for all pages, -that contains setting LCID, setting Codepage (we will discuss below in this topic), setting "Charset", setting "Buffer" and setting cache-control parameters, and the parameters like this- and include it to the top of every page. I have a setting file like this:
<%@ LANGUAGE="VBSCRIPT" LCID=1055%>
<%
response.Charset="utf-8"
session.CodePage="65001"
Response.Expires = -1
Response.ExpiresAbsolute = Now() - 1
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
Response.Buffer=True
' Database connection
Set conn = Server.CreateObject("ADODB.Connection")
conn.Provider = "Microsoft.Jet.OLEDB.4.0"
conn.Open Server.MapPath("path_to_db.mdb")
%>
You see my setting or header -whatever you name it- file contains all of the common session and response settings. And I include this file (let's say "settings.asp") to the top of all my web pages like this:
<!-- #include file="settings.asp"-->
<%
' the ASP codes ...
%>
<html>
<!-- the html codes ... -->
</html>
The important point is, you must include the file to the top of the pages, nothing (an ASP code or html code) must be written above. Because <%@ ... %> directive must be at the top of an ASP page.
2- Modifying LCID property between the code
You can modify the LCID property between the code. Here the example comes:
<%
Session.LCID = 1055
Dim curNumb
curNumb = FormatCurrency(125)
Response.Write (curNumb)
%>
But, I prefer setting the LCID on Page directive, at top of the page and not chage it during runtime. You will not usually need to change it at runtime.
What about the codepage and the character encoding?
The character encoding is another problem. When you store your string data on database is UTF-8 encoded, you will have problem to display it on your ASP page. Or, simply you will have a problem that you cannot understand why, on displaying Turkish characters. Also, when you are testing your ASP page on local, no problem about displaying your TR characters, but when you upload the file to host and run your ASP page (usually having DB access and reading string that has TR characters on it from DB) you have problem to display the character. The reason is, you have a host abroad, and your host's default codepage is set to standart latin (English) letters.
Like LCID property, you can set the codepage property in two ways.
1- In page directives:
<%@ LANGUAGE="VBSCRIPT" codepage=65001 %>
' Continuing the asp code
' ...
But, this will modify the codepage for only this response. To modify the codepage for whole session -that is better-, use the second way.
2- Between the code:
<%
Session.codepage = 1254
' or Response.codepage= 1254
Response.Write ("öçüğış")
%>
Note that 1254 is Turkish codepage and 65001 is Unicode(utf-8) codepage.
Setting Response.CodePage explicitly affects a single page, whereas Session.CodePage affects all responses in a session.
If Response.CodePage is not explicitly set in a page, it is implicitly set by Session.CodePage, if sessions are enabled. If sessions are not enabled, Response.CodePage is set by @CodePage, if @CodePage is present in the page. If there is no @CodePage in the page, Response.CodePage is set by the AspCodePage metabase property. If the AspCodePage metabase property is not set, or set to 0, Response.CodePage is set by the system ANSI codepage.
There can be only one codepage per response body, otherwise incorrect characters are displayed. If you set the codepage explicitly in two pages where one is called by the other with #include, Server.Execute, or Server.Transfer, usually the parent page decides the codepage. The only exception is if Response.CodePage is explicitly set in the parent page of a Server.Execute call. In that case, an @CodePage command in the child page overrides the parent codepage.
Literal strings in a script are still encoded by using @CodePage (if present) or the AspCodePage metabase property value (if set), or the system ANSI codepage. If you set Response.CodePage or Session.CodePage explicitly, do so before sending nonliteral strings to the client. If you use literal and nonliteral strings in the same page, make sure the codepage of @CodePage matches the codepage of Response.CodePage, or the literal strings are encoded differently from the nonliteral strings and display incorrectly.
If the codepage of your Web page matches the system defaults of the Web client, you do not need to set a codepage in your Web page. However, setting the value is recommended. If the codepage is set in a page, then Response.Charset should also be set. The codepage value specifies to IIS how to encode the data when building the response, and the Charset value specifies to the browser how to decode the data when displaying the response. The CharsetName parameter of Response.Charset must match the codepage value, or mixed characters will be displayed in the browser. Lists of CharsetName parameters and matching codepage values can be found on MSDN
Web Workshop under the columns for Preferred Charset Label and FamilyCodePage.
The file format of a Web page must be the same as the @CodePage used in the page. Notepad enables you to save files in UTF-8 format or in the system ANSI format. For example, if @CodePage is set to 65001 (indicating UTF-8), the Web file must be saved in UTF-8 format. If @CodePage is set to 1252 (indicating English or German), the Web file must be saved in ANSI format on an English or German system. If you want to save a page in the ANSI format for a language other than your system language, you can change your default System Locale settings in Regional and Language Options in the Control Panel. For example, after you change your system locale to Japanese, any files you save in ANSI format are saved using the Japanese codepage and are only readable from a Japanese system locale.
If you are writing and testing Web pages that use different codepages and character sets (for example, if you were creating a multilingual Web site), remember that your test client computer must have the language packs installed for each language you want to display. You can install language packs from Regional and Language Options in the Control Panel.
Using Unicode charset is a good practice. I will write a different topic on using Unicode and advantages and importance of Unicode charset.
Please follow the blog, and comment on entries. Your comments are important.
|
Set as Homepage
Add to Favourites
Recommend
Contact
