Locale Klasse
Definition
Wichtig
Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.
Ein Locale Objekt stellt eine bestimmte geografische, politische oder kulturelle Region dar.
[Android.Runtime.Register("java/util/Locale", DoNotGenerateAcw=true)]
public sealed class Locale : Java.Lang.Object, IDisposable, Java.Interop.IJavaPeerable, 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
- Attribute
- Implementiert
Hinweise
Ein Locale Objekt stellt eine bestimmte geografische, politische oder kulturelle Region dar. Ein Vorgang, der eine Locale zum Ausführen seiner Aufgabe erfordert, wird em>locale-sensitive</em> genannt <und verwendet denLocale, um Informationen für den Benutzer anzupassen. Die Anzeige einer Zahl ist beispielsweise ein gebietsschemaabhängiger Vorgang— Die Nummer sollte gemäß den Gepflogenheiten und Konventionen des Heimatlandes, 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" besteht und die LDML-Erweiterungen (UTS#35, "Unicode Locale Data Markup Language") BCP 47-kompatible Erweiterungen für den Gebietsschemadatenaustausch unterstützen.
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 Sprache subtagiert bis zu 8 Alphabuchstaben (für zukünftige Verbesserungen). Wenn eine Sprache sowohl über einen Alpha-2-Code als auch über einen Alpha-3-Code verfügt, muss der Alpha-2-Code verwendet werden. Eine vollständige Liste der gültigen Sprachcodes finden Sie in der IANA Language Subtag Registry (suchen Sie nach "Type: language"). Für das Sprachfeld wird die Groß-/Kleinschreibung nicht beachtet, aber Locale immer in Kleinbuchstaben kanonisiert.</Dd>
<dd>Wohlgeformte Sprachwerte haben das Format [a-zA-Z]{2,8}. Beachten Sie, dass dies nicht die vollständige BCP47-Sprachproduktion ist, da extlang ausgeschlossen ist. 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. Eine vollständige Liste gültiger Skriptcodes finden Sie in der IANA Language Subtag Registry (suchen Sie nach "Type: script"). Im Skriptfeld wird die Groß-/Kleinschreibung nicht beachtet, aber Locale immer in die Groß-/Kleinschreibung des Titels kanonisiert (der erste Buchstabe ist Großbuchstaben, und der Rest der Buchstaben ist Kleinbuchstaben).</Dd>
<dd>Wohlgeformte Skriptwerte haben das Format [a-zA-Z]{4}</dd>
<dd>Beispiel: "Latn" (Lateinisch), "Cyrl" (Kyrillisch)</dd>
<dt>"def_region"><b>country (region)</b></dt>
<dd>ISO 3166 alpha-2 Ländercode oder UN M.49 numerisch-3-Vorwahl. Eine vollständige Liste der gültigen Länder- und Regionscodes finden Sie in der IANA Language Subtag Registry (suchen Sie nach "Typ: Region"). Beim Feld "Land (Region)" wird die Groß-/Kleinschreibung nicht beachtet, aber Locale immer in Großbuchstaben kanonisiert.</Dd>
<dd>Wohlgeformte Länder-/Regionswerte haben das Format [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>Beliebiger Wert, der verwendet wird, um eine Variation eines Localeanzugeben. Wenn es zwei oder mehr Variantenwerte gibt, die jeweils ihre eigene Semantik angeben, sollten diese Werte nach Wichtigkeit sortiert werden, wobei die wichtigsten zuerst durch Unterstriche('_') getrennt werden. Beim Feld "Variante" wird die Groß-/Kleinschreibung beachtet.</Dd>
<dd>Hinweis: IETF BCP 47 setzt syntaktische Einschränkungen für Variantenuntertags. Außerdem werden BCP 47-Untertags streng verwendet, um zusätzliche Variationen anzugeben, die eine Sprache oder ihre Dialekte definieren, die nicht durch Kombinationen von 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 "Type: variant").
Das Variantenfeld in Locale wurde jedoch in der Vergangenheit für jede Art von Variation verwendet, nicht nur für Sprachvariationen. Einige unterstützte Varianten, die in Java SE-Laufzeitumgebungen verfügbar sind, weisen beispielsweise auf alternative kulturelle Verhaltensweisen hin, z. B. Kalendertyp oder Zahlenskript. In BCP 47 werden diese Art von Informationen, die die Sprache nicht identifizieren, von Erweiterungsuntertags oder untertags für private Verwendung unterstützt.</Dd>
<dd>Wohlgeformte Variantenwerte weisen das Format SUBTAG (('_'|'-') SUBTAG)* auf, in dem SUBTAG = [0-9][0-9a-zA-Z]{3} | [0-9a-zA-Z]{5,8}. (Hinweis: BCP 47 verwendet nur Bindestriche ('-') als Trennzeichen, dies ist nachsichtiger).</Dd>
<dd>Beispiel: "polyton" (polyton griechisch), "POSIX"</dd>
<dt>"def_extensions"><b>extensions</b></dt>
<dd>Eine Zuordnung von Einzelzeichenschlüsseln zu Zeichenfolgenwerten, die Erweiterungen außer der Sprachidentifikation angibt. Die Erweiterungen in Locale implementieren die Semantik und Syntax von BCP 47-Erweiterungsuntertags und Untertags für private Verwendung. 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 aufweisen können.</Dd>
<dd>Wohlgeformte Schlüssel sind einzelne Zeichen aus dem Satz [0-9a-zA-Z]. Wohlgeformte Werte haben die Form SUBTAG ('-' SUBTAG)* , in der 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. a. "x" einzeichenige Untertags 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 die Registrierung von Feldwerten in der IANA Language Subtag Registry erfordert, bietet die Locale Klasse keine Validierungsfeatures. Die Builder einzige Überprüfung, ob ein einzelnes Feld die syntaktische Anforderung erfüllt (wohlgeformt), aber nicht den Wert selbst überprüft. Einzelheiten dazu finden Sie unter Builder.
<h3>"def_locale_extension">Unicode-Gebietsschema/Spracherweiterung</h3>
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 (keyword) wird durch ein Schlüssel- und Typpaar dargestellt. "nu-thai" gibt beispielsweise an, dass lokale thailändische Ziffern (wert:"thai") zum Formatieren von Zahlen (key:"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 ein Locale Objekt also Unicode-Gebietsschemaattribute und Schlüsselwörter enthält, getExtension(UNICODE_LOCALE_EXTENSION) wird eine Zeichenfolge zurückgegeben, die diese Informationen darstellt, z. B. "nu-thai". Die Locale -Klasse bietet #getUnicodeLocaleAttributesauch , #getUnicodeLocaleKeysund #getUnicodeLocaleType ermöglicht ihnen den direkten Zugriff auf Unicode-Gebietsschemaattribute und Schlüssel-Typ-Paare. Wenn sie als Zeichenfolge dargestellt wird, listet die Unicode-Gebietsschemaerweiterung Attribute alphabetisch auf, gefolgt von Schlüssel-/Typsequenzen mit alphabetisch aufgeführten Schlüsseln (die Reihenfolge der Untertags, die den Typ eines Schlüssels enthalten, wird bei der Definition des Typs festgelegt).
Ein wohlgeformter Gebietsschemaschlüssel hat das Format [0-9a-zA-Z]{2}. Ein wohlgeformte Gebietsschematyp hat das Formular "" | [0-9a-zA-Z]{3,8} ('-' [0-9a-zA-Z]{3,8})* (es kann leer sein oder eine Reihe von Untertags mit einer Länge von 3-8 Alphanumen). Ein wohlgeformte Gebietsschemaattribute hat das Formular [0-9a-zA-Z]{3,8} (es ist ein einzelnes Untertag mit dem gleichen Formular wie ein Gebietsschematyp-Subtag).
Die Unicode-Gebietsschemaerweiterung gibt optionales Verhalten in gebietsschemaabhängigen Diensten an. Obwohl die LDML-Spezifikation verschiedene Schlüssel und Werte definiert, unterstützen die tatsächlichen gebietsschemaabhängigen Dienstimplementierungen in einer Java-Runtime-Umgebung möglicherweise keine bestimmten Unicode-Gebietsschemaattribute oder Schlüssel-Typ-Paare.
<h4>Erstellen eines Gebietsschemas</h4>
Es gibt verschiedene Möglichkeiten, ein Locale Objekt zu erstellen.
<h5>Builder</h5>
Mit Builder diesem Können Sie ein Locale Objekt erstellen, das der BCP 47-Syntax entspricht.
<h5-Konstruktoren></h5>
Die Locale -Klasse bietet drei Konstruktoren: <blockquote>
{@link #Locale(String language)}
{@link #Locale(String language, String country)}
{@link #Locale(String language, String country, String variant)}
</blockquote> Mit diesen Konstruktoren können Sie ein Locale Objekt mit Sprache, Land und Variante erstellen, aber Sie können kein Skript oder Keine Erweiterungen angeben.
<h5>Factory-Methoden</h5>
Die -Methode #forLanguageTag erstellt ein Locale -Objekt für ein wohlgeformtes BCP 47-Sprachtag.
<h5>Gebietsschemakonstanten</h5>
Die Locale -Klasse stellt eine Reihe von praktischen Konstanten bereit, mit denen Sie Objekte für häufig verwendete Gebietsschemas erstellen Locale können. So wird beispielsweise ein Locale Objekt für die USA erstellt: <blockquote>
Locale.US
</Blockquote>
<h4>"LocaleMatching">Locale Matching</h4>
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 Vorlieben jedes Benutzers entsprechen. Beachten Sie, dass in dieser Dokumentation zum Gebietsschemaabgleich ein Begriff "Sprachtag" synonym 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 Suchen. <em>Filtering</em> wird verwendet, um alle übereinstimmenden Gebietsschemas abzurufen, während <em>lookup</em> darin besteht, das am besten übereinstimmende Gebietsschema auszuwählen. Beim Abgleich wird die Groß-/Kleinschreibung nicht beachtet. Diese Abgleichsmechanismen werden in den folgenden Abschnitten beschrieben.
Die Einstellung eines Benutzers wird als em>Language Priority List</em> bezeichnet <und als Liste der Sprachbereiche ausgedrückt. Es gibt syntaktisch zwei Arten von Sprachbereichen: einfach und erweitert. Einzelheiten dazu finden Sie unter Locale.LanguageRange Locale.LanguageRange.
<h5>Filterung</h5>
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 (d. h. das Sprachtag mit der wenigsten Anzahl von Untertags) dar, das eine akzeptable Übereinstimmung darstellt. Alle Sprachtags im übereinstimmenden Satz von Tags weisen eine gleiche oder größere Anzahl von Untertags auf als der Sprachbereich. Jedes Untertag ohne Denkplatzhalter im Sprachbereich wird in jedem der übereinstimmenden Sprachtags angezeigt."
Es gibt zwei Arten von Filterung: Filtern nach grundlegenden Sprachbereichen (als "Basisfilterung" bezeichnet) und Filtern nach erweiterten Sprachbereichen (als "erweiterte Filterung" bezeichnet). Sie können unterschiedliche Ergebnisse zurückgeben, je nach der Art von Sprachbereichen, die in der angegebenen Sprachprioritätsliste enthalten sind. Locale.FilteringMode ist ein Parameter, um anzugeben, wie die Filterung erfolgen soll.
<h5>Lookup</h5>
Der Suchvorgang gibt die besten übereinstimmenden Sprachtags zurück. Es ist in RFC 4647 wie folgt definiert: "Im Gegensatz zur Filterung stellt jeder Sprachbereich das spezifischste Tag dar, das eine akzeptable Übereinstimmung darstellt. Das erste übereinstimmende Tag, das je nach Priorität des Benutzers gefunden wurde, wird als die nächstgelegene Übereinstimmung betrachtet und ist das zurückgegebene Element."
Wenn beispielsweise eine Sprachprioritätsliste aus zwei Sprachbereichen besteht, "zh-Hant-TW" und "en-US", in priorisierter Reihenfolge, durchsucht die Nachschlagemethode schrittweise die folgenden Sprachtags, um das am besten übereinstimmende Sprachtag zu finden. <Blockquote>
1. zh-Hant-TW
2. zh-Hant
3. zh
4. en-US
5. en
</blockquote> Wenn ein Sprachtag vorhanden ist, das vollständig mit einem darüber stehenden Sprachbereich übereinstimmt, wird das Sprachtag zurückgegeben.
"*" ist der spezielle Sprachbereich, der bei der Suche ignoriert wird.
Wenn mehrere Sprachtags aufgrund des in einem Sprachbereich enthaltenen Untertags '*' übereinstimmen, wird das erste übereinstimmende Sprachtag, das von einem über ein IteratorCollection von Sprachtags zurückgegeben wird, als das am besten übereinstimmende Tag behandelt.
<h4>Verwendung des Gebietsschemas</h4>
Nachdem Sie eine Locale erstellt haben, können Sie ihn nach Informationen über sich selbst abfragen. Verwenden Sie getCountry , um den Ländercode (oder die Region) abzurufen und getLanguage den Sprachcode abzurufen. 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 Sie verwenden getDisplayLanguage , um den Namen der Sprache abzurufen, die für die Anzeige für den Benutzer geeignet ist. Interessanterweise sind die getDisplayXXX Methoden selbst gebietsschemaabhängig und verfügen über zwei Versionen: eine, die das Standardgebietsschema Locale.Category#DISPLAY DISPLAY verwendet, und eine, die das als Argument angegebene Gebietsschema verwendet.
Die Java-Plattform stellt eine Reihe von Klassen bereit, die gebietsschemaabhängige Vorgänge ausführen. Die Klasse formatiert z. NumberFormat B. Zahlen, Währungen und Prozentwerte gebietsschemaabhängig. Klassen wie NumberFormat verfügen über mehrere Komfortmethoden zum Erstellen eines Standardobjekts dieses Typs. Die -Klasse bietet beispielsweise NumberFormat die folgenden drei Komfortmethoden zum Erstellen eines Standardobjekts NumberFormat : <blockquote>
NumberFormat.getInstance()
NumberFormat.getCurrencyInstance()
NumberFormat.getPercentInstance()
</blockquote> Jede dieser Methoden verfügt über zwei Varianten: eine mit einem expliziten Gebietsschema und eine ohne; letztere verwendet das Standardgebietsschema Locale.Category#FORMAT FORMAT blockquote: <blockquote>
NumberFormat.getInstance(myLocale)
NumberFormat.getCurrencyInstance(myLocale)
NumberFormat.getPercentInstance(myLocale)
</blockquote> A Locale ist der Mechanismus zum Identifizieren der Art des Objekts (NumberFormat), das Sie erhalten möchten. Das Gebietsschema ist <STRONG>just</STRONG> ein Mechanismus zum Identifizieren von Objekten, <STRONG>nicht</STRONG> ein Container für die Objekte selbst.
<h4>Kompatibilität</h4>
Um die Kompatibilität mit der vorhandenen Verwendung zu gewährleisten, behalten die Gebietsschemakonstruktoren ihr Verhalten vor der Java Runtime Environment Version 1.7 bei. Das gleiche gilt weitgehend für die toString -Methode. Daher können Gebietsschemaobjekte weiterhin wie bisher verwendet werden. Insbesondere Clients, die die Ausgabe von toString in Sprach-, Länder- und Variantenfelder analysieren, können dies weiterhin tun (obwohl dies dringend abgeraten wird), obwohl das Feld variant zusätzliche Informationen enthält, wenn Skripts oder Erweiterungen vorhanden sind.
Darüber hinaus erzwingt BCP 47 Syntaxeinschränkungen, die nicht von den Gebietsschemakonstruktoren auferlegt werden. Dies bedeutet, dass Konvertierungen zwischen einigen Locales und BCP 47-Sprachtags nicht durchgeführt werden können, ohne Informationen zu verlieren. Somit toLanguageTag kann nicht der Zustand von Gebietsschemas dargestellt werden, deren Sprache, Land oder Variante nicht BCP 47 entspricht.
Aufgrund dieser Probleme wird empfohlen, dass Clients vom Erstellen nicht konformer Gebietsschemas migrieren und stattdessen die forLanguageTag APIs und Locale.Builder verwenden. Clients, die eine Zeichenfolgendarstellung des vollständigen Gebietsschemas benötigen, können sich dann immer auf toLanguageTag diesen Zweck verlassen.
<h5>"special_cases_constructor">Sonderfälle</h5>
Aus Kompatibilitätsgründen werden zwei nicht übereinstimmende Gebietsschemas als Sonderfälle behandelt. Dies sind <b<>ja_JP_JP/b> und <bth_TH_TH></b.> Diese sind in BCP 47 schlecht ausgebildet, da die Varianten zu kurz sind. Um die Migration zu BCP 47 zu erleichtern, werden diese speziell während des Baus behandelt. Diese beiden Fälle (und nur diese) führen dazu, dass ein Konstruktor eine Erweiterung generiert. Alle anderen Werte verhalten sich genau wie vor Java 7.
Java hat früher ja_JP_JP japanisch dargestellt, wie es in Japan zusammen mit dem japanischen Kaiserkalender verwendet wird. Dies kann jetzt mithilfe einer Unicode-Gebietsschemaerweiterung dargestellt werden, indem sie den Unicode-Gebietsschemaschlüssel ca (für "kalender") und den Typ angeben japanese. Wenn der Gebietsschemakonstruktor mit den Argumenten "ja", "JP", "JP" aufgerufen wird, wird die Erweiterung "u-ca-japanese" automatisch hinzugefügt.
Java hat früher th_TH_TH thailändisch dargestellt, wie es in Thailand zusammen mit thailändischen Ziffern verwendet wird. Dies kann jetzt auch mit einer Unicode-Gebietsschemaerweiterung dargestellt werden, indem sie den Unicode-Gebietsschemaschlüssel nu (für "Zahl") und den Wert thaiangeben. Wenn der Gebietsschemakonstruktor mit den Argumenten "th", "TH", "TH" aufgerufen wird, wird die Erweiterung "u-nu-thai" automatisch hinzugefügt.
<h5>Serialisierung</h5>
Während der Serialisierung schreibt writeObject alle Felder in den Ausgabedatenstrom, einschließlich Erweiterungen.
Während der Deserialisierung fügt readResolve Erweiterungen hinzu, wie unter Special Cases beschrieben, nur für die beiden Fälle th_TH_TH und ja_JP_JP.
<h5>Legacy-Sprachcodes</h5>
Der Gebietsschemakonstruktor hat immer drei Sprachcodes in ihre früheren, veralteten Formulare konvertiert: he Zuordnungen zu iw, yi zuordnungen zu ji, und id Zuordnungen zu in. Dies ist weiterhin der Fall, um die Abwärtskompatibilität nicht zu unterbrechen.
Die apIs, die in Version 1.7 hinzugefügt wurden, ordnen den alten und neuen Sprachcodes zu, wobei die alten Codes innerhalb des Gebietsschemas beibehalten werden (so dass getLanguage und toString den alten Code widerspiegeln), aber die neuen Codes in den BCP 47-Sprachtag-APIs verwenden (dies toLanguageTag spiegelt den neuen wider). Dadurch wird die Äquivalenz zwischen Gebietsschemas beibehalten, unabhängig davon, welcher Code oder API für deren Erstellung verwendet wird. Der Standardmäßige Nachschlagemechanismus für Ressourcenbündel von Java implementiert auch diese Zuordnung, sodass Ressourcen mithilfe einer der beiden Konventionen benannt werden können, siehe ResourceBundle.Control.
<h5>Dreibuchstaben-Sprach-/Länder(Region)-Codes</h5>
Die Gebietsschemakonstruktoren haben immer angegeben, dass die Sprache und der Länderparam zwei Zeichen lang sind, obwohl sie in der Praxis eine beliebige Länge akzeptiert haben. Die Spezifikation wurde nun gelockert, um Sprachcodes von zwei bis acht Zeichen und Ländercodes von zwei bis drei Zeichen zuzulassen, insbesondere Dreibuchstaben-Sprachcodes und dreistellige Regionscodes, wie in der IANA Language Subtag Registry angegeben. Aus Gründen der Kompatibilität erzwingt die Implementierung immer noch keine Längeneinschränkung.
"locale_data"><h4>Gebietsschemadaten</h4>
Beachten Sie, dass Gebietsschemadaten ausschließlich von der Intensivstation stammen. Vom Benutzer bereitgestellte Gebietsschemadienstanbieter (mit den java.text.spi Mechanismen oder java.util.spi ) werden nicht unterstützt.
Hier sind die Versionen der ICU (und der entsprechenden CLDR- und Unicode-Versionen), die in verschiedenen Android-Versionen verwendet werden: <table BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="><"tr><td>Android 1.5 (Cupcake)/Android 1.5 (Cupcake)/Android 1.5 1.6 (Donut)/Android 2.0 (Eclair)</td td<>td>ICU 3.8</td td>><CLDR 1.5</td td><td>Unicode 5.0</td></tr><tr><td>Android 2.2 (Froyo)</td><td>ICU 4.2</td><td td>CLDR 1.7</td td><>Unicode 5.1</td></tr><tr trd><>Android 2.3 (Gingerbread)/Android 3.0 (Honeycom b)</td td<>>iCU 4.4</td td<>> CLDR 1.8</td td<>td> Unicode 5.2</td></tr<>trd><>Android 4.0 (Ice Cream Sandwich)</td td><td>ICU 4.6</td><td td>CLDR 1.9</td><td>Unicode 6.0</td></tr<>tr tr><td>Android 4.1 (Jelly Bean)</td td tdICU 4.8</td<>> td>>< CLDR 2.0</td td><td> Unicode 6.0</td></tr<>trd><>Android 4.3 (Jelly Bean MR2)</td td<>td> ICU 50</td><td>CLDR 22.1</td td><td>Unicode 6.2</td></tr><trd>><Android 4.4 (KitKat)</td td<>td> ICU 51</td><tdtd> CLDR 23</td td><>Unicode6.2</td></tr<>tr trd>><Android 5.0 (Lollipop)</td<>td td> ICU 53</Td><td>CLDR 25</td td><>Unicode 6.3</td></tr<>trd><>Android 6.0 (Marshmallow)</td td<>> iCU 55.1</td td<>td> CLDR 27.0.1</td td><>Unicode7.0</td></tr<>tr trd>><Android 7.0 (Nougat)</td td<>td> ICU 56.1</Td><td>CLDR 28</td td<>>Unicode 8.0</td></tr><trd><>Android 8.0 (Oreo)</td td<>> iCU 58.2</td td td>>< CLDR 30.0.3</td td<> td> Unicode 9.0</td></tr><trd>><Android 9.0 (Pie)</td td<>> ICU 60.2</td><td>CLDR 32.0.1</td td><td>Unicode 10.0</td></tr><tr trd><>Android 10.0 (Q)</td td>>< ICU 63.2</td td><td> CLDR 34</td td><> Unicode 11.0</td></tr></table>
"default_locale"><h4>Achten Sie auf das Standardgebietsschema</h3>
Beachten Sie, dass es viele Komfortmethoden gibt, die automatisch das Standardgebietsschema verwenden, aber die Verwendung dieser Methoden kann zu subtilen Fehlern führen.
Das Standardgebietsschema eignet sich für Aufgaben, die die Darstellung von Daten für den Benutzer umfassen. In diesem Fall möchten Sie die Datums-/Uhrzeitformate, Zahlenformate, Regeln für die Konvertierung in Kleinbuchstaben usw. verwenden. In diesem Fall ist es sicher, die Convenience-Methoden zu verwenden.
Das Standardgebietsschema ist für die maschinenlesbare Ausgabe nicht geeignet. Die beste Wahl gibt es in der Regel Locale.US – dieses Gebietsschema ist garantiert auf allen Geräten verfügbar, und die Tatsache, dass es keine überraschenden Sonderfälle aufweist und häufig verwendet wird (insbesondere für die Kommunikation zwischen Computer und Computer), bedeutet, dass es auch die effizienteste Wahl ist.
Ein häufiger Fehler ist die implizite Verwendung des Standardgebietsschemas bei der Erstellung einer Ausgabe, die maschinenlesbar sein soll. Dies funktioniert in der Regel auf den Testgeräten des Entwicklers (insbesondere, weil so viele Entwickler en_US verwenden), schlägt jedoch fehl, wenn sie auf einem Gerät ausgeführt wird, dessen Benutzer sich in einem komplexeren Gebietsschema befindet.
Wenn Sie z. B. ganze Zahlen formatieren, verwenden einige Gebietsschemas Nicht-ASCII-Dezimalstellen. Ein weiteres Beispiel: Wenn Sie Gleitkommazahlen formatieren, werden einige Gebietsschemas als Dezimalpunkt und '.' für die Zifferngruppierung verwendet','. Dies ist für die für Menschen lesbare Ausgabe richtig, verursacht aber wahrscheinlich Probleme, wenn es auf einem anderen Computer angezeigt wird (Double#parseDouble kann eine solche Zahl z. B. nicht analysieren). Sie sollten auch vorsichtig mit den String#toLowerCase und String#toUpperCase Überladungen sein, die keine nehmen Locale: in der Türkei zum Beispiel die Zeichen 'i' und 'I' werden nicht in 'I' und 'i'konvertiert. Dies ist das richtige Verhalten für türkischen Text (z. B. Benutzereingaben), aber nicht für beispielsweise HTTP-Header geeignet.
In Version 1.1 hinzugefügt.
Java-Dokumentation für java.util.Locale.
Teile dieser Seite sind Änderungen, die auf Arbeiten basieren, die vom Android Open Source Project erstellt und freigegeben wurden und gemäß den In der Attribution License beschriebenen Begriffen verwendet werden.
Konstruktoren
| Locale(String) |
Erstellen Sie ein Gebietsschema aus einem Sprachcode. |
| Locale(String, String) |
Erstellen Sie ein Gebietsschema aus Sprache und Land. |
| Locale(String, String, String) |
Erstellen Sie ein Gebietsschema aus Sprache, Land und Variante. |
Felder
| PrivateUseExtension |
Der Schlüssel für die Erweiterung für die private Verwendung ('x'). |
| UnicodeLocaleExtension |
Der Schlüssel für die Unicode-Gebietsschemaerweiterung ('u'). |
Eigenschaften
| Canada |
Nützliche Konstante für das Land. |
| CanadaFrench |
Nützliche Konstante für das Land. |
| China |
Nützliche Konstante für das Land. |
| Chinese |
Nützliche Konstante für Sprache. |
| Class |
Gibt die Laufzeitklasse dieses |
| Country |
Gibt den Länder-/Regionscode für dieses Gebietsschema zurück, das entweder die leere Zeichenfolge, ein ISO 3166-Code mit 2 Buchstaben oder ein UN M-Code in Großbuchstaben sein sollte. |
| Default |
Ruft den aktuellen Wert des Standardgebietsschemas für diese instance des virtuellen Java-Computers ab. -or: Legt das Standardgebietsschema für diese instance des virtuellen Java-Computers fest. |
| DisplayCountry |
Gibt einen Namen für das Land des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| DisplayLanguage |
Gibt einen Namen für die Sprache des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| DisplayName |
Gibt einen Namen für das Gebietsschema zurück, das für die Anzeige für den Benutzer geeignet ist. |
| DisplayScript |
Gibt einen Namen für das Skript des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| DisplayVariant |
Gibt einen Namen für den Variantencode des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| English |
Nützliche Konstante für Sprache. |
| ExtensionKeys |
Gibt den Satz von Erweiterungsschlüsseln zurück, die diesem Gebietsschema zugeordnet sind, oder den leeren Satz, wenn er keine Erweiterungen enthält. |
| France |
Nützliche Konstante für das Land. |
| French |
Nützliche Konstante für Sprache. |
| German |
Nützliche Konstante für Sprache. |
| Germany |
Nützliche Konstante für das Land. |
| Handle |
Das Handle zum zugrunde liegenden Android-instance. (Geerbt von Object) |
| HasExtensions |
Gibt zurück |
| ISO3Country |
Gibt eine Dreibuchstaben-Abkürzung für das Land dieses Gebietsschemas zurück. |
| ISO3Language |
Gibt eine Dreibuchstaben-Abkürzung der Sprache dieses Gebietsschemas zurück. |
| Italian |
Nützliche Konstante für Sprache. |
| Italy |
Nützliche Konstante für das Land. |
| Japan |
Nützliche Konstante für das Land. |
| Japanese |
Nützliche Konstante für Sprache. |
| JniIdentityHashCode |
Ein |
| JniPeerMembers |
Ein |
| Korea |
Nützliche Konstante für das Land. |
| Korean |
Nützliche Konstante für Sprache. |
| Language |
Gibt den Sprachcode dieses Gebietsschemas zurück. |
| PeerReference |
Ein |
| Prc |
Nützliche Konstante für das Land. |
| Root |
Nützliche Konstante für das Stammgebietsschema. |
| Script |
Gibt das Skript für dieses Gebietsschema zurück, das entweder die leere Zeichenfolge oder ein ISO 15924-Skriptcode mit vier Buchstaben sein sollte. |
| SimplifiedChinese |
Nützliche Konstante für Sprache. |
| Taiwan |
Nützliche Konstante für das Land. |
| ThresholdClass |
Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen. (Geerbt von Object) |
| ThresholdType |
Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen. (Geerbt von Object) |
| TraditionalChinese |
Nützliche Konstante für Sprache. |
| Uk |
Nützliche Konstante für das Land. |
| UnicodeLocaleAttributes |
Gibt den Satz von Unicode-Gebietsschemaattributen zurück, die diesem Gebietsschema zugeordnet sind, oder den leeren Satz, wenn keine Attribute vorhanden sind. |
| UnicodeLocaleKeys |
Gibt den Satz von Unicode-Gebietsschemaschlüsseln zurück, die durch dieses Gebietsschema definiert sind, oder den leeren Satz, wenn dieses Gebietsschema keines aufweist. |
| Us |
Nützliche Konstante für das Land. |
| Variant |
Gibt den Variantencode für dieses Gebietsschema zurück. |
Methoden
| Clone() |
Überschreibt Klonbar. |
| Dispose() |
Ein |
| Dispose(Boolean) |
Ein |
| Equals(Object) |
Gibt an, ob ein anderes Objekt diesem "gleich" ist. (Geerbt von Object) |
| Filter(IList<Locale.LanguageRange>, ICollection<Locale>) |
Gibt eine Liste übereinstimmenden |
| Filter(IList<Locale.LanguageRange>, ICollection<Locale>, Locale+FilteringMode) |
Gibt eine Liste übereinstimmenden |
| FilterTags(IList<Locale.LanguageRange>, ICollection<String>) |
Gibt eine Liste übereinstimmenden Sprachentags mithilfe des in RFC 4647 definierten grundlegenden Filtermechanismus zurück. |
| FilterTags(IList<Locale.LanguageRange>, ICollection<String>, Locale+FilteringMode) |
Gibt eine Liste übereinstimmenden Sprachentags mithilfe des in RFC 4647 definierten grundlegenden Filtermechanismus zurück. |
| ForLanguageTag(String) |
Gibt ein Gebietsschema für die angegebene IETF BCP 47-Sprachtagzeichenfolge zurück. |
| GetAvailableLocales() |
Gibt ein Array aller installierten Gebietsschemas zurück. |
| GetDefault(Locale+Category) |
Ruft den aktuellen Wert des Standardgebietsschemas für diese instance des virtuellen Java-Computers ab. |
| GetDisplayCountry(Locale) |
Gibt den Namen des Landes dieses Gebietsschemas zurück, lokalisiert in |
| GetDisplayLanguage(Locale) |
Gibt den Namen der Sprache dieses Gebietsschemas zurück, lokalisiert in |
| GetDisplayName(Locale) |
Gibt den Sprachnamen, den Ländernamen und die Variante dieses Gebietsschemas zurück, lokalisiert in |
| GetDisplayScript(Locale) |
Gibt einen Namen für das Skript des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| GetDisplayVariant(Locale) |
Gibt einen Namen für den Variantencode des Gebietsschemas zurück, der für die Anzeige für den Benutzer geeignet ist. |
| GetExtension(Char) |
Gibt den Dem angegebenen Schlüssel zugeordneten Erweiterungswert (oder private Verwendung) zurück, oder NULL, wenn dem Schlüssel keine Erweiterung zugeordnet ist. |
| GetHashCode() |
Gibt einen Hashcodewert für das Objekt zurück. (Geerbt von Object) |
| GetISOCountries() |
Gibt eine Liste aller in ISO 3166 definierten 2-Buchstaben-Ländercodes zurück. |
| GetISOCountries(Locale+IsoCountryCode) |
Ein |
| GetISOLanguages() |
Gibt eine Liste aller 2-Buchstaben-Sprachcodes und einige der in ISO 639 definierten 3-Buchstaben-Codes zurück. |
| GetUnicodeLocaleType(String) |
Gibt den Unicode-Gebietsschematyp zurück, der dem angegebenen Unicode-Gebietsschemaschlüssel für dieses Gebietsschema zugeordnet ist. |
| JavaFinalize() |
Wird vom Garbage Collector für ein Objekt aufgerufen, wenn die Garbage Collection feststellt, dass keine Verweise mehr auf das Objekt vorhanden sind. (Geerbt von Object) |
| Lookup(IList<Locale.LanguageRange>, ICollection<Locale>) |
Gibt mithilfe des in RFC 4647 definierten Nachschlagemechanismus eine |
| LookupTag(IList<Locale.LanguageRange>, ICollection<String>) |
Gibt das am besten übereinstimmende Sprachtag mithilfe des in RFC 4647 definierten Nachschlagemechanismus zurück. |
| Notify() |
Aktiviert einen einzelnen Thread, der auf dem Monitor dieses Objekts wartet. (Geerbt von Object) |
| NotifyAll() |
Aktiviert alle Threads, die auf dem Monitor dieses Objekts warten. (Geerbt von Object) |
| SetDefault(Locale+Category, Locale) |
Legt das Standardgebietsschema für die angegebene Kategorie für diese instance des virtuellen Java-Computers fest. |
| SetHandle(IntPtr, JniHandleOwnership) |
Legt die Handle-Eigenschaft fest. (Geerbt von Object) |
| StripExtensions() |
Gibt eine Kopie davon |
| ToArray<T>() |
Ein |
| ToLanguageTag() |
Gibt ein wohlgeformte IETF BCP 47-Sprachtag zurück, das dieses Gebietsschema darstellt. |
| ToString() |
Gibt eine Zeichenfolgendarstellung dieses |
| UnregisterFromRuntime() |
Ein |
| Wait() |
Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel durch em benachrichtigen/em> oder <em>interrupted</em>.<>< (Geerbt von Object) |
| Wait(Int64) |
Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel, indem <er>benachrichtigt</em> oder <em>interrupted</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object) |
| Wait(Int64, Int32) |
Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel, indem <er>benachrichtigt</em> oder <em>interrupted</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object) |
Explizite Schnittstellenimplementierungen
| IJavaPeerable.Disposed() |
Ein |
| IJavaPeerable.DisposeUnlessReferenced() |
Ein |
| IJavaPeerable.Finalized() |
Ein |
| IJavaPeerable.JniManagedPeerState |
Ein |
| IJavaPeerable.SetJniIdentityHashCode(Int32) |
Ein |
| IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates) |
Ein |
| IJavaPeerable.SetPeerReference(JniObjectReference) |
Ein |
Erweiterungsmethoden
| JavaCast<TResult>(IJavaObject) |
Führt eine Für Android-Runtime überprüfte Typkonvertierung aus. |
| JavaCast<TResult>(IJavaObject) |
Ein |
| GetJniTypeName(IJavaPeerable) |
Ein |