Utf 8 理解LC_ALL=C及其对标准英语字符的影响

请原谅我在处理这个问题时的笨拙，到目前为止，我在字符编码方面所学到的一切都是在过去的几个小时里，我意识到我的深度不够。这可能会在网站的其他地方得到回答，比如在我的链接问题中，但如果有，这些答案对我来说过于密集，以至于我无法准确理解其中的结论

我经常需要

grep

浏览包含过大文本文件（总计超过100GB）的文件夹。我读过关于如何使用的文章，但我想确定这样做会影响我的搜索

---

这些文件很旧，并且通过了许多不同的在线来源，因此可能包含来自许多不同编码（包括UTF-8）的混杂字符。（顺便问一下，单个文件是否可能包含来自多个编码的字符？）

我关心的主要问题是：如果我想在我的数据中搜索给定的

b

，我可以期望数据中存在的每个字母

b

都被编码为ASCII，还是同样的字母也可以被编码为UTF-8

---

或者换一种说法，ASCII字符是否总是且仅限于ASCII？如果即使是标准英文字符也可以编码为UTF-8，并且使用

LC_ALL=C grep

将忽略所有UTF-8字符，那么这将意味着我的搜索将错过非ASCII格式的搜索词，这显然不是我想要的行为，对于

grep

来说，采用

LC_ALL=C将是一个相当大的障碍。关于理解UTF-8与ASCII，以下内容非常好


对于含有少量非ASCII字符的UTF-8文件，grep在时间上的差异，使用LC_ALL=C或LANG=C与标准LANG=en_US.UTF-8或类似字符基本上没有区别

在Cygwin 64位上执行的测试，在20GB文本上重复搜索1000次：

$ time for i in $(seq 1000) ; do  grep -q LAPTOP-82F08ILC wia-*.log ; done

real    0m53.289s
user    0m7.813s
sys     0m31.635s

$ time for i in $(seq 1000) ; do  LC_ALL=C grep -q LAPTOP-82F08ILC wia-*.log ; done

real    0m53.027s
user    0m7.497s
sys     0m31.010s
s

    $ ls -sh wia-*
     10G wia-1024.log  160M wia-16.log  2.5G wia-256.log   40M wia-4.log    639M wia-64.log
    1.3G wia-128.log    20M wia-2.log   320M wia-32.log   5.0G wia-512.log   80M wia-8.log

这两种情况下的差异都在53-55秒的重复公差范围内
“包含来自多个字符集的字符”：当然（由于字符集之间的重叠），但不是来自多个字符编码。作者只选择了一个，你必须知道它是哪一个。我的错，我在那篇文章中确实指的是不同的字符编码，我现在编辑了它，但是感谢你为我回答这个问题。如果你在搜索固定字符串，即不使用正则表达式，ASCII码是UTF-8的子集，尝试使用
grep-f
或
fgrep
我很抱歉反应太晚，但要澄清的是，你是说在我的文件中使用
LC_ALL=C
在排序和匹配数据时可能会有风险吗？我只是说速度上的差异很小。您可以根据具体需要选择LC_ALL value。