국제 프로그래밍에 직면했을 때 JavaScript에 대한 몇 가지 제안_기본 지식

국제화란 무엇인가요?

국제화(Internationalization의 약어는 i18n——i, 가운데 18자, n)는 다양한 곳의 사용자가 다양한 언어를 구사하는 사용자가 쉽게 사용할 수 있도록 소프트웨어를 처리하는 과정입니다. 사용자가 특정 지역 출신이고 특정 언어를 사용한다고 가정하면 실수로 오류 메시지가 나타날 수 있습니다. 특히 당신은 그런 가정조차 하지 않았기 때문에 더욱 그렇습니다.

function formatDate(d)
{
 // Everyone uses month/date/year...right?
 var month = d.getMonth() + 1;
 var date = d.getDate();
 var year = d.getFullYear();
 return month + "/" + date + "/" + year;
}
 
function formatMoney(amount)
{
 // All money is dollars with two fractional digits...right?
 return "$" + amount.toFixed(2);
}
 
function sortNames(names)
{
 function sortAlphabetically(a, b)
 {
 var left = a.toLowerCase(), right = b.toLowerCase();
 if (left > right)
  return 1;
 if (left === right)
  return 0;
 return -1;
 }
 
 // Names always sort alphabetically...right?
 names.sort(sortAlphabetically);
}

JavaScript의 과거 i18n 지원은 형편없었습니다

기존 JS i18n 프로그램은 형식화를 위해 toLocaleString() 메서드를 사용합니다. 결과 문자열에는 구현 자체에서 제공하는 모든 세부 정보가 포함되어 있습니다. 직접 선택할 수 있는 방법은 없습니다(해당 날짜 형식의 평일이 정말로 필요합니까? 연도는 관련이 없습니까?). 해당 내용이 포함되어 있더라도 백분율을 기대했는데 숫자가 나오는 등 형식이 잘못될 수 있습니다. 그리고 아직 로케일을 선택할 수 없습니다.

정렬을 위해 JS는 기본적으로 쓸모없는 로케일 구분 텍스트 비교 기능을 제공합니다. localeCompare()가 존재하지만 해당 인터페이스가 정렬에 전혀 적합하지 않습니다. 또한 지역 설정이나 정렬 방법을 선택할 수 없습니다.

이러한 제한은 끔찍합니다(이 사실을 깨닫고 충격을 받았습니다!). 왜냐하면 i18n 지원이 필요한 심각한 웹 애플리케이션(보통 통화 표시를 위한 금융 사이트)은 데이터를 패키지하여 서버로 전송하고 서버는 이를 처리하기 때문입니다. 작업을 수행한 다음 클라이언트로 다시 전송합니다. 통화 금액을 처리하기 위해서만 데이터가 서버와 주고받습니다. 응.

새로운 JS 국제화 API

새로운 ECMAScript 국제화 API는 JS의 i18n 기능을 크게 향상시킵니다. 날짜, 숫자 및 텍스트 정렬 형식을 지정하는 상상할 수 있는 모든 방법을 제공합니다. 로케일은 선택 사항이며 요청한 로케일이 지원되지 않는 경우 대체될 수 있습니다. 형식 지정 요청은 포함할 특정 구성 요소를 지정할 수 있습니다. 사용자 정의된 백분율, 유효 숫자 및 통화 형식을 지원합니다. 텍스트 정렬을 위한 다양한 정렬 옵션을 엽니다. 성능이 우려되는 경우 첫 번째 작업은 로케일을 선택한 다음 옵션 매개변수를 처리하는 것입니다. 이제 이 작업은 로케일 관련 작업이 수행될 때마다 한 번씩 수행되는 대신 한 번만 처리됩니다.

이 API가 만병통치약이라는 말은 아니고 그냥 "최선을 다해 보세요"라는 뜻입니다. 정확한 출력은 거의 항상 의도적으로 지정되지 않습니다. 구현은 합법적인 oj 로케일만 지원하거나 제공된 형식 지정 옵션을 거의 모두 무시할 수 있습니다. 대부분의 구현에는 고품질 다중 지역 지원이 포함되지만 보장되지는 않습니다(특히 휴대폰과 같이 리소스가 제한된 시스템의 경우).

내부적으로 Firefox의 구현은 유니코드 ICU(International Component Library)에 의존하며, 이는 다시 유니코드 CLDR(Unicode Common Regional Data Repository) 지역 데이터 세트에 의존합니다. 우리의 구현은 자체 호스팅됩니다. ICU를 기반으로 하는 대부분의 구현은 JS로 작성됩니다. 도중에 몇 가지 문제에 직면했지만(이렇게 대규모로 자체 호스팅한 적은 없었습니다) 대부분 사소한 문제였습니다.

Intl 인터페이스(숫자 1이 아닌 문자 l)

i18n은 Intl 객체 위에 존재합니다. Intl에는 Intl.Collator, Intl.DateTimeFormat 및 Intl.NumberFormat이라는 3개의 생성자가 포함되어 있습니다. 각 생성자는 관련 작업을 제공하고 해당 작업에 대한 로케일과 옵션을 효율적으로 캐싱하는 개체를 만듭니다. 다음과 같이 개체를 만듭니다.

var ctor = "Collator"; // 或其他 
var instance = new Intl[ctor](locales, options);

locales 是个字符串，指定单个语言标签，或者包含多个语言标签的类数组对象。语言标签如下面的字符串：en(普通英语)，de-AT(奥地利德语)，zh-Hant-TW(台湾使用的繁体中文)。语言标签可以包含一个“Unicode扩展”，形式为-u-key1-value1-key2-value2..., 其中每个key是“扩展key”。不同的构造函数对此进行具体解释。

opions 是个对象，其属性(如果不存在，就赋值为undefined)决定格式化器(formatter)和整理器(collator)的行为。精确的解释由构造函数决定。

给定区域信息和选项，实现会尝试生成近似理想行为的最接近行为。Firefox 支持用于整理(collation)的400+区域，用于date/time和数字格式化的600+区域，所以很可能(但不保证)你想要的区域是被支持的。

Intl 通常不保证某些特定行为。如果请求的区域不被支持，Intl 允诺“尽最大努力”的行为。即使区域是被支持的，行为也不是严格指定的。永远不要假设特定的选项集适用于某个特定格式。(围绕请求的组件)总体格式的用语可能因浏览器甚至浏览器的版本而不同。单个组件的格式是未指定的：weekday的短格式可以为“S”, “Sa”, 或“Sat”。Intl API并不用于公开精确的特定行为。

选项

date/time格式化的主要选项属性如下：

•     weekday, era

    "narrow", "short", or "long".  (era通常指历法系统中长于一年的分段，如现行日皇统治, 或者其他纪年法)

•     month

    "2-digit", "numeric", "narrow", "short", or "long"

•     year
•     day
•     hour, minute, second

    "2-digit" or "numeric"

•     timeZoneName

    "short" or "long"

•     timeZone

    区分大小写的"UTC"通过对应的toUTC进行格式化。有些值如"CEST"和"America/New_York"不是必须被支持的，它们确实在当前Firefox下没有效果。

这些值并不映射到特定格式：记住Intl API几乎不指定精确的行为。Intl的目的，举例来说是"narrow", "short", 和"long"生成对应大小的“S”/“Sa”, “Sat”, 和“Saturday”(输出可能不太准确，因为Saturday和Sunday都可以生成“S”)。  "2-digit"和"numeric"映射到2位数字的字符串或者全长度的数字字符串，如“70”和“1970”。

最终使用的选项大部分是请求的选项。但是，如果你不指定请求的 weekday/year/month/day/hour/minute/second，那么 year/month/day 将会被加入到你提供的选项。

除此之外，还有些特殊的选项：

•     hour12

    指定hour采用12小时还是24小时格式。默认通常是依赖于区域设置的(某些细节，如午夜是0点，还是12点，以及是否存在前导0，都是依赖于区域设置的)。

还有另外2种特殊属性，localeMatcher (可选"lookup"或"best fit") 和formatMatcher (可选"basic"或"best fit")，两者默认值都是"best fit"。这些会影响正确的区域设置和格式的选取。它们的用例可能比较难懂，就不赘述了。
区域设置相关选项

DateTimeFormat也允许通过自定义历法和数字系统来格式化。具体细节存在于区域设置，所以它们可以在语言标签的Unicode扩展中找到。

例如，泰国的泰语中语言标签为th-TH。回一下Unicode扩展的格式-u-key1-value1-key2-value2....  历法系统的key是ca, 数字系统的key时nu。泰语数字系统值为thai，中文历法系统值为chinese。因此用大体这样的方式来格式化date，我们把包含这些key/value对的Unicode追加到语言标签上去：th-TH-u-ca-chinese-nu-thai。

关于更多历法和数字系统的信息，查看DateTimeFormat的完整文档。
举例

创建DateTimeFormat对象后，下一步是通过方便的format()函数来格式化date。更方便的是，这个函数是有界函数(bound function)：你不必在DateTimeFormat上直接调用。之后给它传递一个时间戳或者Date对象。

总结一下，下文是如何为特定用途创建DateTimeFormat选项的例子(在当前Firefox执行行为下)。
 

var msPerDay = 24 * 60 * 60 * 1000; 
 
// July 17, 2014 00:00:00 UTC.
var july172014 = new Date(msPerDay * (44 * 365 + 11 + 197));

我们来格式化美国英语的date。我们先创建一个2位数字的month/day/year, 加上2位数字的hours/minutes, 还有一个短时区来确定这个时间。(结果肯定因不同时区而明显不同)
 

var options =
 { year: "2-digit", month: "2-digit", day: "2-digit",
 hour: "2-digit", minute: "2-digit",
 timeZoneName: "short" };
var americanDateTime =
 new Intl.DateTimeFormat("en-US", options).format; 
 
print(americanDateTime(july172014)); // 07/16/14, 5:00 PM PDT

或者类似的，对葡萄牙语，最好是巴西使用的葡语，但是用在葡萄牙作品中的。格式会稍长，因为包含完整的year和正式拼写的month，但是因移植性要转成UTC格式。
 

var options =
 { year: "numeric", month: "long", day: "numeric",
 hour: "2-digit", minute: "2-digit",
 timeZoneName: "short", timeZone: "UTC" };
var portugueseTime =
 new Intl.DateTimeFormat(["pt-BR", "pt-PT"], options); 
 
// 17 de julho de 2014 00:00 GMT
print(portugueseTime.format(july172014));

那对于一个压缩的，UTC格式的瑞士火车每周调度表？我们尝试用正式语言按流行度从大到小来选择最易读的一个。
 

var swissLocales = ["de-CH", "fr-CH", "it-CH", "rm-CH"];var options =
 { weekday: "short",
 hour: "numeric", minute: "numeric",
 timeZone: "UTC", timeZoneName: "short" };
var swissTime =
 new Intl.DateTimeFormat(swissLocales, options).format; 
 
print(swissTime(july172014)); // Do. 00:00 GMT

或者我们尝试某个日本博物馆里的一幅画中的描述性文本中的date，这个date使用日本的year和era历法。
 

var jpYearEra =
 new Intl.DateTimeFormat("ja-JP-u-ca-japanese",
       { year: "numeric", era: "long" }); 
 
print(jpYearEra.format(july172014)); // 平成26年

对一些完全不同的、更长的date，用于泰国泰语，但是使用泰语数字系统和中国历法。(类似Firefox的高质量实现通常会将普通的th-TH当做th-TH-u-ca-buddhist-nu-latn, 因为泰国使用佛历系统和拉丁0-9数字)。
 

var options =
 { year: "numeric", month: "long", day: "numeric" };
var thaiDate =
 new Intl.DateTimeFormat("th-TH-u-nu-thai-ca-chinese", options); 
 
print(thaiDate.format(july172014)); // ?? 6 ??

撇开历法和数字系统，还是很简单的。只要选取自己的组件和长度。
 
选项

数字格式化的主要选项属性有：

•     style

    "currency", "percent", or "decimal" (默认值).

•     currency

    3字母货币代码，如USD、CHF。需要style是"currency", 不然没有意义

•     currencyDisplay

    "code", "symbol", or "name", 默认为"symbol".  "code"使用格式字符串的3字母货币代码。"symbol"使用货币符号，如$或￡。"name"通常使用某些正式拼写版本的货币。(Firefox 目前仅支持"symbol", 这个问题不就就修复)

•     minimumIntegerDigits

    范围1到21(包含)的整数，默认为1。结果字符串的整数部分如果没有这么长，它前面会用0来填充。  (若这个值为2，那么3的格式化形式为“03”。)

•     minimumFractionDigits, maximumFractionDigits

    0-20(包含)的整数。结果字符串至少minimumFractionDigits, 至多maximumFractionDigits个有效数字。如果style是"currency"，默认最小值跟货币有关(通常是2，很少0或者3)，不然就是0。默认最大值，百分比是0，数字是3，货币的最大值跟货币有关。

•     minimumSignificantDigits, maximumSignificantDigits

    1-21(包含)的整数。如果有，它们将会覆盖上文关于整数/分数的对数字的控制，而由它们以及数字的要求长度，共同确定格式化的数字字符串中最小/最大有效数字的值。 (注意对10的倍数，有效数字可能不准确，如100，它的1，2，3位有效数字。)

•     useGrouping

    布尔值(默认true)决定格式化字符串是否包含分组分隔符(如，英语的千分隔符“,”)。

NumberFormat还识别难懂的、大多数可忽略的localeMatcher属性。

区域化选项

在Unicode扩展中，使用nu关键字可以使DateTimeFormat支持自定义数字系统，NumberFormat也是这样。 例如，在中国，中文的语言标签是zh-CN。 汉语十进制数字系统对应的值是hanidec。 为了格式化这些系统的数字，我们在这些语言标签上添加一些Unicode扩展：zh-CN-u-nu-hanidec。

关于不同数字系统标识的完整信息，见NumberFormat详细说明文档。

示例

NumberFormat对象有一个 format方法，这一点和 DateTimeFormat相同。 format方法是一个有界函数，它有时可以独立于 NumberFormat使用。

下面是在当前Firefox环境下为特定用途创建NumberFormat选项的例子。首先，我们来格式化中国大陆中文的货币格式，特别是使用汉字数字(而不是更普遍的拉丁数字)。选择"currency" style, 然后使用renminbi(yuan)的货币代码，数字分组默认，小数部分数字采用通常做法。
 

var tibetanRMBInChina =
 new Intl.NumberFormat("zh-CN-u-nu-hanidec",
      { style: "currency", currency: "CNY" }); 
print(tibetanRMBInChina.format(1314.25)); // ￥ 一,三一四.二五

或者我们来格式化美国的天然气价格，千分位有个古怪的9，用在美国英语中。
 

var gasPrice =
 new Intl.NumberFormat("en-US",
      { style: "currency", currency: "USD",
       minimumFractionDigits: 3 }); 
print(gasPrice.format(5.259)); // $5.259

或者我们尝试埃及的阿拉伯语中的百分比。确定百分比有至少2个有效数字。(注意这个以及其他RTL例子可能在RTL上下文出现的顺序不一样，如?????? 而不是??????，RTL/right to left，从右到左的)
 

var arabicPercent =
 new Intl.NumberFormat("ar-EG",
      { style: "percent",
       minimumFractionDigits: 2 }).format; 
print(arabicPercent(0.438)); // ??????

或者假设我们格式化阿富汗波斯语，我们期望至少2位的整数部分，至多2位的小数部分。
 

var persianDecimal =
 new Intl.NumberFormat("fa-AF",
      { minimumIntegerDigits: 2,
       maximumFractionDigits: 2 }); 
print(persianDecimal.format(3.1416)); // ?????

最后，我们格式化巴林的阿拉伯语中的巴林第纳尔的数量。不同于大部分货币，巴林第纳尔等于1000费尔，因此我们需要三位小数位。(再次注意，不要太过相信表面的阅读顺序)？
 

var bahrainiDinars =
 new Intl.NumberFormat("ar-BH",
      { style: "currency", currency: "BHD" }); 
print(bahrainiDinars.format(3.17)); // ?.?.? ?????

整理
选项

下面是整理的主要选项属性：

•     usage

    "sort" or "search" (默认"sort"), 指定整理器(collator)的目的。(查找整理器可能比排序整理器更多考虑字符串是否相等。)

•     sensitivity/敏感性

    "base", "accent", "case", or "variant"。这个选项影响整理器对基本字符相同但是重音/变音不同的字符的敏感性。(基本字符与区域设置有关：“a”和“?”在德语中基本字符相同，但是瑞典语中是不同的。)  "base"敏感性只考虑基本字符，忽略各种变体(如德语中“a”, “A”,和“?”被认为是相同的)。 "accent"敏感性考虑基本字符和重音，但是忽略大小写(如德语中的“a和“A”是相同的，“?”与两者不同)。"case"考虑基本字符和大小写，而忽略重音(如德语中的“a”和“?”相同，而与“A”不同)。"variant"考虑基本字符、重音、大小写(如德语的“a”, “?”和“A”均不同)。如果usage是"sort"，默认"variant"; 否则与区域设置有关。

•     numeric

    默认false的布尔值，决定字符串中的数字是否被当做数字参与比较。如当做数字的排序结果可能是"F-4 Phantom II", "F-14 Tomcat", "F-35 Lightning II"; 不当做数字的结果"F-14 Tomcat", "F-35 Lightning II", "F-4 Phantom II".

•     caseFirst

    "upper", "lower", or "false" (默认)。决定比较时是否考虑大小写："upper"把大写放在前面("B", "a", "c"), "lower"把小写放前面("a", "c", "B"), "false"完全忽略大小写("a", "B", "c")。 (注意，目前Firefox完全忽略这个属性)

•     ignorePunctuation

    默认false的布尔值。决定比较时是否忽略标点(如"biweekly"和"bi-weekly"是否相等)。

localeMatcher属性你可以忽略了。

区域相关选项

区域的Unicode扩展部分指定的整理器主要选项是co，它选择排序操作的方式：电话本(phonebk), 字典 (dict), 还有其他。

另外，kn和kf这两个key可以选择拷贝选项对象的numeric和caseFirst属性。但是并不保证可用于语言标签，而且选项比语言标签的组件更清晰。所以最好在选项内部进行调整。

key-value对(paris)嵌入到Unicode的方式跟DateTimeFormat和NumberFormat相同; 想知道如何在语言标签中指定它们，可以查看对应的章节。

举例

整理器Collator对象有个比较函数属性。这个函数接受2个参数x和y, 如果x6a026eaa792646456731363697f99c09y返回正值，x==y返回0。对于格式化函数，比较是个有界函数(bound function)，可以抽取出来做其他用途。

我们尝试来给德国德语的姓氏进行排序。德语中实际上有2种排序方式，电话本和字典。电话本排序强调读音，比如“?”, “?”等近似被扩展成“ae”, “oe”等。
 

var names =
 ["Hochberg", "H?nigswald", "Holzman"]; 
var germanPhonebook = new Intl.Collator("de-DE-u-co-phonebk"); 
 
//就像对["Hochberg", "Hoenigswald", "Holzman"]排序
// Hochberg, H?nigswald, Holzman
print(names.sort(germanPhonebook.compare).join(", "));

有些德语单词使用变音符进行词形变化，所以在字典中排序会忽略变音符(除了两个单词仅仅变音符不同：schon，sch?n)。
 

var germanDictionary = new Intl.Collator("de-DE-u-co-dict"); 
 
//就像对["Hochberg", "Hoenigswald", "Holzman"]排序
// Hochberg, H?nigswald, Holzman
print(names.sort(germanDictionary.compare).join(", "));

或者我们来对美国英语的Firefox的版本进行排序，这些字符串故意打错(大小写不同，随机重音，变音标记，额外的连字符)。我们希望根据版本号进行排序，所以要做numeric排序，这样字符串中的数字才会作为数字参与比较，而不是逐字符的。
 

var firefoxen =
 ["FireF?x 3.6",
 "Fire-fox 1.0",
 "Firefox 29",
 "Fírefox 3.5",
 "Fírefox 18"]; 
var usVersion =
 new Intl.Collator("en-US",
     { sensitivity: "base",
      numeric: true,
      ignorePunctuation: true }); 
 
// Fire-fox 1.0, Fírefox 3.5, FireF?x 3.6, Fírefox 18, Firefox 29
print(firefoxen.sort(usVersion.compare).join(", "));

最后，我们来做跟区域有关的字符串查找，查找忽略大小写和重音，并用于美国英语。

 

// Comparisons work with both composed and decomposed forms.
var decoratedBrowsers =
 [
 "A\u0362maya", // A?maya
 "CH\u035Br?me", // CH?r?me
 "Firefóx",
 "sAfàri",
 "o\u0323pERA", // ?pERA
 "I\u0352E",  // I?E
 ]; 
var fuzzySearch =
 new Intl.Collator("en-US",
     { usage: "search", sensitivity: "base" }); 
function findBrowser(browser)
{
 function cmp(other)
 {
 return fuzzySearch.compare(browser, other) === 0;
 }
 return cmp; 
} 
print(decoratedBrowsers.findIndex(findBrowser("Firêfox"))); // 2 
print(decoratedBrowsers.findIndex(findBrowser("Saf?ri"))); // 3 
print(decoratedBrowsers.findIndex(findBrowser("?maya"))); // 0 
print(decoratedBrowsers.findIndex(findBrowser("?pera"))); // 4 
print(decoratedBrowsers.findIndex(findBrowser("Chromè"))); // 1 
print(decoratedBrowsers.findIndex(findBrowser("I?")));  // 5

琐碎

检测某个操作是否支持特定区域，或者一个区域是否被支持，会很有用。Intl在每个构造函数上都提供了supportedLocales()函数，在每个原型上提供了resolvedOptions()函数来公开这些信息。
 

var navajoLocales =
 Intl.Collator.supportedLocalesOf(["nv"], { usage: "sort" });
print(navajoLocales.length > 0
  ? "Navajo collation supported"
  : "Navajo collation not supported"); 
var germanFakeRegion =
 new Intl.DateTimeFormat("de-XX", { timeZone: "UTC" });
var usedOptions = germanFakeRegion.resolvedOptions();
print(usedOptions.locale); // de
print(usedOptions.timeZone); // UTC

遗留行为

ES5的toLocaleString和localeCompar函数之前没有特定语义，不接受特定选项，基本上没有任何用处。因此i18n API根据Intl操作重组了它们。现在每个方法都接受附加的尾随locales和options参数，它们会像Intl构造函数一样被解释。(除了toLocaleTimeString 和 toLocaleDateString, 如果options没有，它们就会使用不同的默认组件)

对并不关心精确行为的简单应用，这没关系，老方法也可以用。但是如果需要更多控制或者多次格式化、比较的话，最好直接使用Intl。