Informationen zu CLDR-Gebietsschemadaten, die standardmäßig in Java 9 aktiviert sind

Überblick

Dies ist eine Studie zu CLDR-Gebietsschemadaten, die in Java 1.8 übernommen (aber standardmäßig deaktiviert) und in Java 9 standardmäßig aktiviert wurden. Sie können CLDR auf den als Referenz aufgeführten Websites überprüfen. Kurz gesagt, es handelt sich um ein Projekt, das beim Unicode-Konsortium durchgeführt wird und über unterschiedliche Gebietsschemas verfügt (Datumsformat, Datumsformat, weltweit). Währungsname, Ländername, Tagesliste, Zahlenformat usw.) werden in einer Datenbank gespeichert. Diese Daten werden in LDML (Locale Data Markup Language) im XML-Format verwaltet und veröffentlicht, und Java enthält diese Daten ebenfalls, wenn auch nicht vollständig.

Die Motivation für das Schreiben dieses Artikels ist Probleme und Lösungen, die durch die Migration der Nulab-Kontoinfrastruktur auf Java 9 verursacht werden. Nachdem ich den Artikel gelesen hatte, fragte ich mich, welche Art von Code sich auf den unten angegebenen Teil auswirken würde.

** Datums- und Währungsformate haben sich geändert ** Der automatisierte Test ist aufgrund einer Änderung des Laufzeitverhaltens zwischen Java 8 und 9 fehlgeschlagen.

Das Datumsformat ist internationalisiert. Dies liegt daran, dass Java 9 den Anfangswert der Internationalisierungserweiterung in CLDR (Common Locality Data Repository) geändert hat, den De-facto-Standard für die Internationalisierung, der vom Unicode-Konsortium (JEP 252) definiert wurde.

Umgebung

• Windows 10 Professional
• Oracle JDK 1.8.0_172
• OpenJDK 9.0.4
• OpenJDK 10.0.1

Referenz

• CLDR - Unicode Common Locale Data Repository
• Datums- und Uhrzeitformat in Java 9 nähert sich dem Unicode-Gebietsschema-Standard
• What is CLDR?

Unterschiede im Verhalten zwischen Java-Versionen

Ich habe kurz den Unterschied im Verhalten zwischen Versionen von Java 8 (Oracle JDK) / Java 9 (OpenJDK) / Java 10 (OpenJDK) untersucht.

Locale.toLanguageTag

Gibt ein wohlgeformtes IETF BCP 47-Sprach-Tag zurück, das dieses Gebietsschema darstellt.

Locale.getDefault().toLanguageTag();             // → (1)
new Locale("ja", "JP").toLanguageTag();          // → (2) 
new Locale("ja", "JP", "JP").toLanguageTag();    // → (3)

** Ausgabeergebnis **

Über das Gebietsschema ("ja", "JP", "JP") des speziellen Gebietsschemas

Locale (Java SE 10 & JDK 10) Um die Kompatibilität zu gewährleisten, werden zwei nicht konforme Gebietsschemas als Sonderfall behandelt. Dies sind ja_JP_JP und th_TH_TH.

In Java wurde ja_JP_JP verwendet, um den japanischen imperialen Kalender zusammen mit den in Japan verwendeten Japanern darzustellen. Dies wird jetzt mithilfe der Unicode-Gebietsschemaerweiterung dargestellt, indem der Unicode-Gebietsschema-Schlüssel ca (Kalender) angegeben und Japanisch eingegeben wird. Die Erweiterung u-ca-japanese wird automatisch hinzugefügt, wenn der Locale-Konstruktor mit den Argumenten "ja", "JP", "JP" aufgerufen wird.

Das "u-ca-japanese" im oben zitierten JavaDoc ist "u", was für die Unicode-Gebietsschemaerweiterung steht, und ein Schlüsselwort (Schlüssel / Typ-Paar), das das Standardverhalten des Gebietsschemas (in diesem Beispiel Kalender) überschreibt. ) Ist eine Kombination von "ca-japanese".

+----- U extension
| +--- Keyword (Key & Type)
| |
- -----------
u-ca-japanese
  ^^ ^^^^^^^^
  |  |
  |  +--- Type (japanese = Japanese Imperial calendar)
  +------ Key  (ca = Calendar algorithm)

Java 9 unterstützt zwei Arten von Schlüsseln (JEP 314: Zusätzliche Unicode-Sprach-Tag-Erweiterungen):

• ca (Calendar algorithm)
  • bcp47/calendar.xml
• nu (Numbering system)
  • bcp47/number.xml

Java 10 fügt vier Dinge hinzu:

• cu (Currency type)
  • bcp47/currency.xml
• fw (First day of week)
  • bcp47/calendar.xml
• rg (Region Override)
  • unicode_region_subtag
• tz (Time zone)
  • bcp47/timezone.xml

Überschreiben Sie den Währungstyp des Gebietsschemas

Es gibt eine Locale.forLanguageTag-Methode, aber Locale.Builder wird empfohlen. Verwenden Sie diesen Builder, um ein benutzerdefiniertes Gebietsschema zu generieren. Das folgende Beispiel zeigt, wie der Währungstyp für das japanische Gebietsschema mit US-Dollar überschrieben wird.

Locale locale = new Locale.Builder()
    .setLocale(Locale.getDefault())
    .setUnicodeLocaleKeyword("cu", "USD")
    .build();

System.out.println(locale.toLanguageTag());
// → ja-JP-u-cu-usd

Currency currency = Currency.getInstance(locale);
System.out.println(currency.getCurrencyCode());
// → USD
System.out.println(currency.getDisplayName());
//→ US-Dollar
System.out.println(currency.getSymbol());
// → $

double money = 123456789.12345;
NumberFormat formatter = NumberFormat.getCurrencyInstance(locale);
formatter.setMinimumFractionDigits(3);
System.out.println(formatter.format(money));
// → $123,456,789.123

Überschreiben Sie den ersten Wochentag im Kalender

Wie unten angegeben, können Sie den ersten Tag der Woche mit einem beliebigen Tag überschreiben, indem Sie das Unicode-Erweiterungsschlüsselwort "u-fw-xxx" angeben, wie in JavaDoc der Calendar-Klasse beschrieben.

Calendar (Java SE 10 & JDK 10)

Kalender Eine länderspezifische 7-Tage-Woche wird anhand von zwei Parametern definiert: dem ersten Wochentag und der Mindestanzahl von Tagen in der ersten Woche (1-7). Diese Nummern stammen aus den Ressourcendaten des Gebietsschemas, als der Kalender erstellt wurde, oder aus dem Gebietsschema selbst. Wenn das angegebene Gebietsschema "fw" und / oder "rg" "Unicode-Erweiterungen" enthält, wird der erste Wochentag entsprechend diesen Erweiterungen abgerufen.

Calendar calendar = Calendar.getInstance();
System.out.println(calendar.getCalendarType());
// → gregory
System.out.println(calendar.getFirstDayOfWeek());
// → 1 (Calendar.SUNDAY)

Locale locale = new Locale.Builder()
    .setLocale(Locale.getDefault())
    .setUnicodeLocaleKeyword("fw", "mon")
    .build();

System.out.println(locale.toLanguageTag());
// → ja-JP-u-fw-mon

Calendar calendar = Calendar.getInstance(locale);
System.out.println(calendar.getCalendarType());
// → gregory
System.out.println(calendar.getFirstDayOfWeek());
// → 2  (Calendar.MONDAY)

Datum und Datumsformat

Unicode-Gebietsschemaerweiterung (Hinzufügung von u-ca-japanese)

Locale locale = new Locale("ja", "JP", "JP");
Date now = new Date();
DateFormat.getDateInstance(DateFormat.FULL, locale).format(now);   // → (1)
DateFormat.getDateInstance(DateFormat.LONG, locale).format(now);   // → (2)
DateFormat.getDateInstance(DateFormat.MEDIUM, locale).format(now); // → (3)
DateFormat.getDateInstance(DateFormat.SHORT, locale).format(now);  // → (4)

Standardgebietsschema

Date now = new Date();
DateFormat.getDateInstance(DateFormat.FULL).format(now);           // → (5)
DateFormat.getDateInstance(DateFormat.LONG).format(now);           // → (6)
DateFormat.getDateInstance(DateFormat.MEDIUM).format(now);         // → (7)
DateFormat.getDateInstance(DateFormat.SHORT).format(now);          // → (8)

** Ausgabeergebnis **

Kalender und Datumsformat

Unicode-Gebietsschemaerweiterung (Hinzufügung von u-ca-japanese)

Locale locale = new Locale("ja", "JP", "JP");
Calendar now = Calendar.getInstance(locale);
DateFormat.getDateInstance(DateFormat.FULL, locale).format(now.getTime());   // → (1)
DateFormat.getDateInstance(DateFormat.LONG, locale).format(now.getTime());   // → (2)
DateFormat.getDateInstance(DateFormat.MEDIUM, locale).format(now.getTime()); // → (3)
DateFormat.getDateInstance(DateFormat.SHORT, locale).format(now.getTime());  // → (4)

Standardgebietsschema

Calendar now = Calendar.getInstance();
DateFormat.getDateInstance(DateFormat.FULL).format(now.getTime());           // → (5)
DateFormat.getDateInstance(DateFormat.LONG).format(now.getTime());           // → (6)
DateFormat.getDateInstance(DateFormat.MEDIUM).format(now.getTime());         // → (7)
DateFormat.getDateInstance(DateFormat.SHORT).format(now.getTime());          // → (8)

** Ausgabeergebnis **

LocalDateTime und DateTimeFormatter

Unicode-Gebietsschemaerweiterung (Hinzufügung von u-ca-japanese)

Locale locale = new Locale("ja", "JP", "JP");
LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL).withLocale(locale).format(now);    // → (1)
DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(locale).format(now);    // → (2)
DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM).withLocale(locale).format(now);  // → (3)
DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale).format(now);   // → (4)

Standardgebietsschema

LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL).format(now);     // → (5)
DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).format(now);     // → (6)
DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM).format(now);   // → (7)
DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).format(now);    // → (8)

** Ausgabeergebnis **

DateTimeFormatter.localizedBy

Die localizedBy-Methode ist eine in Java 10 eingeführte Methode. Wenn das Gebietsschema Unicode-Erweiterungen enthält, wird das Gebietsschema überschrieben. (Keine Nebenwirkungen auf Gebietsschemainstanzen)

Locale locale = new Locale("ja", "JP", "JP");
LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL).localizedBy(locale).format(now);    // → (1)
DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).localizedBy(locale).format(now);    // → (2)
DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM).localizedBy(locale).format(now);  // → (3)
DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).localizedBy(locale).format(now);   // → (4)

** Ausgabeergebnis **

Zonierte DateTime und DateTimeFormatter

Unicode-Gebietsschemaerweiterung (Hinzufügung von u-ca-japanese)

Locale locale = new Locale("ja", "JP", "JP");
ZonedDateTime now = ZonedDateTime.now();
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL, FormatStyle.FULL).withLocale(locale).format(now);     // → (1)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG, FormatStyle.LONG).withLocale(locale).format(now);     // → (2)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM, FormatStyle.MEDIUM).withLocale(locale).format(now); // → (3)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT, FormatStyle.SHORT).withLocale(locale).format(now);   // → (4)

Standardgebietsschema

ZonedDateTime now = ZonedDateTime.now();
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL, FormatStyle.FULL).format(now);      // → (5)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.LONG, FormatStyle.LONG).format(now);      // → (6)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM, FormatStyle.MEDIUM).format(now);  // → (7)
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT, FormatStyle.SHORT).format(now);    // → (8)

** Ausgabeergebnis **

Geben Sie ein beliebiges Muster an

Es gab keinen Unterschied zwischen den Versionen, wenn ein Muster erstellt wurde.

Locale locale = new Locale("ja", "JP", "JP");
LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofPattern("G yyyy-MM-dd (E) a HH:mm:ss.SSS", locale).format(now);                // → (1)
DateTimeFormatter.ofPattern("G yyyy-MM-dd (E) a HH:mm:ss.SSS").format(now);                        // → (2)
DateTimeFormatter.ofPattern("G yy-MM-dd (E) a HH:mm:ss.SSS").localizedBy(locale).format(now);      // → (3)

Locale locale = new Locale("ja", "JP", "JP");
ZonedDateTime now = ZonedDateTime.now();
DateTimeFormatter.ofPattern("G yyyy-MM-dd (E) a HH:mm:ss.SSS zzz", locale).format(now);            // → (4)
DateTimeFormatter.ofPattern("G yyyy-MM-dd (E) a HH:mm:ss.SSS zzz").format(now);                    // → (5)
DateTimeFormatter.ofPattern("G yy-MM-dd (E) a HH:mm:ss.SSS zzz").localizedBy(locale).format(now);  // → (6)

** Ausgabeergebnis **

Ergänzung

Unicode Technical Standard #35

UNICODE LOCALE DATA MARKUP LANGUAGE (LDML)

Übergang erweiterter Funktionen der Internationalisierung

Erweiterung der Internationalisierung in Java SE 6

Es gibt keine Beschreibung zu CLDR. Obwohl dies nichts mit CLDR zu tun hat, wird die japanische Geschichte in Java SE 6 unterstützt.

** Japanische Kalenderunterstützung **

Eine neue Kalenderimplementierung wurde hinzugefügt, um das Zählen im japanischen Kalender zu unterstützen, z. B. 2005 (Gregorio-Kalender) als 2005. Diese japanische Kalenderinstanz kann in der Calendar.getInstance-Factory durch Angabe des Gebietsschemas ("ja", "JP", "JP") erstellt werden. Die Klasse java.text.SimpleDateFormat unterstützt andere kalenderspezifische Jahres- und Datumsformate als den Gregorio-Kalender.

Locale locale = new Locale("ja", "JP", "JP");
Calendar calendar = Calendar.getInstance(locale);
System.out.println(calendar.getClass().getCanonicalName());
// → java.util.JapaneseImperialCalendar

System.out.println(new SimpleDateFormat("Gyy Jahr MM Monat dd Tag(E)", locale).format(calendar.getTime()));
//→ 25. Juni 2018(Mond)

Calendar calendar = Calendar.getInstance();
System.out.println(calendar.getClass().getCanonicalName());
// → java.util.GregorianCalendar

System.out.println(new SimpleDateFormat("Gyyyy Jahr MM Monat dd Tag(E)").format(calendar.getTime()));
//→ 25. Juni 2018(Mond)

Erweiterung der Internationalisierung in Java SE 7

** Die Lokalitätsklasse unterstützt BCP47 und UTR35 **

Die Locale-Klasse wurde aktualisiert, um austauschbare Bezeichner mit BCP 47 (IETF BCP 47 "Tags zum Identifizieren von Sprachen") und LDML für den Datenaustausch von Gebietsschemas (UTS # 35 "Unicode Locale Data Markup Language") zu implementieren. Unterstützt BCP 47-Kompatibilitätserweiterungen.

Erweiterung der Internationalisierung in JDK 8

** Übernahme von Unicode-CLDR-Daten und Systemeigenschaften von java.locale.providers **

Das Unicode-Konsortium hat das Common Locale Data Repository (CLDR) -Projekt veröffentlicht, um "die Sprachen der Welt mit dem größten und umfangreichsten Standard-Gebietsschema-Datenrepository zu unterstützen". CLDR wird zum De-facto-Standard für Gebietsschemadaten.

Die XML-basierten Gebietsschemadaten von CLDR sind in der JDK 8-Version enthalten, jedoch standardmäßig deaktiviert.

Standard

Das Standardverhalten entspricht den folgenden Einstellungen.

java.locale.providers=JRE,SPI

Erweiterung der Internationalisierung in JDK 9

** Standardmäßig aktivierte CLDR-Gebietsschemadaten **

Die XML-basierten Gebietsschemadaten für das Unicode Common Locale Data Repository (CLDR), das zuerst zu JDK 8 hinzugefügt wurde, sind die Standardgebietsschemadaten für JDK 9. In früheren Versionen war die Standardeinstellung JRE.

Standard

Wenn Sie diese Eigenschaft nicht festlegen, entspricht das Standardverhalten der folgenden Einstellung:

java.locale.providers=CLDR,COMPAT,SPI

• COMPAT (früher JRE)

Erweiterung der Internationalisierung in JDK 10

** Zusätzliche Unicode-Sprach-Tag-Erweiterungen **

Java SE 9 unterstützt nur die Erweiterungen -ca (Kalender) und -nu (numerisch). Java SE 10 bietet Unterstützung für die folgenden zusätzlichen Erweiterungen in den zugehörigen JDK-Klassen:

• -cu (Währungstyp)
• -fw (erster Tag der Woche)
• -rg (Region Override)
• -tz (Zeitzone)

In Java 9 behandelte Probleme

java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

Java 9 hat das Problem gelöst, dass eine Ausnahme auftritt, wenn "DD" in der Musterzeichenfolge angegeben wird, wenn die Gesamtzahl der Tage im Zieldatum 100 Tage oder mehr beträgt.

LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofPattern("D").format(now);
// → 177
DateTimeFormatter.ofPattern("DD").format(now);  // ← Java 1.Ausnahme in 8
// → 177
DateTimeFormatter.ofPattern("DDD").format(now);
// → 177

DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

In Java 1.8 wurde der Fehler, dass eine Ausnahme auftritt, wenn "yyyyMMddHHmmssSSS" in der Musterzeichenfolge angegeben ist, in Java 9 behoben.

LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS").format(now);
// → 20180625222024147

java.time.format.FormatStyle.LONG or FULL causes unchecked exception

Das Formatieren von LocalDateTime mit DateTimeFormatter.ofLocalizedDateTime (FormatStyle.FULL) löst eine Ausnahme aus, dies ist jedoch beabsichtigt und kein Problem.

LocalDateTime now = LocalDateTime.now();
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL).format(now);
// → Exception in thread "main" java.time.DateTimeException: Unable to extract ZoneId from temporal 2018-06-26T01:00:54.557262700

Im Falle von ZonedDateTime kann es problemlos formatiert werden.

ZonedDateTime now = ZonedDateTime.now();
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.FULL, FormatStyle.FULL).format(now);
//→ Montag, 25. Juni 2018, 22:24:57 Uhr japanische Standardzeit

Korrespondenz für andere Musterzeichenfolgen (Korrespondenz, die eher den CLDR-Spezifikationen als der Addition entspricht)

DateTimeFormatter pattern letters 'A','n','N' Add date-time patterns 'v' and 'vvvv' DateTimeFormatter pattern letter 'g' Incorrect documentation for DateTimeFormatter letter 'k'

Von Java 11 behandelte Probleme

Ich nehme auf, woran ich interessiert bin, daher sind hier nicht alle aufgelistet.

Japanese new era implementation Release Note: Japanese New Era Implementation

Dies ist eine Antwort auf die Überarbeitung, die am 1. Mai 2019 stattfinden wird. Momentan wird "New Era" in der Originalausgabe als vorläufige Maßnahme angezeigt.

Release Note: Update locale data to Unicode CLDR v33

CLDR-Daten auf Version 33 werden aktualisiert.