이 등호(=) 기호들은 도대체 뭐지?

• 최근 트위터에 옛 이메일 인용문이 퍼지며, 문장 끝의 등호(=) 가 왜 생기는지에 대한 의문이 제기됨
• 이 기호는 ‘quoted-printable’ 인코딩 과정에서 생기는 것으로, 긴 줄을 강제로 나눌 때 줄이 이어짐을 표시하기 위해 사용됨
• 이메일 전송 시 CRLF(캐리지리턴+라인피드) 를 줄바꿈으로 쓰는데, 이를 Unix의 NL 로 변환할 때 디코딩 알고리듬이 잘못 작동하면 등호가 남거나 문자가 손실됨
• 등호는 줄바꿈 외에도 비ASCII 문자(예: =C2=A0) 를 표현하는 데 쓰이며, 잘못된 디코더가 이를 단순 치환해 오류를 유발함
• 문제의 원인은 버그가 있는 디코딩 로직과 부적절한 변환 처리로, 이메일을 가공한 사람이 기술적으로 미숙했음을 보여줌

이메일 인용문 속 등호(=)의 정체

• 최근 며칠간 트위터에 옛 이메일 인용문이 다수 공유되며, 문장 끝의 등호 기호가 눈에 띄는 현상 발생

  • 작성자는 이를 코드나 OCR(광학문자인식) 오류로 오해하는 주장들을 반박
  • 실제로는 이메일을 읽기 쉽게 변환한 과정에서 발생한 인코딩 처리 오류임

• 이메일은 과거 단순 텍스트였으나, 긴 줄이나 특수문자를 처리하기 위해 ‘quoted-printable’ 인코딩이 도입됨

  • 긴 줄을 나눌 때 줄 끝에 등호(=)를 붙여 “이 줄은 이어진다”는 의미를 표시
  • 이때 등호 다음에는 CRLF(캐리지리턴+라인피드) 가 붙음

줄바꿈 인코딩과 디코딩 오류

• 이메일 서버는 CRLF 줄바꿈을 표준으로 사용하지만, Unix 시스템은 NL만 사용

  • 변환 과정에서 한 바이트가 줄어들며, 디코더가 이를 잘못 처리하면 등호가 남거나 문자가 빠짐
  • 예시로, “non- =CRLF cloven”이 잘못 처리되면 “non- loven”처럼 ‘c’가 사라짐

• 일부 구현체는 줄 끝의 등호를 발견하면 두 문자를 삭제하는 방식으로 처리

  • 이 알고리듬이 Unix 형식 파일에서는 오작동해 등호가 그대로 남는 현상 발생

등호의 또 다른 용도: 비ASCII 문자 인코딩

• 등호는 줄바꿈 외에도 비ASCII 문자 인코딩에 사용됨

  • 예: “=C2=A0”은 non-breaking space(줄바꿈 방지 공백) 을 의미
  • 이메일 본문에서 들여쓰기나 특수문자 표현 시 자주 등장

• 작성자는 일부 변환자가 =C2, =A0 등을 단순 치환(search-replace)만 하고, 정상적인 디코더를 사용하지 않은 것으로 추정

기술적 배경과 표준

• RFC 2045 표준은 quoted-printable 인코딩을 전송용(transport) 으로 정의

  • 수신 후에는 디코딩되어 깨끗한 텍스트로 저장되는 것이 원칙
  • 그러나 실제 구현에서는 이 과정이 생략되어, 줄바꿈 처리 오류가 잦음

• 예시 코드에서 (quoted-printable-decode-string "he=\nllo") 는 "hello" 로 정상 복원됨

  • 이는 SMTP 서버 맥락에서 CRLF를 가정한 알고리듬을 재사용했기 때문
  • Windows 기반 파일에서는 정상 작동하지만, Unix 기반에서는 실패함

결론

• 이메일 인용문 속 등호는 quoted-printable 인코딩의 잔재이며,
  줄바꿈 처리와 비ASCII 문자 디코딩의 결함이 결합된 결과
• 문제의 근본 원인은 부정확한 디코더 구현과 인코딩 변환 실수
• 작성자는 이를 “기술적 문제이자, 잘못된 처리의 결과”로 요약하며,
  이메일 변환 과정의 세밀한 표준 준수가 필요함을 강조함