RobotAutomationDevelopment-Dept/Ubisam-MergeTool

ksj09406 8e28a16fc2 5차 A-1: 실제 소스 인코딩 확인 - 깨지는 파일 0개

실제 저장소 2091개를 MergeHub 로 읽어 봤다. CP949 67개 포함해 깨짐 0, 저장 왕복 어긋남 0.
판별 코드가 TextFile 과 GitService 두 군데에 복사돼 있던 것을 한 곳으로 모았다.
상태바가 KS_C_5601-1987, 목록이 CP949 로 같은 것을 다르게 부르던 것도 맞췄다.

2026-09-11 08:44:16 +09:00

2.9 KiB

Raw Blame History

5차 — 실제 소스에 맞추기 (2026-09-11 ~)

지시서: 작업지시/5차.md

A-1. CP949 파일 67개를 잘못 읽으면 한글이 깨진다 — 완료 (2026-09-11)

지시서가 먼저 확인만 하고 틀리면 고치라고 했다. 확인부터 했다.

잰 것 — 실제 저장소 2,091개 전부

TextFile.Read 로 실제 파일을 한 개씩 읽어 보는 도구를 만들어 돌렸다(원본은 읽기만 하고, 저장 왕복은 사본에만 했다).

실제 인코딩	개수
UTF-8 (BOM)	1,441
UTF-8 (BOM 없음)	353
CP949	67
ASCII 만	230

MergeHub 로 읽었을 때	결과
한글이 깨진 파일	0개
사본에 그대로 저장했을 때 바이트가 달라진 파일 (한글 파일 1,861개)	0개

판정 기준을 이미 만족하고 있었다. 판별 규칙(BOM → 엄격한 UTF-8 → 실패하면 시스템 ANSI)이 실제 소스에서 맞게 돈다. 고칠 것이 없었다.

그래도 고친 것 둘

① 판별 코드가 두 군데에 복사돼 있었다. TextFile.Detect 와 GitService.DetectEncoding 이 글자 하나까지 같은 코드였다. TextFile 주석에는 "판별 규칙은 GitService 와 같다 - 같은 파일을 어느 경로로 열든 결과가 같아야 한다" 고 적혀 있었는데, 지키는 방법이 복사뿐이었다. 한쪽만 고치면 조용히 어긋나고, 그러면 같은 파일이 워킹트리에서는 멀쩡한데 커밋에서 열면 깨져 보인다. 어느 쪽이 맞는지 알 방법도 없다. TextFile.DetectEncoding 하나로 모으고 GitService 는 그것을 부른다.

② 같은 인코딩을 두 이름으로 부르고 있었다. 상태바는 KS_C_5601-1987(코드페이지 949 의 공식 이름), 저장 형식 목록은 CP949. 실제 CP949 파일을 열어 보다가 눈에 띄었다 - "지금 이 파일이 그 CP949 라는 건가" 를 되묻게 된다. FriendlyName 으로 949 는 언제나 CP949 라고 적는다. 두 자리 모두 고쳤다.

확인한 것

확인	결과
실제 CP949 파일(`AXA.cs` 사본)을 열었을 때	`//========== 보드 및 모듈 정보 확인 함수 ...` 그대로 읽힌다
깨진 글자(U+FFFD)	없다
상태바 인코딩	`CP949` (전에는 `KS_C_5601-1987`)
고친 뒤 실제 저장소 2,091개 재확인	깨짐 0개 · 왕복 어긋남 0개 (고치기 전과 같다)

검사를 새로 만들었다(EncTest 16건). 실제 저장소가 없어도 도는 것이 요점이다 - BOM · BOM 없는 UTF-8 · CP949 · ASCII 를 만들어 놓고 읽기 · 왕복 저장 · 형식 바꿔 저장까지 본다. 규칙을 여기 못박아 두면 다음에 누가 고쳐도 바로 걸린다.

전체 587건 통과(하네스 18벌) · 빌드 경고 0 · 오류 0. 실제 저장소는 건드리지 않았다 - 작업 전후 모두 변경 1건(7월부터 있던 것)으로 같다.

2.9 KiB Raw Blame History