텍스트 인코딩 · 특수문자 점검 (보이지 않는 문자 · 줄바꿈 · 정규화)

어떤 상황에서 이 점검이 필요한가

증상은 대개 이렇게 나타납니다. 엑셀에서 복사한 회사명이 데이터베이스 검색에 안 걸립니다. 회원 가입 폼에서 이메일이 자꾸 형식 오류로 튕깁니다. JSON 파일이 "position 0" 오류를 냅니다. 맥에서 만든 압축 파일을 윈도우에서 풀었더니 파일 이름이 "ㅎㅏㄴㄱㅡㄹ"처럼 보입니다. 셸 스크립트가 "command not found"를 내는데 명령어는 분명히 맞습니다. 이 다섯 가지 모두 눈에 보이지 않는 문자나 인코딩 차이가 원인입니다. 공통점은 화면에 멀쩡히 보인다는 것이라, 육안으로는 아무리 봐도 찾을 수 없습니다. 텍스트를 여기 붙여넣으면 어디에 무엇이 몇 개 있는지 위치까지 나옵니다.

공백처럼 보이지만 공백이 아닌 것들

일반 공백은 U+0020 하나뿐이고, 나머지는 전부 다른 문자입니다. 웹 페이지에서 복사하면 줄바꿈 없는 공백(NBSP, U+00A0)이 자주 딸려 옵니다. 엑셀의 TRIM 함수로 지워지지 않는 공백이 거의 이것입니다. 한글 입력기로 특수문자를 넣다 보면 전각 공백(U+3000)이 들어가고, 웹 편집기는 줄바꿈 위치를 조정하려고 제로 폭 공백(U+200B)을 넣기도 합니다. 이들은 폭만 조금 다를 뿐 화면에서는 공백으로 보이지만, 문자열 비교에서는 완전히 다른 값이라 검색·중복 제거·유효성 검사가 전부 어긋납니다. 정리 기능은 이 중 공백 역할을 하는 것은 일반 공백으로 바꾸고, 폭이 없는 것은 삭제합니다. 다만 이모지 조합(👨‍👩‍👧)이나 아랍어·힌디어에서는 제로 폭 접합자가 정상적인 구성 요소이므로, 그런 텍스트에서는 정리 결과를 확인하고 쓰세요.

줄바꿈 세 가지와 git

줄바꿈은 윈도우가 CRLF(\r\n), 리눅스와 맥이 LF(\n), 아주 오래된 맥이 CR(\r)을 씁니다. 한 파일 안에 두 가지가 섞이면 편집기마다 줄 수가 다르게 세어지고, git에서는 내용을 한 글자도 안 고쳤는데 파일 전체가 바뀐 것으로 표시됩니다. 더 성가신 경우는 셸 스크립트입니다. 윈도우에서 저장한 .sh 파일을 리눅스에서 실행하면 줄 끝의 \r까지 명령의 일부로 읽혀 "command not found"나 "bad interpreter"가 납니다. 이 도구가 CRLF·LF·CR 개수를 각각 세어 주므로 섞였는지 바로 확인할 수 있고, 정리 기능으로 LF 통일 결과를 받을 수 있습니다.

NFC와 NFD — 파일 이름이 깨지는 진짜 이유

"한"이라는 글자는 완성형 코드 하나(U+D55C)로도, 초성·중성·종성 세 코드(U+1112 U+1161 U+11AB)로도 적을 수 있습니다. 앞을 NFC, 뒤를 NFD라고 합니다. macOS는 파일 이름을 NFD로 저장하는 반면 윈도우와 대부분의 리눅스 도구는 NFC를 기대해서, 맥에서 압축한 한글 파일 이름이 윈도우에서 자모가 흩어져 보이는 일이 생깁니다. 화면에 똑같이 보여도 바이트가 다르므로 문자열 비교, 데이터베이스 조회, 파일 검색이 전부 실패합니다. 해결은 한쪽으로 통일하는 것이고, 일반적으로는 NFC가 기준입니다. 이 도구는 자모 범위 문자를 세어 NFD 여부를 알려 주고, 정리 항목에서 NFC 정규화를 켜면 합쳐진 결과를 보여 줍니다.

자주 묻는 질문