눈에는 같은 주소인데 거래자료 결합이 실패한다면 유니코드 정규화를 확인할까

화면에서 같은 주소로 보이는데 거래자료가 결합되지 않는다면, 이미 읽어 들인 문자열의 유니코드 표현을 확인할 수 있다. 글자가 깨진 파일의 인코딩 문제나 주소 약칭 문제와는 다른 원인이다. 겉모습이 같아도 내부 코드포인트 배열이 다르면 정확히 일치하는 문자열로 비교되지 않을 수 있다.

한글 한 글자로 확인한다

예를 들어 ‘가’는 U+AC00 한 글자로 저장할 수도 있고, 초성 U+1100과 중성 U+1161의 조합으로 표현할 수도 있다. 두 표현은 화면에서 같게 보일 수 있지만 원래 배열의 길이와 값은 다르다. Python의 unicodedata 문서는 정규화 형식 NFC·NFD와 canonical equivalence를 설명한다. 같은 형식인 NFC로 정규화한 두 값이 일치하는지 사본에서 확인하면 이 원인을 좁힐 수 있다.

이 작업이 틀린 주소를 올바른 주소로 고치는 것은 아니다. 번지나 동·호가 다르거나 자료가 가려져 있으면 문자 정규화로 동일 주택임을 확인할 수 없다. 띄어쓰기·약칭 변환과도 규칙을 구분해야 어느 처리가 결합 결과를 바꿨는지 찾을 수 있다.

원본과 결합 키를 나누어 둔다

거래표에는 원본 주소, 정규화 형식과 변환한 키를 별도 열로 남긴다. 변환 전후 정확 일치 건수와 연결되지 않은 행, 여러 행에 연결된 경우를 대조한다. NFKC 같은 호환성 변환은 다른 종류의 표현까지 합칠 수 있으므로 의미 검토 없이 모든 기호를 일괄 치환하지 않는다. 표준화 후 결합이 늘었다고 모두 정확한 연결이 된 것도 아니다.

기관의 주소 식별자나 공식 코드가 있다면 그 정의와 함께 사용한다. 이 글의 한글 예시는 문자 비교 원리만 검산한 것이며 실제 거래파일을 정리한 결과가 아니다. 동일한 글자 표현인지 확인하는 단계와 동일한 부동산인지 확인하는 단계가 각각 필요하다는 점을 유지한다.