LC_COLLATE是否（应该）影响字符范围？
整理顺序LC_COLLATE不仅定义了各个字符的排序顺序，而且还定义了字符范围的含义。还是呢？考虑以下代码段： unset LANGUAGE LC_ALL echo B | LC_COLLATE=en_US grep '[a-z]' 直观上，Bnot in中[a-z]，因此不应输出任何内容。这就是在Ubuntu 8.04或10.04上发生的情况。但是，在某些运行Debian lenny或squeeze的计算机上，B发现了该字符，因为该范围a-z包括排序规则之间a和z排序规则中的所有内容，包括大写字母B到Z。 所有测试的系统的确en_US生成了语言环境。我还尝试过更改语言环境：在B上面匹配的机器上，{en_{AU,CA,GB,IE,US},fr_FR,it_IT,es_ES,de_DE}{iso8859-1,iso8859-15,utf-8}除日语（使用任何可用编码）和C/ 之外，每个可用语言环境（大多是基于拉丁语的：，也包括中文语言环境）中都会发生相同的情况POSIX。 当您超出ASCII时，字符范围在正则表达式中意味着什么？为什么一方面某些Debian安装与另一方面的其他Debian安装与Ubuntu之间有区别？其他系统如何表现？谁是正确的，谁应该报告错误？ （请注意，我是专门询问字符范围的行为，例如[a-z]在en_US语言环境中，主要是在基于GNU libc的系统上。我不是在问如何匹配小写字母或ASCII小写字母。） 两个Debian的机器，一个地方B是在[a-z]和一个地方是不是，输出LC_COLLATE=en_US locale -k LC_COLLATE就是 collate-nrules=4 collate-rulesets="" collate-symb-hash-sizemb=1 collate-codeset="ISO-8859-1" 和的输出LC_COLLATE=en_US.utf8 locale -k LC_COLLATE是 collate-nrules=4 collate-rulesets="" collate-symb-hash-sizemb=2039 collate-codeset="UTF-8"