a에 대한 답변으로Unix 및 Linux 문제, 저는 Gedit와 다른 두 편집기인 Leafpad와 Medit(총 12개의 편집기를 테스트했습니다)에서 특정 버그를 발견했습니다. 이 버그는 Canonical의 런치패드에서 Bug #332321로 알려져 있는 것으로 밝혀졌습니다.ss를 ß로 검색(및 바꾸기).
잘못된 동작은 및 ...을 find ß모두 일치시키는 것 입니다 (특히 전체 교체를 수행하는 경우 좋지 않음). ßss
How to bind “ß” to Meta-s?그런 다음 StackExchange 소프트웨어가 질문 에 대한 href 링크를 생성하기 위해 질문 제목을 에서 로 변환했음을 확인했습니다 how-to-bind-ss-to-meta-s.
ß그렇다면 비슷한 방식으로 취급되는 전혀 관련이 없는 두 환경 ß사이의 이 이상한 매력은 무엇입니까 ss? … 그러한 "관계"가 또 있습니까?
답변1
ßss실제로는 합자(독일어)입니다. 유니코드나 기타 확장된 알파벳 문자를 URL과 같은 "안전한" 문자로 변환하기 위해 테이블을 사용하는 사람은 아마도 이를 ss.
URL을 사용하여 이 작업을 수행하는 것이 일반적입니다. 예를 들어, 저는 영어에는 없는 문자가 있는 터키어를 사용합니다 ö ü ı â ğ ç ş İ. 이러한 문자는 URL, 특수 양식 필드 등에 사용하기에 항상 안전한 것은 아닙니다. 이를 유사한 문자(예: )로 바꿉니다 o u i a g c s I. 일반적으로 이는 소리보다는 시각적 유사성을 통해 이루어지지만 ß청각적 유사성의 경우 ss일반적인 변환이 됩니다.
이로 인해 데이터가 완전히 손실되지만 URL이나 기타 특수 필드를 안전하게 표현하는 역할을 하며 웹사이트 자체에서 실제 문자를 사용할 수 있습니다.
gedit이 전환이 필요한 이유는 나에게 달려 있지 않습니다. 이것은 실수입니다.
답변2
사례 정규화. <Gedit로 확인> 네.
대소문자를 구분하지 않고 검색할 때 GEdit(그리고 다른 사람들도 마찬가지)는 대소문자를 정규화하므로 많은 문자 동등성이 손상됩니다. 예를 들어, ß및 ss는 모두 대문자입니다 SS. é및 é(첫 번째 문자는 U+00E9 LATIN SMALL LETTER E AND ACUTE이고 두 번째 문자는 U+0301 COMBINING ACUTE ACCENT 다음에 U+0065 LATIN SMALL LETTER E임) 와 같은 복합 문자 도 동일한 것으로 간주됩니다.
대소문자를 구분하여 검색을 수행하는 경우 이러한 문자 순서는 다른 것으로 간주됩니다.