Microsoft MVP성태의 닷넷 이야기
닷넷: 2349. C# 14 - (4) 문자열 리터럴을 utf-8 인코딩으로 저장 [링크 복사], [링크+제목 복사],
조회: 3116
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일

(시리즈 글이 12개 있습니다.)
닷넷: 2342. C# 14 - (취소된 글)
; https://www.sysnet.pe.kr/2/0/13970

닷넷: 2343. C# 14 - (1) 속성 구문에서 문맥 키워드로 추가되는 field 예약어
; https://www.sysnet.pe.kr/2/0/13971

닷넷: 2346. C# 14 - (2) Span 타입과 배열 간의 암시적 형변환
; https://www.sysnet.pe.kr/2/0/13974

닷넷: 2347. C# 14 - (3) 형식 인자가 없는 제네릭 타입의 nameof 지원
; https://www.sysnet.pe.kr/2/0/13975

닷넷: 2349. C# 14 - (4) 문자열 리터럴을 utf-8 인코딩으로 저장
; https://www.sysnet.pe.kr/2/0/13977

닷넷: 2350. C# 14 - (5) 람다 매개 변수에 접근자가 있는 경우에도 타입 생략 가능
; https://www.sysnet.pe.kr/2/0/13986

닷넷: 2351. C# 14 - (6) event와 생성자에도 partial 메서드 적용
; https://www.sysnet.pe.kr/2/0/13987

닷넷: 2354. C# 14 - (7) 확장 메서드에 정적 메서드와 속성 지원을 위한 전용 구문 추가
; https://www.sysnet.pe.kr/2/0/13998

닷넷: 2355. C# 14 - (8) null 조건부 연산자 개선 - 대입문에도 사용 가능
; https://www.sysnet.pe.kr/2/0/13999

닷넷: 2357. C# 14 - (9) 새로운 지시자 추가 (Ignored directives)
; https://www.sysnet.pe.kr/2/0/14003

닷넷: 2359. C# 14 - (10) 복합 대입 연산자의 오버로드 지원
; https://www.sysnet.pe.kr/2/0/14008

닷넷: 2360. C# 14 - (11) Expression Tree에 선택적 인수와 명명된 인수 허용
; https://www.sysnet.pe.kr/2/0/14009




C# 14 - (4) 문자열 리터럴을 utf-8 인코딩으로 저장

이번엔 C# 자체의 언어 수준에 대한 변화는 아니고 C# 컴파일러 측의 변경입니다.

String literals in data section
; https://github.com/dotnet/roslyn/blob/main/docs/features/string-literals-data-section.md#eligible-string-literals

기본적으로 C# 컴파일러는 문자열 리터럴을 UTF-16 인코딩으로 저장하고, C# 11부터 추가된 UTF-8 문자열 리터럴의 경우에는 UTF-8 인코딩으로 저장합니다.

그런데, C# 14부터는 (u8 접미사를 붙이지 않은) 일반적인 문자열 리터럴도 UTF-8 인코딩으로 바이너리에 저장하는 옵션이 추가됐습니다. 이를 위해 C# 프로젝트에서는 다음과 같이 설정을 추가하면 되는데요,

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
        <LangVersion>preview</LangVersion>
        <!-- 아래는 0을 지정, 만약 숫자를 지정하지 않으면 기본값 100 -->
        <Features>$(Features);experimental-data-section-string-literals=0</Features>
    </PropertyGroup>

</Project>

그럼, (위에서는 0으로 설정했으므로, 그 이상의 길이를 갖는) 모든 문자열 리터럴을 UTF-8 인코딩으로 저장합니다. 실제로 눈으로 확인해 볼까요? ^^ 이를 위해 간단한 예제를 하나 만들고,

// 아래의 코드로 빌드한 DLL로 테스트
using System;

namespace ConsoleApp1;

internal class Program
{
    static void Main(string[] args)
    {
        string s = "Hello, World!";
        Console.WriteLine(s);
    }
}

일단 csproj 파일에 Features 설정 없이 빌드해 ConsoleApp1.dll 파일을 PE Viewer로 열어 보면,

cs14_string_literals_utf8_0.png

보는 바와 같이 닷넷 메타데이터 영역에 "#US", 즉 "UserString" 섹션에 문자열이 UTF-16 인코딩으로 저장돼 있습니다. 이제 csproj 파일에 Features 옵션을 추가하고 다시 빌드하면,

cs14_string_literals_utf8_1.png

#US 섹션에는 "Hello, World!" 문자열이 없어졌고, 대신 (닷넷 메타데이터가 아닌) PE 포맷의 하나인 ".text" 섹션에 "Hello, World!" 문자열이 UTF-8 인코딩으로 저장된 것을 확인할 수 있습니다.

cs14_string_literals_utf8_2.png




이 기능으로 어떤 성능 향상을 기대할 수 있는 것은 아닙니다. 왜냐하면, 리터럴 데이터만 디스크에 UTF-8로 저장하는 것일 뿐, 어차피 실행 시에는 UTF-16 인코딩으로 변환돼 System.String 타입으로 다뤄져야 하기 때문입니다. 이에 대한 사실을 "Hello, World!" 문자열을 다루기 위해 C# 컴파일러가 생성한 자동 코드를 보면 알 수 있습니다.

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Text;

[CompilerGenerated]
internal sealed class \u003CPrivateImplementationDetails\u003E
{
  internal static readonly \u003CPrivateImplementationDetails\u003E.__StaticArrayInitTypeSize\u003D13 DFFD6021BB2BD5B0AF676290809EC3A53191DD81C7F70A4B28688A362182986F;

  private static unsafe string BytesToString(byte* bytes, int length)
  {
    return Encoding.UTF8.GetString(bytes, length);
  }

  [StructLayout(LayoutKind.Explicit, Size = 13, Pack = 1)]
  internal struct __StaticArrayInitTypeSize\u003D13
  {
  }

  internal sealed class \u003CS\u003E531DF2844447DD5077DB03842CD75395
  {
    internal static readonly string s;

    static unsafe \u003CS\u003E531DF2844447DD5077DB03842CD75395()
    {
      \u003CPrivateImplementationDetails\u003E.\u003CS\u003E531DF2844447DD5077DB03842CD75395.s = \u003CPrivateImplementationDetails\u003E.BytesToString((byte*) &\u003CPrivateImplementationDetails\u003E.DFFD6021BB2BD5B0AF676290809EC3A53191DD81C7F70A4B28688A362182986F, 13);
    }
  }
}

저렇게 정적 생성자 단계에서 "Hello, World!" 문자열을 UTF-16 인코딩으로 변환해 System.String 타입으로 들고 있게 한 후, 원래의 코드에서 다음과 같이 사용하도록 바뀝니다.

private static void Main(string[] args)
{
    Console.WriteLine(\u003CPrivateImplementationDetails\u003E.\u003CS\u003E531DF2844447DD5077DB03842CD75395.s);
}

그렇다면, 왜 굳이 이런 기능을 추가했을까요? 문서를 보면, 그동안 C# 컴파일러는 문자열 리터럴을 (위의 PE Viewer에서 "#US"로 지정된) UserString 힙에 보관하는데, 그 크기가 2의 24승(16MB)으로 제한돼 있다고 합니다. 의외로 꽤 작죠? 그래서 이 한계를 넘게 문자열 리터럴을 사용하면 컴파일 시점에 이런 오류가 발생한다고 합니다.

error CS8103: Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals.


아마도 저 제약에 걸린 프로그램을 만드는 개발자들이 은근 있었나 봅니다. ^^ (그랬다면, 그들은 그동안 순전히 문자열 리터럴을 나누기 위해 별도의 DLL을 만들어서 사용해야만 했을 것입니다.)

하지만 C# 14부터는, "experimental-data-section-string-literals" 기능을 통해 빌드하는 경우 #US 섹션이 아닌, C/C++처럼 문자열을 PE 파일의 readonly 섹션에 저장해 두기 때문에 문자열 리터럴의 크기에 대한 제약이 없어집니다. 좋은 소식이죠?!!! ^^

정리하면, CS8103 오류를 겪지 않는 한 굳이 설정할 필요가 없는 옵션입니다.




참고로 (네트워크 통신 등의 속도를 높이기 위해), UTF-16으로의 변환을 하고 싶지 않다면 u8 접미사를 이용한 UTF-8 인코딩을 사용하면 됩니다.

C# 11 - UTF-8 문자열 리터럴
; https://www.sysnet.pe.kr/2/0/13096

물론, 저 u8 문자열 리터럴도 "#US" 섹션이 아닌 PE 파일의 .text 섹션에 저장되므로 16MB의 제약은 없습니다.





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 8/14/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  [35]  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
13158정성태11/9/202216485오류 유형: 826. Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain' [...] conflicts with manifest 'microsoft.net.workload.mono.toolchain.net7'
13157정성태11/8/202217665.NET Framework: 2065. C# - Mutex의 비동기 버전파일 다운로드1
13156정성태11/7/202221017.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점파일 다운로드1
13155정성태11/4/202218066디버깅 기술: 183. TCP 동시 접속 (연결이 아닌) 시도를 1개로 제한한 서버
13154정성태11/3/202219285.NET Framework: 2063. .NET 5+부터 지원되는 GC.GetGCMemoryInfo파일 다운로드1
13153정성태11/2/202219867.NET Framework: 2062. C# - 코드로 재현하는 소켓 상태(SYN_SENT, SYN_RECV)
13152정성태11/1/202218987.NET Framework: 2061. ASP.NET Core - DI로 추가한 클래스의 초기화 방법 [1]
13151정성태10/31/202218247C/C++: 161. Windows 11 환경에서 raw socket 테스트하는 방법파일 다운로드1
13150정성태10/30/202215700C/C++: 160. Visual Studio 2022로 빌드한 C++ 프로그램을 위한 다른 PC에서 실행하는 방법
13149정성태10/27/202216544오류 유형: 825. C# - CLR ETW 이벤트 수신이 GCHeapStats_V1/V2에 대해 안 되는 문제파일 다운로드1
13148정성태10/26/202218402오류 유형: 824. msbuild 에러 - error NETSDK1005: Assets file '...\project.assets.json' doesn't have a target for 'net5.0'. Ensure that restore has run and that you have included 'net5.0' in the TargetFramew
13147정성태10/25/202217323오류 유형: 823. Visual Studio 2022 - Unable to attach to CoreCLR. The debugger's protocol is incompatible with the debuggee.
13146정성태10/24/202219058.NET Framework: 2060. C# - Java의 Xmx와 유사한 힙 메모리 최댓값 제어 옵션 HeapHardLimit
13145정성태10/21/202218400오류 유형: 822. db2 - Password validation for user db2inst1 failed with rc = -2146500508
13144정성태10/20/202219632.NET Framework: 2059. ClrMD를 이용해 윈도우 환경의 메모리 덤프로부터 닷넷 모듈을 추출하는 방법파일 다운로드1
13143정성태10/19/202220149오류 유형: 821. windbg/sos - Error code - 0x000021BE
13142정성태10/18/202228961도서: 시작하세요! C# 12 프로그래밍
13141정성태10/17/202220120.NET Framework: 2058. [in,out] 배열을 C#에서 C/C++로 넘기는 방법 - 세 번째 이야기파일 다운로드1
13140정성태10/11/202220329C/C++: 159. C/C++ - 리눅스 환경에서 u16string 문자열을 출력하는 방법 [2]
13139정성태10/9/202217260.NET Framework: 2057. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프로부터 모든 닷넷 모듈을 추출하는 방법파일 다운로드1
13138정성태10/8/202220416.NET Framework: 2056. C# - await 비동기 호출을 기대한 메서드가 동기로 호출되었을 때의 부작용 [1]
13137정성태10/8/202219606.NET Framework: 2055. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프로부터 닷넷 모듈을 추출하는 방법
13136정성태10/7/202218678.NET Framework: 2054. .NET Core/5+ SDK 설치 없이 dotnet-dump 사용하는 방법
13135정성태10/5/202220016.NET Framework: 2053. 리눅스 환경의 .NET Core 3/5+ 메모리 덤프를 분석하는 방법 - 두 번째 이야기 [1]
13134정성태10/4/202215003오류 유형: 820. There is a problem with AMD Radeon RX 5600 XT device. For more information, search for 'graphics device driver error code 31'
13133정성태10/4/202217394Windows: 211. Windows - (commit이 아닌) reserved 메모리 사용량 확인 방법 [1]
... 31  32  33  34  [35]  36  37  38  39  40  41  42  43  44  45  ...