화면에서 같은 사용자명인데 DB에서는 다른 값으로 저장됩니다. 유니코드 정규화와 대소문자 처리는 어떻게 정하나요?

같아 보이는 글자가 다른 code point 조합으로 표현될 수 있습니다. 저장·비교·검색에 사용할 정규화 규칙을 정하고 표시 원문과 비교 키를 구분해야 합니다. 모든 시각적 유사 문자가 정규화로 합쳐지는 것은 아닙니다.

동작 원리와 전제

조합형·분해형 문자열은 NFC 등 정규화로 맞출 수 있지만 NFKC는 호환 문자를 합쳐 의미가 바뀔 수 있습니다. case folding과 locale별 대소문자도 별도입니다. 바이트 길이·문자 수·사용자가 보는 grapheme 수를 같은 것으로 세지 않습니다.

선택과 실패 처리

이름 유일성은 앱과 DB collation·고유 제약이 같은 규칙을 적용해야 합니다. 기존 데이터에 새 규칙을 적용하면 충돌이 생길 수 있어 대표 선택·사용자 안내·migration이 필요합니다. 비밀번호를 사용자명처럼 임의 정규화하는 정책은 별도 보안 검토가 필요합니다.

구체적인 사례와 검증

같은 글자가 한 code point 또는 기본 문자와 결합 부호로 표현되면 byte 비교는 다를 수 있습니다. 정규화한 비교 키를 따로 저장하고 표시 원문을 보존하면 검색·유일성과 사용자 표현을 나눌 수 있습니다. 그러나 라틴 문자와 닮은 다른 문자처럼 시각적 유사성은 정규화만으로 모두 합쳐지지 않습니다. 허용 문자·혼합 script 정책과 사용자 안내가 필요할 수 있습니다. 기존 데이터에 새 정규화를 적용하면 두 계정이 같은 키로 합쳐질 수 있어 임의 병합하지 않고 충돌 처리 절차를 둡니다. 문자의 표시·식별·정렬·보안은 관련되지만 서로 다른 요구입니다.

조합 문자·터키어 대소문자·이모지·혼합 문자·정규화 충돌을 시험합니다. 시각적 spoofing은 허용 문자·표시·신고 정책과 함께 다룹니다. 입력을 정규화했다고 인증·인가까지 해결되는 것은 아닙니다.