本地化 支援是指應用程式尊重關於字母、排序、數字格式等的文化偏好。PostgreSQL 使用標準 ISO C 和POSIX由伺服器作業系統提供的本地化功能。如需更多資訊,請參考您系統的文件。
當使用 initdb
建立資料庫叢集時,會自動初始化本地化支援。initdb
預設會使用其執行環境的本地化設定來初始化資料庫叢集,因此如果您的系統已經設定為在資料庫叢集中使用您想要的本地化,則您無需執行任何其他操作。如果您想使用不同的本地化(或者您不確定您的系統設定為哪種本地化),您可以透過指定 --locale
選項來指示 initdb
確切要使用的本地化。例如
initdb --locale=sv_SE
此範例適用於 Unix 系統,將本地化設定為瑞典語 (sv
),如在瑞典 (SE
) 所使用的。其他可能性可能包括 en_US
(美國英語) 和 fr_CA
(加拿大法語)。如果多個字元集可用於某個本地化,則規格可以採用 language_territory.codeset
格式。例如,fr_BE.UTF-8
代表在比利時 (BE) 使用的法語 (fr),使用UTF-8字元集編碼。
您的系統上可用的本地化以及其名稱取決於作業系統供應商提供的內容以及已安裝的內容。在大多數 Unix 系統上,命令 locale -a
將提供可用本地化的列表。Windows 使用更詳細的本地化名稱,例如 German_Germany
或 Swedish_Sweden.1252
,但原理相同。
有時將多個本地化的規則混合使用會很有用,例如,使用英語排序規則但使用西班牙語訊息。為了支援這一點,存在一組本地化子類別,它們僅控制本地化規則的某些方面
LC_COLLATE |
字串排序順序 |
LC_CTYPE |
字元分類(什麼是字母?它的大寫形式是什麼?) |
LC_MESSAGES |
訊息的語言 |
LC_MONETARY |
貨幣金額的格式 |
LC_NUMERIC |
數字的格式 |
LC_TIME |
日期和時間的格式 |
類別名稱會轉換為 initdb
選項的名稱,以覆寫特定類別的本地化選擇。例如,要將本地化設定為加拿大法語,但使用美國規則來格式化貨幣,請使用 initdb --locale=fr_CA --lc-monetary=en_US
。
如果您希望系統表現得好像沒有本地化支援,請使用特殊本地化名稱 C
,或等效地使用 POSIX
。
某些本地化類別必須在建立資料庫時固定其值。您可以為不同的資料庫使用不同的設定,但一旦建立資料庫,您就無法再變更該資料庫的設定。LC_COLLATE
和 LC_CTYPE
是這些類別。它們會影響索引的排序順序,因此必須保持固定,否則文字欄位上的索引將會損毀。(但是您可以透過使用排序規則來緩解此限制,如 第 23.2 節中所討論的。)這些類別的預設值是在執行 initdb
時確定的,並且在建立新資料庫時會使用這些值,除非在 CREATE DATABASE
命令中另有指定。
其他本地化類別可以隨時變更,只需設定與本地化類別名稱相同的伺服器組態參數(請參閱 第 19.11.2 節 以了解詳細資訊)。initdb
選擇的值實際上只會寫入組態檔案 postgresql.conf
中,以在伺服器啟動時用作預設值。如果您從 postgresql.conf
中移除這些指定,則伺服器將繼承其執行環境的設定。
請注意,伺服器的本地化行為由伺服器看到的環境變數決定,而不是由任何用戶端的環境決定。因此,請務必在啟動伺服器之前設定正確的本地化設定。這樣做的結果是,如果用戶端和伺服器設定在不同的本地化中,則訊息可能會以不同的語言顯示,具體取決於它們的來源。
當我們談論從執行環境繼承本地化時,這意味著在大多數作業系統上:對於給定的本地化類別,例如排序規則,會依此順序查詢以下環境變數,直到找到已設定的變數:LC_ALL
、LC_COLLATE
(或對應於各種類別的變數)、LANG
。如果未設定這些環境變數,則本地化預設為 C
。
某些訊息本地化程式庫也會查看環境變數 LANGUAGE
,該變數會覆寫所有其他本地化設定,以設定訊息的語言。如有疑問,請參閱您的作業系統的文件,特別是有關 gettext 的文件。
為了讓訊息能夠翻譯成使用者偏好的語言,NLS必須在建置時選取 (configure --enable-nls
)。所有其他locale支援都會自動內建。
locale設定會影響下列SQL功能
在 PostgreSQL 中使用 C
或 POSIX
以外的 locale 的缺點是其效能影響。它會減慢字元處理速度,並阻止 LIKE
使用一般索引。因此,只有在實際需要時才使用locale。
作為一種變通方法,允許 PostgreSQL 在非 C locale 下使用帶有 LIKE
子句的索引,存在多個自訂運算子類別。 這些允許建立執行嚴格的字元比字元比較的索引,忽略locale比較規則。 有關更多資訊,請參閱第 11.10 節。另一種方法是使用 C
校對建立索引,如第 23.2 節中所討論的。
可以根據需求在不同的範圍內選取locale。 上面的概述顯示了如何使用 initdb
指定locale來設定整個叢集的預設值。 以下清單顯示了可以選取locale的位置。 每個項目都為後續項目提供預設值,並且每個較低的項目都允許以更精細的粒度覆寫預設值。
如上所述,作業系統的環境為新初始化的資料庫叢集的locale提供預設值。 在許多情況下,這就足夠了:如果作業系統配置為所需的語言/地區,則依預設,PostgreSQL 也會根據該locale執行。
如上所示,initdb
的命令列選項指定了新初始化資料庫叢集的locale設定。 如果作業系統沒有您希望用於資料庫系統的locale配置,請使用此選項。
可以為每個資料庫單獨選取locale。 SQL 命令 CREATE DATABASE
及其命令列等效命令 createdb
具有此選項。 例如,如果資料庫叢集包含具有不同要求的複數個租戶的資料庫,請使用此選項。
可以為單個資料表欄位進行locale設定。 這使用名為 collation 的 SQL 物件,並在第 23.2 節中進行說明。 例如,使用它來對不同語言的資料進行排序,或自訂特定資料表的排序順序。
最後,可以為單個查詢選取locale。 同樣,這使用 SQL collation 物件。 這可用於根據執行階段選擇更改排序順序,或用於特別實驗。
locale提供者指定哪個函式庫定義 collation 和字元分類的locale行為。
選取locale設定的命令和工具(如上所述)各自具有一個選取locale提供者的選項。 這是一個使用 ICU 提供者初始化資料庫叢集的範例
initdb --locale-provider=icu --icu-locale=en
有關詳細資訊,請參閱各個命令和程式的說明。 請注意,您可以在不同的粒度上混合locale提供者,例如預設情況下為叢集使用 libc
,但擁有一個使用 icu
提供者的資料庫,然後在這些資料庫中使用任一提供者的collation物件。
無論locale提供者如何,作業系統仍用於提供一些locale感知行為,例如訊息(請參閱lc_messages)。
可用的locale提供者如下所示
builtin
builtin
提供者使用內建的操作。 此提供者僅支援 C
和 C.UTF-8
locale。
C
locale行為與 libc 提供者中的 C
locale 相同。 使用此locale時,行為可能取決於資料庫編碼。
C.UTF-8
locale 僅在資料庫編碼為 UTF-8
時可用,並且該行為基於 Unicode。 collation 僅使用程式碼點值。 正規表示式字元類別基於“POSIX 相容”語意,大小寫對應是“簡單”變體。
icu
icu
提供者使用外部 ICU 函式庫。PostgreSQL 必須已配置支援。
ICU 提供與作業系統和資料庫編碼無關的 collation 和字元分類行為,如果您希望轉換到其他平台而不會更改結果,則這是首選。 可以獨立於 ICU locale 設定 LC_COLLATE
和 LC_CTYPE
。
對於 ICU 提供者,結果可能取決於所使用的 ICU 函式庫的版本,因為它會更新以反映自然語言隨時間的變化。
libc
libc
提供者使用作業系統的 C 函式庫。 collation 和字元分類行為由設定 LC_COLLATE
和 LC_CTYPE
控制,因此它們不能獨立設定。
使用 libc 提供者時,相同的locale名稱在不同的平台上可能具有不同的行為。
locale名稱的 ICU 格式是語言標籤。
CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP'); CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');
當使用 ICU 作為提供者定義新的 ICU collation 物件或資料庫時,如果給定的locale名稱尚未採用該形式,則會將其轉換(“正規化”)為語言標籤。 例如,
CREATE COLLATION mycollation3 (provider = icu, locale = 'en-US-u-kn-true'); NOTICE: using standard form "en-US-u-kn" for locale "en-US-u-kn-true" CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8'); NOTICE: using standard form "de-DE" for locale "de_DE.utf8"
如果您看到此通知,請確保 provider
和 locale
是預期的結果。為了在使用 ICU 提供者時獲得一致的結果,請指定標準的語言標籤,而不是依賴轉換。
沒有語言名稱的地區設定,或特殊的語言名稱 root
,將轉換為具有語言 und
("未定義")。
ICU 可以將大多數 libc 地區設定名稱,以及其他一些格式,轉換為語言標籤,以便更輕鬆地過渡到 ICU。 如果在 ICU 中使用 libc 地區設定名稱,它的行為可能與 libc 中不完全相同。
如果在解釋地區設定名稱時出現問題,或者地區設定名稱表示 ICU 無法識別的語言或區域,您將看到以下警告:
CREATE COLLATION nonsense (provider = icu, locale = 'nonsense'); WARNING: ICU locale "nonsense" has unknown language "nonsense" HINT: To disable ICU locale validation, set parameter icu_validation_level to DISABLED. CREATE COLLATION
icu_validation_level 控制訊息的報告方式。 除非設定為 ERROR
,否則仍然會建立排序規則,但其行為可能不是使用者想要的。
語言標籤定義於 BCP 47 中,是用於識別語言、區域以及有關地區設定的其他資訊的標準化識別碼。
基本的語言標籤只是 language
-
region
; 甚至只是 language
。language
是一個語言代碼(例如,fr
代表法語),而 region
是一個區域代碼(例如,CA
代表加拿大)。 範例: ja-JP
、de
或 fr-CA
。
排序規則設定可以包含在語言標籤中,以自訂排序規則的行為。 ICU 允許廣泛的自訂,例如對重音、大小寫和標點符號的敏感(或不敏感); 文本中數字的處理; 以及許多其他選項,以滿足各種用途。
若要在語言標籤中包含此額外的排序規則資訊,請附加 -u
,這表示有其他排序規則設定,後跟一個或多個 -
key
-
value
配對。key
是 排序規則設定 的鍵,而 value
是該設定的有效值。 對於布林設定,可以指定 -
key
而不使用對應的 -
value
,這表示值為 true
。
例如,語言標籤 en-US-u-kn-ks-level2
表示美國地區的英語語言地區設定,排序規則設定 kn
設定為 true
,而 ks
設定為 level2
。 這些設定表示排序規則將不區分大小寫,並將一系列數字視為單個數字。
CREATE COLLATION mycollation5 (provider = icu, deterministic = false, locale = 'en-US-u-kn-ks-level2'); SELECT 'aB' = 'Ab' COLLATE mycollation5 as result; result -------- t (1 row) SELECT 'N-45' < 'N-123' COLLATE mycollation5 as result; result -------- t (1 row)
有關詳細資訊和使用語言標籤以及地區設定的自訂排序規則資訊的其他範例,請參閱第 23.2.3 節。
如果地區設定支援無法按照上述說明運作,請檢查作業系統中的地區設定支援是否已正確設定。 若要檢查系統上安裝了哪些地區設定,如果您的作業系統有提供,您可以使用命令 locale -a
。
檢查 PostgreSQL 實際上是否正在使用您認為的地區設定。 LC_COLLATE
和 LC_CTYPE
設定是在建立資料庫時確定的,除非建立新的資料庫,否則無法變更。 其他地區設定,包括 LC_MESSAGES
和 LC_MONETARY
,最初由伺服器啟動時的環境決定,但可以隨時變更。 您可以使用 SHOW
命令檢查作用中的地區設定。
來源發布中的目錄 src/test/locale
包含 PostgreSQL 地區設定支援的測試套件。
如果客戶端應用程式透過剖析錯誤訊息的文字來處理伺服器端錯誤,那麼當伺服器的訊息使用不同的語言時,顯然會出現問題。 建議此類應用程式的作者改為使用錯誤代碼方案。
維護訊息翻譯目錄需要許多志願者的持續努力,他們希望看到 PostgreSQL 以他們喜歡的語言流利地表達。 如果您語言的訊息目前不可用或未完全翻譯,我們將感謝您的協助。 如果您想提供協助,請參閱第 55 章或寫信給開發人員的郵件清單。
如果您在文件中發現任何不正確、與您特定功能的使用經驗不符或需要進一步說明的地方,請使用 此表格 回報文件問題。