Locale Klasse

Definition

[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

Vererbung

Object

JavaObject

Object

Locale

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable ISerializable ICloneable IDisposable

Hinweise

Ein Locale Objekt stellt eine bestimmte geografische, politische oder kulturelle Region dar. Ein Vorgang, der eine Locale Aufgabe ausführen muss, wird als "em<locale-sensitive>/em<" bezeichnet >und verwendet die Locale Informationen zum Anpassen der Informationen für den Benutzer. Das Anzeigen einer Zahl ist z. B. ein gebietsschemasensitiver Vorgang— die Nummer sollte gemäß den Zoll- und Konventionen des heimischen Landes, der Region oder der Kultur des Benutzers formatiert werden.

Die Locale Klasse implementiert IETF BCP 47, die aus RFC 4647 "Matching of Language Tags" und RFC 5646 "Tags for Identifying Languages" mit Unterstützung für ldML (UTS#35, "Unicode Locale Data Markup Language") BCP 47-kompatible Erweiterungen für den Gebietsschemadatenaustausch besteht.

Ein Locale Objekt besteht logisch aus den unten beschriebenen Feldern.

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

<dd>ISO 639 Alpha-2- oder Alpha-3-Sprachcode oder registrierte Sprachuntertags bis zu 8 Alphabuchstaben (für zukünftige Verbesserungen). Wenn eine Sprache sowohl einen Alpha-2-Code als auch einen Alpha-3-Code enthält, muss der Alpha-2-Code verwendet werden. Sie finden eine vollständige Liste gültiger Sprachcodes in der IANA Language Subtag Registry (Suchen nach "Typ: Sprache"). Bei dem Sprachfeld wird die Groß-/Kleinschreibung nicht beachtet, aber Locale immer in Kleinbuchstaben kanonisiert.</dd>

<dd>Wohlgeformte Sprachwerte weisen die Form [a-zA-Z]{2,8}auf. Beachten Sie, dass dies nicht die vollständige BCP47-Sprachproduktion ist, da sie extlang ausschließt. Sie werden nicht benötigt, da moderne Drei-Buchstaben-Sprachcodes sie ersetzen.</dd>

<dd>Beispiel: "en" (Englisch), "ja" (Japanisch), "kok" (Konkani)</dd>

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

<dd>ISO 15924 Alpha-4-Skriptcode. Sie finden eine vollständige Liste der gültigen Skriptcodes in der IANA Language Subtag Registry (Suchen nach "Typ: Skript"). Bei dem Skriptfeld wird die Groß-/Kleinschreibung nicht beachtet, die Groß-/Kleinschreibung wird jedoch Locale immer kanonisiert (der erste Buchstabe ist Groß- und Kleinschreibung, und die restlichen Buchstaben sind Kleinbuchstaben).</dd>

<dd>Well-formed script values have the form [a-zA-Z]{4}</dd>

<dd>Beispiel: "Latn" (Lateinisch), "Cyrl" (Kyrillisch)</dd>

<dt>"def_region"><b>Land (Region)</b></dt>

<dd>ISO 3166 Alpha-2 Ländercode oder UN M.49 numerisch-3 Vorwahl. Sie finden eine vollständige Liste der gültigen Länder- und Regionscodes in der IANA Language Subtag Registry (suchen Sie nach "Typ: Region"). Bei dem Feld "Land (Region) wird die Groß-/Kleinschreibung nicht beachtet, aber Locale immer in Großbuchstaben kanonisiert.</dd>

<dd>Well-formed country/region values have the form [a-zA-Z]{2} | [0-9]{3}</dd>

<dd>Beispiel: "US" (USA), "FR" (Frankreich), "029" (Karibik)</dd>

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

<dd>Any any arbitrary value used to indicate a variation of a Locale. Wenn zwei oder mehr Variantenwerte vorhanden sind, die jeweils eine eigene Semantik angeben, sollten diese Werte nach Wichtigkeit sortiert werden, wobei sie zuerst durch Unterstrich('_') getrennt sind. Bei dem Variant-Feld wird die Groß-/Kleinschreibung beachtet.</dd>

<dd>Hinweis: IETF BCP 47 platziert syntaktische Einschränkungen auf Varianten-Subtags. Außerdem werden BCP 47-Untertags streng verwendet, um zusätzliche Variationen anzugeben, die eine Sprache oder ihre Dialekte definieren, die nicht von Kombinationen aus Sprach-, Skript- und Regionsuntertags abgedeckt werden. Eine vollständige Liste der gültigen Variantencodes finden Sie in der IANA Language Subtag Registry (suchen Sie nach "Typ: Variante").

Das Feld "Variante" in Locale der Vergangenheit wurde jedoch für jede Art von Variation verwendet, nicht nur für Sprachvariationen. Einige unterstützte Varianten, die in Java SE-Laufzeitumgebungen verfügbar sind, geben beispielsweise alternative kulturelle Verhaltensweisen an, z. B. Kalendertyp oder Zahlenskript. In BCP 47 wird diese Art von Informationen, die die Sprache nicht identifizieren, von Erweiterungsuntertags oder privaten Verwendungsuntertags unterstützt.</dd>

<dd>Well-form variant values have the form SUBTAG (('_'|'-') SUBTAG)* where SUBTAG = [0-9][0-9a-zA-Z]{3} | [0-9a-zA-Z]{5,8}. (Hinweis: BCP 47 verwendet nur Bindestrich ('-') als Trennzeichen, dies ist lenienter).</dd>

<dd>Beispiel: "Polyton" (Polyton griechisch), "POSIX"</dd>

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

<dd>A-Zuordnung von einzelnen Zeichenschlüsseln zu Zeichenfolgenwerten, die Erweiterungen abgesehen von der Sprachidentifikation angeben. Die Erweiterungen in Locale der Implementierung der Semantik und Syntax von BCP 47-Erweiterungsuntertags und privaten Verwendungs-Subtags. Bei den Erweiterungen wird die Groß-/Kleinschreibung nicht beachtet, aber Locale alle Erweiterungsschlüssel und Werte werden in Kleinbuchstaben kanonisiert. Beachten Sie, dass Erweiterungen keine leeren Werte enthalten können.</dd>

<dd>Wohlgeformte Schlüssel sind einzelne Zeichen aus dem Satz [0-9a-zA-Z]. Wohlgeformte Werte weisen das Format SUBTAG ('-' SUBTAG)* auf, in dem für den Schlüssel "x" SUBTAG = [0-9a-zA-Z]{1,8} und für andere Schlüssel SUBTAG = [0-9a-zA-Z]{2,8} (d. h. "x" einstellige Subtags zulässt).</dd>

<dd>Beispiel: key="u"/value="ca-japanese" (japanischer Kalender), key="x"/value="java-1-7"</dd></dl>

<b>Hinweis:</b> Obwohl BCP 47 feldwerte in der IANA Language Subtag Registry registriert werden muss, stellt die Locale Klasse keine Überprüfungsfunktionen bereit. Die Builder einzige Überprüfung, ob ein einzelnes Feld die syntaktische Anforderung erfüllt (ist wohlgeformt), überprüft jedoch nicht den Wert selbst. Weitere Informationen finden Sie unter Builder.

<h2>"def_locale_extension">Unicode-Gebietsschema/Spracherweiterung</h2>

UTS#35, "Unicode Locale Data Markup Language" definiert optionale Attribute und Schlüsselwörter, um das Standardverhalten zu überschreiben oder zu verfeinern, das einem Gebietsschema zugeordnet ist. Ein Schlüsselwort wird durch ein Schlüsselpaar und einen Typ dargestellt. Beispielsweise gibt "nu-thai" an, dass thailändische lokale Ziffern (Wert:"thai") zum Formatieren von Zahlen (schlüssel:"nu") verwendet werden sollen.

Die Schlüsselwörter werden einem BCP 47-Erweiterungswert mithilfe des Erweiterungsschlüssels "u" (#UNICODE_LOCALE_EXTENSION) zugeordnet. Das obige Beispiel, "nu-thai", wird zur Erweiterung "u-nu-thai".

Wenn also ein Locale Objekt Unicode-Gebietsschemaattribute und Schlüsselwörter enthält, wird eine Zeichenfolge zurückgegeben, getExtension(UNICODE_LOCALE_EXTENSION) die diese Informationen darstellt, z. B. "nu-thai". Die Locale Klasse bietet #getUnicodeLocaleAttributesaußerdem , #getUnicodeLocaleKeysund #getUnicodeLocaleType ermöglicht es Ihnen, direkt auf Unicode-Gebietsschemaattribute und Schlüssel-/Typpaare zuzugreifen. Wenn sie als Zeichenfolge dargestellt wird, listet die Unicode-Gebietsschemaerweiterung Attribute alphabetisch auf, gefolgt von Schlüssel-/Typsequenzen mit alphabetisch aufgelisteten Schlüsseln (die Reihenfolge der Untertags, die den Typ eines Schlüssels umfassen, wird beim Definieren des Typs festgelegt)

Ein wohlgeformter Gebietsschemaschlüssel hat das Formular [0-9a-zA-Z]{2}. Ein wohlgeformte Gebietsschematyp hat das Format "" | [0-9a-zA-Z]{3,8} ('-' [0-9a-zA-Z]{3,8})* (es kann leer sein oder eine Reihe von Untertags 3-8 Alphanums länge). Ein wohlgeformtes Gebietsschema-Attribut weist das Formular [0-9a-zA-Z]{3,8} auf (es handelt sich um ein einzelnes Untertag mit demselben Formular wie ein Gebietsschematyp-Untertag).

Die Unicode-Gebietsschemaerweiterung gibt optionales Verhalten in gebietsschemasensitiven Diensten an. Obwohl die LDML-Spezifikation verschiedene Schlüssel und Werte definiert, unterstützen tatsächliche gebietsschemasensitive Dienstimplementierungen in einer Java Runtime Environment möglicherweise keine bestimmten Unicode-Gebietsschemaattribute oder Schlüssel-/Typpaare.

<h3>"ObtainingLocale">Abrufen eines Gebietsschemas</h3>

Es gibt mehrere Möglichkeiten zum Abrufen eines Locale Objekts.

<h4>Builder</h4>

Mit der Verwendung Builder können Sie ein Locale Objekt erstellen, das der BCP 47-Syntax entspricht.

<h4>Factory Methods</h4>

Die Methode #forLanguageTag ruft ein Locale Objekt für ein wohlgeformte BCP 47-Sprachtag ab. Die Methode #of(String, String, String) und die zugehörigen Überladungen erhalten ein Locale Objekt aus dem angegebenen language, countryund/oder variant definierten oben definierten Objekt.

<h4>Gebietsschemakonstanten</h4>

Die Locale Klasse stellt eine Reihe praktischer Konstanten bereit, mit denen Sie Objekte für häufig verwendete Gebietsschemas abrufen Locale können. Ist z. BLocale.US. das Locale Objekt für das USA.

<h3>"LocaleMatching">Locale Matching</h3>

Wenn eine Anwendung oder ein System internationalisiert ist und lokalisierte Ressourcen für mehrere Gebietsschemas bereitstellt, muss sie manchmal ein oder mehrere Gebietsschemas (oder Sprachtags) finden, die den spezifischen Einstellungen der einzelnen Benutzer entsprechen. Beachten Sie, dass ein Begriff "Sprachtag" in dieser Gebietsschemaabgleichsdokumentation austauschbar mit "Gebietsschema" verwendet wird.

Um die bevorzugten Gebietsschemas eines Benutzers mit einer Reihe von Sprachtags abzugleichen, definiert RFC 4647 Matching of Language Tags zwei Mechanismen: Filtern und Nachschlagen. <em>Filtering</em wird verwendet, um alle übereinstimmenden Gebietsschemas abzurufen, während >em<lookup>/em<> das beste übereinstimmende Gebietsschema auswählen soll. Der Abgleich erfolgt ohne Groß-/Kleinschreibung. Diese Abgleichsmechanismen werden in den folgenden Abschnitten beschrieben.

Die Einstellung eines Benutzers wird als <em-Liste>der Sprachpriorität</em> bezeichnet und wird als Liste der Sprachbereiche ausgedrückt. Es gibt syntaktisch zwei Arten von Sprachbereichen: einfach und erweitert. Weitere Informationen finden Sie unter Locale.LanguageRange Locale.LanguageRange.

<h4-Filterung></h4>

Der Filtervorgang gibt alle übereinstimmenden Sprachtags zurück. Sie wird in RFC 4647 wie folgt definiert: "Beim Filtern stellt jeder Sprachbereich das am wenigsten spezifische Sprachtag dar (d. h. das Sprachtag mit der kleinsten Anzahl von Untertags), das eine akzeptable Übereinstimmung darstellt. Alle Sprachtags in der übereinstimmenden Gruppe von Tags haben eine gleiche oder größere Anzahl von Untertags als der Sprachbereich. Jedes Nicht-Wildcard-Untertag im Sprachbereich wird in jedem der entsprechenden Sprachtags angezeigt."

Es gibt zwei Arten von Filtern: Filtern für grundlegende Sprachbereiche (als "grundlegende Filterung") und Filterung für erweiterte Sprachbereiche (als "erweiterte Filterung" bezeichnet). Sie können unterschiedliche Ergebnisse zurückgeben, je nach Art von Sprachbereichen in der angegebenen Sprachenprioritätsliste enthalten sind. Locale.FilteringMode ist ein Parameter, der angibt, wie die Filterung durchgeführt werden soll.

<h4>Lookup</h4>

Der Nachschlagevorgang gibt die besten übereinstimmenden Sprachtags zurück. Sie wird in RFC 4647 wie folgt definiert: "Im Gegensatz zum Filtern stellt jeder Sprachbereich das spezifischste Tag dar, das eine akzeptable Übereinstimmung darstellt. Das erste übereinstimmende Tag, das gemäß der Priorität des Benutzers gefunden wurde, wird als die nächstgelegene Übereinstimmung betrachtet und ist das zurückgegebene Element."

Wenn beispielsweise eine Sprachenprioritätsliste aus zwei Sprachbereichen besteht, "zh-Hant-TW" und "en-US"in priorisierter Reihenfolge durchsucht die Nachschlagemethode schrittweise die folgenden Sprachtags, um das beste passende Sprachtag zu finden. <Blockquote>

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

</blockquote> If there is a language tag which matches vollständig to a language range above, the language tag is returned.

"*" ist der spezielle Sprachbereich und wird im Nachschlagevorgang ignoriert.

Wenn mehrere Sprachtags als Ergebnis des in einem Sprachbereich enthaltenen Untertags '*' übereinstimmen, wird das erste übereinstimmende Sprachtag, das von einem über einem IteratorCollection Sprachtag zurückgegeben wird, als der beste übereinstimmende Tag behandelt.

<h3>Verwendung des Gebietsschemas</h3>

Nachdem Sie einen Locale Abgerufen haben, können Sie ihn nach Informationen zu sich selbst abfragen. Dient getCountry zum Abrufen des Landescodes (oder der Region) und getLanguage zum Abrufen des Sprachcodes. Sie können verwenden getDisplayCountry , um den Namen des Landes abzurufen, das für die Anzeige für den Benutzer geeignet ist. Ebenso können getDisplayLanguage Sie den Namen der Sprache abrufen, die für die Anzeige für den Benutzer geeignet ist. Interessanterweise sind die getDisplayXXX Methoden selbst gebietsschemasensitiv und weisen zwei Versionen auf: eines, das das Standardgebietsschema Locale.Category#DISPLAY DISPLAY verwendet, und eines, das das als Argument angegebene Gebietsschema verwendet.

Die Java Plattform stellt eine Reihe von Klassen bereit, die gebietsschemabezogene Vorgänge ausführen. Beispielsweise formatiert die NumberFormat Klasse Zahlen, Währungen und Prozentsätze auf gebietsschemasensitive Weise. Klassen, z NumberFormat . B. mehrere Komfortmethoden zum Erstellen eines Standardobjekts dieses Typs. Die Klasse stellt beispielsweise NumberFormat diese drei Komfortmethoden zum Erstellen eines Standardobjekts NumberFormat bereit: {

In 1.1 hinzugefügt.

Java Dokumentation für java.util.Locale.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.

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