我将系统从 CentOS 6.9 VM 迁移到 Debian 10 Docker 容器,我无法解释为什么千位分隔符不同。相同的语言环境 (fr_FR.UTF-8)、相同版本的语言环境但不同的分隔符:
CentOS 6.9 虚拟机:
[user@host ~]$ cat /etc/redhat-release
CentOS release 6.9 (Final)
[user@host ~]$ locale -v -a fr_FR.UTF-8 | grep -A10 fr_FR.utf8
locale: fr_FR.utf8 archive: /usr/lib/locale/locale-archive
-------------------------------------------------------------------------------
title | French locale for France
source | RAP
contact | Traduc.org
email | [email protected]
language | French
territory | France
revision | 1.0
date | 2008-03-15
codeset | UTF-8
[user@host ~]$ yum list installed | grep libc
glibc.x86_64 2.12-1.209.el6_9.2 @updates
glibc-common.x86_64 2.12-1.209.el6_9.2 @updates
glibc-devel.x86_64 2.12-1.209.el6_9.2 @updates
glibc-headers.x86_64 2.12-1.209.el6_9.2 @updates
[...]
[user@host ~]$ grep "thousands_sep" /usr/share/i18n/locales/fr_FR
mon_thousands_sep "<U0020>"
thousands_sep "<U0020>"
[user@host ~]$ LC_NUMERIC="fr_FR" printf "%'.f\n" 1234 | hexdump -C
00000000 31 20 32 33 34 0a |1 234.|
00000006
Debian 10 容器:
root@240c7f7ca3a1:~# cat /etc/issue.net
Debian GNU/Linux 10
root@240c7f7ca3a1:~# locale -v -a fr_FR.UTF-8 | grep -A10 fr_FR.utf8
locale: fr_FR.utf8 archive: /usr/lib/locale/locale-archive
-------------------------------------------------------------------------------
title | French locale for France
source | RAP
contact | Traduc.org
email | [email protected]
language | French
territory | France
revision | 1.0
date | 2008-03-15
codeset | UTF-8
root@240c7f7ca3a1:~# apt list --installed | grep libc
libc-bin/stable,now 2.28-10 amd64 [installé, automatique]
libc-l10n/stable,now 2.28-10 all [installé, automatique]
libc6/stable,now 2.28-10 amd64 [installé]
[...]
root@240c7f7ca3a1:~# grep "thousands_sep" /usr/share/i18n/locales/fr_FR
mon_thousands_sep "<U202F>"
thousands_sep "<U202F>"
root@240c7f7ca3a1:~# LC_NUMERIC="fr_FR" printf "%'.f\n" 1234 | hexdump -C
00000000 31 e2 80 af 32 33 34 0a |1...234.|
00000008
正如您所看到的,在第一种情况下,我得到一个正常的空间(<U0020>
/ 20),而在后一种情况下,我得到一个狭窄的不易破坏的空间(<U202F>
/ e2 80 af)。
我知道 NNBSP 是法语语言环境的合法字符(根据多个来源,包括维基百科),但这会改变我在生成 PDF 报告时的应用程序行为(并非每种字体中都存在该字符)。
我在 GNU/Glibc/JDK 邮件列表上看到很多关于它应该是什么字符的争论,但找不到它在哪里被改变Glibc 变更日志。
我可以直接在代码中将所有 NNBSP 替换为标准空间(或简单的 NBSP)来修复应用程序,但这对我来说似乎有点混乱。我想我可以修改语言环境文件并重新编译它?有更好的解决方案吗?