UTF-7

UTF-7
UTF-7
언어국제
표준.RFC 2152
분류Unicode Transformation Format, ASCII Armor, 가변폭 부호화, 스테이트풀 부호화
변환/인코딩ISO/IEC 10646(유니코드)
선행HZ-GB-2312
에 의해 성공자UTF-8 over 8BITIME

UTF-7(7-bit Unicode Transformation Format)은 ASCII 문자 스트림을 사용하여 Unicode 텍스트를 나타내기 위한 오래된 가변 길이 문자 인코딩입니다.원래는 UTF-8과 따옴표 인쇄 가능을 조합하는 것보다 효율적인 인터넷 전자 메일메시지로 사용하기 위한 Unicode 텍스트 인코딩 수단을 제공하기 위한 것입니다.

UTF-7(RFC에 따르면)은 BMP(이모지와 많은 다른 문자를 포함하지 않는 최초의 65536 유니코드 코드 포인트)의 코드 포인트만 인코딩할 수 있기 때문에 "유니코드 변환 포맷"이 아닙니다.단, UTF-7 트랜슬레이터가 UTF-16으로 송수신하는 경우, 각 대행의 절반을 16비트코드 포인트인 것처럼 부호화할 수 있기 때문에, 모든 코드 포인트를 부호화할 수 있습니다.다른 UTF-7 소프트웨어(UTF-32 또는 UTF-8로의 변환기 등)가 이것을 서포트하고 있는지는 불명확합니다.

UTF-7은 유니코드 컨소시엄의 공식 표준이 된 적이 없습니다.보안 문제가 있는 것으로 알려져 [1]있기 때문에 소프트웨어를 사용하지 않도록 변경했습니다.HTML [2][3]5에서는 금지되어 있습니다.

동기

MIME은 E-메일 포맷의 최신 표준으로 ASCII 범위보다 큰 바이트 값을 사용하여 헤더를 인코딩하는 것을 금지하고 있습니다.MIME 에서는, 다양한 문자 세트(ASCII 보다 넓은 범위)로 메시지 본문을 부호화할 수 있습니다만, 기반이 되는 전송 인프라스트럭처(SMTP, 메인 전자 메일 전송 규격)는, 8 비트의 클린은 보증되지 않습니다.따라서 의심스러운 경우 중요하지 않은 콘텐츠 전송 인코딩을 적용해야 합니다.유감스럽게도 base64에는 MIME 이외의 클라이언트에서는 US-ASCII 문자조차 읽을 수 없게 되는 단점이 있습니다.한편, UTF-8과 따옴표 인쇄 가능을 조합하면, 비ASC에서는 6 ~9 바이트의 사이즈가 매우 비효율적인 포맷이 됩니다.BMP로부터의 II 문자, BMP 이외의 문자의 12 바이트.

부호화 중에 특정 규칙을 따르는 경우 기본 MIME 전송 부호화를 사용하지 않고 UTF-7을 이메일로 전송할 수 있지만 텍스트 문자 세트로 명시적으로 식별해야 합니다.또, 「Subject:」등의 전자 메일 헤더내에서 사용하는 경우는, 문자 세트를 식별하는 MIME 부호화 워드에 UTF-7 를 포함할 필요가 있습니다.인코딩된 단어는 따옴표 인쇄 가능 또는 base64를 사용하도록 강제하기 때문에 UTF-7은 따옴표 인쇄 가능(또는 헤더의 변형인 RFC 2047/1522 ?Q?-encoding)과 결합될 때 = 기호를 이스케이프 문자로 사용하지 않도록 설계되었습니다.

UTF-7은 처리하기가 매우 어렵기 때문에 일반적으로 응용 프로그램 내에서 네이티브 표현으로 사용되지 않습니다.UTF-8을 인용 인쇄 가능 또는 base64와 조합하는 것보다 크기 면에서 유리하지만 현재는 폐지된 Internet Mail Consortium은 사용을 [4]권장하지 않습니다.

8BITMIME도 도입되어 메시지 본문을 7비트 형식으로 인코딩할 필요가 없어졌습니다.

UTF-7('[5]mUTF-7'[citation needed]이라고도 함)의 수정된 형식이 현재 IMAP 전자 메일 검색 프로토콜에서 우편함 이름에 사용됩니다.

묘사

UTF-7은 RFC 1642 "A Mail-Safe Transformation Format of Unicode"에서 실험 프로토콜로 처음 제안되었습니다.이 RFC는 표준이 된 적이 없는 정보 RFC인 RFC 2152에 의해 폐지되었습니다.RFC 2152가 명확하게 기술하고 있듯이 RFC는 "어떤 종류의 인터넷 표준도 규정하지 않는다"고 되어 있습니다.그럼에도 불구하고 RFC 2152는 IANA의 문자 목록에서 UTF-7의 정의로 인용되고 있습니다.UTF-7도 Unicode 표준이 아닙니다.Unicode Standard 5.0에는 UTF-8, UTF-16 및 UTF-32만 기재되어 있습니다.또, RFC 2060에 규정되어 있는 수정판도 있습니다.이 버전은 UTF-7로 식별되는 경우가 있습니다.

일부 문자는 단일 ASCII 바이트로 직접 표시할 수 있습니다.첫 번째 그룹은 "다이렉트 문자"로 알려져 있으며 62개의 영숫자와 9개의 기호를 포함합니다.' ( ) , - . / : ?. 직접 문자는 문자 그대로 포함해도 안전합니다."옵션 직접 문자"로 알려진 다른 주 그룹에는 U+0020 범위의 다른 모든 인쇄 가능한 문자가 포함됩니다.U+007E 제외~ \ +및 공백(문자)\그리고.~JIS-Roman과 같은 "ASCII 변수"에서 재정의되어 제외됩니다.옵션인 직접 문자를 사용하면 크기가 작아지고 사람의 가독성이 향상되지만 잘못 설계된 메일 게이트웨이와 같은 것으로 인해 파손될 가능성이 높아지며 헤더 필드에 인코딩된 단어로 사용할 경우 추가적인 이스케이프가 필요할 수 있습니다.

공간, 탭, 캐리지 리턴 및 라인 피드는 단일 ASCII 바이트로 직접 표시할 수도 있습니다.단, 인코딩된 텍스트를 전자 메일에서 사용하는 경우 이러한 문자가 전자 메일에 적합하도록 더 이상의 콘텐츠 전송 인코딩을 필요로 하지 않는 방식으로 사용되도록 주의해야 합니다.플러스 기호(+)는 다음과 같이 부호화할 수 있습니다.+-.

그 외의 문자는 UTF-16으로 부호화(따라서 U+10000 이후는 2개의 대용 문자로 부호화), 그 후 변경된 Base64로 부호화해야 합니다.변경된 Base64 부호화 UTF-16 블록의 시작은+부호. 끝은 수정된 Base64 세트에 포함되지 않은 문자로 표시됩니다.변경된 Base64 뒤의 문자가-(ASCII 하이픈 마이너스) 디코더에 의해 소비되어 다음 문자부터 디코딩이 재개됩니다.그렇지 않으면 디코딩은 base64 뒤에 나오는 문자와 함께 재개됩니다.

예

  • "Hello, World!"는 " 로 인코딩됩니다.Hello, World+ACE-"
  • "1 + 1 = 2"는 " 로 인코딩됩니다.1 +- 1 +AD0- 2"
  • "£1"는 " 로 인코딩됩니다.+AKM-1". 파운드 기호의 Unicode 코드 포인트는 U+00A3로, 아래 표와 같이 Base64로 변환됩니다.0으로 패딩된 두 개의 비트가 남아 있습니다.
16진수 0 0 A 3
비트 패턴 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0
색인 0 10 12
Base64-인코딩 A K M

부호화 및 복호화 알고리즘

부호화

먼저 인코더는 ASCII 형식으로 직접 표시할 문자를 결정해야 합니다.+로서 벗어나야 한다.+-및 Unicode 문자 블록에 배치해야 합니다.UTF-7의 확장 비용은 높을 수 있습니다.예를 들어 UTF-8에서는 U+10FFF U+0077 U+10FFF의 문자 시퀀스는 9바이트이지만 UTF-7에서는 17바이트입니다(최악의 경우 각 코데포인트를 자신의 오른쪽 시퀀스로 취급하면 최대 5g의 부호화가 발생합니다).@@~하듯이+AEA-+AEA-각 Unicode 시퀀스는 다음 절차에 따라 인코딩한 후 적절한 구분 기호로 둘러싸야 합니다.

£ （ U + 00A3 U + 2020 ）문자 시퀀스를 예로 사용합니다.

  1. 캐릭터의 유니코드 번호(UTF-16)를 바이너리로 나타냅니다.
    • 0x00A3 → 0000 0000 1010 0011
    • 0x2020 → 0010 0000 0010 0000
  2. 이진 시퀀스를 연결합니다.
    0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
  3. 왼쪽부터 시작하여 바이너리를 6비트 그룹으로 다시 묶습니다.
    0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
  4. 마지막 그룹의 비트 수가 6비트 미만일 경우 후행 0을 추가합니다.
    000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
  5. 6비트의 각 그룹을 각각의 Base64 코드로 바꿉니다.
    000000 001010 001100 100000 001000 000000 → AKMgIA

디코딩

먼저 부호화된 데이터는 설명 섹션에서 설명한 대로 플레인 ASCII 텍스트 청크(+e 뒤에 대시 포함)와 비어 있지 않은 Unicode 블록으로 구분해야 합니다.이 처리가 완료되면 다음 절차에 따라 각 Unicode 블록을 디코딩해야 합니다(위의 인코딩 예시를 사용).

  1. 각 Base64 코드를 나타내는 비트시퀀스로 나타냅니다.
    AKMgIA → 000000 001010 001100 100000 001000 000000
  2. 왼쪽부터 시작하여 바이너리를 16비트 그룹으로 다시 묶습니다.
    000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
  3. 끝에 0만을 포함하는 불완전한 그룹이 있는 경우 해당 그룹을 폐기합니다(완전한 그룹에 1이 포함되어 있는 경우 코드는 유효하지 않습니다).
    0000000010100011 0010000000100000
  4. 16비트의 각 그룹은 문자의 Unicode(UTF-16) 번호이며, 다른 형식으로 나타낼 수 있습니다.
    0000 0000 1010 0011 ≡ 0x00A3 ≡ 16310

바이트 순서 표시

바이트 순서 마크(BOM)는 스트림 또는 파일의 맨 앞에 있는 옵션의 특수 바이트 시퀀스이며, 데이터 자체가 아니라 후속 데이터에 사용되는 인코딩을 나타냅니다. 인코딩을 나타내는 메타데이터가 없는 경우에도 사용할 수 있습니다.특정 인코딩 스킴에 대해 유니코드 코드 포인트의 스킴의 표현입니다.U+FEFF를 클릭합니다.[6]

UTF-7에서는 일반적으로 1개의 고정 바이트시퀀스이지만 UTF-7 인코딩의 4번째 바이트의 마지막 2비트가 나타나기 때문에 4가지 변형이 나타날 수 있습니다.U+FEFF는 다음 문자에 속하므로 4개의 비트패턴이 발생하며, 따라서 4번째 위치에 4개의 다른 바이트가 발생하게 됩니다.Unicode 바이트 순서 [7]마크의 표의 UTF-7 엔트리를 참조해 주세요.

보안.

UTF-7 에서는, 같은 송신원스트링을 복수 표현할 수 있습니다.특히 ASCII 문자는 Unicode 블록의 일부로 나타낼 수 있습니다.따라서 표준 ASCII 기반 이스케이프 또는 검증 프로세스를 나중에 UTF-7로 해석할 수 있는 문자열로 사용할 경우 Unicode 블록을 사용하여 악의적인 문자열을 슬립할 수 있습니다.이 문제를 완화하려면 검증 전에 디코딩을 실행하여 UTF-7 자동검출을 피해야 합니다.

이전 버전의 Internet Explorer는 UTF-7로 페이지를 해석하도록 속일 수 있습니다.이는 사이트 간 스크립팅 공격에 사용할 수 있습니다.<그리고.>마크는 로 부호화할 수 있습니다.+ADw-그리고.+AD4-UTF-7에서는 대부분의 검증자가 단순한 [8]텍스트로 통과시킵니다.

UTF-7은 적어도 Microsoft 소프트웨어(.)에서는 사용되지 않는 것으로 간주됩니다.(보안 문제를 방지하기 위해) 이전에 코드 경로를 지원했던 NET)을 참조해당 코드 패스는 보안 문제를 방지하기 위해 의도적으로 파손되었습니다.NET 5, [1]2020년

레퍼런스

  1. ^ a b "Breaking change: UTF-7 code paths are obsolete". docs.microsoft.com. Retrieved 8 January 2021.
  2. ^ "8.2.2.3. Character encodings". HTML 5.1 Standard. W3C.
  3. ^ "12.2.3.3 Character encodings". HTML Living Standard. WHATWG.
  4. ^ "Using International Characters in Internet Mail". Internet Mail Consortium. 1 August 1998. Archived from the original on 7 September 2015.
  5. ^ RFC 3501 섹션 5.1.3
  6. ^ "FAQ – UTF-8, UTF-16, UTF-32 & BOM".
  7. ^ https://unicode.org/L2/L2021/21038-bom-guidance.pdf[베어 URL PDF]
  8. ^ "ArticleUtf7 - doctype-mirror - UTF-7: the case of the missing charset - Mirror of Google Doctype - Google Project Hosting". 14 October 2011. Retrieved 29 June 2012.

「 」를 참조해 주세요.