다음 예를 고려하십시오.
$ bash --version
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ LC_COLLATE=C bash --norc -c '[[ B == [a-z] ]] && echo yes || echo no'
no
$ LC_COLLATE=en_GB bash --norc -c '[[ B == [a-z] ]] && echo yes || echo no'
yes
$ LC_COLLATE=C bash --norc -c '[[ B =~ [a-z] ]] && echo yes || echo no'
no
$ LC_COLLATE=en_GB bash --norc -c '[[ B =~ [a-z] ]] && echo yes || echo no'
no
매칭할 때 그런 것 같다.무늬(즉, =or 사용 ==) Bash는 LC_COLLATE에 따라 대조합니다. 그러나 정규식과 일치하는 경우(즉, or 사용 =~) Bash는 POSIX 또는 유사한 것에 따라 대조합니다.
Zsh는 - 최소한 - 모든 경우에 zsh 5.8.0.2-dev (x86_64-pc-linux-gnu)인쇄합니다 .no
[a-z]패턴이나 정규식에 사용될 때 그것이 정확히 일치하는 것이 보장됩니까?
답변1
[a-z]아니요, 정확하게 일치할 것이라는 보장은 없습니다 .
다른 로케일에서는 가능합니다 "C"(유틸리티가 POSIX 규격인 경우).
핵심 문제는 "범위" 표현(사용법 -)에 있습니다.
이와 같은 명확한 목록은 [abcdefghijklmnopqrstuvwxyz]결코 실패하지 않습니다.
POSIX는 정확히 를 요청합니다 a-z. abcdefghijklmnopqrstvwxyz그렇습니다. 하지만 로캘이 POSIX 기본값인 경우에만 해당됩니다 "C".
POSIX 사양에서:
POSIX 로케일에서 범위 표현식은 조합 시퀀스의 두 요소를 포함하는 두 요소 사이의 조합된 요소 세트를 나타냅니다.범위 표현식에는 다른 로케일에서 지정되지 않은 동작이 있습니다.: 엄격한 규정 준수 애플리케이션은 범위 식이 유효한지 여부나 일치하는 조합 요소 집합에 의존해서는 안 됩니다. 범위 표현식은 ('-')로 구분된 시작점과 끝점으로 표현되어야 합니다.
POSIX가 특정 의미를 요청하더라도 a-z모든 애플리케이션은 단순히 POSIX를 무시하도록 선택할 수 있습니다.
빙산의 일각을 보여드리자면:
Python 2.7은 ASCII에만 일치 a-z하지만 Python 3.0은 다른 많은 유니코드 문자와 일치합니다. Bash는 3.2 이전 ASCII에만 일치하는 데 사용되었습니다. 그런 다음 일치시킬 문자를 결정합니다.정돈하다a및 는 앱의 로케일에 포함될 z수 A-Y있습니다(일반적으로 포함되지 않음) . Z이제 bash 버전 5.0+에서는 globasciiranges 옵션을 사용하여 범위를 구성할 수 있습니다.존재하다기본적으로 a-z의도를 일치 시킵니다.최대ASCII 문자.
$ LC_COLLATE=en_GB bash -c 'shopt -u globasciiranges; [[ B == [a-z] ]] && echo yes || echo no'
yes
$ LC_COLLATE=en_GB bash -c 'shopt -s globasciiranges; [[ B == [a-z] ]] && echo yes || echo no'
no
그러나 globasciiranges가 활성화된 bash 5.0이라도 == [a-z]en_GB.utf-8 로케일에서는 2190자와 일치합니다. 이해를 돕기 위해 a허용되는 유사 문자 목록은 다음과 같습니다.
a ａ ͣ ⒜