Linuxのコマンドライン（本 - ページ 47）は次のように述べています。
...正しく設定しないと、期待した結果は生成されないため、[文字範囲]に非常に注意する必要があります。今では、これらの文字クラスを使用せずに文字クラスを使用する必要があります。
それ以外は本では何の理由も提示しません。
質問1：もしそうなら、なぜ正確にキャラクタークラス（例：、、[:alnum:]など）が優先します。[:alpha:][:digit:]文字範囲（例えば、、、[a-z]など）？[A-Z][0-9]
質問2：[:alpha:]、、、[a-z][A-Z]他の言語の大文字と小文字？同様に[:digit:]、他の言語の数も含まれますか？一致する場合。
（2つの質問があることを知っていますが、この場合IMOとほぼ関連しています。）
答え1
bashマンページによると、LC_COLLATE環境変数はHauke Lagingの答えと同様に文字範囲に影響します。
LC_COLLATE この変数は、パス名拡張の結果をソートするときに使用される照合順序を決定し、範囲式、同等クラス、パス名拡張、およびパターン一致のソート順の動作を決定します。
一方、LC_CTYPEキャラクターのカテゴリーに影響を与えるのは次のとおりです。
LC_CTYPEこの変数は、パス名拡張とパターンマッチングの文字解釈と文字クラスの動作を決定します。
それはどういう意味ですか？両方英語、左から右、ラテン文字、アラビア数字の文脈で考えると、このような状況は問題になる可能性があります。
あなたがそれに興味がある場合、または複数のロケールのスクリプトを書いている場合は、ファイルを一致させるときにロケール変数が何であるかを確認するか、完全に一般的な方法で実行していることを確認するのが最善です。
しかし、言語学を勉強しないと、特定の状況を予測することは困難です。
しかし、ラテン語のロケール変更を使用するかどうかはわかりません。注文する文字なので[az]は大丈夫です。そこはい合字と発音区別符号をさまざまな方法で構成するラテンアルファベットの拡張です。しかし、ここにいくつかの実験があります。
mkdir /tmp/test
cd /tmp/test
export LC_CTYPE=de_DE.UTF-8
export LC_COLLATE=de_DE.UTF-8
touch Grüßen
ls G* # This says ‘Grüßen’
ls *[a-z]en # This says nothing!
ls *[a-zß]en # This says ‘Grüßen’
ls Gr[a-z]*en # This says nothing!
これは面白いです。少なくともドイツ語の場合、üのような発音区別記号とßのような合字はラテン文字に縮小されません。 （または私がロケール変更を台無しにしたか！）
もちろん、この方法は不利かもしれません。文字で始まるファイル名を見つけるには、この文字[a-z]*を使用して「A」で始まるファイルに適用します。
答え2
少なくともbash 4.2を使用するOS Xでは、UTF-8ロケールはASCII照合を使用しているように見えますが、ISO 8859-1ロケールは場合によっては使用されません。
$ LC_ALL=en_US.UTF-8 tr A-C 1-9 <<< B
2
$ LC_ALL=en_US.ISO8859-1 tr A-C 1-9 <<< B
6
$ LC_ALL=en_US.UTF-8 grep [A-Z] <<< ä
$ LC_ALL=en_US.ISO8859-1 grep [A-Z] <<< ä
ä
一部の環境では、UTF-8ロケールも異なる照合順序を使用します。
[:upper:] および [:lower:] には、多くのロケールで ASCII 以外の文字も含まれています。 ASCII文字のみを一致させるには、次のように使用します。
LC_ALL=C tr a-zA-Z n-za-mN-ZA-M
LC_COLLATE=C または LANG=C は、LC_ALL が別の値に設定されている場合は効果がありません。
答え3
「他の言語」、つまり。ロケールごとにソート順が異なる場合があります。したがって、理論的には、これはa-z他のロケールと異なる場合があります。すべてを一致させるには範囲が難しくなります。最初の文字は何で、最後の文字は何ですか？
openSUSEの人は、ユーザー名/パスワードを確認するときに非常に編集的です。彼らは次のようにします。[abcdefghi...]
他の言語/文字セットの数字については考えたことがありません。興味深い点。