ASP Miscellaneous Features

Besides the feature of reusing of the existing codes, ASP technology also provides extra features for setting the process configuration of the ASP engine execution.

ASP @ Processing Directives

In order to have a flexible ASP web application, ASP supports the feature of @ processing directives as optional features. Each ASP page can have an individual control setting for processing  the ASP files. Since each ASP page including included files can only have one single setting and the control setting should be specified before the ASP file  is processed by the ASP engine, the ASP @ processing directives must be the first command within the ASP page, usually placing at the begining of an ASP file to pass information to the web servre on how to process the ASP file and the included files of an ASP page. The five supported ASP @ Processing Directives are

• @CODEPAGE: to specify the literal strings encoding in a web pagee
• @ENABLESESSIONSTATE: to turn off session tracking for a web page
• @LANGUAGE: to set the programing language for interpreting the scripting commands
• @LCID: to specify the display format of dates, times and currencies in a web page by locale identifiers
• @TRANSACTION: to specify the scripting command of the ASP page is treated as a transaction for activating the component services to create a transaction for coordinate the resources updating. That is  to specify the ASP file to run under a transaction context

ASP @ CODEPAGE Processing Directive

The @ CODEPAGE directive is used to specify which "codepage" encoding is used to encode  the literal or static strings or the contents of a web page stored in an ASP page. The presenting contents of a web page stored in an ASP page may be written in different language. In general, there is a code page for each language to represent the character encoding of the character set of the language. A character set of an language is a set of digits, alphabets, symbols, punctuation marks, and other glyphs. Code pages are tables of encoded characters mapped to single-byte values or multibyte values for each language. e.g. English is encoded by single byte, Chinese is encoded by multiple bytes. A code page is usually represented by a number. The @ CODEPAGE directive is a write-only option assigned to an ASP page specifically.

Syntax: Syntax:

<%@ CODEPAGE = code page %>

Parameters:

code page

The parameter "code page" is an unsigned integer used to interpret the literal or static strings contents stored in the ASP page. The unsigned integer should be a valid code page or well defined code page for the system in which the ASP scripting engine running.

Remarks:

The default code page of all ASP page is set by the AspCodePage metabase property or by the system ANSI code page implicitly. The @ CODEPAGE directive is used to set the code page of the literal or static strings contents of an ASP page explicitly in a ASP page. Therefore the setting of @ CODEPAGE directive explicitly in an ASP page only affects the literal strings of the stored contents of the ASP page in one single response. While the specifying of the Response.CodePage will only affect the dynamic strings or the HTML output response of the ASP engine in a single response. And the specifying of the Session.CodePage is used to affect dynamic strings for all HTML output responses in a session.

No matter what types of code page setting are specified in the ASP page, there can only be one code page for all the response body or the HTML output response of a web page in the client browser. Incorrect characters are displayed when the code page setting does not match with the character encoding of the response characters. However in order to increase the flexibility of ASP, the code page settings for processing an ASP page are divided into static and dynamic strings. The @CODEPAGE directive is for the code page setting of the static string. And the Response.CodePage or Session.CodePage are for the code page setting of the dynamic strings. The @CODEPAGE directive must be the first command of the ASP page, while the setting of code page by Response.CodePage explicitly can be just done before the response output of the non-literal or dynamic strings by the ASP engine. This is important when literal and non-literal strings are used in the same page especially when static and dynamic strings are used in same command. In general, the code page of @CODEPAGE must match with the code page of Response.CodePage, or literal strings and non-literal strings with different code page setting will display the character incorrectly in either case. Usually, when a web page is created by two asp files, where one file is called by the parent file using #include directive, Server.Execute, or Server.Transferand, the code page of the web page is decided by the parent file of the two ASP pages are set explicitly. The only exception is the using of the Response.CodePage to set the output response explicitly in the parent page before a Server.Execute then the @CODEPAGE directive setting in the child page explicitly can override the code page setting in the parent page.

Since the system default code page will be used when there is no code page setting in a web page, sometimes it is not necessary to set a code page in the web page for those web client with matched system default code page. However, setting the code page for a web page is alway necessary for encoding the response output correctly for all web client in the WWW.

And therefore if the code page is set in a page, the Response.Charset should also be set in order to ensure the response output is displayed correctly for all web client in the WWW.

In order to make the response output display correctly, the file format of a web page must be stored with the same @CodePage setting used in the page. In window, notepad can save files in UTF-8 format or in the system ANSI format. Therefore the ASP file should be saved in UTF-8 format if the @CodePage is set to 65001. Since notepad can save files in system ANSI format according to the default system locale setting in the Regional and Language Options in the Control Panel, notepad can save file in different file format according to @CodePage setting by changing the system locale setting before saving the file.

Similarly, in order to test web pages that use different code pages and character sets in a client computer, the corresponding language packs should also be installed through the adding of language packs in the Regional and Language Options in the Control Panel.

ASP @ ENABLESESSIONSTATE Processing Directive

The @ ENABLESESSIONSTATE directive is used turn off session tracking for a page. By default, the information about requests from a single client is maintained by session tracking.

Syntax:

<%@ ENABLESESSIONSTATE = False %>

Remarks:

If no page response rely on session information, session tracking can be disabled to reduce script processing time.

ASP @ LANGUAGE Processing Directive

The @ LANGUAGE directive is used to specify the scripting language or the script engine that the ASP engine should be used to interpret the script commands in the ASP page. Since ASP engine of Internet Information Server supports both Microsoft VBScript and JScript and other ActiveX compliant scripting languages. In general, both VBScript and JScript can be used as the scripting language for ASP.  The @ LANGUAGE directive is an option, by default, the scripting language is VBScript. If no @ LANGUAGE directive is specified in the script, all script is interpreted by the default VBScript engine.

Syntax:

<%@ LANGUAGE = script engine %>

Parameters:

script engine

The parameter "script engine" is the name of the script engine used to interpret the script or the name of scripting language used in the ASP page. However only two script engines, VBScript and JScript are pre-installed with Internet Information Services (IIS), other types of scripting language should be installed before using.

Remarks:

The default scripting language is VBScript. The default scripting language can also be changed by modifying the IIS Admin Object AspScriptLanguage property. The changes of property can be applied to web service, web server, virtual directory, or web directory.

ASP @ LCID Processing Directive

The @LCID Directive is used to specify the format of dates, times and currencies that the ASP engine should be used to interpret the static or literal strings in the ASP page for different geographical locale. The @LCID Directive is write only.

Syntax:

<%@ LCID = locale identifier %>

Parameters:

locale identifier

The parameter "locale identifier" is a valid locale identifer to represent the locale formatting used for the HTML output. The data type of "LocaleID" is integer. The possible LocaleID are.

Remarks:

The local identifier, LCID is a standard international numeric abbreviation for different geographical locale. However, locale identifier is being to be a valid locale identifier after the locale group is being installed on the web server that can be installed through the Regional and Language Options of control panel application. The LCID is also the unique identifier to identify the installed system-defined locales. The two defined LCID of the system is the default locale of the system, LOCALE_SYSTEM_DEFAULT and the individual user's locale setting for the current user, LOCALE_USER_DEFAULT.

The @LCID directive is used to set the locale format of dates, times and currencies for all static or literal strings in a single response explicitly. The locale format is only to specify the display format, not the encoded code. While Response.LCID affects dynamic strings in a single response, and Session.LCID affects dynamic strings in all responses in a session.

And a locale format is always needed for formating the locale format of dates, times and currencies of all static or literal strings in an ASP page. If @LCID directive is not explicitly set in a page, it is implicitly set by the AspLCID metabase property or by the default system locale.

The @LCID directive sets the locale used in an ASP page for both the ASP engine and the scripting engine. But the VBScript function, setLocale only sets the locale used in the script for the scripting engine only. 

Both Response.LCID and Session.LCID can be used to set LCID of dynamic or non-literal static explicitly before displaying formatted output. Therefore if literal and nonliteral output in the same page, the locale of @LCID setting must match with the locale setting by Response.LCID, otherwise the non-literal output may be formatted differently from the literal output.

Since the system default locale will be used when there is no locale setting in a web page, sometimes it is not necessary to set a locale in the web page for those web client with matched system default locale. However, setting the locale for a web page is alway necessary for formating the response output correctly for all web client in the WWW.

And therefore if locale is set in the page,  the code page is also set in a page, the Response.Charset should also be set in order to ensure the response output is displayed correctly for all web client in the WWW. So that the server can encode the page according to the specified code page with the specified locale format before sending the response output to the client and the client can therefore decode the page according to the specified charset correctly.

SSimilarly, in order to test web pages that use different locales, code pages and character sets in a client computer, the corresponding language packs should also be installed in the client computer through the adding of language packs in the Regional and Language Options in the Control Panel.

Examples:

ASP @ TRANSACTION Processing Directive

The @ TRANSACTION directive is used to specify that the script of the ASP page should be treated as a transaction so that Component Services creates a transaction for the script of the ASP and to coordinate the updating of resources related.

Syntax:

<%@ TRANSACTION = value %>

Parameters:

value

The parameter "value" is the type of the transaction support. Possible values are

Required: Always participates in a transaction, and initiates a transaction if one does not currently exist.

 Requires_New: Always initiates a new transaction.

Supported: Participates in a transaction if one exists but does not require a transaction.

Not_Supported: Never participates in a transaction. If called from a script that is using transactions, the script containing the @TRANSACTION processing directive still runs but outside of the context of the transation.

Remarks:

The @TRANSACTION directive must be the very first line in the ASP file, otherwise an error is generated.

The @TRANSACTION directive must be added to each page that should be run under a transaction. The current transaction ends when the script finishes processing.

When an ASP with the @TRANSACTION directive of value equal to Required is called by either the Server.Transfer or Server.Execute method, if the calling ASP file was transacted, the script of the called ASP file continues the transaction of the calling ASP page. And if the calling ASP was not transacted, the called ASP file creates a new transaction.

ASP Output Directive

Unlike the @ Processing directive, the ASP output directive is used to displays the value of an expression or response output  the result of an expression.

Syntax:

<%@= expression  %>

Parameters:

expression

The parameter "expression" is the statement of script commands

Remarks:

This output directive is equivalent to using Response.Write to display information or to response an HTML output.