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"

如果您使用的不是C语言环境，则不应使用诸如范围之类的范围，[a-z]因为它们是与语言环境相关的，并且不一定总能提供您期望的结果。与您已经遇到的案例问题一样，某些语言环境将带变音符号（例如á）的字符与基本字符（即a）相同。

而是使用命名字符类：

echo B | grep '[[:lower:]]'

这将始终为区域设置提供正确的结果。但是，您需要选择语言环境以反映输入文本和您要应用的测试的含义。

例如，如果需要查找特定的字节值，请使用C始终可用的语言环境：

echo B | LANG=C grep '[a-z]'

如果这不能按预期工作，那确实是一个错误。

正则表达式中的范围应遵守排序规则设置。这是相关的标准：http : //pubs.opengroup.org/onlinepubs/007908799/xbd/re.html（查找“范围表达式”）。因此，echo B | LC_COLLATE=en_US grep '[a-z]'应在B给定相应区域的明智定义的情况下输出。我无法解释为什么有时这对您不起作用，但是如果我在正确安装和配置的非古代系统上遇到此问题，我会感到非常惊讶。