Localisation des Dates, nombres et chaines avec LCID

Articles et ressources connexes

• KB-LJW-ASP-202 : Localisation des Dates, nombres et chaines avec LCID

Qu'est-ce que le LCID en ASP ?

Le LCID (Locale Identifier) est un identifiant numérique utilisé par Windows (et donc par ASP Classic en VBScript et JScript) pour définir les règles culturelles et linguistiques applicables à l'exécution de votre code, lorsque celui-ci doit traiter des données en lien avec :

•  Le format des dates et heures,
•  Les séparateurs de décimales et de milliers,
•  Les données financières et monétaires décimales,
•  Les tris et comparaison de chaînes, dates et nombres,
•  L'affichage de chaînes, dates et nombres,
•  La langue à utiliser par défaut pour certaines opérations.

Le LCID n'est ni une langue ni un pays. En effet, une même langue peut être utilisée dans plusieurs pays avec parfois des différences notables ou subtiles. De la même manière, la population d'un même pays peut parler plusieurs langues. Cette réalité justifie donc la définition de plusieurs LCID pour une même langue. Les LCID de Windows sont construits sur la base d'un LANGID (langue) + d'un SUBLANG (variante / script).

Où et comment spécifier le LCID ?

Il existe plusieurs manières de spécifier le LCID que votre site, session ou script ASP utilise :

•  Définir le LCID par défaut dans les propriétés ASP de IIS,
•  Appeller la fonction ASP native SetLocale(),
•  Définir la propriété ASP native Session.LCID dans votre script,
•  Définir la propriété ASP native Response.LCID dans votre script.

Bien que reconnus par Windows, notez que tous les LCID ne sont pas immédiatemment utilisables : certains nécessitent l'installation de packages linguistiques supplémentaires sur le système Windows Server concerné avant de pouvoir être mis en œuvre. Pour connaître la liste des LCID disponibles cliquez ici.

Vous pouvez vérifier que le LCID que vous avez spécifié a bien été appliqué en utilisant la fonction GetLocale() de la manière suivante :

<%
'Appliquer le LCID 1036 '(Français)
SetLocale(1036)

'Si le LCID est conforme
if (GetLocale() = 1036) then
   Response.Write "LCID Valide"
'Si le LCID est différent
else
   Response.Write "LCID utilisé en remplacement : " & GetLocale()
end if
%>

Si le LCID est valide et reconnu, mais non installé sur le système, le moteur d'exécution ASP Classic échoue silencieusement à appliquer le LCID mais ne lève pas d'erreur explicite : il applique alors soit le LCID défini par défaut dans IIS pour votre site (si différent de 0), soit le LCID par défaut en vigueur sur le système Windows Server s'il y a échoué.

Si vous spécifiez un LCID non-supporté (lignes surlignées en jaune), le moteur d'exécution ASP Classic lève généralement une erreur explicite, comme le montre l'extrait de code suivant :

<%
'-------------------------
'Assigner un LCID invalide (via "SetLocale")
SetLocale(98765)

'L'erreur suivante se produit :
'   0x800A01BF
'   Object doesn't support current locale setting: 'SetLocale'


'-------------------------
'Assigner un LCID invalide (via "Session")
Session.LCID = 98765

'L'erreur suivante se produit :
'   0x80004005 (ASP 0219)
'   SessionID
'   The specified LCID is not available.


'-------------------------
'Assigner un LCID invalide (via "Response")
Response.LCID = 98765

'L'erreur suivante se produit :
'   0x80004005 (ASP 0219)
'   Response object
'   The specified LCID is not available.
%>

Portée du LCID

Le LCID n'a pas la même portée selon l'emplacement où vous le spécifiez. Vous pouvez jouer de ces différences à votre avantage afin d'appliquer des exceptions à des règles précédemment définies, afin d'utiliser un LCID dans certaines portions de votre code uniquement, de sorte qu'il ne s'applique qu'à certains éléments ou objets.

Ces différents modes de déclaration du LCID sont détaillés ci-dessous, classés par ordre de portée.

LCID par défaut dans IIS > ASP

•  Portée
  • Globale à l'application IIS
  • Appliquée avant toute exécution de script
  • Sert de valeur initiale pour Session.LCID, Response.LCID et le thread
•  Cas d'usage typiques
  • Application monoculturelle
  • Héritage historique
  • Valeur de secours quand aucun LCID n'est défini dans le code
•  Éléments influencés
  • Dates
  • Nombres
  • Chaînes
•  Limites
  • Statique
  • Non adaptable à l'utilisateur
•  Exemple d'usage
  • IIS > ASP > LCID = 1036 (Français)

Définition via SetLocale()

•  Portée
  • Thread courant
  • Durée de la requête uniquement
  • Non-persistant
•  Cas d'usage typiques
  • Formatage ponctuel et localisé
  • Exception temporaire
  • Bloc de code bien délimité
•  Éléments influencés
  • Dates
  • Nombres
  • Chaînes
•  Limites
  • Fragile
  • Effet de bord invisible
  • À éviter comme mécanisme global
•  Exemple d'usage
  ASP CLASSIC

  <%
  'Configuration globale de la locale ID au niveau de la session
  Session.LCID = 1036 'Français
  
  'Effectuer certaines actions avec le LCID 1036
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Exception locale : Récupérer la locale ID active puis la remplacer
  '   previousLocale reçoit depuis Session.LCID la locale ID active à ce moment précis (1036)
  '   Note : SetLocale() ne modifie pas Session.LCID
  Dim previousLocale : previousLocale = SetLocale(1033) 'Anglais
  
  'Effectuer un traitement dans la locale ID désormais active (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  
  'Restaurer la locale ID précédente du thread (1036)
  SetLocale previousLocale
  %>

Définition dans Session.LCID

•  Portée
  • Session utilisateur
  • Persistant sur toutes les requêtes de la session
•  Cas d'usage typiques
  • Application multilingue
  • Culture utilisateur (langue, pays)
  • Politique de formatage cohérente
•  Éléments influencés
  • Dates
  • Nombres
  • Chaînes
•  Limites
  • Dépendance à un état implicite
  • Peut masquer des erreurs de format
  • Problématique pour les exports techniques
•  Exemple d'usage
  ASP CLASSIC

  <%
  'Configuration globale de la locale ID au niveau de la session
  Session.LCID = 1036 'Français
  
  'Effectuer certaines actions avec le LCID 1036 (Français)
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Remplacer désormais la locale ID au niveau de la session par 1033
  Session.LCID = 1033 'Anglais
  
  'Effectuer les actions suivantes dans la locale ID désormais active (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Définition dans Response.LCID

•  Portée
  • Réponse HTTP courante
  • Appliqué au flux de sortie
•  Cas d'usage typiques
  • Export CSV / texte
  • Génération de documents
  • Format de sortie indépendant de l'utilisateur
•  Éléments influencés
  • Dates
  • Nombres
  • Chaînes
  • Formatage des données écrites via Response.Write
•  Limites
  • Peu intuitif
  • Source de confusion
  • Rarement nécessaire
•  Exemple d'usage
  ASP CLASSIC

  <%
  'Configuration globale de la locale ID au niveau de la session
  Session.LCID = 1036 'Français
  
  'Effectuer certaines actions avec le LCID 1036
  Response.Write FormatDateTime(Now(), vbShortDate)
  
  'Exception locale : Récupérer la locale ID active puis la remplacer
  '   previousLocale reçoit depuis Session.LCID la locale ID active à ce moment précis (1036)
  '   Note : Response.LCID() ne modifie pas Session.LCID
  Dim previousLocale : previousLocale = GetLocale() 'Français (1036)
  Response.LCID = 1033 'Anglais
  
  'Renvoyer une date dans la locale ID désormais active (1033)
  Response.Write FormatDateTime(Now(), vbLongDate)
  %>

Impacts du LCID ASP Classic

Le LCID est une convention Windows (32 bits), historiquement composée d'un identifiant de langue et d'un identifiant de région. Il influence donc notamment des fonctions comme CDate, FormatDateTime, FormatNumber, FormatCurrency, InStr, StrComp, LCase, etc (liste non exhaustive). En pratique, le point critique dans des cas de développement est rarement l'affichage, mais bien les étapes en amont, à savoir la lecture, le parsing, et les calculs. L'absence de normalisation des séparateurs de milliers et de décimales dans les nombres est un piège courant qui peut provoquer des erreurs lors d'insertions dans vos bases de données.

L'exécution du même code ASP Classic sur deux serveurs différents avec des paramètres régionaux différents peut donc générer des résultats divergents. C'est pourquoi il est recommandé d'une part de fixer le LCID par défaut dans les propriétés de IIS, et d'autre part de spécifier ce LCID dans votre code source ASP avant chaque opération de lecture, calcul, et rendu de données textuelles, numériques, et de date/heure.

Vous pouvez à tout moment définir et modifier le LCID via SetLocale(), Session.LCID et Response.LCID au sein d'un même script. C'est d'ailleurs une technique fréquemment utilisée pour gérer des données numériques ou des dates au sein d'une page : utiliser un LCID anglais (1033) pour effectuer les calculs, puis utiliser un LCID localisé dans une autre langue/région pour renvoyer les informations à l'internaute.

Une stratégie de LCID courante concernant les comparaisons et affichages de chaînes de caractères est :

•  Pour votre logique métier
  • Définir Session.LCID au début ou d'un script (ou d'une session dans le global.asa)
  • Effectuer toutes les lectures et calculs avec ce LCID
  • Toujours utiliser un mode de comparaison binaire (0=vbBinaryCompare)
•  Pour gérer une exception
  • Utiliser temporairement SetLocale() pour un traitement ponctuel
•  Présentation/affichage/sortie
  • Spécifier Response.LCID au moment de l'affichage d'une donnée

Lors du codage, vous ne devez compter sur aucun paramètre prédéfini : vous devez vous-même fixer les règles du jeu et forcer le paramètre LCID dès le début de votre script. Il s'agit de la seule manière de vous assurer que votre code puisse fonctionner sur tout type de serveur, quelle que soit sa configuration régionale et linguistique (ex. Windows Server en Anglais, Français, Espagnol, etc).

Définir de manière systématique le LCID avant chaque opération à une valeur constante vous assurera un code fiable au fonctionnement prévisible sur tout serveur Windows. La manipulation de dates et données numériques sur un système ASP Classic demande de la rigueur et de la constance. Vous pouvez faire appel à nous si vous avez besoin de fiabiliser votre code sur ces aspects :

•  Passer d'une langue à une autre (changement de LCID en cours de script)
•  Convertir des dates et nombres entre différentes régions
•  Gérer des dates dans plusieurs fuseaux horaires différents
•  Gérer des nombres provenant de régions différentes
•  Opérer des calculs complexes entre calendriers
•  Gérer les années bissextiles
•  Gérer les fuseaux horaires, heures d'hiver/d'été
•  Lire ou formater des dates au format standard ISO
•  Convertir des dates depuis UTC vers une région (et inversement)

Impacts du LCID sur les dates

Les dates et heures sont très fortement impactées par le LCID en vigueur dans votre script ASP Classic. Certaines langues utilisent des formats de date très différents, avec des slash, tirets, et espaces pour séparer les jours, années et heures. Si vous avez historiquement développé sur un système Windows en Anglais, Français ou Espagnol, puis que vous déplacez votre code sur un autre serveur, il générera de très nombreuses erreurs si le LCID par défaut sur IIS n'est pas exactement le même.

Si votre code ne définit aucun LCID, et s'attend à une valeur particulière que vous avez toujours connu, nous proposons gracieusement de définir dans IIS le LCID par défaut de votre choix sur votre hébergement mutualisé ASP Classic. Ceci vous permettra de faire fonctionner votre code source de la même manière qu'il l'a toujours historiquement fait.

Fonctions impactées

Les fonctions relatives aux dates qui sont impactées par le LCID sont les suivantes :

•  Fonctions de conversion :
  • CDate : influe sur la reconnaissance des formats de date (ordre jour/mois/année, séparateurs, mois en toutes lettres selon la langue). Exemple : La date "03/04/2025" sera interprétée comme le 3 Avril en fr-FR (LCID 1036), mais signifiera le 4 Mars avec un LCID en-US (1033).
  
  
•  Fonctions de comparaison :
  • IsDate, IsNumeric : influe sur la validation des données avant conversion. Exemple : La date "13/04/2025" sera acceptée car reconnue comme le 13 Avril en fr-FR (LCID 1036), mais sera considérée comme invalide avec un LCID en-US (1033), car le mois n°13 n'existe pas.
  
  
•  Fonctions de formatage/affichage/sortie :
  • FormatDateTime : influe sur les formats de date/heure (ordre jour/mois, séparateurs, noms localisés, etc).
  • WeekdayName : influe sur le nom du jour et détermine la langue du texte retourné.
  
  

Conseils & Bonnes pratiques

•  Toujours définir le LCID

  Déclarez explicitement le LCID de manière identique avant chaque opération :

  • Lecture depuis votre base de données
  • Récupération de données depuis un formulaire
  • Modification d'une date
  • Affichage d'une date
  
  
•  Calculez avec le LCID 1033

  Il est recommandé d'effectuer un maximum d'opérations de comparaison et modification de dates en utilisant le LCID 1033, prévisible et connu par tous les développeurs, et disponible en standard sur tous les systèmes Windows Server.

  
  
•  Reconstruisez vos dates

  Il est prudent de systématiqument "parser" la date pour en extraire les différentes composantes (Jour, Mois, Année, Heure, Minute, Seconde), puis de la reconstruire dans une variable à l'aide des fonctions DateSerial() ou TimeSerial(). Vous obtenez ainsi une variable VBScript de type date parfaitement fiable. Cela est souvent indispensable si certaines dates proviennent d'un formulaire web, et plus rarement lorsque lues depuis votre base de données.

  
  
•  Comparez des dates du même LCID

  Lorsque vous comparez et modifiez des dates, utilisez toujours deux dates ayant été définies avec le même LCID.

Impacts du LCID sur les nombres

Les nombres entiers et décimaux sont très fortement impactés par le LCID en vigueur dans votre script ASP Classic. Certaines langues utilisent des points, des virgules, des espaces, etc pour séparer les milliers et les décimales. Si vous avez historiquement développé sur un système Windows en Anglais, Français ou Espagnol, puis que vous déplacez votre code sur un autre serveur, il générera de très nombreuses erreurs si le LCID par défaut sur IIS n'est pas exactement le même.

Si votre code ne définit aucun LCID, et s'attend à une valeur particulière que vous avez toujours connu, nous proposons gracieusement de définir dans IIS le LCID par défaut de votre choix sur votre hébergement mutualisé ASP Classic. Ceci vous permettra de faire fonctionner votre code source de la même manière qu'il l'a toujours historiquement fait.

Fonctions impactées

Les fonctions relatives aux nombres qui sont impactées par le LCID sont les suivantes :

•  Fonctions de conversion :
  • CLng, CInt, CSng, CDbl, CCur : influe sur l'interprétation des séparateurs de milliers et de décimales. Exemple : "1,23" signifiera 1.23 en fr-FR (LCID 1036), mais pourra être mal interprété avec un LCID en-US (1033). Notez à ce titre que CCur() convertit en Currency, seul type décimal exact, là où CDbl() convertir en Double, qui est pour sa part un nombre flottant binaire pouvant potentiellement conduire à des approximations inacceptables lorsqu'il s'agit de données monétaires ou financières.
  
  
•  Fonctions de formatage/affichage/sortie :
  • FormatNumber, FormatPercent : influe sur l'interprétation des séparateurs de milliers et de décimales, les regroupements et les pourcentages.
  • FormatCurrency : influe sur l'interprétation des symboles monétaires, les placement du symbole, les séparateurs, le nombre de décimales, les nombres négatifs.

Conseils & Bonnes pratiques

•  Toujours définir le LCID

  Déclarez explicitement le LCID de manière identique avant chaque opération :

  • Lecture depuis votre base de données
  • Récupération de données depuis un formulaire
  • Modification d'une donnée numérique
  • Affichage d'une donnée numérique
  
  
•  Calculer avec le LCID 1033

  Il est recommandé d'effectuer un maximum d'opérations de comparaison et modification de nombres décimaux et monétaires en utilisant le LCID 1033, prévisible et connu par tous les développeurs, et disponible en standard sur tous les systèmes Windows Server.

  
  
•  Standardiser les séparateurs de milliers

  Ne négligez pas les séparateurs de milliers : certaines langues utilisent la virgule ou le point (voir l'espace) comme séparateur de milliers. Vous courez au-devant de gros problèmes si vous ne standardisez par ces séparateurs avant de convertir votre donnée en variable numérique avec CLng(), CCur(), etc.

  
  
•  Standardiser les nombres décimaux

  N'utilisez aucune variable numérique décimale en toute confiance. Le séparateur décimal varie selon les langues (virgule, point). VBScript effectue tous ses calculs avec des variables dont le séparateur décimal est le point.

  Quelle que soit l'origine de votre variable numérique, assurez-vous qu'elle utilise un point comme séparateur de décimales avant de la convertir avec CLng(), CCur(), etc. Vous pourriez être tenté de remplacer les virgules par des points comme ceci :

  ASP CLASSIC

  <%
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Lecture depuis base de données
  myDecimalNumber = Replace(myDecimalNumber, ",", ".") 'Remplacer les virgules par des points
  myDecimalNumber = Trim(Replace(myDecimalNumber, " ", "")) 'Supprimer les espaces
  myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable décimale (type Currency)
  %>

  
  

  Pourtant, dans certaines langues et régions, la virgule ne sert pas de séparateur décimal, mais de séparateur de milliers. Cette technique ne fonctionnera donc pas. C'est pourquoi il est important que vous connaissiez à l'avance l'origine des données numériques que votre code utilise.

  Utilisez plutôt ce code, qui fait usage de fonctions ASP chargées de récupérer (en jaune) et d'utiliser (en bleu) les symboles de séparation réellement en vigueur avec le LCID courant. Cette technique fonctionne même si vous ne connaissez pas avec certitude le format d'origine de la donnée numérique que vous vous apprêtez à traiter dans votre code :

  ASP CLASSIC

  <%
  'Fonction : Retourne le caractère séparateur utilisé pour les milliers
  Function GetSystemThousandSep()
     GetSystemThousandSep = Mid(FormatNumber(2000), 2, 1)
  End Function 'GetSystemThousandSep
  
  'Fonction : Retourne le caractère séparateur utilisé pour les décimales
  Function GetSystemDecimSep()
     GetSystemDecimSep = Mid(CStr(1/2), 2, 1)
  End Function 'GetSystemDecimSep
  
  'Forcer le LCID en Anglais pour effectuer les calculs
  Response.LCID = 1033
  
  'Récupérer les séparateurs
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = 1234.56
  myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Forcer le séparateur de décimales à "point"
  myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Supprimer les séparateurs de milliers
  myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable décimale (type Currency)
  
  Response.LCID = 1033 'Définir le Locale ID d'affichage en Anglais
  myDecimalNumber = myDecimalNumber + 0.01 'Ajouter 1 centime (le LCID n'a aucune incidence sur ce calcul)
  Response.Write "EN : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Afficher la variable => Renvoie 1,234.57
  
  
  Response.LCID = 1036 'Définir le Locale ID d'affichage en Français
  myDecimalNumber = myDecimalNumber + 0.01 'Ajouter 1 centime (le LCID n'a aucune incidence sur ce calcul)
  Response.Write "FR : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Afficher la variable => Renvoie 1 234,58
  
  
  Response.LCID = 1034 'Définir le Locale ID d'affichage en Espagnol
  myDecimalNumber = myDecimalNumber + 0.01 'Ajouter 1 centime (le LCID n'a aucune incidence sur ce calcul)
  Response.Write "ES : " & FormatNumber(myDecimalNumber, 2) & "<hr>" 'Afficher la variable => Renvoie 1.234,59
  %>

  
  
•  Ne pas faire confiance à vos chiffres

  Votre code peut à tout moment provoquer une erreur. Aussi, ajoutez des sécurités tout au long de votre code. Utilisez pour cela les mêmes techniques que nous : programmez de manière ultra-défensive. Nous utilisons à cet effet des fonctions que nous avons spécialement développées, mais le code ci-dessous vous donne une idée générale du type de vérifications qui doivent être mises en oeuvre : (contactez-nous si vous avez besoin d'assistance pour renforcer vos défenses)

  ASP CLASSIC

  <%
  'Récupérer les séparateurs (cf. fonctions définies ailleurs sur cette page)
  Dim sepDecimal : sepDecimal = GetSystemDecimSep()
  Dim sepThousand : sepThousand = GetSystemThousandSep()
  
  Dim myDecimalNumber
  myDecimalNumber = rs("productPrice") 'Lecture depuis base de données
  if (NOT IsNull(myDecimalNumber)) then
     if (myDecimalNumber <> "") then
        myDecimalNumber = Replace(myDecimalNumber, sepDecimal, ".") 'Forcer le séparateur de décimales à "point"
        myDecimalNumber = Trim(Replace(myDecimalNumber, sepThousand, "")) 'Supprimer les séparateurs de milliers
        Err.Clear
        On Error Resume Next
           myDecimalNumber = CCur(myDecimalNumber) 'Convertir en variable décimale (type Currency)
           if (Err.Number <> 0) then
              Response.Write "<br>Une erreur s'est produite lors de la conversion en type Currency"
              Response.Write "<br>" & Err.Number & " - " & Err.Description
           end if
        On Error Goto 0
     end if
  end if
  %>

  
  

Impacts du LCID sur les chaînes de caractères

Le LCID influence les règles linguistiques utilisées par Windows et donc le moteur ASP pour comparer et trier des chaînes (collation et comparaisons Unicode). Cela impacte en particulier les comparaisons textuelles, certaines opérations relatives à la casse des caractères et à la manières dont gérés les accents. C'est l'un des points les plus souvent oubliés des nombreux impacts du choix du LCID.

Le LCID affecte les tris et comparaisons textuelles, mais n'affecte en revanche pas les les tris explicites faits par la base de données, ou les comparaisons ASCII brutes.

Fonctions impactées

Les fonctions relatives aux chaînes de caractères qui sont impactées par le LCID sont les suivantes :

•  Fonctions de comparaison :
  • Opérateurs VBScript = et <> : influe sur les comparaisons, qui sont donc effectuées en mode textuel (1=vbTextCompare), et sont donc sensibles au LCID. Ces opérateurs sont insensibles à la casse mais restent toutefois sensibles aux accents dans les locales latines usuelles (français, anglais, etc.). La comparaison textuelle VBScript est insensible à la casse (e = E) et sensible aux accents (e ≠ é), car elle s'appuie sur la collation Windows associée au LCID actif. VBScript n'effectue jamais de normalisation Unicode (NFD / NFC) ni de "déaccentuation" : il ne transforme jamais é en e. À la différence de VBA, Option Compare n'est pas disponible en VBScript, et c'est une différence majeure qui constitue un risque. De ce fait, les comparaisons effectuées par ces opérateurs sont systématiquement influencées par le LCID et sont des comparaisons textuelles. N'utilisez JAMAIS = et <> si une comparaison exacte est requise.
  • StrComp, InStr : influe sur la comparaison de la casse des caractères, mais n'influe PAS sur les caractères accentués : StrComp est toujours sensible aux accents et le LCID ne change pas cela. StrComp devient sensible au LCID dès lors que la comparaison est effectuée en mode textuel (1=vbTextCompare) et sur des chaînes incluant des caractères accentués provenant de certaines langues non-occidentales. Notez à ce titre que cette fonction utilise une comparaison textuelle simplifiée, historiquement limitée sur les langues utilisant des mappings Unicode spéciaux (exemples en Turc avec les caractères İ et i, qui seront systématiquement considérés comme différents, même avec 1=vbTextCompare). Cette fonction dépend également de l'encodage de votre fichier et du Codepage que vous définissez dans votre script (surligné en bleu). Le code suivant démontre les effets du LCID sur les comparaisons de chaînes :
    
    ASP CLASSIC

    <%@codepage=65001%>
    <%
    'S'assurer d'un encodage cohérent en UTF-8
    'Nécessite évidemment que votre fichier ASP ait lui aussi été enregistré au format UTF-8 à la source.
    Session.CodePage = 65001
    Response.CodePage = 65001
    Response.CharSet = "utf-8"
    
    
    Session.LCID = 1036 'Définir sur Français
    
    Dim sourceText : sourceText = "Voici une belle phrase écrite"
    Dim searchedText : searchedText = "BELLE"
    
    'Recherche technique (ex. identifiants, chemins, emails, balises)
    'Utilisez 0=vbBinaryCompare pour que le LCID n'ait aucune influence
    '=> searchedText n'est PAS trouvé
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbBinaryCompare))
    
    'Recherche utilisateur (ex. texte affiché, saisie utilisateur)
    'Utilisez un LCID explicite et maîtrisé
    '=> searchedText est trouvé
    Response.Write "<br>" & (InStr(1, sourceText, searchedText, vbTextCompare))
    
    
    
    'Comparaison binaire implicite (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse
    Response.Write "<br>" & ("E" = "e")
    
    'Comparaison explicitement binaire (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Comparaison explicitement textuelle (dépend du LCID)
    'Renvoie "True" : 1=vbTextCompare Insensible à la casse
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Comparaison explicitement binaire (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse et aux accents
    Response.Write "<br>" & (StrComp("É", "é", vbBinaryCompare) = 0)
    
    'Comparaison explicitement textuelle (dépend du LCID)
    'Renvoie "True" : 1=vbTextCompare Insensible à la casse, sensible aux accents.
    '"É" et "é" sont le même caractère accentué.
    '   => Ceci est le comportement attendu.
    '   Se produit si :
    '      - Fichier enregistré par exemple en UTF-8 ou Windows-1252, et exécuté comme tel
    '      - Cohérence du @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    
    'Comparaison explicitement textuelle (dépend du LCID) (MÊME CODE QUE LE TEST CI-DESSUS => MAIS RÉSULTAT INCORRECT)
    'Renvoie "False" : 1=vbTextCompare Insensible à la casse, sensible aux accents.
    '"É" et "é" ne sont pas le même caractère accentué : les caractères comparés sont mal encodés.
    '   => Ceci est un comportement incohérent et non-fiable.
    '   Se produit si :
    '      - Fichier enregistré par exemple en UTF-8 mais exécuté en Windows-1252 (ou inversement)
    '      - Incohérences entre @codepage + Session.CodePage + Response.CodePage + Response.CharSet
    Response.Write "<br>" & (StrComp("É", "é", vbTextCompare) = 0)
    'Attendu : 201 et 233. Dans le cas contraire, le "False" s'explique par les incohérences d'encodage précitées.
    Response.Write "<br>AscW(É)=" & AscW("É") & " / AscW(é)=" & AscW("é")
    
    Response.Write "<hr>"
    
    
    Session.LCID = 1055 'Turc
    
    'Comparaison binaire implicite (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse
    Response.Write "<br>" & ("E" = "e")
    
    'Comparaison explicitement binaire (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse
    Response.Write "<br>" & (StrComp("E", "e", vbBinaryCompare) = 0)
    
    'Comparaison explicitement textuelle (dépend du LCID)
    'Renvoie "True" : 1=vbTextCompare Insensible à la casse
    Response.Write "<br>" & (StrComp("E", "e", vbTextCompare) = 0)
    
    'Comparaison explicitement binaire (indépendant du LCID)
    'Renvoie "False" : 0=vbBinaryCompare Sensible à la casse et aux accents
    Response.Write "<br>" & (StrComp("İ", "i", vbBinaryCompare) = 0)
    
    'Comparaison explicitement textuelle (dépend du LCID)
    'Devrait renvoyer "True" car : 1=vbTextCompare Insensible à la casse, sensible aux accents.
    '"İ" et "i" sont le même caractère accentué.
    'Mais cette fonction VBScript souffre d'une limitation historique et effectue une comparaison textuelle simplifiée.
    'Cette fonction renvoie donc "False", ce qui est attendu en VBScript.
    'Par conséquent il est conseillé d'utiliser une fonction de remplacement des caractères accentués
    'avant toute comparaison dans des langues non-occidentales.
    Response.Write "<br>" & (StrComp("İ", "i", vbTextCompare) = 0)
    
    Response.Write "<hr>"
    %>
    

    
    
•  Fonctions liées à la casse des caractères :
  • UCase, LCase : influe sur la conversion effectuée. Les règles linguistiques utilisées sont déléguées/sous-traitées à Windows et dépendent du LCID. Les règles linguistiques utilisées gèrent bien les langues non occidentales comme le Turc, à la différence de StrComp(). Exemple : UCase("i") renverra İ en tr-TR (LCID 1055), mais renverra I en en-US (LCID 1033).
  
  
•  - Fonctions de tri et classement :
  • Scripting.Dictionary (avec CompareMode : 1=vbTextCompare) : influe sur l'ordre dans lequel les caractères sont comparés. Exemple :
    
    ASP CLASSIC

    <%
    'Selon le LCID, les clés "e", "é", "è" ne seront pas considérées comme équivalentes, ou ordonnées de la même manière.
    Set oDict = Server.CreateObject("Scripting.Dictionary")
    oDict.CompareMode = 1 'vbTextCompare
    %>

    
    

Conseils & Bonnes pratiques

•  Toujours définir le LCID

  Déclarez explicitement le LCID de manière identique avant chaque opération :

  • Récupération de données depuis un formulaire
  • Tri de chaînes
  • Comparaison de chaînes
  • Recherche dans une chaîne
  
  
•  Comparer avec 0=vbBinaryCompare

  Lorsque vous comparez ou classez des chaînes de caractères, utilisez toujours un mode 0=vbBinaryCompare pour éviter les faux-positifs. Le risque est d'autant plus grand sur certains types de données (identifiants, codes, emails, mots de passe) : ces derniers ne doivent JAMAIS être comparés en 1=vbTextCompare, mais toujours en mode 0=vbBinaryCompare.

Listes historiques incorrectes de LCID

 Il existe de nombreuses sources fournissant des listes de LCID. Abordez ces sources avec une grande précaution, du fait que beaucoup d'entre-elles sont datées, parcellaires, voire erronnées. Nous fournissons une liste à jour et totalement compatilble.

ASP Classic ne définit en lui-même aucune liste des LCID disponibles : il délègue cette tâche aux API NLS (National Language Support)  de Windows. La plateforme ASP Classic hérite donc intégralement de la liste de LCID (Locale ID) fournie par Windows.

Certaines listes se basent sur des sources fantaisistes ou restrictives (concernant par exemple Microsoft Office ou Exchange), ou effectuent des extrapolations depuis la norme BCP-47 pour en déduire artificiellement des LCID Windows imaginaires. Ces déductions sont erronnées, car chaque code linguistique BCP-47 ne possède pas obligatoirement une correspondance dans la liste des LCID Windows valides officiellement supportés et implémentés par Microsoft : bon nombre d'entrées BCP-47 ne sont en effet pas supportées. Windows distingue strictement pour chaque langue le couple "script + région", là où la notation BCP-47 abrégée n'indique souvent que le code langue seul (sur 2 ou 3 caractères).

Soyez enfin également particulièrement attentif au fait que certaines listes de LCID intègrent à tort tous les LCID nativement pris en charge par Windows. Or, bien que définis dans Windows, cela ne signifie pas que tous sont utilisables par ASP Classic. Un LCID n'est en réalité supporté par ASP Classic que s'il correspond à une "Locale Windows complète" (language + region) installable via les paramètres régionaux de Windows d'une part, mais aussi s'il n'est pas uniquement "script-only", réservé, théorique ou sans région, d'autre part. Assurez-vous de ne pas spécifier un LCID qui n'existe pas.

Liste complète des LCID utilisables en ASP Classic

 Nous vous fournissons la liste la plus fiable des différents LCID possibles en ASP Classic. Cette liste inclut uniquement les LCID qui sont réellement reconnus et toujours pris en charge par ASP Classic sur Windows Server 2025, 2022 et 2019.

Quelques-unes de ces entrées sont historiques et considérées comme "dépréciées" dans le sens où la combinaison "région + langue" a changé pour des raisons géopolitiques ou de nommage normatif; elles restent toutefois techniquement viables et gérées par le moteur d'exécution ASP Classic comme elles l'étaient sur Windows Server 2016, 2012, 2008, 2003 et 2000. Il est recommandé de substituer les codes indiqués dans la colonne "Tags Locale - historiques" par la version en vigueur indiquée dans la colonne "Tag Locale - IETF BCP 47" afin d'assurer la pérennité de votre code.

La liste fournie ci-dessous a été élaborée par nos soins de manière méthodique et vérifiée, et éprouvée avec le temps au fil des nombreux sites, intranets, applications et systèmes ASP Classic sur lesquels nous avons travaillé. Ces LCID sont tous pleinement fonctionnels : utilisez-les en toute confiance avec SetLocale() ou Session.LCID par exemple.

Hébergement ASP Classic

Hébergement ASP Classic et migration vers Windows Server 2025 / 2022 / 2019

Maintenance & développement ASP Classic

Maintenance, support et développement de sites et applications ASP Classic

Audit & configuration de IIS

Audit et amélioration de la configuration de Microsoft® IIS