인코딩 이해

아티클
08/20/2008

업데이트: 2007년 11월

.NET Framework에서는 내부적으로 텍스트를 유니코드 UTF-16으로 저장합니다. 인코더에서는 이 텍스트 데이터를 바이트 시퀀스로 변환하고, 디코더에서는 바이트 시퀀스를 이 내부 형식으로 변환합니다. 인코딩은 인코더나 디코더의 작동 규칙을 설명합니다. 예를 들어, UTF8Encoding 클래스는 바이트 시퀀스로 인코딩하고 바이트 시퀀스를 디코딩하기 위한 규칙을 설명합니다. 바이트 시퀀스는 텍스트를 유니코드 UTF-8로 나타냅니다. 인코딩 및 디코딩에는 몇 가지 유효성 검사 단계도 포함될 수 있습니다. 예를 들어, UnicodeEncoding 클래스는 모든 서로게이트가 올바른 서로게이트 쌍으로 구성되었는지 확인합니다. 이러한 클래스는 모두 Encoding 클래스에서 상속됩니다.

인코딩 선택

유니코드 표준에서는 지원되는 모든 언어의 각 문자에 코드 포인트(숫자)를 할당합니다. UTF(유니코드 변환 형식)는 코드 포인트를 인코딩하는 한 가지 방법입니다. System.Text의 클래스에서 지원되는 UTF에 대한 자세한 내용은 .NET Framework의 유니코드에서 유니코드 인코딩 사용을 참조하십시오.

인코딩 클래스 선택

Encoding 클래스는 매우 일반적인 클래스입니다. .NET 응용 프로그램에서는 Encoding에서 상속되는 지원 클래스를 사용하여 레거시 응용 프로그램에서 필요할 수 있는 일반적인 인코딩 작업을 수행할 수 있으며 추가 인코딩을 구현할 수 있습니다. 그러나 인코딩을 선택할 수 있는 경우에는 일반적으로 유니코드 인코딩인 UTF8Encoding이나 UnicodeEncoding(UTF32Encoding도 지원됨)을 사용하는 것이 좋습니다. 특히 ASCIIEncoding보다 UTF8Encoding을 사용하는 것이 좋습니다. 콘텐츠가 ASCII인 경우에는 두 인코딩이 동일하지만 UTF8Encoding은 모든 유니코드 문자도 나타낼 수 있는 반면 ASCIIEncoding은 U+0000에서 U+007F 사이의 유니코드 문자 값만 지원합니다. ASCIIEncoding은 오류 검색을 제공하지 않으므로 보안상으로도 UTF8Encoding을 사용하는 것이 더 좋습니다.

UTF8Encoding은 인코딩 속도를 가능한 한 높일 수 있도록 조정되었으므로 다른 인코딩보다 속도가 빠릅니다. 콘텐츠 전체가 ASCII인 경우에도 UTF8Encoding으로 작업을 수행하는 속도가 ASCIIEncoding의 경우보다 빠릅니다. ASCIIEncoding은 특정 레거시 응용 프로그램에만 사용하는 것이 좋습니다. 그러나 이러한 경우에도 UTF8Encoding을 사용하는 것이 더 좋습니다. 기본 설정에서는 다음과 같은 경우가 발생할 수 있습니다.

응용 프로그램에서 일부가 ASCII가 아닌 콘텐츠를 ASCIIEncoding으로 인코딩하면 ASCII가 아닌 각 문자가 물음표("?")로 인코딩됩니다. 그런 다음 응용 프로그램에서 이 데이터를 인코딩하면 정보가 손실됩니다.
응용 프로그램에서 일부가 ASCII가 아닌 콘텐츠를 UTF8Encoding으로 인코딩하면 ASCII로 해석할 때 알아볼 수 없는 결과가 나타납니다. 그러나 응용 프로그램에서 이 데이터를 디코딩하면 데이터가 성공적으로 복원됩니다.

대체 전략 선택

응용 프로그램에서 문자를 인코딩/디코딩하려고 할 때 매핑이 없는 경우를 대비하여 오류 처리 메커니즘인 대체 전략을 구현해야 합니다. 다음과 같은 두 가지 유형이 있습니다.

최적 문자 대체

대상 인코딩/디코딩에 정확히 일치하는 문자가 없는 경우 응용 프로그램에서 해당 문자를 비슷한 문자로 매핑할 수 있습니다.
대체 문자열 대체

비슷한 문자가 없는 경우 응용 프로그램에서 대체 문자열을 지정할 수 있습니다.

예를 들어 응용 프로그램에서 GetEncoding(1252, 0, 0)(GetEncoding 참조)을 호출할 수 있습니다. 이렇게 하면 코드 페이지 1252(서유럽어를 위한 Windows 코드 페이지)가 지정되고 encoderFallback 및 decoderFallback이 0으로 지정됩니다. 기본 동작은 특정 유니코드 문자에 가장 적합한 문자를 매핑하는 것입니다. 예를 들어, CIRCLED LATIN CAPITAL LETTER S(U+24C8)는 인코딩되기 전에 LATIN CAPITAL LETTER S(U+0053)로 변경되고, SUPERSCRIPT FIVE(U+2075)는 DIGIT FIVE(U+0035)로 변경됩니다. 그런 다음 응용 프로그램에서 코드 페이지 1252를 다시 유니코드로 디코딩하면 문자 주위의 원이 사라지고 2⁵는 25가 됩니다. 보다 심하게 왜곡되는 경우도 있습니다. 예를 들어 유니코드의 INFINITY 기호(U+221E)는 DIGIT EIGHT (U+0038)에 매핑됩니다.

최적 문자 대체 전략은 코드 페이지에 따라 달라지지만 여기에서는 이에 대해 자세히 설명하지 않습니다. 예를 들어 일부 코드 페이지에서는 전자 라틴 문자가 보다 일반적인 반자 라틴 문자로 매핑되지만 다른 코드 페이지에서는 그렇지 않습니다.

적극적인 최적 문자 대체 전략에서도 일부 인코딩에서는 일부 문자에 가장 적합한 문자가 없는 경우가 있습니다. 예를 들어 중국어 표의 문자는 코드 페이지 1252로 적절히 매핑되지 않으므로 대체 문자열이 사용됩니다. 기본적으로 이 문자열은 단일 QUESTION MARK(U+003F)입니다.

최적 문자 매핑은 유니코드 데이터를 코드 페이지 데이터로 인코딩하는 Encoding의 기본 동작이며, 이 동작을 사용하는 레거시 응용 프로그램이 있습니다. 그러나 대부분의 새 응용 프로그램에서는 보안상의 이유로 최적 문자 매핑 동작을 사용하지 않아야 합니다. 예를 들어 응용 프로그램에서 최적 문자 인코딩을 통한 도메인 이름을 사용해서는 안 됩니다.

응용 프로그램에서는 최적 문자 매핑 대신 다음과 같은 방법을 사용해야 합니다.

대체 문제를 방지하려면 유니코드 인코딩(UTF8Encoding, UnicodeEncoding 및 UTF32Encoding)만 사용합니다.

주의:
UTF7Encoding은 기술적으로는 유니코드 인코딩이지만 다른 인코딩보다 안정적이지 않으며 보안성이 약합니다. 1비트만 변경해도 전체 UTF-7 문자열의 해석이 크게 바뀌는 경우가 있을 수 있으며, 아주 다른 UTF-7 문자열이 동일한 텍스트로 인코딩되는 경우도 있을 수 있습니다. 따라서 UTF-7은 되도록 사용하지 않는 것이 좋습니다. UTF-7보다 UTF-8을 사용하는 것이 좋습니다.

UTF7Encoding은 기술적으로는 유니코드 인코딩이지만 다른 인코딩보다 안정적이지 않으며 보안성이 약합니다. 1비트만 변경해도 전체 UTF-7 문자열의 해석이 크게 바뀌는 경우가 있을 수 있으며, 아주 다른 UTF-7 문자열이 동일한 텍스트로 인코딩되는 경우도 있을 수 있습니다. 따라서 UTF-7은 되도록 사용하지 않는 것이 좋습니다. UTF-7보다 UTF-8을 사용하는 것이 좋습니다.

문자가 정확하게 매핑되지 않는 경우 예외(EncoderFallbackException 및 DecoderFallbackException)를 throw하는 EncoderExceptionFallback 및 DecoderExceptionFallback을 사용합니다.
문자가 정확히 매핑되지 않는 경우 항상 EncoderReplacementFallback 및 DecoderReplacementFallback을 사용하여 대체 문자열로 바꿉니다. 이는 ASCIIEncoding의 기본 동작입니다. 기본적으로 이 문자열에는 물음표만 들어 있지만 응용 프로그램에서 다른 문자열을 선택할 수 있는 메서드가 제공됩니다. 일반적으로는 단일 문자가 사용되지만 여러 문자를 사용할 수도 있습니다. 텍스트를 유니코드로 변환할 때 사용되는 DecoderReplacementFallback의 경우 일반적으로 사용되는 단일 문자는 REPLACEMENT CHARACTER(U+FFFD)입니다.
사용자 지정된 EncoderFallback 및/또는 DecoderFallback을 통해 사용할 전략을 구현합니다. 대체(fallback) 인코딩 응용 프로그램 샘플을 참조하십시오.

다음은 최적 문자 인코딩(또는 디코딩) 대체 전략과 관련하여 참고할 사항입니다.

최적, 즉 가장 적합하다는 것은 주로 디코딩 문제가 아니라 인코딩 문제와 관련됩니다. 유니코드에 성공적으로 매핑할 수 없는 문자가 들어 있는 코드 페이지는 매우 적습니다. 이러한 문자는 일반적으로 사용되지 않으므로 유니코드에서 생략되었습니다.
최적 문자 대체 전략에 해당하는 명명된 개체는 지원되지 않습니다. 최적 문자 대체 전략은 코드 페이지마다 서로 다릅니다. 응용 프로그램에서 단일 Encoding 개체에 대해 최적 문자 대체와 다른 대체 방법 사이에서 전환하려면 다른 대체 개체를 할당하기 전에 원래 최적 문자 개체를 변수에 복사해야 합니다. 그런 다음 Encoding.EncoderFallback 또는 Encoding.DecoderFallback 에 이러한 값을 다시 할당하여 최적 문자 대체를 복구할 수 있습니다.