相同的区域设置，不同的分布，不一致的行为

Question

我将系统从 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）来修复应用程序，但这对我来说似乎有点混乱。我想我可以修改语言环境文件并重新编译它？有更好的解决方案吗？