Locale Classe

Définition

[Android.Runtime.Register("java/util/Locale", DoNotGenerateAcw=true)]
public sealed class Locale : Java.Lang.Object, IDisposable, Java.IO.ISerializable, Java.Lang.ICloneable

[<Android.Runtime.Register("java/util/Locale", DoNotGenerateAcw=true)>]
type Locale = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ICloneable

Héritage

Object

JavaObject

Object

Locale

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable ISerializable ICloneable IDisposable

Remarques

Un Locale objet représente une région géographique, politique ou culturelle spécifique. Une opération qui nécessite une Locale exécution de sa tâche est appelée <em>locale-sensitive</em> et utilise les informations pour personnaliser les Locale informations pour l’utilisateur. Par exemple, l’affichage d’un nombre est une opération sensible aux paramètres régionaux&mdash ; le nombre doit être mis en forme conformément aux coutumes et conventions du pays, de la région ou de la culture de l’utilisateur.

La Locale classe implémente IETF BCP 47, composée de RFC 4647 « Correspondance des balises de langage » et de RFC 5646 « Balises pour l’identification des langages » avec prise en charge des extensions LDML (UTS#35, « Unicode Locale Data Markup Language ») BCP 47 compatibles pour l’échange de données de paramètres régionaux.

Un Locale objet se compose logiquement des champs décrits ci-dessous.

<dl><dt>"def_language"><b>language</b></dt>

<dd>ISO 639 alpha-2 ou alpha-3 code de langue, ou les sous-balises linguistiques inscrites jusqu’à 8 lettres alpha (pour des améliorations futures). Lorsqu’une langue a à la fois un code alpha-2 et un code alpha-3, le code alpha-2 doit être utilisé. Vous trouverez la liste complète des codes de langue valides dans le Registre de sous-balises de langue IANA (recherchez « Type : langue »). Le champ de langue ne respecte pas la casse, mais Locale il est toujours canonique en minuscules.</dd>

< >Les valeurs de langage bien formées ont la forme [a-zA-Z]{2,8}. Notez que ce n’est pas la production complète du langage BCP47, car elle exclut l’extlang. Ils ne sont pas nécessaires, car les codes de langue en trois lettres modernes les remplacent.</dd>

< >exemple : « en » (anglais), « ja » (japonais), « kok » (Konkani)</dd>

<dt>"def_script"><b>script</b></dt>

<dd>code de script ISO 15924 alpha-4. Vous trouverez une liste complète des codes de script valides dans le Registre de sous-tags du langage IANA (recherchez « Type : script »). Le champ de script ne respecte pas la casse, mais Locale il est toujours canonique à la casse de titre (la première lettre est majuscule et le reste des lettres est en minuscules).</dd>

< >Les valeurs de script bien formées ont la forme [a-zA-Z]{4}</dd>

< >exemple : « Latn » (Latin), « Cyrl » (Cyrillique)</dd>

<dt>"def_region"><b>pays (région)</b></dt>

<dd>code de pays ISO 3166 alpha-2 ou code de zone UN M.49 numeric-3. Vous trouverez la liste complète des codes de pays et de région valides dans le Registre de sous-balises de langue IANA (recherchez « Type : région »). Le champ pays (région) ne respecte pas la casse, mais Locale il est toujours canonique en majuscules.</dd>

< >Les valeurs pays/régions bien formés ont la forme [a-zA-Z]{2} | [0-9]{3}</dd>

<dd>Example : « US » (États-Unis), « FR » (France), « 029 » (Caraïbes)</dd>

<dt>"def_variant"><b>variant</b></dt>

<dd>Toute valeur arbitraire utilisée pour indiquer une variante d’un Locale. Lorsqu’il existe deux valeurs variant ou plus indiquant chacune sa propre sémantique, ces valeurs doivent être classées par importance, avec la plus importante première, séparées par un trait de soulignement('_'). Le champ variant respecte la casse.</dd>

<dd>Remarque : IETF BCP 47 place les restrictions syntactiques sur les sous-balises variant. En outre, les sous-balises BCP 47 sont strictement utilisées pour indiquer des variantes supplémentaires qui définissent une langue ou ses dialectes qui ne sont pas couverts par des combinaisons de sous-balises de langue, de script et de région. Vous trouverez la liste complète des codes de variante valides dans le Registre de sous-balises de langue IANA (recherchez « Type : variant »).

Toutefois, le champ de variante dans Locale lequel il a été utilisé a historiquement été utilisé pour n’importe quel type de variante, pas seulement pour les variantes linguistiques. Par exemple, certaines variantes prises en charge disponibles dans Java environnements SE Runtime indiquent d’autres comportements culturels tels que le type de calendrier ou le script de nombre. Dans BCP 47, ce type d’informations, qui n’identifie pas la langue, est pris en charge par les sous-balises d’extension ou les sous-balises d’utilisation privée.</dd>

< >les valeurs de variantes bien formées ont le formulaire SUBTAG (('_'|'-') SUBTAG)* où SUBTAG = [0-9][0-9a-zA-Z]{3} | [0-9a-zA-Z]{5,8}. (Remarque : BCP 47 utilise uniquement le trait d’union ('-') comme délimiteur, il s’agit d’un trait d’union plus lent).</dd>

< >exemple : « polyton » (grec polytonique), « POSIX"</dd>

<dt>"def_extensions"><b>extensions</b></dt>

<dd>Carte d’une clé de caractère unique à des valeurs de chaîne, indiquant des extensions en dehors de l’identification du langage. Les extensions dans Locale l’implémentation de la sémantique et de la syntaxe des sous-balises d’extension BCP 47 et des sous-balises d’utilisation privée. Les extensions ne respectent pas la casse, mais Locale canoniquent toutes les clés et valeurs d’extension en minuscules. Notez que les extensions ne peuvent pas avoir de valeurs vides.</dd>

< >les clés bien formées sont des caractères uniques de l’ensemble [0-9a-zA-Z]. Les valeurs bien formées ont le formulaire SUBTAG ('-' SUBTAG)* où la clé « x » SUBTAG = [0-9a-zA-Z]{1,8} et d’autres clés SUBTAG = [0-9a-zA-Z]{2,8} (autrement dit, « x » autorise les sous-balises à caractère unique).</dd>

<exemple dd>: key="u"/value="ca-japanese » (calendrier japonais), key="x"/value="java-1-7"</dd></dl>

<b>Remarque :</b> Bien que BCP 47 exige que les valeurs de champ soient inscrites dans le Registre de sous-tags du langage IANA, la Locale classe ne fournit aucune fonctionnalité de validation. La Builder seule vérification si un champ individuel satisfait à l’exigence syntaxique (est bien formée), mais ne valide pas la valeur elle-même. Pour plus d’informations, consultez Builder.

<h2>"def_locale_extension">Paramètres régionaux/extension< de langage Unicode/h2>

UTS#35, « Unicode Locale Data Markup Language » définit des attributs et des mots clés facultatifs pour remplacer ou affiner le comportement par défaut associé à des paramètres régionaux. Un mot clé est représenté par une paire de clés et de type. Par exemple, « nu-thai » indique que les chiffres locaux thaïlandais (value :"thai ») doivent être utilisés pour la mise en forme des nombres (key :"nu »).

Les mots clés sont mappés à une valeur d’extension BCP 47 à l’aide de la clé d’extension 'u' (#UNICODE_LOCALE_EXTENSION). L’exemple ci-dessus, « nu-thai », devient l’extension « u-nu-thai ».

Par conséquent, lorsqu’un Locale objet contient des attributs de paramètres régionaux Unicode et des mots clés, getExtension(UNICODE_LOCALE_EXTENSION) retourne une chaîne représentant ces informations, par exemple « nu-thai ». La Locale classe fournit #getUnicodeLocaleAttributeségalement , #getUnicodeLocaleKeyset #getUnicodeLocaleType qui vous permet d’accéder directement aux attributs régionaux Unicode et aux paires clé/type. Lorsqu’elle est représentée sous forme de chaîne, l’extension de paramètres régionaux Unicode répertorie les attributs par ordre alphabétique, suivis par des séquences de clé/type avec des clés répertoriées par ordre alphabétique (l’ordre des sous-balises comprenant le type d’une clé est fixe lorsque le type est défini)

Une clé de paramètres régionaux bien formée a la forme [0-9a-zA-Z]{2}. Un type de paramètres régionaux bien formé a la forme "" | [0-9a-zA-Z]{3,8} ('-' [0-9a-zA-Z]{3,8})* (il peut être vide ou une série de sous-balises de 3 à 8 alphanums de longueur). Un attribut de paramètres régionaux bien formé a le formulaire [0-9a-zA-Z]{3,8} (il s’agit d’un sous-tag unique avec le même formulaire qu’un sous-tag de type de paramètres régionaux).

L’extension de paramètres régionaux Unicode spécifie le comportement facultatif dans les services sensibles aux paramètres régionaux. Bien que la spécification LDML définit différentes clés et valeurs, les implémentations de service sensibles aux paramètres régionaux réels dans un environnement d’exécution Java peuvent ne pas prendre en charge des attributs régionaux Unicode ou des paires clé/type particulières.

<h3>"ObtainingLocale">Obtention d’un paramètre régional</h3>

Il existe plusieurs façons d’obtenir un Locale objet.

<h4>Builder</h4>

Vous Builder pouvez construire un Locale objet conforme à la syntaxe BCP 47.

<Méthodes d’usine> h4</h4>

La méthode #forLanguageTag obtient un Locale objet pour une balise de langue BCP 47 bien formée. La méthode #of(String, String, String) et ses surcharges obtiennent un objet à partir d’un Locale objet donné language, countryet/ou variant défini ci-dessus.

<Constantes> de paramètres régionaux h4</h4>

La Locale classe fournit un certain nombre de constantes pratiques que vous pouvez utiliser pour obtenir des Locale objets pour les paramètres régionaux couramment utilisés. Par exemple, Locale.US est l’objet Locale de la États-Unis.

<h3>"LocaleMatching">Paramètres régionaux correspondant</h3>

Si une application ou un système est internationalisé et fournit des ressources localisées pour plusieurs paramètres régionaux, il doit parfois trouver un ou plusieurs paramètres régionaux (ou balises de langue) qui répondent aux préférences spécifiques de chaque utilisateur. Notez qu’un terme « balise de langue » est utilisé de manière interchangeable avec « paramètres régionaux » dans cette documentation correspondante sur les paramètres régionaux.

Pour faire correspondre les paramètres régionaux préférés d’un utilisateur à un ensemble d’étiquettes de langue, la correspondance RFC 4647 des balises de langue définit deux mécanismes : le filtrage et la recherche. <em>Filtering</em> est utilisé pour obtenir tous les paramètres régionaux correspondants, tandis que <em>lookup</em> consiste à choisir les paramètres régionaux correspondants les mieux adaptés. La correspondance est effectuée sans respect de la casse. Ces mécanismes de correspondance sont décrits dans les sections suivantes.

La préférence d’un utilisateur est appelée liste <><de priorité de langue em> et est exprimée sous la forme d’une liste de plages de langues. Il existe deux types de plages de langage de manière syntactique : de base et étendue. Pour plus d’informations, consultez Locale.LanguageRange Locale.LanguageRange.

<Filtrage> h4</h4>

L’opération de filtrage retourne toutes les balises de langue correspondantes. Il est défini dans RFC 4647 comme suit : « Dans le filtrage, chaque plage de langues représente la balise de langue la moins spécifique (autrement dit, la balise de langue avec le plus petit nombre de sous-balises) qui est une correspondance acceptable. Toutes les balises de langue dans l’ensemble de balises correspondant ont un nombre égal ou supérieur de sous-balises que la plage de langues. Chaque sous-balise non générique de la plage de langues s’affiche dans chacune des balises de langue correspondantes. »

Il existe deux types de filtrage : le filtrage pour les plages de langage de base (appelé « filtrage de base ») et le filtrage pour les plages de langues étendues (appelées « filtrage étendu »). Ils peuvent retourner des résultats différents selon le type de plages de langues inclus dans la liste de priorité de langue donnée. Locale.FilteringMode est un paramètre pour spécifier la façon dont le filtrage doit être effectué.

<Recherche> h4</h4>

L’opération de recherche retourne les balises de langue les plus correspondantes. Il est défini dans RFC 4647 comme suit : « Contrairement au filtrage, chaque plage de langues représente la balise la plus spécifique qui est une correspondance acceptable. La première balise correspondante trouvée, en fonction de la priorité de l’utilisateur, est considérée comme la correspondance la plus proche et l’élément retourné.

Par exemple, si une liste de priorités linguistiques se compose de deux plages de langues et "zh-Hant-TW""en-US", dans l’ordre hiérarchisé, la méthode de recherche recherche recherche progressivement les balises de langue ci-dessous afin de trouver la balise de langue la plus adaptée. <blockquote>

1. zh-Hant-TW
               2. zh-Hant
               3. zh
               4. en-US
               5. en

</blockquote> S’il existe une balise de langue qui correspond complètement à une plage de langues ci-dessus, la balise de langue est retournée.

"*" est la plage de langues spéciale, et elle est ignorée dans la recherche.

Si plusieurs balises de langue correspondent à la suite de la sous-balise '*' incluse dans une plage de langues, la première balise de langue correspondante retournée par Iterator une Collection étiquette de langue supérieure est traitée comme la meilleure correspondance.

< >Utilisation de paramètres régionaux</h3>

Une fois que vous avez obtenu une requête Locale , vous pouvez l’interroger pour obtenir des informations sur elle-même. Permet getCountry d’obtenir le code pays (ou région) et getLanguage d’obtenir le code de langue. Vous pouvez utiliser getDisplayCountry pour obtenir le nom du pays approprié pour l’affichage à l’utilisateur. De même, vous pouvez utiliser getDisplayLanguage pour obtenir le nom de la langue appropriée pour l’affichage à l’utilisateur. Intéressantement, les getDisplayXXX méthodes sont elles-mêmes sensibles aux paramètres régionaux et ont deux versions : une qui utilise les paramètres régionaux par défaut Locale.Category#DISPLAY DISPLAY et une qui utilise les paramètres régionaux spécifiés comme argument.

La plateforme Java fournit un certain nombre de classes qui effectuent des opérations sensibles aux paramètres régionaux. Par exemple, la NumberFormat classe met en forme les nombres, la devise et les pourcentages de manière sensible aux paramètres régionaux. Les classes telles que NumberFormat plusieurs méthodes pratiques permettent de créer un objet par défaut de ce type. Par exemple, la NumberFormat classe fournit ces trois méthodes pratiques pour créer un objet par défaut NumberFormat : {

Ajouté dans la version 1.1.

Java documentation pour java.util.Locale.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.

        Language is always lower case, country is always upper case, script is always title
        case, and extensions are always lower case.