전각 ↔ 반각 변환기 (전각문자 반각문자)

같은 ‘A’가 두 개 있습니다

화면에 A와 Ａ를 나란히 놓으면 폭만 다를 뿐 같은 글자처럼 보입니다. 하지만 컴퓨터에게 이 둘은 완전히 다른 문자입니다. 왼쪽 반각 A는 코드 U+0041, 오른쪽 전각 Ａ는 U+FF21 입니다. 이 “보기엔 같지만 코드는 다른” 성질이 온갖 조용한 오류의 원인입니다.

전각(full-width)은 한글·한자의 넓은 사각형 칸에 폭을 맞춘 영문·숫자·기호 (Ａ·１·！)이고, 반각(half-width)은 영문 타자기에서 온 좁은 폭의 일반 문자(A·1·!)입니다. 한글 문서 안에서 숫자를 나란히 적어도 줄 간격이 흐트러지지 않게 하려고 전각이 만들어졌지만, 웹·데이터 처리에서는 이 전각이 섞여 들어오면 문제가 됩니다.

실무에서 전각이 만드는 사고

• 로그인·인증 실패 — 아이디나 쿠폰코드에 전각 Ａ가 섞이면 반각 A로 저장된 값과 안 맞아 “분명히 똑같이 쳤는데” 로그인이 안 됩니다.
• 검색 0건 — 전각 １２３으로 저장된 값을 반각 123으로 검색하면 아무것도 안 나옵니다.
• 중복·정렬 오류 — 두 값을 비교하는 프로그램은 Ａ와 A를 다른 값으로 보아, 같은 데이터가 중복으로 쌓이거나 엉뚱하게 정렬됩니다.
• 엑셀·CSV — 일본·중국에서 온 데이터, 또는 IME(입력기) 설정 탓에 전각 숫자가 섞이면 SUM이 안 되고 숫자가 텍스트로 취급됩니다.

가장 고약한 것: 전각 공백

전각 문자 중에서도 특히 조용한 사고뭉치가 전각 공백(U+3000, ideographic space)입니다. 일반 공백보다 넓지만 화면에서는 그냥 빈칸으로 보여서, 이름·주소 끝이나 엑셀 셀에 섞여 있어도 눈으로는 절대 안 보입니다.

"홍길동 "   ← 끝에 전각 공백(U+3000)이 숨어 있다
"홍길동 "   ← 일반 공백(U+0020)

두 값은 눈엔 같지만 코드가 달라 "다른 사람"으로 취급된다.
trim() 을 걸어도 전각 공백은 안 지워지는 경우가 많다.

그래서 “값이 분명히 같은데 시스템이 다르다고 한다”거나 “공백을 지웠는데 여전히 남아 있다”면, 십중팔구 이 전각 공백입니다. 위 변환기는 입력에 전각 공백이 몇 개 숨어 있는지 세어 알려 주고 일반 공백으로 바꿔 줍니다.

변환의 원리: 0xFEE0 이라는 간격

전각↔반각 변환이 정확한 이유는 두 문자 집합이 유니코드에 일정한 간격으로 나란히 놓여 있기 때문입니다.

반각  !  "  #  …  A  …  z  ~     (U+0021 ~ U+007E)
전각  ！ ＂ ＃ …  Ａ …  ｚ  ～    (U+FF01 ~ U+FF5E)
        └──────── + 0xFEE0 (65248) ────────┘

공백만 예외:  반각 U+0020  ↔  전각 U+3000

그래서 변환은 출력 가능한 ASCII 문자에 0xFEE0을 더하면 전각, 빼면 반각이 됩니다(공백만 따로 대응). 규칙이 단순하고 빈틈이 없어 왕복해도 값이 보존됩니다. 코드값을 직접 확인하고 싶다면 아스키코드 변환기에서 A가 65(U+0041) 인 것을, 그리고 전각 Ａ가 U+FF21인 것을 나란히 볼 수 있습니다.

한 가지 짚어 둘 것은 이 도구가 다루는 범위입니다. ASCII 영문·숫자·기호와 공백만 변환하고, 반각 가타카나나 반각 한글 자모처럼 탁점·결합 규칙이 따로 있는 문자는 건드리지 않고 그대로 통과시킵니다. 여러 줄 문서 전체의 연속 공백·빈 줄 정리는 이 zone이 아니라 형제 사이트 TextKit의 공백 정리 도구가 맡습니다 — 이 변환기는 “문자 폭을 통일”하는 데 집중합니다.