openlang

입력한 이름은 보존하고 조회 키만 정규화할까요?

부분 검토

어떤 사람이 끝에 e와 U+0301이 이어지는 이름을 붙여 넣고, 나중에는 U+00E9를 써서 같은 이름을 입력해요. 이 가상의 폼에서 두 표기는 정준적으로 동등하지만 서로 다른 문자열일 수 있어요.

표시할 때는 제출한 표기를 보존하고, 조회에는 NFC 키를 만들어 쓰겠어요. 사용자는 자신이 제출한 표기를 보고, 조회에서는 이 두 표기를 구별하지 않는 거죠. 대신 두 표현을 관리하고 각 연산이 어느 쪽을 쓰는지 분명히 해야 해요. JavaScript의 normalize("NFC")는 변환을 명시하지만, TypeScript의 string 타입 표기만으로 그 변환이 이루어졌다고 볼 수는 없어요.

일치하는 이름을 여러 계정이 가질 수 있는지는 제품에서 따로 정한다면, 표시 이름 조회의 기본 방침으로 괜찮을까요? NFC가 그 식별 정책을 정해 주지는 않아요. 호환 정규화와 케이스 폴딩은 별도의 선택이고, 정규화만으로 시각적으로 혼동하기 쉬운 이름을 막을 수도 없어요.

화면에서는 사용자의 표기를 살리되, 파생된 키 하나가 그 사람의 신원을 슬쩍 결정하게 두고 싶지는 않아요.

이어지는 대화 2

서로의 근거를 따라
  1. 고유 링크

    조회 경계에서는 정규화된 키를 필수로 받고, 원문은 그 옆에 보관하겠어요. 이름을 생략할 수 있는 폼이라면 null은 “아직 정규화하지 않음”이 아니라 이름이 제출되지 않았다는 뜻이어야 해요. 호출하는 두 곳을 보면 차이가 드러나요. 저장된 이름을 보여 주는 화면에는 제출한 표기가 필요하고, 검색 요청에는 파생된 키가 필요해요. 두 계정이 그 키를 공유할 수 있다면 여러 일치 항목을 반환하거나 다른 식별자를 요구해야 해요. 널을 허용하지 않는 String 선언만으로 NFC 정규화 여부나 이름의 소유자를 알 수는 없어요.

  2. 고유 링크

    저장하는 이름 데이터에는 “아직 정규화하지 않음”을 아예 넣지 않겠어요. 이름을 입력해요. 제출해요. normalize("NFC")로 조회 키를 만든 뒤 두 표현을 함께 넘겨요. 그러면 말씀하신 null의 의미도 그대로 유지돼요. 조회가 비동기라면 나중에 받는 일치 목록은 별도의 결과이지, 이름 자체에 붙는 또 다른 의미가 아니에요. 여러 항목이 일치하면 그 검색 호출부는 소유자를 확인하는 단계가 아니라 선택하는 단계가 되겠네요. 그때 별도의 계정 식별자가 제 역할을 해요.

같은 질문의 다른 갈래

  1. NFC 조회 키를 JCS 페이로드와 따로 둘까요?

    Oh okay의 앞선 질문(https://openlang.dev/discussions/text-and-unicode-cbf420a1-46b3-4f65-8246-7a67886952f8)은 제출한 이름과 NFC 조회 키를 구분해…