다시 되짚어 보는 공공데이터포털 API Key 오류와 해결 과정

문제점1

공공데이터포털에서 제공되는 키는 인코딩이 한 번된 서비스키다. 

urlComponents의 queryItems를 통해서 쿼리파라미터를 설정하는 url을 생성하는 과정에서

한번 더 인코딩이 되어 2번 인코딩이 되는 문제가 발생했다. 

인코딩이 2번됨에 따라, 완성된 url의 주소가 달라져 서버로 부터 데이터를 받아올 수 없었다. 

 

 

문제해결1

해당 사항을 구글링을 통해 인코딩이 두번 되어 발생한 문제라는 것을 발견할 수 있었다. 

인코딩이 두 번된 것이 문제였으므로, 디코딩을 해준다.

 

공공데이터포털의 마이페이지에 들어가면 인코딩된 인증키와 디코딩된 인증키 둘 다 제공하고 있다.

 

기본 인코딩된 키를 사용해 아래와 같이 removingPercentEncoding 프로퍼티를 사용해서 디코딩할 수도 있다. 

이미지 클릭 시 공식문서로 이동

 

리시버에서 퍼센트 인코딩된 모든 시퀀스를 UTF-8 문자로 대체하여 새로운 문자열을 반환합니다.

 

반환 값:
퍼센트 인코딩된 시퀀스가 제거된 새로운 문자열을 반환하며, 리시버에 잘못된 퍼센트 인코딩 시퀀스가 포함되어 있으면 nil을 반환합니다.

 

중요:
이 메서드는 퍼센트 인코딩된 문자열에만 호출해야 합니다. 퍼센트 인코딩되지 않은 문자열에 이 메서드를 호출하면 퍼센트 문자가 퍼센트 인코딩 시퀀스의 시작으로 잘못 해석될 수 있습니다.

 

 

디코딩 된 키를 비교해본다면 위와 같이 특수문자가 %로 퍼센트인코딩된 것을 볼 수 있다. 

 

 

 

이렇게 디코딩된 키를 상수로 할당해서 url을 만들었으나 +를 제외한 특수문자만 인코딩이 되는 문제가 발생했다. 

 

URLComponents를 사용하면 자동으로 URL인코딩 처리가 된다.

특수문자나 공백이 포함된 경우 자동으로 퍼센트 인코딩을 적용하기 때문이다.

그러나 여기서 +만 퍼센트 인코딩이 되지 않는 이유는, +가 쿼리 파라미터에서 공백을 나타나는 표준 문법으로 사용되기 때문이다. 

RFC 3986에 따라 쿼리 문자열에서 +는 공백(%20)으로 해석된다.

+는 공백으로 사용할 수 있는 특수 문자로 지정되어 있기 때문에 URL 쿼리 파라미터에서 인코딩되지 않으며,

나머지 특수 문자(예: =, &)는 자동으로 퍼센트 인코딩된다.

 

 

 

URL을 구성 요소로 분해하고, 이들 구성 요소로부터 URL을 생성하는 구조체입니다.

이 구조체는 RFC 3986에 따라 URL을 분석하고 구성합니다. 이 구조체의 동작은 구형 RFC에 따르는 URL 구조체와 미세하게 다릅니다. 그러나 URLComponents 값을 기반으로 URL 값을 쉽게 얻거나 그 반대로도 가능합니다.

 

RFC 3986에 관련된 글

https://medium.com/a-day-of-a-programmer/swift-url-%EC%9D%B8%EC%BD%94%EB%94%A9-%EB%AC%B8%EC%A0%9C-%EB%81%9D%EC%9E%A5%EB%82%B4%EA%B8%B0-5c915225edb1 

 

addingPercentEncoding(withAllowedCharacters:) 메서드를 사용해서

API 서비스 키에 대해서 CharacterSet을 직접 정의하여 필요한 특수문자를 수동으로 인코딩해주기로 했다. 

 

**참고) CharacterSet **

Unicode character의 모음이다. 이 CharacterSet을 파라미터로 전달해서 문자열을 검색할 수 있다. 

 

이미지를 클릭하면 공식문서로 이동합니다.

특정 집합에 포함되지 않은 모든 문자를 퍼센트 인코딩 문자로 대체하여 새로운 문자열을 반환합니다.

-> 즉, 특정 집합에 포함된 문자들은 인코딩 되지 않는다.

-> 나의 경우에는 +만 특정집합에 포함되지 않게 해야한다는 것.

 

매개변수

allowedCharacters: 문자열에서 대체되지 않는 문자들입니다. 일반적으로, URL 구성 요소에 대한 미리 정의된 문자 집합 중 하나를 지정합니다. 예를 들어, urlPathAllowed나 urlQueryAllowed와 같은 것이 있습니다.

 

**참고) urlQueryAllowed **

쿼리 URL 구성 요소에서 허용되는 문자의 문자 집합을 반환합니다.

 

**참고) urlQueryAllowed **

CharacterSet은 유니코드 호환 문자의 집합을 나타냅니다. Foundation 타입은 CharacterSet을 사용하여 문자들을 그룹화하여 검색 작업을 수행하며, 이를 통해 검색 중 특정 문자 집합에 속하는 문자를 찾을 수 있습니다.

 

 

반환 값

인코딩된 문자열을 반환하거나, 변환이 불가능할 경우 nil을 반환합니다.

 

설명

전체 URL 문자열은 퍼센트 인코딩될 수 없습니다. 각 URL 구성 요소는 허용되는 문자의 서로 다른 집합을 지정하기 때문입니다. 예를 들어, URL의 쿼리 구성 요소는 "@" 문자를 허용하지만, 이 문자는 비밀번호 구성 요소에서는 퍼센트 인코딩되어야 합니다.

UTF-8 인코딩이 올바른 퍼센트 인코딩 문자를 결정하는 데 사용됩니다. allowedCharacters에 있는 7비트 ASCII 범위를 벗어난 문자는 무시됩니다.

 

중요

이미 퍼센트 인코딩된 문자열에 이 메서드를 호출해서는 안 됩니다. 이미 퍼센트 인코딩된 문자열에 이 메서드를 호출하면, 퍼센트 인코딩된 시퀀스의 퍼센트 문자가 두 번 퍼센트 인코딩됩니다.

 

 

그렇다면 내가 해야할 일:  "+"만 인코딩을 직접해서 url을 만들 것!!

 

근데 이게 진짜 너무 어려웠다.... 🥹

 

 

 

 

 

percentEncodedQuery는 URLComponents에 설정된 쿼리 아이템을 기반으로 퍼센트 인코딩 된 문자열을 반환한다. 

이때, +는 공백의 대체 문자로 해석 되기 때문에 변환 되지 않은 것.

 

마지막에 urlComponents.percentEncodedQuery = plusEncodedQuery를 할당 해주는 이유는 

인코딩 된 + 의 쿼리 문자열을 다시 할당해줘야하기 때문.

 

 

데이터가 제대로 들어 온 것을 볼 수 있다....!!!

 

---

두 번째 이슈...

 

 

문제해결2

iOS10부터는 ATS(App Transport Security)가 강화되어 보안이 안전하지 않은 Https 트래픽을 비활성화 시킨다고 한다.

Info.plist에서 ATS setting을 수정함으로 해결할 수 있다고 한다.

 

 

 

https://leetaek.tistory.com/3

---

여기서 직면한 또 다른 문제

endpoint를 사용하는 이유 중 하나는 형식이 다른 url들을 쉽게 만들고 네트워크매니저에서 하나의 메서드로 관리할 수 있게 만들기 위한 이유도 있다. 현재 다른 API들은 제대로 데이터를 받아고오 있으나, 이 서비스 키 하나로 인해서 네트워크매니저에서 서비스키를 따로 처리 해야하는 상황이 발생하게 된다. 이는 네트워크 요청을 관리하는 NetworkManager에서 쿼리파라미터 인코딩까지 수행해야하는가에 대한 의문이 들게 한다. 

 

추가적으로 쿼리 뿐만 아니라 헤더 파라미터나 path 등에도 이러한 상황이 발생한다면,,,?

현재 네트워크 매니저에서 처리하기에는 책임에 있어 모호해지지 않을까라는 생각이 든다. 

 

 

문제해결3

시도해 본 방법은 extension을 사용하는 방법이다. 

URLComponents는 구조체로 인스턴스 내에서 속성을 수정하려면 mutating 키워드를 사용해야 속성 변경이 가능했다. 

-> self.perenteEncodedQuery 값을 수정하고 있기 때문.

 

path나 URLComponents의 다른 속성에도 인코딩 로직을 추가할 수 있을 것 같다.

그러나 이 부분에 대해서는 좀 더 좋은 방법이 있는지 알아봐야할 것 같다.  

 

 

 

 

Refence
- https://zeddios.tistory.com/1103