텍스트 비교
Myers 방식 최장 공통 부분수열로 줄 단위 비교를 수행합니다.
대소문자 무시
공백 무시
원본
변경본
+2
-1
동일 2줄
변경된 줄만
11 the quick brown fox
2-jumps over
2+leaps over
33 the lazy dog
4+and naps
두 텍스트를 줄 단위로 비교해 무엇이 바뀌었는지 정확히 보여줍니다. 설정 파일, API 응답, 번역문, 누군가 말없이 고친 문단을 확인할 때 씁니다.
똑같아 보이는데 동작이 다른 두 파일은 대개 눈에 보이지 않는 곳이 다릅니다. 줄 끝의 공백, 한쪽은 탭이고 다른 쪽은 스페이스인 들여쓰기, 윈도우의 CRLF와 나머지 환경의 LF 같은 것들입니다. 눈으로 비교하면 셋 다 놓치지만 문자 단위 비교는 놓치지 않습니다.
이 페이지는 줄 단위로 비교한 뒤 바뀐 줄 안에서 다시 비교합니다. 긴 문단에서 한 단어만 고쳤다면 줄 전체가 교체된 것이 아니라 그 단어가 바뀐 것으로 표시됩니다. 대소문자와 공백을 무시하는 옵션은 찾으려는 차이가 정말 내용일 때를 위한 것입니다.
비교 결과는 무엇이 바뀌었는지의 목록이 아니라 한쪽 텍스트를 다른 쪽으로 바꾸는 가장 짧은 편집 절차이고, 둘이 늘 같지는 않습니다. 보통 쓰이는 알고리즘은 가장 긴 공통 부분 수열을 찾으므로, 파일 위쪽에 있던 줄 뭉치가 아래로 옮겨졌을 때 이동으로 표시되지 않고 한쪽에서 삭제되고 다른 쪽에서 삽입된 것으로 보고됩니다. 이 사실을 알아 두면 순서만 바뀐 설정 파일이 통째로 다시 쓰인 것처럼 보일 때 시간을 아낄 수 있습니다. 내용은 그대로이고, 알고리즘이 이동을 가진 어휘만으로 설명하고 있는 것입니다.
어떤 차이는 문자 자체가 보이지 않아서 눈에 띄지 않습니다. 한글 음절은 한 개의 코드 포인트로도, 낱자 조합으로도 저장될 수 있습니다. 한 은 U+D55C 이기도 하고 U+1112 U+1161 U+11AB 라는 연속이기도 합니다. macOS를 거친 텍스트는 분해된 형태로 도착하는 반면 다른 곳에서 온 같은 텍스트는 결합된 형태일 수 있습니다. 웹 페이지에서 붙여넣어 딸려 온 줄바꿈 없는 공백, 편집기가 남긴 폭 없는 문자, 서로 다른 두 종류의 작은따옴표도 모두 같은 결과를 냅니다. 화면에서는 두 줄이 똑같아 보이는데 바뀐 줄로 표시되는 것입니다. 그런 일이 생기면 대개 이것이 이유이고, 문자 단위 비교가 존재하는 이유이기도 합니다.
공백 무시 옵션은 편의 기능이 아니라 판단입니다. 산문을 비교하거나 서식만 다시 잡힌 소스 파일을 비교할 때는 무시하는 쪽이 맞습니다. 반대로 파이썬, YAML, Makefile에서는 들여쓰기와 탭 문자가 의미의 일부이므로 그것을 감추는 비교는 찾으려는 버그를 함께 감춥니다. 같은 JSON을 압축한 것과 보기 좋게 정렬한 것을 비교할 때도 논리는 같습니다. 양쪽을 같은 방식으로 먼저 정렬하면 모든 줄이 바뀌었다는 보고가 실제로 다른 한 필드에 대한 보고로 바뀝니다. 애초에 원했던 비교가 그것입니다.
이것은 두 방향 비교이고, 버전 관리 시스템이 병합할 때 하는 세 방향 비교와 구분해 둘 값어치가 있습니다. 두 방향 비교는 두 파일이 다르다는 사실을 보여 주지만 어느 쪽이 바뀐 것인지는 알 수 없습니다. 둘이 어디서 출발했는지에 대한 기록이 없기 때문입니다. 병합 도구가 더하는 것이 정확히 그 공통 조상이고, 그래서 두 방향 화면이 차이를 보고만 할 수 있는 자리에서 한쪽을 자동으로 채택할 수 있습니다. 수정 내용을 검토하거나, 두 번 내려받은 파일을 비교하거나, 설정을 정상 사본과 대조하는 용도라면 두 방향이 맞는 모양이고 조상이 있어도 보태 줄 것이 없습니다.
아니요. 비교는 브라우저 안에서만 이루어집니다.
파일 내용을 두 칸에 붙여넣으면 됩니다. 파일이 아니라 텍스트를 비교합니다.
줄 단위로 비교합니다. 코드와 설정에는 이 단위가 적절합니다. 산문이라면 긴 문단을 짧은 줄로 나눈 뒤 비교하세요.