Swift - String CompareOptions (2)

 

 

 

오늘은 지난 포스팅에 이어 compareOptions에 대해서 공부하도록 하겠습니다.

 

---

 

numeric

 

numeric option은 문자열 안에 있는 숫자를 숫자로 인식하여 비교할 때 사용합니다.

 

정수 2와 10을 비교하면 당연히 2 < 10 입니다.

하지만 문자열 "2"와 "10"을 비교하면 "2" < "10" 일까요??

문자열을 비교할 때는 leading 부분부터 하나씩 비교하게 됩니다.

그래서 "2"와 "1"을 비교하게 되고 "2" > "10" 라는 결과가 나오게 됩니다.

 

만약 우리가 파일을 이름 순서대로 정렬하고자 한다면 문제가 발생합니다.

File2.txt File3.txt File10.txt .... 이렇게 정렬하고 싶은데 문자열을 비교하여 정렬을 하면 "File10.txt"는 "File2.txt보다 작은 것으로 판단되어 File10.txt File2.txt File3.txt 이렇게 정렬이 됩니다.

이를 해결하기 위해서 nemeric option이 필요합니다.

 

코드를 보시면 file2이 file10보다 큰 것을 확인할 수 있습니다.

이때 numeric option을 사용하면 문자열 안에 숫자를 숫자로 판단합니다.

그래서 문자열이지만 2보다 10이 큰 숫자이기 때문에 우리가 원하는 대로 file10이 file2보다 큰 것을 확인할 수 있습니다.

 

numeric option은 검색에서는 사용하지 않습니다. 비교할 때만 사용하는 option입니다.

 

---

 

diacriticInsensitive

 

diacriticInsensitive option은 발음 구분 기호를 무시하고 비교하는 option입니다.

 

Swift는 우리 눈에 보이는 결괏값으로 문자열을 비교한다고 했죠??

ozil과 özil은 다른 문자열입니다. 그래서 코드의 결과도 true로 나온 것을 확인할 수 있습니다.

 

하지만 diacriticInsensitive option을 사용하면 발음 구분 기호가 있지만 같은 o로 판단하게 됩니다.

 

---

widthInsensitive

 

widthInsensitive option은 전각 반각 문자를 무시하고 비교하는 option입니다.

전각 문자는 기존에 우리가 아는 문자이고 반각은 전각보다 너비가 반인 문자를 의미합니다.

동아시아에서 주로 사용하고 영어권에서는 자주 사용하지 않습니다.

 

코드를 보면 @ ＠을 비교하고 있습니다. 같아 보이지만 자세히 보면 살짝 다릅니다.

당연히 우리가 보기에는 다른 문자이므로 서로 다른 문자입니다.

하지만 widthinsensitive option을 사용하면 서로 같은 문자로 판단하게 됩니다.

 

---

 

forcedOrdering

 

forcedOrdering option은 강제로 정렬하는 option입니다.

쉽게 말하면 서로 순서가 애매한 경우에 option이 적용되지 않은 결과를 기준으로 강제로 정렬합니다.

 

"BEEPEACH"는 대문자로 "beepeach" 보다 작습니다.

여기서 caseInsensitive option을 사용하면 서로 같아지겠죠??

그럼 이 두 문자열을 서로 정렬을 하고 싶습니다.

이때  caseInsensitive option을 추가한 상태에서 forcedOrdering option을 추가하면 caseInsensitive을 무시하고 원래대로 비교한 후에 강제로 정렬시킵니다.

 

이 option은 혼자서는 잘 사용되지 않고 다른 option이 추가되어있을 때 강제로 순서를 정렬하고 싶을 때 사용합니다.

---

regularExpression

 

regularExpression option은 문자열을 regularExpression(정규식)으로 처리합니다.

(정규식에 대해서는 구글에 검색하시면 자세히 나옵니다.)

 

정규식은 특정 규칙을 만족하는 문자열을 검색할 때 자주 사용합니다.

우리가 사용해볼 예는 email 주소의 적합성 판단입니다.

email 주소는 주로 Beepeach @ naver . com 과 같이 문자열, @, 문자열, comma, 문자열의 규칙을 가지고 있습니다. (물론 .co.kr같은 경우도 있습니다.)

이러한 규칙을 만족하지 않으면 email 주소가 아닙니다.

 

코드를 보겠습니다.

email에서 range로 regularExpression을 검색하면 당연히 "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}" 이러한 문자열은 email에 포함되지 않으므로 바인딩에 실패합니다.

여기서 option에 regularExprssion을 전달하게 되면 "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}" 문자열을 regular expression으로 인식하게 됩니다.

그럼 email 상수는 정규식의 규칙을 만족하는 문자열이므로 바인딩에 성공합니다.

 

여기서 주의할 점은 앞뒤에 공백이 들어가는 경우입니다.

fakeEmail은 마지막에 공백이 추가됐습니다.
공백이 추가되면 유효한 email 주소가 아닙니다. 하지만 range(of:options:) 메서드는 포함 관계만 확인하므로 이를 감지하지 못하고 바인딩에 성공하는 것을 볼 수 있습니다.

 

이 문제를 해결하는 방법은 range의 범위와 email의 범위를 비교하는 방법입니다.

email의 범위가 range의 범위보다 공백의 범위만큼 벗어나게 되므로 바인딩에 실패하게 됩니다.

 

 

---

 

참고자료

 

https://kxcoding.com

여러분의 새로운 도전을 응원합니다 | KxCoding

 

 

https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html

Strings and Characters — The Swift Programming Language (Swift 5.6)