Problèmes de globalisation dans ASP et ASP.NET

Jeux de caractères et pages de code

Nous savons tous que les caractères sur notre écran d’ordinateur ne sont qu’une série d’octets. La série d’octets peut être créée et interprétée de plusieurs façons. Si l’interprétation utilise un encodage différent de celui avec lequel le tableau d’octets a été créé, l’interprétation s’affiche sous forme de mémoire. Les jeux de caractères (jeux de caractères) sont des formats d’encodage qui sont généralement utilisés par les navigateurs. La propriété Codepage, qui est plus applicable aux conversions côté serveur, est simplement une table de conversion qui spécifie la façon dont les caractères sont encodés.

Les navigateurs encodent les données de publication de formulaire en fonction du jeu de caractères actuel. Si le jeu de caractères actuel est « windows-1256 », la transmission d’octets au serveur est également encodée en tant que « windows-1256 ».

Lorsque l’ASP est interprété, les collections Form et Querystring ne sont pas générées tant qu’elles ne sont pas référencées dans le code. Lorsqu’elles sont générées, les données de chaîne sont transformées en Unicode en fonction de la page de codes actuelle. (Par défaut, ASP et ASP.NET traiter le contenu au format Unicode). Il est très important que vous définissiez la bonne page de codes avant de référencer les collections ; sinon, la représentation Unicode en mémoire ne sera pas correcte.

Pour définir une page de codes, utilisez Session.Codepage ou Response.Codepage. La page Response.Codepage est disponible uniquement dans Microsoft Internet Information Services (IIS) 5.1 ou versions ultérieures. Pour plus d’informations sur les valeurs entières (qui correspondent au jeu de caractères) sur lesquelles nous définirions ces propriétés, visitez le site Web Microsoft suivant :

Reconnaissance du jeu
de caractèreshttp://msdn2.microsoft.com/en-us/library/Aa752010.aspxPar exemple, pour définir la page de codes de la langue arabe, utilisez le code suivant :

Session.Codepage = 1256

Response.Codepage affecte uniquement la réponse actuelle. Toutefois, Session.Codepage affecte toutes les réponses apportées par l’utilisateur actuel. Lorsque la page de codes est définie à l’aide de l’une de ces propriétés et que les collections Form et Querystring sont générées, cette modification dans la page de codes active entraîne la transformation de l’Unicode en mémoire en page de codes actuelle par la méthode Response.Write. Pour plus d’informations sur cette rubrique, visitez le site web MSDN suivant :

Définition de la page de codes pour les conversions de chaînes (ASP)http://msdn2.microsoft.com/en-us/library/ms525789.aspxLa ligne de fond en ce qui concerne les problèmes liés aux jeux de caractères et aux pages de code est que le jeu de caractères client et la page de code du serveur doivent correspondre.

Accepter les langues

Si un développeur ASP souhaite savoir quelles langues un utilisateur a définies dans son navigateur, il peut utiliser la variable Request.ServerVariables (« HTTP_ACCEPT_LANGUAGE ») pour rechercher la liste des langues dans lesquelles l’utilisateur souhaite lire la réponse (par exemple, l’anglais, l’allemand ou l’indien) et l’ordre de préférence dans lequel l’utilisateur souhaite voir ces langues. Dans ASP.NET, des informations similaires sont présentes dans la propriété Request.UserLanguages sous forme de tableau.
Pour plus d’informations sur l’utilisation de ces informations dans le code ASP, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

229690 Comment définir l’ID de paramètres régionaux ASP selon les paramètres de langue du navigateur
 

Affichage de jeux de caractères sur plusieurs octets dans Internet Explorer

Le seul format d’encodage pouvant afficher un jeu de caractères multioctets est Unicode (UTF-8). Avec UTF-8, nous pouvons afficher le cyrillique, l’indien et le japonais sur la même page. Si nous n’utilisons pas UTF-8, nous ne pouvons afficher qu’une seule de ces langues à la fois. Pour définir le jeu de caractères du navigateur, utilisez la propriété Response.CharSet.

Caractères multioctets statiques sur une page

Pour afficher des caractères multioctets stockés directement dans la page, nous devons d’abord enregistrer la page avec un encodage spécifique. UTF-8 sera préférable, mais une page de code spécifique (correspondant à la page de codes des caractères) fonctionnera également.

L’enregistrement d’un fichier ASP à l’aide de Microsoft Visual InterDev n’est pas utile ici, car Visual InterDev peut uniquement enregistrer en anglais ANSI ou Unicode. Toute page ASP enregistrée au format Unicode n’est pas prise en charge par ASP.

Dans Microsoft Visual Studio .NET, vous pouvez enregistrer un fichier dans n’importe quel encodage. Il existe deux façons de procéder. La méthode par défaut consiste à enregistrer le fichier à l’aide de la page de codes actuelle pour l’utilisateur. Une autre façon d’enregistrer un fichier avec un encodage est la suivante :
Dans le menu Fichier , cliquez sur Enregistrer le fichier sous. Dans la boîte de dialogue Enregistrer le
fichier sous, cliquez sur la flèche déroulante du
boutonEnregistrer. Lorsque vous cliquez sur la flèche, les options sont
Enregistrer et Enregistrer avec encodage. Lorsque vous cliquez sur
Enregistrer avec encodage, la boîte de dialogue Options d’enregistrement avancées s’affiche dans laquelle vous pouvez sélectionner le type d’encodage que vous souhaitez appliquer dans une liste des pages de code installées sur l’ordinateur.


Remarque Cela modifie l’encodage de l’opération d’enregistrement, mais pour une seule fois. La valeur par défaut de l’enregistrement suivant est rétablie.

Pour modifier la page de codes par défaut, cliquez sur Options d’enregistrement avancées dans le
menuFichier. Dans la boîte de dialogue Options d’enregistrement avancées , vous pouvez définir l’encodage par défaut pour les opérations d’enregistrement sur la page de code de votre choix.

Ces méthodes sont liées à la façon dont le fichier est enregistré sur le disque. Toutefois, pour contrôler la sortie d’ASP, comme indiqué précédemment, nous devons définir les propriétés Session.CodePage et Response.CharSet. Avec IIS 5.1 et les versions ultérieures, nous pouvons également utiliser la propriété Response.CodePage.

CODEPAGE par défaut sur le serveur

Les paramètres régionaux par défaut et la page de codes par défaut de la page dépendent des paramètres du Registre pour . Utilisateur PAR DÉFAUT. Vous trouverez la clé internationale dans la ruche de registre HKEY_USERS\.DEFAULT\Control Panel\International. Nous pouvons également modifier le comportement des paramètres régionaux choisis par IIS.

Si l’utilisateur connecté a les mêmes paramètres régionaux définis que la clé ci-dessus ou que la valeur système par défaut, le paramètre utilisateur est prioritaire.

Exemple : les paramètres régionaux par défaut ont le format de date défini sur 11.1.2004, tandis que l’utilisateur connecté (avec les mêmes paramètres régionaux) a le format de date 11/1/2004. Le paramètre 11/1/2004 prend effet pour ASP.

(Par ASP.NET, cela peut varier. Dans certaines installations, l’utilisateur ASPNET a son propre profil qui s’affiche sous HKEY_USERS lors du chargement. Dans d’autres, il utilise . Profil DEFAULT. Nous pouvons également utiliser l’attribut codepage dans la déclaration <%@ %>. Il doit être utilisé lorsque le fichier est enregistré avec un encodage différent de celui par défaut, tel que la page de code 932 (japonais)).

Problèmes de page de code par rapport aux problèmes de conversion de police : lequel est-ce ?

Parfois, vous pouvez voir un point d’interrogation (?) ou une zone où un caractère est censé apparaître.

Modifications de l’encodage du runtime

Dans l’événement Application_BeginRequest, nous pouvons modifier la valeur de requestEncoding et l’appliquer avant le traitement de la requête. Pour la réponse, l’événement Page_PreRender est la dernière chance de modifier l’encodage de la sortie. Notez également que Response.Write placera des caractères dans cette mémoire tampon dès que nous l’appelons. Veillez donc à disposer de l’encodage approprié avant d’utiliser Response.Write.

Les données d’origine ne sont pas Unicode : Comment faire en sorte que les Explorer Internet interprètent des jeux de caractères multioctets ?

Nous pouvons également faire en sorte que ASP.NET se comportent comme ASP si nécessaire. Pour ce faire, nous devons définir responseEncoding et requestEncoding sur windows-1252 (un encodage plus complet que iso-8859-1) et utiliser la propriété Response.Charset pour afficher correctement le texte. Cela fonctionne, car windows-1252 est un schéma d’encodage d’octet unique et ne modifie pas les octets ajoutés à la mémoire tampon. Ainsi, les caractères codés sur deux octets sont envoyés sous la forme d’une série d’octets uniques. Nous pouvons ensuite indiquer à Internet Explorer comment interpréter les octets à l’aide de la propriété Response.Charset. Ce scénario peut être nécessaire si les données d’origine ne sont pas stockées au format Unicode ou UTF-8, comme une valeur de retour à partir d’un objet COM, ou si les données sont stockées dans Microsoft SQL Server dans un champ non N (tel que varchar).

SQL Server et ASP.NET problèmes de mondialisation

INSERT INTO MusicAlbum (Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'Abida', 4653, 403)
Or:
Dim t As String = "INSERT INTO MusicAlbum(Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'" & TextBox1.Text & "', 4653, 403)"

Espace de noms System.Globalization

Cet espace de noms est au cœur de la globalisation et de la localisation dans le .NET Framework. La classe main utilisée dans cet espace de noms est la classe CultureInfo. Il contient des informations spécifiques à la culture, telles que le format de date/heure, les formats numériques, les informations de comparaison et les informations de texte. Pour plus d’informations sur la classe CultureInfo, visitez le site web MSDN suivant :

http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspxCultureInfo

Cultures neutres et cultures spécifiques

Une culture neutre est une culture associée à une langue, mais pas à un pays/une région spécifique. Une culture spécifique est associée à la fois à une langue et à un pays/région spécifique.

Exemple : « DE » (culture neutre) est pour la langue allemande, mais « de-AT » (culture spécifique) est pour la langue allemande telle qu’elle est parlée en Autriche. Les cultures neutres ne peuvent pas être utilisées pour la mise en forme.

Connaissance actuelle du thread et de la culture des classes .NET Framework

Toutes les classes et méthodes de la bibliothèque .NET Framework dans laquelle nous nous attendons à ce que la sortie dépende de la culture ont deux comportements intégrés :

• Ils nous permettent de spécifier le code de culture tout en fournissant les arguments afin que la sortie soit basée sur la culture spécifiée. Cette option est facultative.

• Si cela est manqué (généralement), les classes sont suffisamment intelligentes pour conserver une case activée sur la propriété Thread.CurrentThread.CurrentCulture et fonctionnent en fonction de cela.

Nous pouvons modifier la valeur de cette propriété avec du code semblable à ce qui suit :

    Dim ci As CultureInfo
        ci = New CultureInfo("de-AT")
        Thread.CurrentThread.CurrentCulture = ci

Dans cet exemple de code, « de » représente la langue allemande et « AT » représente l’Autriche. Par conséquent, dans cette instance, dateTime.Now(). La méthode ToString renvoie la date et l’heure dans un format correspondant à la façon dont la date et l’heure sont exprimées en langue allemande en Autriche.

L’infrastructure garantit (comme suit) que la propriété CurrentCulture est toujours initialisée :

1. Quel que soit le paramètre défini sur programmatiquement.

2. Dans le cas où elle n’est pas définie explicitement par le programmeur, la propriété est choisie dans les fichiers de configuration (<globalisation> balise).

3. Si la propriété est manquante, il s’agit de la culture sur laquelle le serveur Web s’exécute. Il s’agit généralement de la culture neutre qui correspond à la langue du système d’exploitation.

Fichiers de ressources

Tous les fichiers .resx, .resource et les fichiers dont l’attribut Action de génération est défini sur Ressource incorporée, ajoutés à un projet ASP.NET dans Visual Studio .NET, sont automatiquement compilés et incorporés dans l’assembly d’application dans le cadre de son manifeste. Cette opération peut même être effectuée manuellement à l’aide de l’utilitaire RESOURCE File Generator (RESGEN) via une invite de commandes Visual Studio .NET. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :

http://msdn2.microsoft.com/en-us/library/ccec7sz1(vs.71).aspxIl s’agit d’un concept général qui s’applique chaque fois que nous avons besoin de gérer des ressources d’application qui ne sont pas liées à la mondialisation. Toutefois, lorsque nous implémentons la globalisation, nous devons utiliser des assemblys satellites.

Assemblys satellites

Les assemblys satellites peuvent être utilisés dans un projet ASP.NET lorsque vous vérifiez que les conditions suivantes sont remplies :

1. Tous les éléments d’interface utilisateur dans tous les fichiers aspx doivent être équipés d’attributs id et runat=server.

2. Nous créons des fichiers .resx distincts. Chacun d’eux doit correspondre à chaque culture que notre application doit prendre en charge.

3. Nous devons décider d’un prénom commun pour tous ces fichiers par exemple. 'Strings'.

4. Nous nomlons les fichiers .resx distincts avec la convention de nommage suivante commonfirstname. languagecode-regioncode.resx (par exemple : Strings.de-AT.resx, Strings.en-GB.resx ).

5. Nous devons avoir le fichier
   de ressourcescommonfirstname.resx (Strings.resx) qui contient toutes les chaînes que nous voulons afficher dans le cas par défaut.

6. Écrivez du code pour détecter la culture de l’utilisateur et définissez la propriété Thread.CurrentThread.CurrentUICulture pour qu’elle y corresponde.

7. Écrivez du code pour charger les ressources à l’aide de la classe ResourceManager.

8. Écrivez du code pour extraire des chaînes de l’objet chargé et les affecter aux éléments de l’interface utilisateur.

Une fois ces étapes effectuées, Visual Studio.NET compile Strings.resx et l’incorpore dans l’assembly d’application (MyGlobalizationTestProjectName.dll). Toutefois, pour tous les autres fichiers .resx, il génère des fichiers DLL distincts qui n’ont pas de code exécutable, mais uniquement des données de ressources. Il s’agit en fait d’assemblys satellites. En outre, Visual Studio .NET les place dans une structure de dossiers similaire à la suivante :MyGlobalizationTestProjectName
|------- bac
|------en-US

MyGlobalizationTestProjectName.resources.dll |------ja-JP

MyGlobalizationTestProjectName.resources.dll |------de-AT
MyGlobalizationTestProjectName.resources.dll

Différence entre CurrentCulture et CurrentUICulture

Alors que les méthodes des classes dans l’espace de noms System.Globalization dépendent de la propriété Thread.CurrentThread.CurrentCulture pour fournir leur sortie, la classe ResourceManager qui charge l’assembly de ressources dépend de la propriété Thread.CurrentThread.CurrentUICulture pour charger l’assembly satellite approprié. Voici un exemple de code C# :

using System.Globalization;
using System.Threading;
using System.Resources;

//Load resources. 
protected ResourceManager gStrings = new ResourceManager("MyGlobalizationTestProjectName.strings", typeof(MyTestWebFormName).Assembly);

// Get the user's preferred language.
string sLang = Request.UserLanguages[0];
// Set the thread's culture for formatting, comparisons, etc.   
Thread.CurrentThread.CurrentCulture =  CultureInfo.CreateSpecificCulture(sLang);
// Set the thread's UICulture to load resources
// from satellite assembly.
Thread.CurrentThread.CurrentUICulture = new CultureInfo(sLang);

private void Page_Load(object sender, System.EventArgs e) 

{ 

 if (!IsPostBack)  

 {      
// Get strings from resource file and assign to UI elements.
head1.InnerHtml = gStrings.GetString("satellite.head1");
p1.InnerHtml = gStrings.GetString("satellite.p1");
sp1.InnerHtml = gStrings.GetString("satellite.sp1");
sp2.InnerHtml = gStrings.GetString("satellite.sp2");
butOK.Text = gStrings.GetString("satellite.butOK");
butCancel.Value = gStrings.GetString("satellite.butCancel");
   }

 }

Ordre dans lequel ASP.NET sélectionne les assemblys satellites :

Une fois que vous avez défini currentUICulture du thread, ASP.NET sélectionne automatiquement les ressources qui correspondent, dans l’ordre suivant :

• Si un assembly satellite est trouvé avec une culture correspondante, les ressources de cet assembly sont utilisées.

• Si un assembly satellite est trouvé avec une culture neutre qui correspond à CurrentUICulture, les ressources de cet assembly sont utilisées.

• Si aucune correspondance n’est trouvée pour CurrentUICulture, les ressources de secours stockées dans l’assembly exécutable sont utilisées.

Remarque Ceci est basé sur le processus de secours de ressources plus général. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :

http://msdn2.microsoft.com/en-us/library/sb6a8618(vs.71).aspx

Création manuelle d’assemblys satellites :

Cette utilisation des assemblys satellites est l’endroit où Visual Studio .NET crée les assemblys lui-même. Toutefois, Visual Studio .NET n’utilise pas d’assemblys satellites de nom fort par défaut. Si vous souhaitez modifier ces options, vous devez créer manuellement des assemblys satellites. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :

http://msdn2.microsoft.com/en-us/library/21a15yht(vs.71).aspx .

Glossaire

ANSI est l’acronyme de l’American National Standards Institute. Dans ce contexte, il représente une page de codes spécifique pour un jeu de caractères/langage spécifique. Fait le plus souvent référence à la page de codes anglaise (windows-1252).

ASCII Schéma d’encodage 1 octet (ou 7 bits). Seuls les caractères de la plage 0-127 sont normalisés. La plage 128-255 est une extension de l’ASCII et ne fait pas partie de la norme. La différence entre la plage supérieure du graphique ASCII OEM et le graphique ASCII VB en est un exemple.

Paramètre CharSet utilisé principalement pour les Explorer Internet et les navigateurs qui indiquent au navigateur comment interpréter les données des caractères. Exemple : Response.charSet = « iso-8859-1. »

Page de code Table de conversion qui spécifie la façon dont les caractères sont encodés (généralement utilisés pour les serveurs).

Globalisation La mondialisation est un processus de conception et de création d’une application afin que les exigences uniques d’une culture, d’une région, ou des besoins nationaux/régionaux et linguistiques puissent être satisfaits. En d’autres termes, la conception d’une application de manière à ce qu’elle puisse être localisée ultérieurement est la globalisation.

Paramètres régionaux/Culture Formats/préférences spécifiques à la langue et à la région, notamment les formats de date et de calendrier, les formats d’heure, les formats monétaires, la casse, le tri et la comparaison de chaînes, les formats d’adresse, les formats de numéros de téléphone, les formats de papier, l’unité de mesure, le sens de l’écriture, etc.

LocaleID (LCID) Valeur DWORD qui spécifie l’identificateur de langue et l’ID de tri. Il peut être utilisé pour spécifier les formats de région spécifiques pour ex date/heure, etc. doivent être mis en forme en fonction de .

Localisabilité Capacité d’une application à présenter du contenu pour la langue/les paramètres régionaux demandés.

Localisation La localisation est le processus de traduction d’une interface utilisateur en langues et/ou paramètres régionaux spécifiques.

Jeu de caractères multioctet Jeu de caractères dans lequel les caractères sont composés de deux octets ou plus, comme le japonais. UTF-8 relève également de cette catégorie. (Techniquement, Unicode fait partie de cette catégorie, mais dans Windows, il a sa propre catégorie.)

Schéma d’encodage Unicode A 2 octets. Windows utilise Unicode en interne. Toutes les API spécifiquement pour Unicode sont indiquées par un « W » à la fin du nom de la fonction. Également connu sous le nom de char large; ne peut pas être utilisé directement à partir d’applications web.

UTF-8 Encodage de caractères dans lequel un caractère peut être représenté par 1 à 6 octets. Dans Windows, la plage est comprise entre 1 et 3 octets. Non pris en charge sous NT4 pour les applications web.



Jeu de caractères large Alias pour Unicode. Également appelé DBCS (jeu de caractères sur deux octets), UCS-2, UTF-16.

Comme toujours, n’hésitez pas à soumettre des idées sur des sujets que vous souhaitez aborder dans de futures colonnes ou dans la base de connaissances à l’aide du formulaire Demander.