Localización de fechas, números y cadenas con LCID

Qué es el LCID en ASP ?

El LCID (Locale Identifier) es un identificador numérico utilizado por Windows (y por tanto por ASP Classic en VBScript y JScript) para definir las reglas culturales y lingüísticas aplicables a la ejecución de su código, cuando este debe tratar datos relacionados con:

•  El formato de las fechas y horas,
•  Los separadores de decimales y de miles,
•  Los datos financieros y monetarios decimales,
•  Las ordenaciones y comparaciones de cadenas, fechas y números,
•  La visualización de cadenas, fechas y números,
•  El idioma que se debe utilizar por defecto para ciertas operaciones.

El LCID no es ni un idioma ni un país. En efecto, un mismo idioma puede utilizarse en varios países con diferencias a veces notables o sutiles. Del mismo modo, la población de un mismo país puede hablar varios idiomas. Esta realidad justifica por tanto la definición de varios LCID para un mismo idioma. Los LCID de Windows se construyen sobre la base de un LANGID (idioma) + un SUBLANG (variante / script).

Dónde y cómo especificar el LCID ?

Existen varias maneras de especificar el LCID que utiliza su sitio, sesión o script ASP:

•  Definir el LCID por defecto en las propiedades ASP de IIS,
•  Llamar a la función ASP nativa SetLocale(),
•  Definir la propiedad ASP nativa Session.LCID en su script,
•  Definir la propiedad ASP nativa Response.LCID en su script.

Aunque Windows los reconoce, tenga en cuenta que no todos los LCID son utilizables inmediatamente: algunos requieren la instalación de paquetes lingüísticos adicionales en el sistema Windows Server correspondiente antes de poder implementarse. Para conocer la lista de los LCID disponibles haga clic aquí.

Puede verificar que el LCID que ha especificado se haya aplicado correctamente utilizando la función GetLocale() de la siguiente manera:

<%
'Aplicar el LCID 1034 '(Español)
SetLocale(1034)

'Si el LCID es conforme
if (GetLocale() = 1034) then
   Response.Write "LCID válido"
'Si el LCID es diferente
else
   Response.Write "LCID utilizado como reemplazo : " & GetLocale()
end if
%>

Si el LCID es válido y reconocido, pero no está instalado en el sistema, el motor de ejecución ASP Classic falla silenciosamente al aplicar el LCID, pero no genera un error explícito: aplica entonces el LCID definido por defecto en IIS para su sitio (si es distinto de 0), o bien el LCID por defecto vigente en el sistema Windows Server si ha fallado.

Si especifica un LCID no admitido (líneas resaltadas en amarillo), el motor de ejecución ASP Classic generalmente genera un error explícito, como muestra el siguiente fragmento de código:

<%
'-------------------------
'Asignar un LCID no válido (mediante "SetLocale")
SetLocale(98765)

'Se produce el siguiente error:
'   0x800A01BF
'   Object doesn't support current locale setting: 'SetLocale'


'-------------------------
'Asignar un LCID no válido (mediante "Session")
Session.LCID = 98765

'Se produce el siguiente error:
'   0x80004005 (ASP 0219)
'   SessionID
'   The specified LCID is not available.


'-------------------------
'Asignar un LCID no válido (mediante "Response")
Response.LCID = 98765

'Se produce el siguiente error:
'   0x80004005 (ASP 0219)
'   Response object
'   The specified LCID is not available.
%>

Alcance del LCID

El LCID no tiene el mismo alcance según el lugar donde lo especifique. Puede aprovechar estas diferencias para aplicar excepciones a reglas previamente definidas, con el fin de utilizar un LCID únicamente en ciertas partes de su código, de modo que solo se aplique a ciertos elementos u objetos.

Estos diferentes modos de declaración del LCID se detallan a continuación, clasificados por orden de alcance.

LCID por defecto en IIS > ASP

•  Alcance
  • Global a la aplicación IIS
  • Aplicado antes de cualquier ejecución de script
  • Sirve como valor inicial para Session.LCID, Response.LCID y el thread
•  Casos de uso típicos
  • Aplicación monocultural
  • Herencia histórica
  • Valor de reserva cuando no se define ningún LCID en el código
•  Elementos influenciados
  • Fechas
  • Números
  • Cadenas
•  Límites
  • Estático
  • No adaptable al usuario
•  Ejemplo de uso
  • IIS > ASP > LCID = 1034 (Español)

Definición mediante SetLocale()

•  Alcance
  • Thread actual
  • Duración de la solicitud únicamente
  • No persistente
•  Casos de uso típicos
  • Formateo puntual y localizado
  • Excepción temporal
  • Bloque de código bien delimitado
•  Elementos influenciados
  • Fechas
  • Números
  • Cadenas
•  Límites
  • Frágil
  • Efecto secundario invisible
  • Debe evitarse como mecanismo global
•  Ejemplo de uso
  ASP CLASSIC

  <%
  'Configuración global del Locale ID a nivel de la sesión
  Session.LCID = 1034 'Español
  
  'Ejecutar ciertas acciones con el LCID 1034
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Excepción local: Recuperar el Locale ID activo y luego reemplazarlo
  '   previousLocale recibe desde Session.LCID el Locale ID activo en ese momento preciso (1034)
  '   Nota: SetLocale() no modifica Session.LCID
  Dim previousLocale : previousLocale = SetLocale(1033) 'Inglés
  
  'Ejecutar un procesamiento en el Locale ID ahora activo (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  
  'Restaurar el Locale ID anterior del hilo (1034)
  SetLocale previousLocale
  %>

Definición en Session.LCID

•  Alcance
  • Sesión de usuario
  • Persistente en todas las solicitudes de la sesión
•  Casos de uso típicos
  • Aplicación multilingüe
  • Cultura del usuario (idioma, país)
  • Política de formateo coherente
•  Elementos influenciados
  • Fechas
  • Números
  • Cadenas
•  Límites
  • Dependencia de un estado implícito
  • Puede ocultar errores de formato
  • Problemático para las exportaciones técnicas
•  Ejemplo de uso
  ASP CLASSIC

  <%
  'Configuración global del Locale ID a nivel de sesión
  Session.LCID = 1034 'Español
  
  'Realizar determinadas acciones con el LCID 1034 (Español)
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Reemplazar ahora el Locale ID a nivel de sesión por 1033
  Session.LCID = 1033 'Anglais
  
  'Realizar las siguientes acciones con el Locale ID ahora activo (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Definición en Response.LCID

•  Alcance
  • Respuesta HTTP actual
  • Aplicado al flujo de salida
•  Casos de uso típicos
  • Exportación CSV / texto
  • Generación de documentos
  • Formato de salida independiente del usuario
•  Elementos influenciados
  • Fechas
  • Números
  • Cadenas
  • Formateo de los datos escritos mediante Response.Write
•  Límites
  • Poco intuitivo
  • Fuente de confusión
  • Raramente necesario
•  Ejemplo de uso
  ASP CLASSIC

  <%
  'Configuración global del Locale ID a nivel de la sesión
  Session.LCID = 1034 'Español
  
  'Ejecutar ciertas acciones con el LCID 1034
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Excepción local: Recuperar el Locale ID activo y luego reemplazarlo
  '   previousLocale recibe desde Session.LCID el Locale ID activo en ese momento preciso (1034)
  '   Nota: Response.LCID() no modifica Session.LCID
  Dim previousLocale : previousLocale = GetLocale() 'Español (1034)
  Response.LCID = 1033 'Inglés
  
  'Devolver una fecha en el Locale ID ahora activo (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Impactos del LCID ASP Classic

El LCID es una convención Windows (32 bits), históricamente compuesta por un identificador de idioma y un identificador de región. Por tanto, influye en particular en funciones como CDate, FormatDateTime, FormatNumber, FormatCurrency, InStr, StrComp, LCase, etc. (lista no exhaustiva). En la práctica, el punto crítico en casos de desarrollo rara vez es la visualización, sino las etapas previas, es decir, la lectura, el parsing y los cálculos. La ausencia de normalización de los separadores de miles y decimales en los números es una trampa común que puede provocar errores durante inserciones en sus bases de datos.

La ejecución del mismo código ASP Classic en dos servidores diferentes con configuraciones regionales distintas puede generar resultados divergentes. Por ello, se recomienda, por una parte, fijar el LCID por defecto en las propiedades de IIS, y por otra parte, especificar este LCID en su código fuente ASP antes de cada operación de lectura, cálculo y renderizado de datos textuales, numéricos y de fecha/hora.

Puede definir y modificar el LCID en cualquier momento mediante SetLocale(), Session.LCID y Response.LCID dentro de un mismo script. De hecho, es una técnica utilizada con frecuencia para gestionar datos numéricos o fechas dentro de una página: utilizar un LCID inglés (1033) para efectuar los cálculos, y después utilizar un LCID localizado en otro idioma/región para devolver la información al internauta.

Una estrategia de LCID común respecto a las comparaciones y visualizaciones de cadenas de caracteres es:

•  Para su lógica de negocio
  • Definir Session.LCID al inicio de un script (o de una sesión en el global.asa)
  • Realizar todas las lecturas y cálculos con este LCID
  • Utilizar siempre un modo de comparación binaria (0=vbBinaryCompare)
•  Para gestionar una excepción
  • Utilizar temporalmente SetLocale() para un tratamiento puntual
•  Presentación/visualización/salida
  • Especificar Response.LCID en el momento de mostrar un dato

Al programar, no debe contar con ningún parámetro predefinido: debe fijar usted mismo las reglas del juego y forzar el parámetro LCID desde el inicio de su script. Es la única manera de asegurarse de que su código pueda funcionar en cualquier tipo de servidor, sea cual sea su configuración regional y lingüística (ej. Windows Server en Inglés, Francés, Español, etc.).

Definir sistemáticamente el LCID antes de cada operación a un valor constante le garantizará un código fiable con un funcionamiento previsible en cualquier servidor Windows. La manipulación de fechas y datos numéricos en un sistema ASP Classic exige rigor y constancia. Puede recurrir a nosotros si necesita hacer más fiable su código en estos aspectos:

•  Pasar de un idioma a otro (cambio de LCID durante la ejecución del script)
•  Convertir fechas y números entre diferentes regiones
•  Gestionar fechas en varias zonas horarias diferentes
•  Gestionar números procedentes de diferentes regiones
•  Realizar cálculos complejos entre calendarios
•  Gestionar los años bisiestos
•  Gestionar zonas horarias, horario de invierno/verano
•  Leer o formatear fechas en formato estándar ISO
•  Convertir fechas desde UTC hacia una región (y viceversa)

Impactos del LCID sobre las fechas

Las fechas y horas están muy fuertemente impactadas por el LCID vigente en su script ASP Classic. Algunos idiomas utilizan formatos de fecha muy diferentes, con barras, guiones y espacios para separar los días, años y horas. Si históricamente ha desarrollado en un sistema Windows en Inglés, Francés o Español, y luego mueve su código a otro servidor, generará muchísimos errores si el LCID por defecto en IIS no es exactamente el mismo.

Si su código no define ningún LCID y espera un valor particular que usted siempre ha conocido, proponemos gratuitamente definir en IIS el LCID por defecto de su elección en su alojamiento compartido ASP Classic. Esto le permitirá hacer funcionar su código fuente de la misma manera en que siempre lo ha hecho históricamente.

Funciones impactadas

Las funciones relativas a las fechas que están impactadas por el LCID son las siguientes:

•  Funciones de conversión:
  • CDate: influye en el reconocimiento de los formatos de fecha (orden día/mes/año, separadores, meses escritos con letras según el idioma). Ejemplo: La fecha "03/04/2025" se interpretará como el 3 de Abril en fr-FR (LCID 1036), pero significará el 4 de Marzo con un LCID en-US (1033).
  
  
•  Funciones de comparación:
  • IsDate, IsNumeric: influye en la validación de los datos antes de la conversión. Ejemplo: La fecha "13/04/2025" será aceptada porque se reconoce como el 13 de Abril en fr-FR (LCID 1036), pero se considerará inválida con un LCID en-US (1033), porque el mes n.º 13 no existe.
  
  
•  Funciones de formateo/visualización/salida:
  • FormatDateTime: influye en los formatos de fecha/hora (orden día/mes, separadores, nombres localizados, etc).
  • WeekdayName: influye en el nombre del día y determina el idioma del texto devuelto.
  
  

Consejos & Buenas prácticas

•  Definir siempre el LCID

  Declare explícitamente el LCID de manera idéntica antes de cada operación:

  • Lectura desde su base de datos
  • Recuperación de datos desde un formulario
  • Modificación de una fecha
  • Visualización de una fecha
  
  
•  Calcule con el LCID 1033

  Se recomienda realizar el máximo de operaciones de comparación y modificación de fechas utilizando el LCID 1033, previsible y conocido por todos los desarrolladores, y disponible de serie en todos los sistemas Windows Server.

  
  
•  Reconstruya sus fechas

  Es prudente "parsear" sistemáticamente la fecha para extraer sus diferentes componentes (Día, Mes, Año, Hora, Minuto, Segundo), y luego reconstruirla en una variable mediante las funciones DateSerial() o TimeSerial(). Así obtiene una variable VBScript de tipo date perfectamente fiable. Esto suele ser indispensable si algunas fechas proceden de un formulario web, y más raramente cuando se leen desde su base de datos.

  
  
•  Compare fechas del mismo LCID

  Cuando compare y modifique fechas, utilice siempre dos fechas que hayan sido definidas con el mismo LCID.

  
  
•  Convierta tardíamente a otras zonas horarias

  Realice siempre sus cálculos, comparaciones y modificaciones de fechas con el mismo LCID, y conviértalas a otra zona horaria solo en el momento de su visualización. Puede utilizar el componente LJW ServerSuite para convertir nativamente sus fechas y horas desde ASP Classic en otras zonas horarias, desde y hacia UTC, así como en formato ISO.

Impactos del LCID sobre los números

Los números enteros y decimales están muy fuertemente impactados por el LCID vigente en su script ASP Classic. Algunos idiomas utilizan puntos, comas, espacios, etc. para separar los miles y los decimales. Si históricamente ha desarrollado en un sistema Windows en Inglés, Francés o Español, y luego mueve su código a otro servidor, generará muchísimos errores si el LCID por defecto en IIS no es exactamente el mismo.

Si su código no define ningún LCID y espera un valor particular que usted siempre ha conocido, proponemos gratuitamente definir en IIS el LCID por defecto de su elección en su alojamiento compartido ASP Classic. Esto le permitirá hacer funcionar su código fuente de la misma manera en que siempre lo ha hecho históricamente.

Funciones impactadas

Las funciones relativas a los números que se ven impactadas por el LCID son las siguientes:

•  Fonctions de conversion :
  • CLng, CInt, CSng, CDbl, CCur: influye en la interpretación de los separadores de miles y decimales. Ejemplo: "1,23" significará 1.23 en fr-FR (LCID 1036), pero podrá ser mal interpretado con un LCID en-US (1033). Tenga en cuenta a este respecto que CCur() convierte a Currency, el único tipo decimal exacto, mientras que CDbl() convierte a Double, que por su parte es un número flotante binario que puede potencialmente conducir a aproximaciones inaceptables cuando se trata de datos monetarios o financieros.
  
  
•  Funciones de formateo/visualización/salida:
  • FormatNumber, FormatPercent: influye en la interpretación de los separadores de miles y decimales, las agrupaciones y los porcentajes.
  • FormatCurrency: influye en la interpretación de los símbolos monetarios, la ubicación del símbolo, los separadores, el número de decimales y los números negativos.

Consejos & Buenas prácticas

•  Definir siempre el LCID

  Declare explícitamente el LCID de manera idéntica antes de cada operación:

  • Lectura desde su base de datos
  • Recuperación de datos desde un formulario
  • Modificación de un dato numérico
  • Visualización de un dato numérico
  
  
•  Calcular con el LCID 1033

  Se recomienda realizar el máximo de operaciones de comparación y modificación de números decimales y monetarios utilizando el LCID 1033, previsible y conocido por todos los desarrolladores, y disponible de serie en todos los sistemas Windows Server.

  
  
•  Estandarizar los separadores de miles

  No descuide los separadores de miles: algunos idiomas utilizan la coma o el punto (incluso el espacio) como separador de miles. Se expone a grandes problemas si no estandariza estos separadores antes de convertir su dato en variable numérica con CLng(), CCur(), etc.

  
  
•  Estandarizar los números decimales

  No utilice ninguna variable numérica decimal con total confianza. El separador decimal varía según los idiomas (coma, punto). VBScript realiza todos sus cálculos con variables cuyo separador decimal es el punto.

  Sea cual sea el origen de su variable numérica, asegúrese de que utiliza un punto como separador de decimales antes de convertirla con CLng(), CCur(), etc. Podría verse tentado a reemplazar las comas por puntos de esta manera:

  ASP CLASSIC

  <%
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Lectura desde la base de datos
  myDecimalNumber = Replace(myDecimalNumber, ",", ".") 'Reemplazar las comas por puntos
  myDecimalNumber = Trim(Replace(myDecimalNumber, " ", "")) 'SEliminar los espacios
  myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable decimal (tipo Currency)
  %>

  
  

  Sin embargo, en algunos idiomas y regiones, la coma no sirve como separador decimal, sino como separador de miles. Por tanto, esta técnica no funcionará. Por eso es importante que conozca de antemano el origen de los datos numéricos que utiliza su código.

  Utilice más bien este código, que hace uso de funciones ASP encargadas de recuperar (en amarillo) y utilizar (en azul) los símbolos de separación realmente vigentes con el LCID actual. Esta técnica funciona incluso si no conoce con certeza el formato de origen del dato numérico que se dispone a tratar en su código:

  ASP CLASSIC

  <%
  'Función: Devuelve el carácter separador utilizado para los miles
  Function GetSystemThousandSep()
     GetSystemThousandSep = Mid(FormatNumber(2000), 2, 1)
  End Function 'GetSystemThousandSep
  
  'Función: Devuelve el carácter separador utilizado para los decimales
  Function GetSystemDecimSep()
     GetSystemDecimSep = Mid(CStr(1/2), 2, 1)
  End Function 'GetSystemDecimSep
  
  'Forzar el LCID a Inglés para realizar los cálculos
  Response.LCID = 1033
  
  'Recuperar los separadores
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = 1234.56
  myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Forzar el separador decimal a "punto"
  myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Eliminar los separadores de miles
  myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable decimal (tipo Currency)
  
  Response.LCID = 1033 'Definir el Locale ID de visualización en Inglés
  myDecimalNumber = myDecimalNumber + 0.01 'Agregar 1 céntimo (el LCID no tiene ninguna incidencia en este cálculo)
  Response.Write "EN : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Mostrar la variable => Devuelve 1,234.57
  
  
  Response.LCID = 1036 'Definir el Locale ID de visualización en Francés
  myDecimalNumber = myDecimalNumber + 0.01 'Agregar 1 céntimo (el LCID no tiene ninguna incidencia en este cálculo)
  Response.Write "FR : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Mostrar la variable => Devuelve 1 234,58
  
  
  Response.LCID = 1034 'Definir el Locale ID de visualización en Español
  myDecimalNumber = myDecimalNumber + 0.01 'Agregar 1 céntimo (el LCID no tiene ninguna incidencia en este cálculo)
  Response.Write "ES : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Mostrar la variable => Devuelve 1.234,59
  %>

  
  
•  No confiar en sus cifras

  Su código puede provocar un error en cualquier momento. Por ello, añada protecciones a lo largo de todo su código. Utilice para ello las mismas técnicas que nosotros: programe de manera ultradefensiva. Utilizamos para este fin funciones que hemos desarrollado especialmente, pero el código siguiente le da una idea general del tipo de verificaciones que deben implementarse: (contáctenos si necesita asistencia para reforzar sus defensas)

  ASP CLASSIC

  <%
  'Recuperar los separadores (cf. funciones definidas en otra parte de esta página)
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Lectura desde la base de datos
  if (NOT IsNull(myDecimalNumber)) then
     if (myDecimalNumber <> "") then
        myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Forzar el separador decimal a "punto"
        myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Eliminar los separadores de miles
        Err.Clear
        On Error Resume Next
           myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable decimal (tipo Currency)
           if (Err.Number <> 0) then
              Response.Write "<br>Se produjo un error durante la conversión al tipo Currency"
              Response.Write "<br>" & Err.Number & " - " & Err.Description
           end if
        On Error Goto 0
        Err.Clear
     end if
  end if
  %>

  
  

Impactos del LCID sobre las cadenas de caracteres

El LCID influye en las reglas lingüísticas utilizadas por Windows y por tanto por el motor ASP para comparar y ordenar cadenas (collation y comparaciones Unicode). Esto impacta en particular las comparaciones textuales, ciertas operaciones relativas a la caja de los caracteres y a la manera en que se gestionan los acentos. Es uno de los puntos más frecuentemente olvidados entre los numerosos impactos de la elección del LCID.

El LCID afecta a las ordenaciones y comparaciones textuales, pero en cambio no afecta a las ordenaciones explícitas realizadas por la base de datos, ni a las comparaciones ASCII brutas.

Funciones impactadas

Las funciones relativas a las cadenas de caracteres que se ven impactadas por el LCID son las siguientes:

•  Fonctions de comparaison :
  • Operadores VBScript = y <>: influyen en las comparaciones, que por tanto se efectúan en modo textual (1=vbTextCompare) y son sensibles al LCID. Estos operadores no distinguen mayúsculas de minúsculas, pero siguen siendo sensibles a los acentos en las locales latinas habituales (francés, inglés, etc.). La comparación textual VBScript es insensible a mayúsculas y minúsculas (e = E) y sensible a los acentos (e ≠ é), porque se apoya en la collation Windows asociada al LCID activo. VBScript nunca efectúa normalización Unicode (NFD / NFC) ni "desacentuación": nunca transforma é en e. A diferencia de VBA, Option Compare no está disponible en VBScript, y es una diferencia importante que constituye un riesgo. Por ello, las comparaciones realizadas por estos operadores están sistemáticamente influenciadas por el LCID y son comparaciones textuales. No utilice NUNCA = y <> si se requiere una comparación exacta.
  • StrComp, InStr: influye en la comparación de la caja de los caracteres, pero NO influye en los caracteres acentuados: StrComp siempre es sensible a los acentos y el LCID no cambia esto. StrComp se vuelve sensible al LCID cuando la comparación se realiza en modo textual (1=vbTextCompare) y sobre cadenas que incluyen caracteres acentuados procedentes de ciertos idiomas no occidentales. Tenga en cuenta a este respecto que esta función utiliza una comparación textual simplificada, históricamente limitada en idiomas que utilizan mappings Unicode especiales (ejemplos en Turco con los caracteres İ y i, que serán sistemáticamente considerados diferentes, incluso con 1=vbTextCompare). Esta función también depende de la codificación de su archivo y del Codepage que define en su script (resaltado en azul). El código siguiente demuestra los efectos del LCID en las comparaciones de cadenas:
    
    ASP CLASSIC

    <%@codepage=65001%>
    <%
    'Asegurarse de una codificación coherente en UTF-8
    'Requiere evidentemente que su archivo ASP también haya sido guardado en formato UTF-8 desde el origen.
    Session.CodePage = 65001
    Response.CodePage = 65001
    Response.CharSet = "utf-8"
    
    
    Session.LCID = 1034 'Definir en Español
    
    Dim sourceText : sourceText = "Aquí hay una hermosa frase escrita"
    Dim searchedText : searchedText = "HERMOSA"
    
    'Búsqueda técnica (por ejemplo: identificadores, rutas, correos electrónicos, etiquetas)
    'Utilice 0 = vbBinaryCompare para que el LCID no tenga ninguna influencia
    '=> searchedText NO se encuentra
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbBinaryCompare))
    
    'Búsqueda de usuario (por ejemplo: texto mostrado, entrada del usuario)
    'Utilice un LCID explícito y controlado
    '=> searchedText se encuentra
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbTextCompare))
    
    
    
    'Comparación binaria implícita (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas.
    Response.Write "<br>" & ("E" = "e")
    
    'Comparación explícitamente binaria (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas.
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Comparación explícitamente textual (depende del LCID)
    'Devuelve "True": 1 = vbTextCompare, no distingue entre mayúsculas y minúsculas.
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Comparación explícitamente binaria (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas, y a los acentos.
    Response.Write "<br>" & (StrComp("É", "é", vbBinaryCompare) = 0)
    
    'Comparación explícitamente textual (depende del LCID)
    'Devuelve "True": 1 = vbTextCompare, no distingue entre mayúsculas y minúsculas. Sensible a los acentos.
    '«É» y «é» son el mismo carácter acentuado.
    '   => Este es el comportamiento esperado.
    '   Ocurre si:
    '      - El archivo está guardado, por ejemplo, en UTF-8 o Windows-1252, y se ejecuta como tal
    '      - Existe coherencia entre @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    
    'Comparación explícitamente textual (depende del LCID) (MISMO CÓDIGO QUE LA PRUEBA ANTERIOR => PERO RESULTADO INCORRECTO)
    'Devuelve "False": 1 = vbTextCompare, no distingue entre mayúsculas y minúsculas, pero es sensible a los acentos.
    '«É» y «é» no son el mismo carácter acentuado: los caracteres comparados están mal codificados.
    '   => Este es un comportamiento incoherente y no fiable.
    '   Ocurre si:
    '      - El archivo está guardado, por ejemplo, en UTF-8 pero se ejecuta en Windows-1252 (o viceversa)
    '      - Existen incoherencias entre @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    'Esperado: 201 y 233. En caso contrario, el "False" se explica por las incoherencias de codificación mencionadas anteriormente.
    Response.Write "<br>AscW(É)=" & AscW("É") & " / AscW(é)=" & AscW("é")
    
    Response.Write "<hr>"
    
    
    Session.LCID = 1055 'Turco
    
    'Comparación binaria implícita (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas.
    Response.Write "<br>" & ("E" = "e")
    
    'Comparación explícitamente binaria (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas.
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Comparación explícitamente textual (depende del LCID)
    'Devuelve "True": 1 = vbTextCompare, no distingue entre mayúsculas y minúsculas.
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Comparación explícitamente binaria (independiente del LCID)
    'Devuelve "False": 0 = vbBinaryCompare, sensible a las mayúsculas y minúsculas, y a los acentos.
    Response.Write "<br>" & (StrComp("İ", "i", vbBinaryCompare) = 0)
    
    'Comparación explícitamente textual (depende del LCID)
    'Debería devolver "True" porque: 1 = vbTextCompare no distingue entre mayúsculas y minúsculas, pero es sensible a los acentos.
    '"İ" e "i" son el mismo carácter acentuado.
    'Sin embargo, esta función de VBScript presenta una limitación histórica y realiza una comparación textual simplificada.
    'Por lo tanto, esta función devuelve "False", lo cual es el comportamiento esperado en VBScript.
    'En consecuencia, se recomienda utilizar una función de reemplazo de caracteres acentuados
    'antes de cualquier comparación en idiomas no occidentales.
    Response.Write "<br>" & (StrComp("İ", "i", vbTextCompare) = 0)
    
    Response.Write "<hr>"
    %>
    

    
    
•  Funciones relacionadas con la caja de los caracteres:
  • UCase, LCase: influye en la conversión efectuada. Las reglas lingüísticas utilizadas se delegan/subcontratan a Windows y dependen del LCID. Las reglas lingüísticas utilizadas gestionan bien los idiomas no occidentales como el Turco, a diferencia de StrComp(). Ejemplo: UCase("i") devolverá İ en tr-TR (LCID 1055), pero devolverá I en en-US (LCID 1033).
  
  
•  - Funciones de ordenación y clasificación:
  • Scripting.Dictionary (con CompareMode: 1=vbTextCompare): influye en el orden en que los caracteres se comparan. Ejemplo:
    
    ASP CLASSIC

    <%
    'Según el LCID, las teclas "e", "é" y "è" no se considerarán equivalentes ni se ordenarán de la misma manera.
    Set oDict = Server.CreateObject("Scripting.Dictionary")
    oDict.CompareMode = 1 'vbTextCompare
    %>

    
    

Consejos & Buenas prácticas

•  Definir siempre el LCID

  Declare explícitamente el LCID de manera idéntica antes de cada operación:

  • Recuperación de datos desde un formulario
  • Ordenación de cadenas
  • Comparación de cadenas
  • Búsqueda en una cadena
  
  
•  Comparar con 0=vbBinaryCompare

  Cuando compare o clasifique cadenas de caracteres, utilice siempre un modo 0=vbBinaryCompare para evitar falsos positivos. El riesgo es tanto mayor en ciertos tipos de datos (identificadores, códigos, emails, contraseñas): estos últimos no deben NUNCA compararse en 1=vbTextCompare, sino siempre en modo 0=vbBinaryCompare.

Listas históricas incorrectas de LCID

 Existen numerosas fuentes que proporcionan listas de LCID. Aborde estas fuentes con gran precaución, ya que muchas son antiguas, parciales e incluso erróneas. Nosotros proporcionamos una lista actualizada y totalmente compatible.

ASP Classic no define por sí mismo ninguna lista de LCID disponibles: delega esta tarea en las API NLS (National Language Support)  de Windows. La plataforma ASP Classic hereda por tanto íntegramente la lista de LCID (Locale ID) proporcionada por Windows.

Algunas listas se basan en fuentes fantasiosas o restrictivas (por ejemplo relativas a Microsoft Office o Exchange), o realizan extrapolaciones a partir de la norma BCP-47 para deducir artificialmente supuestos LCID de Windows imaginarios. Estas deducciones son erróneas, porque cada código lingüístico BCP-47 no posee obligatoriamente una correspondencia en la lista de LCID válidos oficialmente soportados e implementados por Microsoft: muchas entradas BCP-47 no están soportadas. Windows distingue estrictamente para cada idioma el par "script + región", mientras que la notación abreviada BCP-47 a menudo solo indica el código de idioma (de 2 o 3 caracteres).

Preste además especial atención al hecho de que algunas listas de LCID incluyen erróneamente todos los LCID soportados nativamente por Windows. Ahora bien, aunque estén definidos en Windows, eso no significa que todos sean utilizables por ASP Classic. Un LCID solo está realmente soportado por ASP Classic si corresponde a una "Locale Windows completa" (idioma + región) instalable mediante la configuración regional de Windows, y además no es únicamente "script-only", reservado, teórico o sin región. Asegúrese de no especificar un LCID que no exista.

Lista completa de LCID utilizables en ASP Classic

 Le proporcionamos la lista más fiable de los distintos LCID posibles en ASP Classic. Esta lista incluye únicamente los LCID que están realmente reconocidos y siguen siendo soportados por ASP Classic en Windows Server 2025, 2022 y 2019.

Algunas de estas entradas son históricas y se consideran "obsoletas" en el sentido de que la combinación "región + idioma" ha cambiado por razones geopolíticas o de nomenclatura normativa; sin embargo siguen siendo técnicamente viables y gestionadas por el motor de ejecución ASP Classic tal como lo eran en Windows Server 2016, 2012, 2008, 2003 y 2000. Se recomienda sustituir los códigos indicados en la columna "Tags Locale - históricas " por la versión vigente indicada en la columna "Tag Locale - IETF BCP 47 " para asegurar la perennidad de su código.

La lista proporcionada a continuación ha sido elaborada por nosotros de manera metódica y verificada, y puesta a prueba con el tiempo a través de los numerosos sitios, intranets, aplicaciones y sistemas ASP Classic en los que hemos trabajado. Todos estos LCID son plenamente funcionales: utilícelos con total confianza con SetLocale() o Session.LCID, por ejemplo.

Alojamiento ASP Classic

Alojamiento ASP Classic y migración a Windows Server 2025 / 2022 / 2019

Mantenimiento y desarrollo ASP Classic

Mantenimiento, soporte y desarrollo de sitios y aplicaciones ASP Classic

Auditoría y configuración de IIS

Auditoría y mejora de la configuración de Microsoft® IIS