Localization of dates, numbers, and strings using LCID

What is the LCID in ASP?

The LCID (Locale Identifier) is a numeric identifier used by Windows (and therefore by Classic ASP in VBScript and JScript) to define the cultural and linguistic rules applicable to the execution of your code, when it must process data related to:

•  The format of dates and times,
•  The separators for decimals and thousands,
•  Financial and monetary decimal data,
•  The sorting and comparison of strings, dates, and numbers,
•  The display of strings, dates, and numbers,
•  The default language to use for certain operations.

The LCID is neither a language nor a country. Indeed, the same language can be used in several countries with sometimes notable or subtle differences. In the same way, the population of a single country may speak several languages. This reality therefore justifies the definition of multiple LCIDs for the same language. Windows LCIDs are constructed based on a LANGID (language) + a SUBLANG (variant / script).

Where and how to specify the LCID ?

There are several ways to specify the LCID that your ASP site, session, or script uses:

•  Set the default LCID in the ASP properties of IIS,
•  Call the native ASP function SetLocale(),
•  Set the native ASP property Session.LCID in your script,
•  Set the native ASP property Response.LCID in your script.

Although recognized by Windows, note that not all LCIDs are immediately usable: some require the installation of additional language packages on the relevant Windows Server system before they can be implemented. To see the list of available LCIDs click here.

You can verify that the LCID you specified has been correctly applied by using the GetLocale() function as follows:

<%
'Apply LCID 1036 (French)
SetLocale(1036)

'If the LCID matches:
if (GetLocale() = 1036) then
   Response.Write "Valid LCID"
'If the LCID is different:
else
   Response.Write "LCID used as a replacement : " & GetLocale()
end if
%>

If the LCID is valid and recognized, but not installed on the system, the Classic ASP runtime engine silently fails to apply the LCID but does not raise an explicit error: it then applies either the LCID defined by default in IIS for your site (if different from 0), or the default LCID currently in effect on the Windows Server system if that also fails.

If you specify an unsupported LCID (lines highlighted in yellow), the Classic ASP runtime engine generally raises an explicit error, as shown in the following code snippet:

<%
'-------------------------
'Assign an invalid LCID (via "SetLocale")
SetLocale(98765)

'The following error is raised:
'   0x800A01BF
'   Object doesn't support current locale setting: 'SetLocale'


'-------------------------
'Assign an invalid LCID (via "Session")
Session.LCID = 98765

'The following error is raised:
'   0x80004005 (ASP 0219)
'   SessionID
'   The specified LCID is not available.


'-------------------------
'Assign an invalid LCID (via "Response")
Response.LCID = 98765

'The following error is raised:
'   0x80004005 (ASP 0219)
'   Response object
'   The specified LCID is not available.
%>

Scope of the LCID

The LCID does not have the same scope depending on where you specify it. You can use these differences to your advantage in order to apply exceptions to previously defined rules, so that a LCID is used only in certain portions of your code, meaning it applies only to specific elements or objects.

These different LCID declaration modes are detailed below, listed in order of scope.

Default LCID in IIS > ASP

•  Scope
  • Global to the IIS application
  • Applied before any script execution
  • Used as the initial value for Session.LCID, Response.LCID and the thread
•  Typical use cases
  • Single-culture application
  • Historical legacy
  • Fallback value when no LCID is defined in the code
•  Affected elements
  • Dates
  • Numbers
  • Strings
•  Limitations
  • Static
  • Not adaptable to the user
•  Usage example
  • IIS > ASP > LCID = 1036 (French)

Definition via SetLocale()

•  Scope
  • Current thread
  • Request duration only
  • Non-persistent
•  Typical use cases
  • Temporary and localized formatting
  • Temporary exception
  • Well-defined code block
•  Affected elements
  • Dates
  • Numbers
  • Strings
•  Limitations
  • Fragile
  • Invisible side effects
  • To be avoided as a global mechanism
•  Usage example
  ASP CLASSIC

  <%
  'Global locale ID configuration at the session level
  Session.LCID = 1036 'French
  
  'Perform certain actions with LCID 1036 (French)
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Locale exception: Retrieve the active locale ID and then replace it
  '   previousLocale receives the active locale ID (1036) from Session.LCID.
  '   Note : SetLocale() does not change Session.LCID
  Dim previousLocale : previousLocale = SetLocale(1033) 'English
  
  'Perform processing in the now active locale ID (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  
  'Restore the thread's previous locale ID (1036)
  SetLocale previousLocale
  %>

Definition in Session.LCID

•  Scope
  • User session
  • Persistent across all requests of the session
•  Typical use cases
  • Multilingual application
  • User culture (language, country)
  • Consistent formatting policy
•  Affected elements
  • Dates
  • Numbers
  • Strings
•  Limitations
  • Dependency on an implicit state
  • May hide formatting errors
  • Problematic for technical exports
•  Usage example
  ASP CLASSIC

  <%
  'Global configuration of the locale ID at the session level
  Session.LCID = 1036 'French
  
  'Perform certain actions with LCID 1036 (French)
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Now replace the locale ID at the session level with 1033
  Session.LCID = 1033 'English
  
  'Perform the following actions in the now active locale ID (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Definition in Response.LCID

•  Scope
  • Current HTTP response
  • Applied to the output stream
•  Typical use cases
  • CSV / text export
  • Document generation
  • User-independent output format
•  Affected elements
  • Dates
  • Numbers
  • Strings
  • Formatting of data written via Response.Write
•  Limitations
  • Not very intuitive
  • Source of confusion
  • Rarely necessary
•  Usage example
  ASP CLASSIC

  <%
  'Global locale ID configuration at the session level
  Session.LCID = 1036 'French
  
  'Perform certain actions with LCID 1036 (French)
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Locale exception: Retrieve the active locale ID and then replace it
  '   previousLocale receives the active locale ID (1036) from Session.LCID.
  '   Note : Response.LCID() does not change Session.LCID
  Dim previousLocale : previousLocale = GetLocale() 'French (1036)
  Response.LCID = 1033 'Anglais
  
  'Return a date to the now active locale ID (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Impacts of LCID in Classic ASP

The LCID is a Windows convention (32 bits), historically composed of a language identifier and a region identifier. It therefore notably influences functions such as CDate, FormatDateTime, FormatNumber, FormatCurrency, InStr, StrComp, LCase, etc (non-exhaustive list). In practice, the critical point in development scenarios is rarely the display, but rather the upstream stages, namely reading, parsing, and calculations. The lack of standardization of thousands and decimal separators in numbers is a common pitfall that can cause errors during insertions into your databases.

Running the same Classic ASP code on two different servers with different regional settings can therefore generate divergent results. This is why it is recommended, on the one hand, to set the default LCID in the IIS properties, and on the other hand to specify this LCID in your ASP source code before each operation involving reading, calculating, and rendering textual, numeric, and date/time data.

You can define and modify the LCID at any time via SetLocale(), Session.LCID and Response.LCID within the same script. This is in fact a technique frequently used to handle numeric data or dates within a page: using an English LCID (1033) to perform calculations, then using a localized LCID in another language/region to return the information to the user.

A common LCID strategy regarding comparisons and displays of character strings is:

•  For your business logic
  • Set Session.LCID at the beginning of a script (or of a session in global.asa)
  • Perform all reads and calculations with this LCID
  • Always use a binary comparison mode (0=vbBinaryCompare)
•  To handle an exception
  • Temporarily use SetLocale() for one-time processing
•  Presentation/display/output
  • Specify Response.LCID when displaying a piece of data

When coding, you must not rely on any predefined setting: you must set the rules yourself and force the LCID setting from the very beginning of your script. This is the only way to ensure that your code can run on any type of server, regardless of its regional and linguistic configuration (for example, Windows Server in English, French, Spanish, etc.).

Systematically setting the LCID to a constant value before each operation will ensure that your code is reliable and behaves predictably on any Windows server. Handling dates and numeric data on a Classic ASP system requires rigor and consistency. You can call on us if you need to make your code more reliable in these areas:

•  Switching from one language to another (changing the LCID during script execution)
•  Converting dates and numbers between different regions
•  Handling dates in several different time zones
•  Handling numbers coming from different regions
•  Performing complex calculations across calendars
•  Handling leap years
•  Handling time zones, standard time/daylight saving time
•  Reading or formatting dates in standard ISO format
•  Converting dates from UTC to a region (and vice versa)

Impacts of LCID on dates

Dates and times are very heavily impacted by the LCID currently in effect in your Classic ASP script. Some languages use very different date formats, with slashes, hyphens, and spaces to separate days, years, and times. If you historically developed on a Windows system in English, French, or Spanish, then move your code to another server, it will generate a very large number of errors if the default LCID in IIS is not exactly the same.

If your code does not define any LCID, and expects a particular value that you have always known, we offer, free of charge, to define the default LCID in IIS of your choice on your Classic ASP shared hosting. This will allow your source code to run in the same way it always historically has.

Impacted functions

The date-related functions impacted by the LCID are the following:

•  Conversion functions:
  • CDate : affects the recognition of date formats (day/month/year order, separators, month names spelled out depending on the language). Example: The date "03/04/2025" will be interpreted as April 3 in fr-FR (LCID 1036), but will mean March 4 with an en-US LCID (1033).
  
  
•  Comparison functions:
  • IsDate, IsNumeric : affects data validation before conversion. Example: The date "13/04/2025" will be accepted because it is recognized as April 13 in fr-FR (LCID 1036), but will be considered invalid with an en-US LCID (1033), because month #13 does not exist.
  
  
•  Formatting/display/output functions:
  • FormatDateTime : affects date/time formats (day/month order, separators, localized names, etc).
  • WeekdayName : affects the day name and determines the language of the returned text.
  
  

Tips & Best Practices

•  Always define the LCID

  Explicitly declare the LCID in the same way before each operation:

  • Reading from your database
  • Retrieving data from a form
  • Modifying a date
  • Displaying a date
  
  
•  Perform calculations with LCID 1033

  It is recommended to perform as many date comparison and modification operations as possible using LCID 1033, which is predictable and known by all developers, and available by default on all Windows Server systems.

  
  
•  Rebuild your dates

  It is advisable to systematically "parse" the date in order to extract its different components (Day, Month, Year, Hour, Minute, Second), then rebuild it into a variable using the functions DateSerial() or TimeSerial(). You thus obtain a VBScript variable of type date that is perfectly reliable. This is often essential if some dates come from a web form, and more rarely when they are read from your database.

  
  
•  Compare dates with the same LCID

  When you compare and modify dates, always use two dates that were defined with the same LCID.

  
  
•  Convert late to other time zones

  Always perform your calculations, comparisons, and date modifications with the same LCID, then convert them to another time zone only at the time of display. You can use the LJW ServerSuite component to natively convert your dates and times from Classic ASP to other time zones, from and to UTC, as well as in ISO format.

Impacts of LCID on numbers

Integer and decimal numbers are very heavily impacted by the LCID currently in effect in your Classic ASP script. Some languages use dots, commas, spaces, etc. to separate thousands and decimals. If you historically developed on a Windows system in English, French, or Spanish, then move your code to another server, it will generate a very large number of errors if the default LCID in IIS is not exactly the same.

If your code does not define any LCID, and expects a particular value that you have always known, we offer, free of charge, to define the default LCID in IIS of your choice on your Classic ASP shared hosting. This will allow your source code to run in the same way it has always historically behaved.

Impacted functions

The number-related functions impacted by the LCID are the following:

•  Conversion functions:
  • CLng, CInt, CSng, CDbl, CCur : affects the interpretation of thousands and decimal separators. Example: "1,23" will mean 1.23 in fr-FR (LCID 1036), but may be misinterpreted with an en-US LCID (1033). Note in this regard that CCur() converts to Currency, the only exact decimal type, whereas CDbl() converts to Double, which is a binary floating-point number that may potentially lead to approximations that are unacceptable when dealing with monetary or financial data.
  
  
•  Formatting/display/output functions:
  • FormatNumber, FormatPercent : affects the interpretation of thousands and decimal separators, the groupings, and percentages.
  • FormatCurrency : affects the interpretation of currency symbols, the placement of the symbol, the separators, the number of decimals, and negative numbers.

Tips & Best Practices

•  Always define the LCID

  Explicitly declare the LCID in the same way before each operation :

  • Reading from your database
  • Retrieving data from a form
  • Modifying a numeric value
  • Displaying a numeric value
  
  
•  Perform calculations with LCID 1033

  It is recommended to perform as many comparison and modification operations as possible on decimal and monetary numbers using LCID 1033, which is predictable and known by all developers, and available by default on all Windows Server systems.

  
  
•  Standardize thousands separators

  Do not overlook thousands separators : some languages use the comma or the dot (or even the space) as a thousands separator. You are heading for serious problems if you do not standardize these separators before converting your value into a numeric variable with CLng(), CCur(), etc.

  
  
•  Standardize decimal numbers

  Do not trust any decimal numeric variable. The decimal separator varies depending on the language (comma, dot). VBScript performs all its calculations using variables whose decimal separator is the dot.

  Regardless of the origin of your numeric variable, make sure it uses a dot as the decimal separator before converting it with CLng(), CCur(), etc. You might be tempted to replace commas with dots like this :

  ASP CLASSIC

  <%
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Read from database
  myDecimalNumber = Replace(myDecimalNumber, ",", ".") 'Replace commas with periods
  myDecimalNumber = Trim(Replace(myDecimalNumber, " ", "")) 'Remove spaces
  myDecimalNumber = CCur(myDecimalNumber) 'Convert to a decimal variable (currency type)
  %>

  
  

  However, in some languages and regions, the comma is not used as a decimal separator, but as a thousands separator. This technique will therefore not work. This is why it is important that you know in advance the origin of the numeric data that your code uses.

  Instead, use the following code, which relies on ASP functions responsible for retrieving (in yellow) and using (in blue) the separators actually in effect with the current LCID. This technique works even if you do not know with certainty the original format of the numeric value that you are about to process in your code :

  ASP CLASSIC

  <%
  'Function: Returns the separator character used for thousands.
  Function GetSystemThousandSep()
     GetSystemThousandSep = Mid(FormatNumber(2000), 2, 1)
  End Function 'GetSystemThousandSep
  
  'Function: Returns the separator character used for decimals.
  Function GetSystemDecimSep()
     GetSystemDecimSep = Mid(CStr(1/2), 2, 1)
  End Function 'GetSystemDecimSep
  
  'Force the LCID to use English to perform calculations
  Response.LCID = 1033
  
  'Retrieve the separators
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = 1234.56
  myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Force the decimal separator to "period"
  myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Remove thousands separators
  myDecimalNumber = CCur(myDecimalNumber) 'Convert to a decimal variable (Currency type)
  
  Response.LCID = 1033 'Set the display locale ID to English
  myDecimalNumber = myDecimalNumber + 0.01 'Add 1 cent (LCID has no impact on this calculation)
  Response.Write "EN : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Display the variable => Returns 1,234.57
  
  
  Response.LCID = 1036 'Set the display locale ID to French
  myDecimalNumber = myDecimalNumber + 0.01 'Add 1 cent (LCID has no impact on this calculation)
  Response.Write "FR : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Display the variable => Returns 1 234,58
  
  
  Response.LCID = 1034 'Set the display locale ID to Spanish
  myDecimalNumber = myDecimalNumber + 0.01 'Add 1 cent (LCID has no impact on this calculation)
  Response.Write "ES : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Display the variable => Returns 1.234,59
  %>

  
  
•  Do not trust your numbers

  Your code can trigger an error at any time. Therefore, add safeguards throughout your code. To do this, use the same techniques that we do : program in an ultra-defensive way. For this purpose we use functions that we have specifically developed, but the code below gives you a general idea of the type of checks that must be implemented : (contact us if you need assistance to strengthen your defenses)

  ASP CLASSIC

  <%
  'Retrieve the separators (see functions defined elsewhere on this page)
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Read from database
  if (NOT IsNull(myDecimalNumber)) then
     if (myDecimalNumber <> "") then
        myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Force decimal separator to "period"
        myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Remove thousands separators
        Err.Clear
        On Error Resume Next
           myDecimalNumber = CCur(myDecimalNumber) 'Convert to decimal variable (Currency type)
           if (Err.Number <> 0) then
              Response.Write "<br>An error occurred during conversion to type Currency"
              Response.Write "<br>" & Err.Number & " - " & Err.Description
           end if
        On Error Goto 0
        Err.Clear
     end if
  end if
  %>

  
  

Impacts of LCID on character strings

The LCID influences the linguistic rules used by Windows and therefore the ASP engine to compare and sort strings (collation and Unicode comparisons). This particularly impacts text comparisons, certain operations related to character casing, and the way accents are handled. This is one of the most frequently overlooked aspects among the many impacts of choosing a LCID.

The LCID affects sorting and text comparisons, but does not affect explicit sorting performed by the database, or raw ASCII comparisons.

Impacted functions

The character string functions impacted by the LCID are the following :

•  Fonctions de comparaison :
  • VBScript operators = and <> : affects comparisons, which are therefore performed in text mode (1=vbTextCompare), and are therefore sensitive to the LCID. These operators are case-insensitive but remain sensitive to accents in common Latin locales (French, English, etc.). VBScript text comparison is case-insensitive (e = E) and accent-sensitive (e ≠ é), because it relies on the Windows collation associated with the active LCID. VBScript never performs Unicode normalization (NFD / NFC) nor "accent removal": it never transforms é into e. Unlike VBA, Option Compare is not available in VBScript, and this is a major difference that represents a risk. As a result, comparisons performed by these operators are systematically influenced by the LCID and are text comparisons. NEVER use = and <> if an exact comparison is required.
  • StrComp, InStr : affects the comparison of character casing, but does NOT affect accented characters : StrComp is always accent-sensitive and the LCID does not change this. StrComp becomes sensitive to the LCID when the comparison is performed in text mode (1=vbTextCompare) and on strings including accented characters from certain non-Western languages. Note in this regard that this function uses a simplified text comparison, historically limited for languages using special Unicode mappings (examples in Turkish with the characters İ and i, which will always be considered different, even with 1=vbTextCompare). This function also depends on the encoding of your file and the Codepage that you define in your script (highlighted in blue). The following code demonstrates the effects of LCID on string comparisons :
    
    ASP CLASSIC

    <%@codepage=65001%>
    <%
    'Ensure consistent UTF-8 encoding
    'Obviously requires that your ASP file was also saved in UTF-8 format at the source.
    Session.CodePage = 65001
    Response.CodePage = 65001
    Response.CharSet = "utf-8"
    
    
    Session.LCID = 1036 'Set to French
    
    Dim sourceText : sourceText = "Here is a beautiful written sentence"
    Dim searchedText : searchedText = "WRITTEN"
    
    'Technical search (e.g., IDs, paths, emails, tags)
    'Use 0=vbBinaryCompare so that the LCID has no influence
    '=> searchedText is NOT found
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbBinaryCompare))
    
    'User search (e.g., displayed text, user input)
    'Use an explicit LCID
    '=> searchedText is found
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbTextCompare))
    
    
    
    'Implicit binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive
    Response.Write "<br>" & ("E" = "e")
    
    'Explicit binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Explicit textual comparison (depends on the LCID)
    'Returns "True" : 1=vbTextCompare InCase-sensitive
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Explicit binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive, Accent-sensitive
    Response.Write "<br>" & (StrComp("É", "é", vbBinaryCompare) = 0)
    
    'Explicit textual comparison (depends on the LCID)
    'Returns "True" : 1=vbTextCompare Case-insensitive, Accent-sensitive.
    '"É" and "é" are the same accentuated character.
    '   => This is the expected behavior.
    '   Happens if:
    '      - File saved, for example, in UTF-8 or Windows-1252, and executed as such
    '      - Consistency between @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    
    'Implicit textual comparison (depends on the LCID) (SAME SOURCE CODE AS THE TEST ABOVE => BUT INCORRECT RESULT)
    'Returns "False" : 1=vbTextCompare Case-insensitive, Accent-sensitive.
    '"É" and "é" are not the same accentuated character : The characters being compared are incorrectly encoded.
    '   => This is inconsistent and unreliable behavior.
    '   Happens if:
    '      - File saved, for example, in UTF-8 but executed in Windows-1252 (or vice versa)
    '      - Inconsistencies between @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    'Expected : 201 and 233. Otherwise, the "False" is explained by the aforementioned encoding inconsistencies.
    Response.Write "<br>AscW(É)=" & AscW("É") & " / AscW(é)=" & AscW("é")
    
    Response.Write "<hr>"
    
    
    Session.LCID = 1055 'Turkish
    
    'Implicit binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive
    Response.Write "<br>" & ("E" = "e")
    
    'Explicitly binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Explicit textual comparison (depends on the LCID)
    'Returns "True" : 1=vbTextCompare Case-insensitive
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Explicitly binary comparison (independent of the LCID)
    'Returns "False" : 0=vbBinaryCompare Case-sensitive and Accent-sensitive
    Response.Write "<br>" & (StrComp("İ", "i", vbBinaryCompare) = 0)
    
    'Explicit textual comparison (depends on the LCID)
    'Should return "True" because of : 1=vbTextCompare Case-insensitive, Accent-sensitive.
    '"İ" et "i" are the same accentuated character.
    'However, this VBScript function suffers from a historical limitation and performs a simplified textual comparison.
    'This function therefore returns "False", which is expected in VBScript.
    'Consequently, it is advisable to use a function to replace accented characters
    'before any comparison in non-Western languages.
    Response.Write "<br>" & (StrComp("İ", "i", vbTextCompare) = 0)
    
    Response.Write "<hr>"
    %>
    

    
    
•  Character casing functions:
  • UCase, LCase : affects the conversion performed. The linguistic rules used are delegated/handled by Windows and depend on the LCID. The linguistic rules used correctly handle non-Western languages such as Turkish, unlike StrComp(). Example: UCase("i") will return İ in tr-TR (LCID 1055), but will return I in en-US (LCID 1033).
  
  
•  - Sorting and ranking functions:
  • Scripting.Dictionary (with CompareMode: 1=vbTextCompare) : affects the order in which characters are compared. Example:
    
    ASP CLASSIC

    <%
    'According to the LCID, the keys "e", "é", "è" will not be considered equivalent, or ordered in the same way.
    Set oDict = Server.CreateObject("Scripting.Dictionary")
    oDict.CompareMode = 1 'vbTextCompare
    %>

    
    

Tips & Best Practices

•  Always define the LCID

  Explicitly declare the LCID in the same way before each operation:

  • Retrieving data from a form
  • Sorting strings
  • Comparing strings
  • Searching within a string
  
  
•  Compare with 0=vbBinaryCompare

  When you compare or classify character strings, always use a 0=vbBinaryCompare mode to avoid false positives. The risk is even greater with certain types of data (identifiers, codes, emails, passwords): these must NEVER be compared using 1=vbTextCompare, but always using 0=vbBinaryCompare.

Incorrect historical lists of LCID

 There are many sources providing LCID lists. Approach these sources with great caution, because many of them are outdated, incomplete, or even incorrect. We provide an up-to-date list that is fully compatible.

Classic ASP itself does not define any list of available LCIDs: it delegates this task to the Windows NLS (National Language Support)  APIs. The Classic ASP platform therefore fully inherits the LCID (Locale ID) list provided by Windows.

Some lists rely on arbitrary or restrictive sources (for example related to Microsoft Office or Exchange), or perform extrapolations from the BCP-47 standard in order to artificially infer imaginary Windows LCIDs. These deductions are incorrect, because each BCP-47 language code does not necessarily have a corresponding entry in the list of valid Windows LCIDs officially supported and implemented by Microsoft: many BCP-47 entries are in fact not supported. Windows strictly distinguishes for each language the pair "script + region", whereas abbreviated BCP-47 notation often indicates only the language code itself (using 2 or 3 characters).

Finally, also pay close attention to the fact that some LCID lists incorrectly include all LCIDs natively supported by Windows. However, although they are defined in Windows, this does not mean that all of them can be used by Classic ASP. An LCID is actually supported by Classic ASP only if it corresponds to a "complete Windows Locale" (language + region) installable via Windows regional settings on the one hand, but also if it is not "script-only", reserved, theoretical, or without a region on the other hand. Make sure you do not specify an LCID that does not exist.

Complete list of LCIDs that can be used in Classic ASP

 We provide you with the most reliable list of the different LCIDs possible in Classic ASP. This list includes only LCIDs that are actually recognized and still supported by Classic ASP on Windows Server 2025, 2022 and 2019.

Some of these entries are historical and considered "deprecated" in the sense that the "region + language" combination has changed for geopolitical or normative naming reasons; however they remain technically viable and handled by the Classic ASP runtime engine as they were on Windows Server 2016, 2012, 2008, 2003 and 2000. It is recommended to replace the codes indicated in the "Tags Locale - (historical)" column with the current version indicated in the "Tag Locale - IETF BCP 47" column in order to ensure the long-term reliability of your code.

The list provided below has been compiled by us methodically and verified, and proven over time across the many websites, intranets, Classic ASP applications and systems on which we have worked. These LCIDs are all fully functional: use them with confidence with SetLocale() or Session.LCID for example.

Classic ASP hosting

Classic ASP hosting and migration to Windows Server 2025 / 2022 / 2019

Classic ASP development & maintenance

Classic ASP maintenance, support and development for websites and business applications

IIS Audit & configuration tweaking

Microsoft® IIS configuration audit and performance tuning