똑같아 보이는 글자가 조인에서 일치하지 않는 이유

먼저 답하면

화면에서 같은 글자로 보여도 저장된 문자 배열이 다르면 정확한 문자열 비교에서 일치하지 않을 수 있습니다. 앞뒤 공백, 결합 문자, 보이지 않는 문자를 구분해서 확인하세요. 공백 정리와 Unicode 정규화는 같은 작업이 아닙니다.

Café의 두 가지 문자 표현

직접 만든 두 키 중 하나는 é 한 글자(U+00E9)를 쓰고 다른 하나는 e(U+0065) 뒤에 결합 악센트(U+0301)를 붙였다고 가정합니다. 둘 다 Café처럼 보이지만 문자 배열은 다릅니다. Unicode 정규화의 NFC는 이런 동등한 표현을 일정한 형태로 맞추는 방법입니다.

보이지 않는 문자나 비슷하게 생긴 다른 문자까지 모두 같은 것으로 바꾸는 것은 별개 문제입니다. 라틴 A와 다른 문자 체계의 닮은 글자를 무조건 합치면 실제로 다른 식별자를 잘못 연결할 수 있습니다. 표기 차이가 의미 차이인지 먼저 판단하세요.

공백 정리만으로 해결되는 범위

웹오피스 Excel 정리는 앞뒤 공백과 연속 공백을 정리하지만 Unicode 정규화를 자동으로 수행하지 않습니다. JavaScript 공백 규칙에 포함된 줄바꿈이나 일부 특수 공백은 정리될 수 있으나 모든 보이지 않는 문자가 그 범위에 들어가는 것은 아닙니다.

웹오피스 조인은 키의 문자열을 정확히 비교합니다. NFC 같은 준비가 필요하다면 원천 데이터를 관리하는 환경에서 기준을 적용한 뒤 가져오세요. MDN의 normalize 설명과 Unicode 표준은 정규화 개념의 참고이며 웹오피스에 해당 기능이 구현됐다는 근거는 아닙니다.

원래 키와 정리한 키를 나란히 보관한다

불일치 행 몇 개를 골라 앞뒤 공백과 문자 구성을 확인하고, 정리한 키로 서로 다른 값이 하나로 합쳐지는지 점검하세요. 이름보다 고유 상품 코드나 고객 코드가 있는 경우 그 식별자가 적절한 기준인지 검토하는 것이 좋습니다.

원본 키를 덮어쓰지 않고 비교 열을 만들면 어떤 변환 때문에 연결됐는지 설명하기 쉽습니다. 자동 연결 결과에서 금액이나 지점까지 함께 대조하세요. 이 글은 합성 문자열의 원리 설명이며 사용자의 실제 키를 외부 서비스로 보내 확인하는 절차를 제안하지 않습니다.

참고 자료와 확인 범위

공식 문서의 개념과 웹오피스의 실제 지원 범위는 다를 수 있습니다. 각 자료를 참고한 범위를 함께 표시합니다.

• Unicode: 정규화 형식

  동등한 문자 표현과 정규화의 정의

• MDN: String.normalize

  NFC 등 문자열 정규화의 예시