개발자 도구 · 텍스트 비교
모든 줄이 변경되었나요? Diff의 줄 끝, 후행 공백 및 BOM
· 작동 방식
텍스트 비교 줄 끝 디버깅
모든 행이 다르다고 보고하는 비교의 보이지 않는 세 가지 원인을 진단하고 작성자를 비난하기 전에 어떤 원인이 있는지 알아내는 방법을 보여줍니다.
두 번 저장되고 다시 작성된 동일한 파일 — 두 운영 체제에서 편집된 파일의 일반적인 경우를 설정합니다.
편집자가 보이지 않는 문자를 변경하면 두 번의 저장이 다시 작성된 것처럼 보일 수 있지만 ToolAcre의 동작은 변경된 문자에 따라 달라집니다. 일치하기 전에 줄 끝을 정규화하는 반면, 줄 가장자리의 공백과 시작 부분의 U+FEFF는 다른 옵션이 키를 변경하지 않는 한 일반 줄 내용으로 유지됩니다.
색상으로 추측하는 대신 진단 장치를 만드세요. 끝 부분만 다른 한 쌍, 후행 공백이 다른 다른 쌍, 선행 BOM이 있는 세 번째 쌍을 비교합니다. 제어된 쌍은 한 번에 여러 가지 보이지 않는 변경 사항이 포함된 실제 파일보다 도구의 경계를 더 안정적으로 드러냅니다.
CRLF 대 LF: 모든 줄 끝에 있는 문자 — Windows는 두 문자로 줄을 끝내고 Unix는 한 문자로 줄을 끝내는 이유와 diff가 추가 캐리지 리턴을 보는 방법을 설명합니다.
`splitLines`는 CRLF와 단독 CR을 LF로 바꾼 다음 분할합니다. 테스트를 통해 세 가지 규칙 모두 동일한 배열을 생성하는 것으로 확인되었습니다. 따라서 공백 무시가 꺼져 있어도 CRLF 전용 차이는 보이지 않습니다. 모든 행이 다를 것이라는 개요의 주장은 이 구현과 모순됩니다.
마지막 개행도 추가 행을 생성하지 않습니다. 분할 후 하나의 터미널 빈 항목이 제거됩니다. 중간에 있는 진짜 빈 줄은 비교 단위로 남아 있으므로 이 동작은 파일 종료 규칙과 문서 내부의 의도적인 수직 분리를 구별합니다.
ToolAcre는 비교 전에 CRLF, CR 및 LF를 정규화하므로 종료 전용 변경 사항이 사라집니다.
후행 공백은 원래 줄에 남아 있습니다. 일반적인 비교에서는 `name=value`과 `name=value `의 키가 다릅니다. 공백 무시는 양쪽 끝을 자르고 내부 실행을 축소하므로 해당 옵션은 표시된 동일한 행에서 왼쪽 원본 텍스트를 유지하면서 쌍을 일치시킬 수 있습니다.
라이브러리는 더 좁은 `ignoreTrailingWhitespace` 옵션도 구현하지만 현재 UI에서는 이를 노출하지 않습니다. 기사에서는 사용자가 선택할 수 없는 확인란을 설명해서는 안 됩니다. 제공된 패널은 대소문자 무시, 모든 공백 차이 무시 및 변경되지 않은 긴 실행 축소를 제공합니다.
파일 상단의 바이트 순서 표시 — 일부 편집자가 UTF-8 파일 앞에 추가하는 U+FEFF 문자와 이로 인해 첫 번째 줄만 달라지는 이유를 설명합니다.
JavaScript 텍스트로 디코딩된 UTF-8 바이트 순서 표시는 첫 번째 줄의 시작 부분에서 U+FEFF입니다. `splitLines`에는 명시적인 BOM 제거가 없습니다. 일반적인 일치를 사용하면 해당 문자는 첫 번째 행만 다르게 만들고 이후 행은 동일하게 유지할 수 있습니다.
JavaScript 공백 작업은 공백 무시가 `trim`을 호출할 때 U+FEFF를 공백으로 처리할 수 있지만 이 문서에서는 이를 파일 디코딩 동작으로 일반화하지 않습니다. 편집기는 문자열을 받습니다. 파일 바이트를 읽거나 인코딩을 보고하지 않습니다. 바이트 수준 출처가 중요한 경우 실제 문자를 검사합니다.
실제 사례: 세 가지 원인 구분 — 결정 경로 제공: 첫 번째 줄만 차이가 BOM을 가리키고, 모든 줄이 끝을 가리키고, 흩어진 줄이 후행 공백을 가리킵니다.
`alpha beta` 및 `alpha beta`로 시작하면 결과가 동일합니다. 다음으로 `alpha beta`을 `alpha beta`과 비교합니다. 일반 모드는 대체 행을 보고하고 공백 모드는 이를 일치시킵니다. 마지막으로 한쪽 알파에 U+FEFF 접두사를 붙이고 첫 번째 줄 효과를 관찰합니다.
해당 시퀀스는 저장소에서 입증된 작업을 사용하여 원인을 분리합니다. 정규화를 마친 후에도 모든 줄이 여전히 다른 경우 CRLF만을 비난하기보다는 내용, 들여쓰기 또는 후행 문자를 조사하십시오. 첫 번째 줄만 다른 경우 전체 파일을 다시 작성하기 전에 선행 코드 포인트를 검사하십시오.
공백 옵션을 진단으로 사용 — ToolAcre의 텍스트 비교에서 공백 무시를 활성화하면 후행 공백 및 줄 끝 노이즈를 흡수하여 실제 편집 내용을 돋보이게 하는 방법을 보여줍니다.
공백 무시는 줄 키를 자르고 압축하므로 후행 공백 노이즈에 유용합니다. CRLF와 LF를 숨기는 역할을 하지 않습니다. 이미 분할 중에 일어난 일입니다. 이러한 단계를 별도로 유지하면 어떤 옵션이 비교를 복구했는지에 대한 오해의 소지가 있는 결론을 방지할 수 있습니다.
자르기로 인해 의미 있는 들여쓰기가 숨겨지고 압축으로 인해 고정 너비 값이나 문자열 리터럴이 변경될 수 있으므로 두 보기를 모두 실행하세요. 조용한 정규화된 결과는 해당 변환에서 키가 일치함을 나타냅니다. 원본 파일이 바이트 동일하거나 의미상 상호 교환 가능하다는 것을 인증하지 않습니다.
공백 모드는 후행 공백을 진단하고 줄 끝은 이미 정규화되어 있습니다.
Text diff는 파일 변환, Git 구성, 편집기 설정 변경 또는 16진수 바이트 노출을 수행하지 않습니다. 붙여넣은 문자열을 받아들이고 라인 작업을 보고합니다. `.gitattributes`, `core.autocrlf` 또는 인코딩 복구에 대한 조언은 동작을 별도로 확인할 수 있는 도구에 속합니다.
또한 도구는 보이지 않는 문자가 텍스트에 어떻게 입력되었는지 구별할 수 없습니다. 포맷터, 클립보드, 디코더 또는 수동 편집은 동일한 문자열을 생성할 수 있습니다. 비교를 사용하여 행을 찾은 다음 원인을 할당하기 전에 소스 파이프라인을 검사합니다.
요점: 작성자를 비난하기 전에 보이지 않는 항목을 확인하십시오. 진단 경로를 요약하고 브라우저에서 비교가 실행되는 것을 기록하므로 민감한 파일이 컴퓨터에 유지됩니다.
고정된 순서(끝, 후행 또는 내부 공백, 선행 특수 문자)로 보이지 않는 항목을 확인합니다. ToolAcre의 테스트는 첫 번째 범주에 대해 확실한 결과를 제공하고 해당 옵션은 두 번째 범주를 분리하는 데 도움이 됩니다. 세 번째는 이 경로 외부에 문자 검사기가 필요할 수 있습니다.
브라우저 측 줄 분할로 인해 플랫폼 간 끝 차이가 사라지도록 설계되었습니다. 이는 편리하지만 이 도구가 두 소스 파일이 동일한 물리적 개행 바이트를 사용한다는 것을 증명할 수 없다는 의미이기도 합니다. 정확한 와이어 또는 저장소 표현을 보존하는 것이 요구사항인 경우 바이트 인식 유틸리티를 선택하십시오.