개발Log

Spring | MultipartFIle에서 파일 이름 가져오기 문제 해결, Normalize 유니코드

이진유진 2024. 8. 26. 13:10
반응형

1. 문제 발견

최근 파일 업로드 기능을 구현하던 중, 특정 파일명을 검색할 때 예상치 못한 문제가 발생했습니다.
MultipartFile의 getOriginalFilename() 메서드를 사용하여 파일 이름을 받아 저장하던 중 
파일 이름에 한글이 포함된 경우, 데이터베이스에서 LIKE 연산자를 사용한 부분 검색이 정상적으로 작동하지 않는 현상이 발생했습니다.
예를 들어, "스크린샷"이라는 단어가 포함된 파일명을 검색하려고 했으나, 결과가 제대로 반환되지 않았습니다.

2. 문제 원인

문제를 분석한 결과, 이 현상은 운영체제(OS) 간의 유니코드 처리 방식 차이로 인해 발생한 것으로 밝혀졌습니다.
특히, MacOSWindows에서 한글을 처리하는 방식이 달랐습니다:

  • MacOS는 한글을 NFD(Normalization Form D, 조합형) 방식으로 처리합니다. 이 방식에서는 한글이 자모(초성, 중성, 종성)로 분리되어 저장됩니다.
  • Windows는 한글을 NFC(Normalization Form C, 완성형) 방식으로 처리합니다. 이 방식에서는 한글이 결합된 형태로 저장됩니다.

예를 들어, "스크린샷"이라는 단어는 MacOS에서는 각각의 자모("ㅅ", "ㅡ", "ㅋ", "ㅡ", "ㄹ", "ㅣ", "ㄴ", "ㅅ", "ㅏ", "ㅅ")로 분리되어 저장될 수 있습니다.
반면 Windows에서는 완성형("스크린샷")으로 저장됩니다. 이로 인해, 같은 문자열이더라도 서로 다른 운영체제에서 다르게 저장되어 검색이 제대로 되지 않는 문제가 발생한 것입니다.

3. 해결 방법

이 문제를 해결하기 위해, 파일 이름을 저장하기 전에 유니코드를 정규화(Normalization)하여 일관된 방식으로 처리하기로 했습니다.
이를 위해 Java의 Normalizer 클래스를 사용하여 파일 이름을 NFC(완성형) 형식으로 변환했습니다.

import java.text.Normalizer;

String originFilename = Normalizer.normalize(multipartFile.getOriginalFilename(), Normalizer.Form.NFC);

 
이 코드를 적용한 후, 데이터베이스에 저장된 파일 이름이 MacOS와 Windows에서 동일한 형식으로 처리되었고, LIKE 연산자를 사용한 검색이 정상적으로 작동했습니다.

4. 느낀 점 및 결론

이번 경험을 통해, 운영체제 간의 유니코드 처리 방식의 차이가 실제 프로젝트에서 어떻게 문제를 일으킬 수 있는지 알게 되었습니다.
특히, 한글과 같이 자모가 분리될 수 있는 언어의 경우, 이러한 문제를 미리 인지하고 적절한 대처 방안을 마련하는 것이 중요하다는 것을 깨달았습니다.
파일 업로드 기능은 많은 웹 애플리케이션에서 필수적이며, 이러한 작은 차이가 큰 문제로 이어질 수 있음을 유념해야 합니다.

반응형