安卓22开发文档翻译:语系,Locale
extends
Object
implements
Cloneable
Serializable
Locale 表示 的是,由语言/国家/变种组成的一个组合。语系 ( Locales ),用来改变某些信息 (例如数字 或日期 )的呈现方式, 以符合它们所代表的语言区域的习惯。
语言代码 ,是两个字母的小写 ISO语言代码(例如"en") ,由 ISO 639-1 定义。 国家码是两个字母的大写 ISO 国家代码 (例如"US") ,由 ISO 3166-1 定义。变种代码 ,未指定。
注意 , Java 用了若干个被废弃的两字母代码。 Hebrew ("he")语言代码 被重写为 "iw" , Indonesian ("id")重写 为 "in" , Yiddish ("yi")重写 为 "ji" 。即使 妳自己构造 Locale 对象 ,而不是得用各种查找方法来获取实例,也会发生这种重写。
这个类的构造函数不会进行错误检查。 妳可以针对不存在的语言 和国家来创建 Locale , 也可以针对不存在的语言和国家组合来创建实例 (例如,"de_US" ,用来表示 " 在US 国讲的 German语言") 。
注意,并非是对于这个类中预定义的所有语系常量都有对应的语系数据可用,只对于en_US有这个保证,这是唯一一个由Java 保证一定会可用的语系。
另一个错误就是,假设所有的设备都有相同的语系集合。在US 出售的设备,几乎可以肯定会支持en_US 和es_US,但是,并不一定会支持在其它国家所讲的相同语言(例如en_GB或es_ES),更不用说针对其它语言的语系(例如de_DE)。对于在Europe 出售的设备,可能就是相反的情况。
妳可使用 getDefault() 来获取针对妳的程序所运行于其上的设备的一个适当的语系,或者 ,使用 getAvailableLocales() 来获取妳的程序所运行于其上的设备上所有可用的语系。
注意 ,语系数据唯一地来自于 ICU 。用户提供 的语系服务提供者 ( 即,使用 java.text.spi 或 java.util.spi 机制) 是不被支持的。
下表列出的是在各个Android 版本中使用的ICU 版本(以及对应的CLDR和Unicode版本):
Android 1.5 (Cupcake)/Android 1.6 (Donut)/Android 2.0 (Eclair) |
ICU 3.8 |
||
Android 2.2 (Froyo) |
ICU 4.2 |
||
Android 2.3 (Gingerbread)/Android 3.0 (Honeycomb) |
ICU 4.4 |
||
Android 4.0 (Ice Cream Sandwich) |
|||
Android 4.1 (Jelly Bean) |
|||
Android 4.3 (Jelly Bean MR2) |
|||
Android 4.4 (KitKat) |
|||
Android 5.0 (Lollipop) |
|||
Android 6.0 (Marshmallow) |
注意,有狠多便利方法都会自动使用默认语系,然而,使用它们的时候可能会引起微妙的缺陷。
默认语系,如果只是用来向用户呈现数据的话,是足够的。在这种情况下,妳希望使用用户的以下东西:日期/时间格式;数字格式;小写转换规则;等等。在这种情况下,可以安全地使用那些便利方法。
默认语系 不 适合于用来产生机器可读的输出内容。最佳选择通常 是使用 Locale.US —— 这个语系, 会被确保在所有的设备上都可用,并且 ,事实上,它没有令人惊讶的特殊形态,而且 还狠常用 (尤其 是,对于机器与机器间的通信 ) ,这就意味着, 它也是最高效的选择。
一个常见的错误就是,在产生用来给机器阅读的输出内容时,隐式地使用了默认语系。这种情况,一般在开发者自己的设备上能够正常运行(尤其是因为,狠多开发者使用en_US),但是,当运行在一个具有更复杂语系的设备上时,就可能会出错。
举个例子, 当妳格式化整数的时候,某些语系 会使用非 ASCII 的二进制数字。 另一个例子,当妳格式化浮点数的时候,某些语系会使用 ',' 作为整数部分 和小数部分的分隔,而使用 '.' 来进行长数字分组。对于 人眼可读的输出来说,这是正确的,但是,如果传递 给另一个机器 ,就可能引发问题 (例如 , parseDouble(String) 就无法解析这样一个数字 ) 。另外 还要注意, 在使用不带 Locale 参数的 toLowerCase() 和 toUpperCase() 重载函数时,也要小心:例如 ,在 Turkey语言 中,字符 'i' 和 'I' 不会被转换为 'I' 和 'i' 。对于Turkish 文字(例如用户输入)来说,这是正确的行为 ,但是,对于其它东西(例如,HTTP 协议 头 )来说就不合适了。
自此版本开始引入 应用编程接口级别1
针对zh_CN 的语系常量。
自此版本开始引入 应用编程接口级别1
针对zh 的语系常量。
自此版本开始引入 应用编程接口级别9
针对根(root)语系的语系常量。根语系,拥有空白的语言、国家和变种。
自此版本开始引入 应用编程接口级别1
针对zh_CN 的语系常量。
自此版本开始引入 应用编程接口级别1
针对zh_TW 的语系常量。
自此版本开始引入 应用编程接口级别1
针对zh_TW 的语系常量。
自此版本开始引入 应用编程接口级别1
构造 一个针对指定语言和国家代码的 Locale 。
自此版本开始引入 应用编程接口级别1
构造 一个针对指定语言 、 国家和变种代码的 Locale 。
自此版本开始引入 应用编程接口级别1
返回针对 此语系的国家代码,或者 ,如果此语系并不对应于特定的国家,则返回 "" 。
自此版本开始引入 应用编程接口级别1
返回用户 的首选语系。 它可能已经被此进程通过 setDefault(Locale) 覆盖掉了。
由于用户的语系会动态改变,因此,应当避免对这个值进行缓存。正确的做法是,每次要使用时,都使用这个方法来获取。
自此版本开始引入 应用编程接口级别1
返回 此 Locale 的语言代码,或者,如果未设置任何语言,则返回空字符串。
自此版本开始引入 应用编程接口级别1
返回 此 Locale 的变种代码,或者,如果未设置任何变种,则返回一个空的 String 。
自此版本开始引入 应用编程接口级别1
覆盖掉默认语系。这并不会影响到系统的配置,并且,尝试覆盖掉系统提供的默认语系的话,可能反过来被系统配置中的变更所覆盖掉。调用此方法的代码通常是不正确的,应当修复,对于所调用的每个与语系相关的方法,都传入适当的语系参数。
超杀女
许晴
BeautyLeg
给人民一个胶带
HxLauncher: Launch Android applications by voice commands