SimpleWebUtils
ENKO

문서 작업 가이드

제로 폭 문자를 제거하기 전에 위치와 의미 검사하기

원문을 보존하고 지원하는 Unicode 제어 문자 6종을 코드 포인트와 위치로 식별한 뒤 의미 있는 결합 문자를 보호하고, 확인된 최소 범위만 제거해 실제 목적지에서 정확한 결과를 검증합니다.

작성 및 검수 게시일: 검토일:

이 작업 흐름을 검증한 방법

제로 폭 문자를 안전하게 검사하고 제거하기에서 다음 가이드 픽스처로 검증을 시작했습니다: “이모지 결합 문자를 유지하면서 일반 구분자 제거”. “정확한 원문과 출처 보존”부터 “각 제어 문자의 가능한 영향 분류”까지 실행해 생성 결과를 기대값과 대조했습니다. 별도 한계 검토에는 “위치를 검토하기 전에 원문 대체”, “ZWJ와 ZWNJ를 무해한 공백으로 삭제” 항목을 사용했습니다.

주소와 legacy text의 일반 zero-width 구분자는 제거됐지만 👩‍💻 안의 ZWJ는 남아 emoji sequence가 갈라지지 않았습니다.

제로 폭 문자를 안전하게 검사하고 제거하기 열기

문제 상황

제로 폭 코드 포인트 하나 때문에 이메일 주소, 계정 키, 소스 식별자, URL 레이블, 복사한 문단이 사람이 보는 모습과 다른 값이 될 수 있습니다. 편집기, 내보내기, 복사·붙여넣기에서 우연히 남은 경우도 있지만 의도된 경우도 있습니다. ZWJ는 하나의 이모지를 만들거나 복잡한 문자 모양에 영향을 주고 ZWNJ는 결합을 막으며, ZERO WIDTH SPACE는 줄바꿈 기회를 만들고 WORD JOINER는 줄바꿈을 억제할 수 있습니다. 따라서 보이지 않는 문자를 모두 삭제하면 비교 문제를 고치는 대신 언어, 표시, 줄 배치를 손상할 수 있습니다. 신뢰할 수 있는 정리는 원문을 보존하고 정확한 코드 포인트와 위치를 식별하며 확인된 집합만 제거하고, 디코딩 문자열의 다른 바이트에 해당하는 문자를 유지한 뒤 정규화나 인코딩 복구와 분리해 목적지 동작을 검증합니다.

이럴 때 사용하세요

  • 화면에는 같은 사용자 이름, 이메일 주소, 검색어, 데이터베이스 키가 서로 다른 값으로 비교될 때
  • 붙여넣은 소스 코드, CSV 데이터, 환경 변수 값, 식별자가 눈에 보이는 원인 없이 파싱 또는 검증에 실패할 때
  • 복사한 텍스트가 예상하지 않은 위치에서 줄바꿈되거나 눈에 보이는 공백과 달리 줄바꿈되지 않을 때
  • 이모지 또는 아랍어, 페르시아어, 인도계, 몽골어 문자열의 결합 제어를 무조건 삭제하지 않고 검토해야 할 때
  • 숨은 제어 문자를 악의의 증거로 단정하지 않으면서 의심스러운 문자열의 코드 포인트 증거가 필요할 때

단계

  1. 1단계

    정확한 원문과 출처 보존

    원본 파일, 클립보드 값, 데이터베이스 필드, 메시지를 바꾸지 않고 보관합니다. 어디에서 왔고 어떻게 디코딩했으며 어떤 비교 또는 표시 문제가 있었는지 기록합니다. 스크린샷은 보이지 않는 코드 포인트를 보존하지 못하므로 원문이 될 수 없습니다.

  2. 2단계

    텍스트 검사와 바이트 인코딩 분리

    증거가 디코딩된 문자열인지 원본 파일인지 구분합니다. 브라우저 텍스트 맨 앞의 U+FEFF는 보고할 수 있지만 UTF-8, UTF-16, UTF-32 서명은 원본 바이트만 증명할 수 있습니다. 바이트 단위 BOM 작업은 별도 단계로 유지합니다.

  3. 3단계

    제거 없이 먼저 검사

    처음에는 검사만을 선택합니다. 전체 탐지 수, 영향받은 줄, 코드 포인트 종류, 1부터 시작하는 위치, 줄과 열, 이스케이프된 문맥을 확인합니다. 결과가 0이라는 것은 지원 문자 6종이 없다는 뜻이지 보이지 않는 Unicode 문자가 전혀 없다는 뜻은 아닙니다.

  4. 4단계

    각 제어 문자의 가능한 영향 분류

    U+200B와 U+FEFF를 일반 정리 후보로 보되 변경 전에 원문을 확인합니다. ZWNJ, ZWJ, WORD JOINER, MVS는 목적지 계약에서 불필요함이 확인되지 않는 한 보호합니다. 문자 모양, 이모지 시퀀스, 줄바꿈, 몽골어 텍스트에 영향을 줄 수 있습니다.

  5. 5단계

    확인된 최소 집합만 제거

    U+200B와 U+FEFF에는 일반 정리를 사용하고 더 작거나 명시적으로 검토한 집합에는 종류 선택을 사용합니다. 원문 소유자와 목적지 규칙이 문자 결합과 줄바꿈 변화를 허용할 때만 전체 지원 문자를 사용합니다.

  6. 6단계

    정확한 출력과 변경 수 비교

    탐지 수가 제거 수와 보존 수의 합인지 확인하고 처음 변경된 문맥을 원문과 비교합니다. 정규화, 공백 제거, 다른 정리를 실행하기 전에 LF, CRLF, CR, 탭, 공백, 마지막 줄바꿈, 이모지, 다국어 문자 모양을 검증합니다.

  7. 7단계

    목적지 검증과 판단 기록

    데이터베이스, 인증 시스템, 파서, 검색 색인, 편집기, URL 처리기, 게시 시스템 등 실제 소비 시스템에서 민감하지 않은 사본을 시험합니다. 제거한 코드 포인트와 이유를 기록하고 감사 또는 되돌리기가 중요하면 원문을 유지합니다.

예시

이모지 결합 문자를 유지하면서 일반 구분자 제거

입력

account​@example.com
Emoji: 👩‍💻
legacymark

출력

account@example.com
Emoji: 👩‍💻
legacymark

흔한 실수

위치를 검토하기 전에 원문 대체

숨은 제어 문자를 제거하면 위치와 주변 증거를 잃을 수 있습니다. 결과를 적용하기 전에 원문을 보존하고 검사 결과를 남기세요.

ZWJ와 ZWNJ를 무해한 공백으로 삭제

두 문자는 일반 공백이 아니라 서식 제어 문자입니다. 제거하면 이모지가 분리되거나 필기체 및 인도계 문자 모양이 달라질 수 있어 언어와 목적지 문맥이 필요합니다.

디코딩된 U+FEFF를 검증된 파일 BOM으로 단정

브라우저 문자열에는 원래 인코딩 서명 바이트가 남아 있지 않습니다. 바이트 순서나 서명 증거가 중요하면 원본 파일을 별도로 검사하세요.

정규화와 제거를 검토 없이 한 번에 실행

NFC, NFKC, 대소문자 접기, 공백 제거, 줄바꿈 변환은 다른 코드 포인트도 바꿀 수 있습니다. 단계를 분리해야 어떤 작업이 각 차이를 만들었는지 확인할 수 있습니다.

탐지 결과 0을 안전 인증으로 사용

탐지기는 이름이 정해진 제어 문자 6종만 다룹니다. 동형 문자, 양방향 제어, 위험한 링크, 파서 동작, 악성 코드는 각자 별도 검증이 필요합니다.

자주 묻는 질문

왜 정리 전에 검사를 먼저 해야 하나요?

종류, 위치, 줄, 열, 문맥 증거를 보존하기 때문입니다. 이 증거로 우연한 구분자와 의미 있는 결합 문자를 구분하고 더 작고 검토 가능한 변경을 선택할 수 있습니다.

일반 정리가 보호하는 문자는 무엇인가요?

U+200C ZWNJ, U+200D ZWJ, U+2060 WORD JOINER, U+180E MVS를 보존합니다. U+200B와 U+FEFF는 제거하지만 줄바꿈에 영향을 줄 수 있으므로 결과를 원문과 비교해야 합니다.

소스 코드의 ZWJ만 제거하고 이모지 ZWJ는 유지할 수 있나요?

입력을 명확히 나누거나 코드 구조를 이해하는 절차에서 확인된 위치만 제거하세요. 종류 선택은 제출한 텍스트의 모든 U+200D를 제거하며 각 발생 위치가 코드, 언어, 이모지인지 추론하지 않습니다.

동형 문자나 양방향 제어도 탐지하나요?

아닙니다. 고정 범위는 제로 폭 제어 문자 6종입니다. 혼동 문자, 양방향 제어, 변형 선택자, 소프트 하이픈, 다른 기본 무시 문자는 전용 Unicode 보안 검토가 필요합니다.

제거하면 정규화나 CRLF도 바뀌나요?

엔진은 선택한 코드 포인트만 생략합니다. 텍스트 정규화나 LF, CRLF, CR, 탭, 공백, 마지막 줄바꿈을 다시 쓰지 않습니다. 이후 편집기나 목적지는 바꿀 수 있습니다.

기밀 텍스트를 안전하게 검사할 수 있나요?

도구 처리는 브라우저 로컬에서 실행되며 입력을 변환 서버로 보내지 않지만 권한, 브라우저 확장 프로그램, 기기 통제, 결과 목적지는 여전히 중요합니다. 정책에서 요구하면 가린 증거를 사용하세요.