사건의 전말
https://demos.telerik.com/kendo-ui/editor/index
위의 링크 kendo editor는 사진 파일 버그가 있다.
나는 이것 때문에 정말 고생을 했다.
이 kendo editor에 사진 파일을 끌어다 넣으면 kendo editor가 그 이벤트를 감지하여 해당 파일을 base64로 인코딩하여 editor안에 넣는다.
그렇게 하면 다음과 같이 나오는 데,
야자수 사진이 보이는가? 저런 식으로 사진이 직접 에디터 안에 들어가서 보여준다.
문제는 이 에디터에 들어간 base64로 인코딩된 문자열을 서버에 보내고 저장하고 있다가 나중에 다시 디비에서 꺼내서 서버로부터 이 문자열을 받을 때 사진이 나오지 않는 거였다.
프로파일링 과정
그래서 디비로부터 받은 문자열을 다음의 온라인 base64 to png 툴을 사용해봤다. 그런데, 사진이 안나오고 인코딩이 잘못되었다는 경고가 떴다.
https://onlinepngtools.com/convert-base64-to-png
그래서 나는 어디서부터 사진 인코딩 문자열이 잘못(corrupt)되었는 지 파악하기 위해서 의심되는 경로를 모두 찾아봤다.
- 첫 번째, 사진이 에디터로 들어갈 때 문제가 발생하는 가?
- 두 번째, 인코딩된 문자열이 Angular를 통해 http 통신을 하면서 corrupt되었는 가?
- 세 번째, 서버에서 DB에 저장할 때 인코딩된 문자열이 corrupt되어 저장이 되는 가?
콘솔로그를 계속 찍고, 개발자도구의 Response, DB를 샅샅이 찾아보고 나서 내린 결론은
첫 번째 문제였다.
그렇다면, 어떤 불순물이 들어가서 base64 인코딩된 문자열이 corrupt되었는 가? 살펴보았다.
문자열을 수작업으로 비교하면서 찾아본 결과,
맨 뒤에 =문자가 달랐다. =문자가 없으면 base64 to png 툴에서 사진이 잘 표현되어 나왔고, =문자가 있으면 그렇지 않았다.
그렇다면 왜 =문자가 들어간 걸까?
base64에 대해 공부해보니 =문자는 base64 인코딩 되기전의 문자열의 문자 갯수에 3을 나눈 나머지 갯수였다.
정말 복잡하다. 이것에 대해서는 한국 위키피디아와 영어 위키피디아를 살펴보면서 공부를 해보자. 또 아래에 다른 블로그 링크도 남겨두겠다.
https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464
https://en.wikipedia.org/wiki/Base64
https://effectivesquid.tistory.com/entry/Base64-%EC%9D%B8%EC%BD%94%EB%94%A9%EC%9D%B4%EB%9E%80
이제 뭐가 문제인지 알아보자
자 이제 base64에 대한 공부를 마쳤다. 이 글을 읽는 독자 분께서 공부를 마치셨다면, 에디터에 사진을 끌어다 올릴 때, 패딩을 잘 못 계산하고 있는 것은 아닌지 의심을 해볼 것입니다.
그러면 이제 패딩이 제대로 되었는 지 역산을 할 줄 알아야한다.
자 예를 들어 base64로 인코딩된 문자열의 갯수가 542893개라고 해보자. 그리고 지정된 패딩 문자 =는 1개이다.
그렇다면, 이 패딩 문자 =가 1개인 게 맞는 계산일까? 역산을 해보자
첫 번째) 문자열의 갯수에서 패딩 문자를 뺀다.
542893 - 1 = 542892두 번째) 6비트로 인코딩되었으므로 6을 곱해줘서 원래의 이진수 비트 갯수로 바꿔준다.
542892 * 6 = 3257352세 번째) 이진수 비트 갯수에서 원래의 8비트인 ASCII로 바꿔준다.
3257352 / 8 = 407169네 번째) 3으로 나눈 나머지 값을 구한다.
407169 % 3 = 0다섯 번째) 구한 나머지 값을 3에 뺄샘한다.
3 - 0 = 3여섯 번째) 결과값이 1 또는 2라면 그 갯수가 올바른 바로 패딩 문자의 갯수가 된다. 만약 결과값으로 3이 나왔다면 인코딩되었을 때 패딩 문자는 없는 게 맞다.
결론
역산을 통해 base64로 인코딩된 값의 패딩 문자 =가 kendo editor에서 비정상적으로 계산되었다는 것을 알게 되었다.
나는 4년 전에 내가 만든 raycasting 엔진에서 스크린샷을 찍어서 bmp파일로 만들어본 경험이 있다. 이 때 내 똑똑한 동료가 패딩계산을 올바르게 해서 좋은 점수를 받도록 도와주고 좋은 피드백을 줬던 기억이 난다.
https://github.com/PennyBlack2008/42_Cub3D/blob/main/screenshot.c
위의 링크의 소스코드는 내가 4년 전에 도움받은 코드이다. 이 때의 기억 때문에 프로파일링을 더 잘 할 수 있었던 것같다.
42서울에서 겪었던 것들이 실무를 하면서 새록새록 기억이 난다. 내가 정말 좋은 교육을 받았다고 생각이 들고 동료들과 같이 정말 고생했던 기억 때문에 가슴이 뜨거워진다.
