텍스트 및 일상 도구 · 텍스트 도구 키트
보이지 않는 문자: 잘림 방지 공백, 너비가 0인 조이너 및 트림
· 배경
텍스트 정리 유니코드 게시
줄바꿈 없는 공백, 너비가 0인 공백 및 결합자, 바이트 순서 표시 등 아무 것도 아닌 것처럼 보이는 문자가 어디서 왔는지, 공백으로 간주되는지, 그리고 이를 찾아 제거하는 방법을 조사합니다.
중복되지 않은 동일한 두 줄 — 보이지 않는 문자가 중복 제거 및 검색을 물리치는 방법
두 줄은 편집기에서 동일하게 보일 수 있지만 동일성, 검색 또는 중복 제거 검사에 실패할 수 있습니다. 하나는 일반 U+0020 공백을 포함하고 다른 하나는 중단되지 않는 공백인 U+00A0을 포함할 수 있습니다. 너비가 0인 문자는 눈에 보이는 너비를 차지하지 않고도 동일한 문제를 일으킬 수 있으며, 게시자에게는 서로 다른 문자열로 남아 있는 명백히 일치하는 두 개의 레이블이 남게 됩니다.
이것은 단순한 화장품이 아닙니다. 숨겨진 코드 포인트는 분석 차원을 분할하고, 정확한 찾기 작업을 무효화하고, 중복 라인을 유지하거나, 복사된 식별자가 유효성 검사에 실패하도록 만들 수 있습니다. 콘텐츠를 눈으로 다시 작성하기 전에 소스의 복사본을 보관하고 의심스러운 문자열을 체계적으로 비교하세요. 시각적 렌더링은 기본 유니코드 시퀀스가 일치한다는 증거가 아니라 모양에 대한 증거입니다.
출처 — 웹 페이지, 워드 프로세서, 이모티콘 시퀀스 및 PDF 복사-붙여넣기
보이지 않는 캐릭터는 일반적으로 일반적인 작업을 통해 도착합니다. 웹 페이지는 단어 잘림 방지 공백을 사용하여 용어를 함께 유지하고, 워드 프로세서는 레이아웃 중심 공백을 유지하며, PDF 추출은 위치가 지정된 문자 모양에서 텍스트를 재구성합니다. 해당 시스템 간에 복사하면 대상에 익숙한 단어와 공백만 표시되는 경우에도 서식 지정 문자를 CMS 필드로 전달할 수 있습니다.
기타 보이지 않는 표시는 쓰기 시스템이나 이모티콘의 의도적인 부분입니다. 너비가 0인 결합자는 이모티콘 구성 요소를 하나의 표시 기호로 결합할 수 있는 반면 결합자와 비결합자는 여러 스크립트의 모양에 영향을 줍니다. 출처가 중요합니다. '볼 수 없음'이 '삭제해도 안전함'을 의미하지는 않습니다. 정리는 진행 너비가 0인 모든 캐릭터가 아닌 진단된 아티팩트를 대상으로 해야 합니다.
공백 계열 — 일반, 잘림 방지, 좁은 표의 문자 공백 및 JavaScript 트림에서 공백으로 간주하는 것
유니코드에는 일상적인 공간 이상의 내용이 포함되어 있습니다. U+00A0은 잘림 방지 공백이고, U+202F는 좁은 잘림 방지 공백이고, U+3000은 표의 문자 공백입니다. JavaScript 공백 처리에는 이러한 문자가 포함되어 있으므로 `trim()`, `trimStart()` 및 `trimEnd()`는 해당 문자가 문자열의 관련 가장자리에 나타날 때 이를 제거할 수 있습니다.
텍스트 도구 키트의 줄 다듬기는 각 줄에서 해당 JavaScript 메서드를 호출합니다. 내부 간격을 정규화하지 않으므로 두 단어 사이에 끊김 없는 공백이 그대로 남아 있습니다. "공백 없는 문자" 통계는 ASCII 공간보다 넓은 JavaScript `s`와 일치하는 문자를 제거합니다. 해당 숫자를 모든 보이지 않는 코드 포인트가 제외된다는 약속이 아니라 정의된 측정값으로 사용하세요.
너비가 0인 계열 — 너비가 0인 공백, 결합자와 비결합자, 단어 결합자 및 바이트 순서 표시(공백이 전혀 아님)
너비가 0인 패밀리는 다른 규칙을 따릅니다. U+200B 너비가 0인 공백, U+200C 너비가 0인 비결합자, U+200D 너비가 0인 결합자 및 U+2060 단어 결합자는 JavaScript 공백이 아닌 형식 문자입니다. 따라서 일반 `trim()`은 이를 제거하지 않습니다. 이러한 표시 중 하나를 포함하는 줄은 단지 화면에 잉크가 표시되지 않는다고 해서 공백이 아닙니다.
U+FEFF에는 두 가지 관련 기록이 있습니다. 인코딩된 데이터의 시작 부분에서는 바이트 순서 표시를 신호할 수 있고, 텍스트에서는 너비가 0인 중단 없는 공백으로 사용되었습니다. ECMAScript는 U+200B부터 U+200D까지와 달리 트림 공백 세트에 U+FEFF를 포함합니다. 따라서 너비가 0인 계열 전체를 공백의 한 종류로 취급하는 것은 실제 JavaScript 동작과 모순됩니다.
탐지 — 문자 카운터를 사용하여 보이는 것과 일치하지 않는 수를 찾아내고, 일부 참여자가 이웃에 붙어 숨어 있다는 것을 기억합니다.
놀라운 개수는 숨겨진 콘텐츠를 알려줄 수 있지만 모든 사례를 식별할 수는 없습니다. ToolAcre는 사용 가능한 경우 `Intl.Segmenter`를 사용하여 문자소 클러스터를 계산합니다. 이모티콘 시퀀스에 참여하는 조이너는 여러 코드 포인트가 하나의 문자소를 형성하는 데 도움이 될 수 있으므로 이를 추가하거나 제거하면 코드 포인트 카운터가 표시하는 간단한 한 문자 증가 없이 렌더링을 변경할 수 있습니다.
몇 가지 단서를 함께 사용하십시오. 정확한 일치 실패, 예상치 못한 "공백 없음" 결과, 유니코드 인식 편집기에서 검사한 복사된 텍스트 또는 특정 코드 포인트에 대한 정규식 검색. 대체 카운터는 Segmenter를 사용할 수 없을 때 코드 포인트를 사용하므로 결과는 브라우저 기능에 따라 다를 수도 있습니다. 계산하면 조사 범위가 좁아집니다. 숨겨진 문자 스캐너나 유니코드 이름 뷰어가 아닙니다.
숨겨진 문자 감지: 개수는 전체 인벤토리가 아닌 단서를 제공합니다.
확인된 복사 및 붙여넣기 아티팩트의 경우 복제 작업을 수행하고 정규식 모드에서 찾기 및 바꾸기를 엽니다. `[]`을 검색하고 아무것도 없는 것으로 바꾸면 텍스트 전체에서 너비가 0인 공백과 포함된 U+FEFF 문자가 제거됩니다. 이 도구는 JavaScript의 전역 플래그를 사용하여 패턴을 컴파일하고 교체 횟수를 보고하며 패턴이 유효하지 않은 경우 텍스트를 변경하지 않고 그대로 둡니다.
해당 패턴을 `[-]`로 자동 확장하지 마세요. 이 범위에서는 스크립트 모양을 변경하고 결합된 이모티콘을 별도의 기호로 분할할 수 있는 U+200C 및 U+200D도 제거됩니다. 검사 결과 원하지 않는 것으로 판명된 경우에만 해당 코드 포인트를 추가하십시오. 교체 후 중복 제거를 실행하고 출력을 게시하기 전에 보존된 원본과 비교합니다.
작업 예: 중복을 제거하기 전에 확인된 원치 않는 너비가 0인 문자만 제거합니다.
이 정리는 양방향 제어 문자, 동형 문자 또는 혼란스러운 텍스트와 관련된 모든 보안 문제를 해결하지 않습니다. 방향 표시는 시각적 순서를 변경할 수 있는 반면, 동형 문자 공격은 서로 유사한 다양한 표시 문자를 사용합니다. 공백을 삭제해도 문제가 해결되지 않으며 무분별한 보이지 않는 문자 정규식은 실제 위험을 놓치면서 합법적인 다국어 콘텐츠를 손상시킬 수 있습니다.
또한 툴킷은 유니코드 또는 여러 줄 모드와 같은 정규식 플래그를 노출하지 않으며, 예정된 일치 항목을 강조 표시하거나, 대체 항목을 개별적으로 실행하지 않습니다. 전체 텍스트에서 모든 작업 바꾸기를 수행하므로 보고된 개수와 실행 취소 작업은 중요한 보호 장치입니다. 소스 코드, 법적 사본 또는 익숙하지 않은 스크립트의 경우 대량 편집을 하기 전에 전용 유니코드 도구를 사용하여 각 문자를 검사하십시오.
테이크아웃 — 눈에 보이지 않는다고 해서 무해하다는 의미는 아닙니다. Text Toolkit의 카운터 및 정규식 찾기 및 바꾸기는 브라우저를 떠나지 않고도 노출 및 제거합니다.
보이지 않는다는 것은 비어 있거나 상호 교환 가능하거나 유해하다는 의미는 아닙니다. 줄바꿈하지 않는 공백은 레이아웃 의미가 있는 공백입니다. 너비가 0인 조이너는 모양 의미를 전달할 수 있습니다. U+FEFF는 JavaScript 트리밍에서 다시 다르게 작동합니다. 정확한 정리는 코드 포인트의 이름을 지정하고 코드 포인트가 존재하는 이유를 이해하고 대상에 여전히 해당 기능이 필요한지 결정하는 것부터 시작됩니다.
텍스트 도구 키트를 제어된 브라우저 측 작업 공간으로 사용하세요. 개수는 불일치를 노출할 수 있고, 정규 표현식 찾기 및 바꾸기는 정확하게 정의된 세트를 제거할 수 있으며, 중복 제거를 통해 숨겨진 차이점이 사라졌는지 확인할 수 있습니다. 원본을 보존하고 기본적으로 조이너 삭제를 방지하며 렌더링된 결과를 확인합니다. 좁고 검토 가능한 수정은 보이지 않는 모든 유니코드를 잔해로 처리하는 것보다 안전합니다.