맨위로가기

UTF-7

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

UTF-7은 이메일 헤더 인코딩을 위해 설계된 유니코드 변환 형식으로, ASCII 범위를 벗어나는 문자를 처리하기 위해 개발되었다. MIME의 전송 인코딩 제약으로 인해 UTF-7은 MIME 인코딩된 단어 내에서 문자 집합을 식별해야 했다. UTF-7은 RFC 1642에서 처음 제안되었지만, 이후 표준이 아닌 RFC 2152에 의해 무효화되었다. 이 형식은 처리하기 어렵고 보안 문제로 인해 현재 사용이 권장되지 않으며, 수정된 UTF-7은 IMAP에서 국제 메일함 이름에 사용된다. UTF-7은 ASCII 문자를 직접 표현하고, 다른 문자는 UTF-16으로 인코딩한 후 수정된 Base64로 변환하는 방식으로 작동한다. 보안 취약성으로 인해, UTF-7은 더 이상 널리 사용되지 않으며, .NET과 같은 최신 시스템에서는 지원이 중단되었다.

더 읽어볼만한 페이지

  • 유니코드 변환 형식 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
  • 유니코드 변환 형식 - UTF-1
    UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
  • 유니코드에 관한 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
  • 유니코드에 관한 - UTF-1
    UTF-1은 유니코드 초기 버전을 인코딩하기 위해 1992년에 설계된 가변 길이 문자 인코딩 방식으로, ASCII 호환성을 유지하고 ISO 2022 및 MIME과의 호환성을 고려했지만, "모듈로 190" 산술을 사용하는 특징과 현대 유니코드 표준과의 차이점을 가진다.
  • 문자 인코딩 - 유니코드
    유니코드는 세계의 모든 문자를 하나의 컴퓨터 인코딩 표준으로 통합하기 위해 설계되었으며, 유니코드 컨소시엄에 의해 관리되고 UTF-8, UTF-16, UTF-32 등의 부호화 형식을 제공하지만, 일부 문자 표현 문제, 버전 간 비호환성, 레거시 인코딩과의 호환성 문제 등의 과제를 안고 있다.
  • 문자 인코딩 - UTF-8
    UTF-8은 유니코드 문자를 표현하는 가변 길이 문자 인코딩 방식으로, ASCII 코드와 호환성을 유지하며 다양한 언어의 문자를 표현할 수 있도록 설계되었지만, 보안 문제점과 공간 효율성 측면에서 단점을 가진다.
UTF-7

2. 역사적 배경

UTF-7은 1990년대 중반, 이메일 시스템에서 유니코드 문자를 안전하게 전송하기 위해 제안되었다.

3. 동기

MIME은 이메일 형식의 현대 표준으로, ASCII 범위를 초과하는 바이트 값을 사용하여 헤더를 인코딩하는 것을 금지한다. MIME은 ASCII보다 넓은 다양한 문자 집합으로 메시지 본문을 인코딩하는 것을 허용하지만, 주요 이메일 전송 표준인 SMTP은 여전히 8비트 클린을 보장하지 않는다. 따라서 의심스러운 경우 비자명한 콘텐츠 전송 인코딩을 적용해야 한다. 불행히도, Base64는 비-MIME 클라이언트에서 ASCII 문자를 읽을 수 없게 만드는 단점이 있다. 반면에, UTF-8과 quoted-printable의 조합은 BMP에서 비-ASCII 문자에 6~9바이트, BMP 외부의 문자에 12바이트가 필요한 매우 크기 비효율적인 형식을 생성한다.[3]

4. 특징

62개의 영문 알파벳 및 숫자와 9개의 기호(' ( ) , - . / : ?)는 직접 표현된다. (직접 문자) 선택적 직접 문자를 사용하여 크기를 줄이고 가독성을 높일 수 있지만, 손상 가능성이 높아진다. 공백, 탭, 캐리지 리턴, 줄 바꿈 문자는 직접 표현될 수 있지만, 이메일 전송 시 주의가 필요하다. 그 외의 문자는 UTF-16으로 인코딩된 후, 수정된 Base64로 인코딩된다. 더하기 기호(+)는 '+-'로 인코딩된다.

수정된 Base64에 대한 예시는 다음과 같다. 파운드 기호 U+00A3는 다음과 같이 Base64로 표기한다. 남은 2비트는 0으로 채워진다.

16진수00A3colspan="2" |
비트 패턴000000001010001100
인덱스01012
Base64 인코딩AKM


5. 인코딩 및 디코딩 알고리즘

0010 0000 0010 00000x00A3 ≡ £
0x2020 ≡ †16비트마다 UTF-16BE의 문자 코드로 해석0000000010100011 0010000000100000£†디코딩 결과

[1]

5. 1. 인코딩

인코더는 먼저 어떤 문자를 ASCII 형태로 표현할지, 어떤 '+'를 '+-'로 이스케이프 처리할지, 어떤 문자를 유니코드 문자의 블록에 배치할지를 결정해야 한다. UTF-7의 확장 비용은 높을 수 있다. 예를 들어, 문자 시퀀스 U+10FFFF U+0077 U+10FFFF는 UTF-8에서는 9바이트이지만 UTF-7에서는 17바이트이다. 각 유니코드 시퀀스는 다음 절차를 사용하여 인코딩한 다음, 적절한 구분 기호로 묶어야 한다.

「£†」(U+00A3 U+2020) 문자 시퀀스를 예로 사용하여 인코딩 과정을 설명하면 다음과 같다.

# 문자의 유니코드 숫자(UTF-16)를 이진수로 표현한다.

#* 0x00A3 → 0000 0000 1010 0011

#* 0x2020 → 0010 0000 0010 0000

# 이진 시퀀스를 연결한다.

#* 0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000

# 이진수를 왼쪽부터 6비트 그룹으로 다시 묶는다.

#* 0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00

# 마지막 그룹이 6비트 미만이면 후행 0을 추가한다.

#* 000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000

# 각 6비트 그룹을 해당 Base64 코드로 대체한다.

#* 000000 001010 001100 100000 001000 000000 → AKMgIA

「£†」(U+00A3 U+2020)의 인코딩 과정은 다음과 같이 표로 나타낼 수 있다.

코드이진 표현
£ ≡ 0x00A30000 0000 1010 0011
†≡ 0x20200010 0000 0010 0000
£†0000000010100011 0010000000100000문자열 「£†」의 비트 표기(순서대로 연결)
0000000010100011 0010000000100000000000 001010 001100 100000 001000 00상위 6비트마다 구분하여 분할
000000 001010 001100 100000 001000 00000000 001010 001100 100000 001000 000000최하위도 6비트가 되도록 0으로 채움
000000 001010 001100 100000 001000 000000AKMgIAbase64의 변환표에 따라 인코딩


5. 2. 디코딩

0010 0000 0010 00000x00A3 ≡ £
0x2020 ≡ †16비트마다 UTF-16BE의 문자 코드로 해석0000000010100011 0010000000100000£†디코딩 결과

[1]

6. 수정 UTF-7 (Modified UTF-7)

IMAP4에서 다국어 폴더명(디렉토리명)을 사용하기 위해 사용되는 규격이다.



이 규격은 메일의 일반적인 이용에서 다음과 같은 배경을 고려하여 도입되었다.[9]

# UTF-7은 시프트하기 위해 문자 "+"를 사용하는데, 이는 메일함 이름이나 USENET 뉴스 그룹 이름에서의 "+"의 흔한 사용과 충돌한다.

# UTF-7의 부호화는 문자 "/"를 사용하는 Base64인데, 이는 일반적인 계층 구분자로서의 "/" 사용과 충돌한다.

# UTF-7은 부호화되지 않은 "\"의 사용을 금지하는데, 이는 일반적인 계층 구분자로서의 "\" 사용과 충돌한다.

# UTF-7은 부호화되지 않은 "~"의 사용을 금지하는데, 이는 몇몇 서버에서 홈 디렉토리를 나타내는 "~"의 사용과 충돌한다.

# UTF-7은 동일한 문자열을 표현하기 위해 여러 다른 형식을 허용하는데, 특히 인쇄 가능한 US-ASCII 문자가 부호화 형식으로 표현될 수 있다.

즉, 수정 UTF-7에서는 전자 메일이나 폴더명에서 빈번하게 사용되는 문자를 수정 Base64로 변환하지 않고, 대체로 평문으로 읽을 수 있게 된다.

7. 보안 문제

UTF-7은 동일한 소스 문자열을 여러 방식으로 표현할 수 있다. 특히, ASCII 문자는 유니코드 블록의 일부로 표현될 수 있다. 따라서 UTF-7로 해석될 수 있는 문자열에 표준 ASCII 기반 이스케이핑 또는 유효성 검사 프로세스를 사용하는 경우, 악성 문자열이 유니코드 블록을 사용하여 이러한 프로세스를 우회할 수 있다. 이 문제를 완화하기 위해 시스템은 유효성 검사 전에 디코딩을 수행하고 UTF-7을 자동으로 감지하려는 시도를 피해야 한다.[7]

구버전의 인터넷 익스플로러는 페이지를 UTF-7로 해석하도록 속일 수 있다. 이는 `<` 및 `>` 마크가 UTF-7에서 `+ADw-` 및 `+AD4-`로 인코딩될 수 있으며, 대부분의 유효성 검사기가 이를 일반 텍스트로 통과시키기 때문에 사이트 간 스크립팅 공격에 사용될 수 있다.[7]

UTF-7은 적어도 마이크로소프트 소프트웨어(.NET)에서는 구식으로 간주되며, 2020년 .NET 5에서 이전에 이를 지원하던 코드 경로는 의도적으로 중단되었다(보안 문제 방지).[8]

8. 참고: 바이트 순서 표식 (Byte Order Mark)

바이트 순서 표식(BOM)은 스트림 또는 파일의 맨 처음에 있는 특수 바이트 시퀀스로, 데이터 자체가 아닌, 뒤따르는 데이터에 사용된 인코딩을 나타낸다. 인코딩을 나타내는 메타데이터가 없는 경우에 사용할 수 있다. 주어진 인코딩 방식에서, 이는 유니코드 코드 포인트 `U+FEFF`의 해당 방식의 표현이다.[5]

일반적으로 단일 고정 바이트 시퀀스이지만, UTF-7에서는 네 가지 변형이 나타날 수 있다. 이는 `U+FEFF`의 UTF-7 인코딩의 4번째 바이트의 마지막 2비트가 ''다음'' 문자에 속하여 4가지 가능한 비트 패턴과 4번째 위치에 4가지 다른 가능한 바이트가 있기 때문이다. 유니코드 바이트 순서 표식 표의 UTF-7 항목을 참조한다.[6]

참조

[1] 웹사이트 8.2.2.3. Character encodings https://www.w3.org/T[...] W3C
[2] 웹사이트 12.2.3.3 Character encodings https://html.spec.wh[...] WHATWG
[3] 웹사이트 Using International Characters in Internet Mail https://www.imc.org/[...] 1998-08-01
[4] 웹사이트 Configuration Manual https://doc.dovecot.[...] 2023-02-28
[5] 웹사이트 FAQ – UTF-8, UTF-16, UTF-32 & BOM https://unicode.org/[...]
[6] 웹사이트 Clarify guidance for use of a BOM as a UTF-8 encoding signature https://unicode.org/[...] 2024-01-17
[7] 웹사이트 ArticleUtf7 - doctype-mirror - UTF-7: the case of the missing charset - Mirror of Google Doctype - Google Project Hosting https://code.google.[...] 2012-06-29
[8] 웹사이트 Breaking change: UTF-7 code paths are obsolete https://docs.microso[...] 2021-01-08
[9] IETF RFC 2060
[10] 웹인용 Usage Statistics of UTF-7 for Websites, December 2018 https://w3techs.com/[...] 2018-12-03
[11] 웹인용 Encoding Standard https://encoding.spe[...] 2018-11-15


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com