TIL: Base64와 URL-Safe

회사에서 프로젝트를 하는 중에 프론트에서 서버로 데이터를 전송하는 과정에서 일부를 RSA로 암호화하여 전송하는 무언가를 만드는 순간이 있었다. (자세하게는 말 못 한다)

그러던 중 서버에서 데이터를 복호화 하는 도중 예외를 뿜뿜 뿜어내던 게 아닌가…

처음에는 RSA 키를 잘못 줬나 싶어 다시 키를 발급받아보기도 하고 적지 않은 시간 동안 프론트랑 백엔드의 코드를 번갈아 보면서 이유를 알아내려 했었다.

하지만 웬걸… 이유는 매우 터무니없었다….

RSA로 변환하면 나오는 Base64의 매핑 테이블은 요렇게 생겨먹었다. 문제는 +, /, = 이 녀석들로 값이 변환될 때 예상치 못한 사태가 발생한다.

URL에서 +, /, =는 특수하게 예약된 제어문자이다. URL에서 +는 띄어쓰기(공백문자) /는 URL 디렉터리 간의 경로 구분, =는 파라미터에서 값의 할당을 나타내게 된다. (자세한 내용은 여기로)

간단하게 설명하면

7Jik64qY7KCA64WB7J2AIOy5mO2CqOydtOuLpH5+fg==

요런 Base64 문자열이 있다고 한다면 브라우저에서는 자기 멋대로

7Jik64qY7KCA64WB7J2AIOy5mO2CqOydtOuLpH5 fg==

요렇게 공백문자로 바꿔버린다는 말이다. (뒤의 = 이 그대로 있는 이유는 어차피 문자열의 끝이라서 치환이 안된다)

그렇기에 웹에서는 위와 같은 일반적인 Base64 인코딩을 하지 않으며 +를 -로, /를 _(언더 스코어)로 바꿔 URL-Safe 하게 바꾸면 된다.

7Jik64qY7KCA64WB7J2AIOy5mO2CqOydtOuLpH5-fg==

(어려울 게 없다 replace로 각각 문자를 바꿔주고 서버에서도 역시 이를 처리할 수 있게 해주면 된다)

이상으로 Base64를 웹에서 url-safe 하게 처리해야만 하는 이유를 알게 되었다.

앞으로 같은 사태가 발생하지 않게 자기가 쓰는 게 뭔지는 제대로 알고 쓰도록 하자

-끝-