Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 5개 있습니다.)
Windows: 265. Win32 API의 W(유니코드) 버전은 UCS-2일까요? UTF-16 인코딩일까요?
; https://www.sysnet.pe.kr/2/0/13777

C/C++: 181. C/C++ - 소스코드 파일의 인코딩, 바이너리 모듈 상태의 인코딩
; https://www.sysnet.pe.kr/2/0/13778

C/C++: 182. 윈도우가 운영하는 2개의 Code Page
; https://www.sysnet.pe.kr/2/0/13785

Windows: 267. Win32 API의 A(ANSI) 버전은 DBCS를 사용할까요?
; https://www.sysnet.pe.kr/2/0/13791

C/C++: 183. C++ - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
; https://www.sysnet.pe.kr/2/0/13793




C++ - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법

(설명을 집중하기 위해 한글 윈도우보다는 영문 윈도우를 기준으로 설명합니다.)

영문 윈도우에서 C++ 프로그램을 다음과 같이 만들고,

#include <iostream>

int main()
{
    std::cout << "안녕하세요\n";
}

컴파일 후 실행하면 결과가 어떻게 나올까요?

이를 위해 우선 소스코드 파일을 저장하는 단계부터 살펴봐야 합니다. 일단 한글이 포함된 소스코드는 (영문 윈도우의 기본 코드 페이지인) CP437/CP1252 상태로는 저장 자체가 안 됩니다. 반면 CP949(비주얼 스튜디오의 경우 "Korean - Codepage 949")로 저장하면 어떨까요?

물론 949 코드 페이지에 따른 문자 셋으로 저장은 됩니다. 문제는 해당 파일을 비주얼 스튜디오에서 다시 열었을 때 "안녕하세요" 문자열이 깨진다는 점입니다. 왜냐하면, 비주얼 스튜디오는 해당 파일을 (BOM 없는) UTF-8로 판정해 읽기 때문입니다.

대신, 에디터 화면에서 한글이 깨지는 문제를 감수한다면 빌드 및 실행은 문제가 없습니다. 물론, 실행할 때 코드 페이지를 반드시 949로 맞춰주어야만 한글이 정상적으로 출력됩니다.

// 현재 코드 페이지는 영문 윈도우의 경우 437
C:\temp\ConsoleApplication1\x64\Debug> chcp
Active code page: 437

// 437 코드 페이지에서는 949로 저장한 문자 셋이 깨짐
C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe
╛╚│τ╟╧╝╝┐Σ

// 반면, 949 코드 페이지로 변경하면,
C:\temp\ConsoleApplication1\x64\Debug> chcp 949
Active code page: 949

// 한글도 정상 출력
C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe
안녕하세요

혹은, 저 chcp를 코드 내에서 처리해도 무방합니다.

#include <iostream>
#include <Windows.h>

int main()
{
    SetConsoleOutputCP(949);
    // 또는, 
    // system("chcp 949");

    std::cout << "¾È³çÇϼ¼¿ä"; // 출력 결과: 안녕하세요
}




당연히 저렇게 소스코드 내의 문자가 깨진 상태로 개발을 하는 것은 불편할 수밖에 없습니다. 따라서, 이런 경우 현실적으로는 유니코드로 저장하는 것이 올바른 선택입니다.

// UTF-8로 저장

#include <iostream>

int main()
{
    std::cout << "안녕하세요\n";
}

하지만, 이 상태는 "소스코드 파일의 인코딩" 단계를 해결한 것일 뿐, "바이너리 모듈 상태의 인코딩"은 전혀 다른 문제가 됩니다.

즉, C++ 컴파일러는 입력 파일 자체는 정상적으로 해석을 하지만, 출력은 (시스템의 코드 페이지인) CP1252로 처리하기 때문에 이번엔 실행 시 (깨지는 정도가 아닌) 단순히 "?????"로 출력됩니다. 왜냐하면, UTF-8로 저장된 "안녕하세요" 문자에 대해 CP1252 문자 셋으로는 표현이 안 되기 때문에 바이너리에 fallback 문자로 출력을 해버린 것입니다.

따라서, 바이너리에도 UTF-8 인코딩을 이어가려면 컴파일러에게 이 사실을 알려야 합니다.

// 현재의 파일 자체는 UTF-8로 저장

// 실행 모듈에 utf-8 인코딩 지시
#pragma execution_character_set( "utf-8" )

#include <iostream>

int main()
{
    std::cout << "안녕하세요\n";
}

그러니까 ^^ 바로 여기까지가 지난 글에서 다뤘던 내용입니다.

C/C++ - 소스코드 파일의 인코딩, 바이너리 모듈 상태의 인코딩
; https://www.sysnet.pe.kr/2/0/13778




다시 한번 정리해 보면, 현실적으로 C++ 프로그램은 UTF-8로 저장하고, 컴파일러에게 바이너리에도 UTF-8로 저장하라는 지시를 포함시키는 것을 기본 방향으로 삼아야 합니다.

자, 그렇게 해서 "바이너리" 모듈은 준비가 되었습니다. 그렇다면 이제 저렇게 utf-8을 따르는 바이너리 모듈을 실행하면 어떤 결과가 나올까요?

C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe
안녕하세요

보는 바와 같이 그래도 한글이 깨집니다. 이유는 간단합니다, 영문 윈도우의 콘솔 화면은 CP437을 따르기 때문에 UTF-8로 출력된 문자열은 저렇게 깨져 나오는 것입니다. 물론, 저 프로그램을 한글 윈도우에서 실행해도, (CP949 코드 페이지는 UTF-8을 이해할 수 없으므로) 역시 한글은 깨집니다.

이 문제를 해결하려면, 단순히 콘솔 화면의 코드 페이지를 65001로 바꾸기만 하면 됩니다.

// 현재의 파일 자체는 UTF-8로 저장

// 실행 모듈에 utf-8 인코딩 지시
#pragma execution_character_set( "utf-8" )

#include <iostream>
#include <Windows.h>

int main()
{
    SetConsoleOutputCP(65001);

    // 또는 아래와 같이 system 명령어를 수행해도 되지만,
    // system("chcp 65001 > nul");
    // SetConsoleOutputCP와 다른 점이 있다면 응용 프로그램이 종료했을 때 여전히 65001로 남아있게 되므로
    // 다시 코드 페이지를 돌려놓는 과정이 필요함.

    std::cout << "안녕하세요\n";
}

// 현재 코드 페이지와 무관하게,
C:\temp\ConsoleApplication1\x64\Debug> chcp
Active code page: 437

// utf-8을 지원하는 응용 프로그램의 출력이 정상적으로 나옴
C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe
안녕하세요




이 외에도 또 다른 방법으로 한글(및 유니코드)를 출력하는 방법이 있는데요, 바로 W 버전을 사용하는 것입니다. 이를 위해 C++ 소스코드를 char 대신 wchar_t로 바꿔 작성하면 되는데요,

#include <iostream>

int main()
{
    std::wcout << L"Hello, 안녕하세요\n";
    std::wcout << L"World\n";
}

그런데, 위와 같이 바꿔도 실행해 보면 화면에 "Hello,"만 출력될 뿐 한글 문자는 아예 보이지도 않습니다.

C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe
Hello,

// 재미있는 건, 한글 출력을 못한 그 순간부터는 모든 출력을 실패(?)하게 됩니다.
// 그래서 "World"도 출력이 안 된 것입니다.

도대체 왜 이런 걸까요? 이유는, Text 모드에 있습니다.

C++ - 파일에 대한 Text 모드의 "translated" 동작
; https://www.sysnet.pe.kr/2/0/13766

C++ - _O_WTEXT, _O_U16TEXT, _O_U8TEXT의 Unicode stream 모드
; https://www.sysnet.pe.kr/2/0/13768

C/C++: 180. C++ - 고수준 FILE I/O 함수에서의 Unicode stream 모드(_O_WTEXT, _O_U16TEXT, _O_U8TEXT)
; https://www.sysnet.pe.kr/2/0/13776

기본적으로 C++ 프로그램은 표준 출력(stdout)에 대해 _O_TEXT 모드로 동작하기 때문에, UTF-16 문자열의 출력이 ANSI로 자동 번역이 돼 정상적인 한글 출력이 안 되는 것입니다.

따라서, 이런 경우에는 명시적으로 표준 출력을 UTF-16 모드로 변경해 주어야 합니다.

#include <iostream>
#include <io.h> // _setmode
#include <fcntl.h> // _O_U16TEXT

int main()
{
    int old_mode = _setmode(_fileno(stdout), _O_U16TEXT); // 표준 출력을 UTF-16 모드로 변경
    wprintf(L"old_mode: 0x%x\n", old_mode); // 0x4000 == _O_TEXT
    std::wcout << L"Hello, 안녕하세요\n"; // 또는 아예 WriteConsoleW와 같은 Win32 API를 사용하거나!
    std::wcout << L"World\n";
}

/* 출력 결과:
old_mode: 0x4000
Hello, 안녕하세요
World
*/

또는, 원한다면 (utf-8 인코딩 모드인) _O_U8TEXT 모드로 변경할 수 있습니다.

#include <iostream>
#include <io.h> // _setmode
#include <fcntl.h> // _O_U8TEXT

int main()
{
    _setmode(_fileno(stdout), _O_U8TEXT);
    std::wcout << L"Hello, 안녕하세요\n";
    std::wcout << L"World\n";
}

위의 코드가 재미있는 점이 하나 있는데요, 얼핏 코드 페이지를 65001로 바꿔야만 할 것 같은데 그렇게 안 해도 한글이 잘 출력된다는 점입니다. 출력을 redirect하면 분명히 utf-8로 인코딩된 것이 맞는데요,

C:\temp\ConsoleApplication1\x64\Debug> ConsoleApplication1.exe > test.txt

// 코드 페이지는 437,
C:\temp\ConsoleApplication1\x64\Debug> chcp
Active code page: 437

// 따라서 한글이 깨져 나오고,
C:\temp\ConsoleApplication1\x64\Debug> type test.txt
Hello, 안녕하세요
World

// 65001 코드 페이지에서만 정상적으로 한글 출력
C:\temp\ConsoleApplication1\x64\Debug> chcp 65001
Active code page: 65001

C:\temp\ConsoleApplication1\x64\Debug> type test.txt
Hello, 안녕하세요
World

음... 뭔가 ^^; 있긴 하겠지만 현재는 저것까지 설명은 안 됩니다. (혹시 아시는 분은 덧글 부탁드립니다. ^^)




참고로, C#의 유니코드 대응과 비교해 보는 것도 좋을 듯합니다. ^^

기본 해석은, "소스코드 파일의 인코딩", "바이너리 모듈 상태의 인코딩", "실행 환경" 3가지를 고려해야 한다는 점은 같은데요, 우선 C#은 소스코드 파일을 기본적으로 비주얼 스튜디오 환경이 UTF-8로 저장합니다. 그렇다면 파일의 문자 셋 해석 문제는 자연스럽게 해결됩니다. 이후, C# 컴파일러는 소스코드의 모든 문자열을 UTF-16으로 변환해 바이너리에 포함시킵니다. 따라서, 바이너리 모듈 상태의 인코딩도 문제가 없습니다.

실행 시에는 어떨까요? C#은 C++이 가지는 file descriptor, FILE Stream 등의 개념을 배제하고 운영체제에서 제공하는 함수를 사용하므로, 즉 윈도우의 경우에는 기본적으로 W 버전의 API를 사용해 I/O를 수행하기 때문에 이것 역시 유니코드 출력에 문제가 없습니다.

따라서, C#으로는 아무 생각 없이 코딩을 해도 기본적으로 한글이 깨지는 등의 문제가 발생하지 않는 것입니다.
(물론, 기존 코드 페이지로 인코딩된 파일을 I/O 할 때는 문제가 발생합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/30/2024]

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

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  [68]  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12237정성태6/20/202017786.NET Framework: 912. 리눅스 환경의 .NET Core에서 "test".IndexOf("\0")가 0을 반환
12236정성태6/19/202018583오류 유형: 621. .NET Standard 대상으로 빌드 시 dynamic 예약어에서 컴파일 오류 - error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'
12235정성태6/19/202017636오류 유형: 620. Windows 10 - Inaccessible boot device 블루 스크린
12234정성태6/19/202017038개발 환경 구성: 494. NuGet - nuspec의 패키지 스키마 버전(네임스페이스) 업데이트 방법
12233정성태6/19/202017644오류 유형: 619. SQL 서버 - The transaction log for database '...' is full due to 'LOG_BACKUP'. - 두 번째 이야기
12232정성태6/19/202016241오류 유형: 618. SharePoint - StoreBusyRetryLater 오류
12231정성태6/15/202019535.NET Framework: 911. Console/Service Application을 위한 SynchronizationContext - AsyncContext
12230정성태6/15/202018387오류 유형: 617. IMetaDataImport::GetMethodProps가 반환하는 IL 코드 주소(RVA) 문제
12229정성태6/13/202020313.NET Framework: 910. USB/IP PROJECT를 이용해 C#으로 USB Keyboard + Mouse 가상 장치 만들기 [1]
12228정성태6/12/202019625.NET Framework: 909. C# - Source Generator를 적용한 XmlCodeGenerator파일 다운로드1
12227정성태6/12/202023562오류 유형: 616. Visual Studio의 느린 업데이트 속도에 대한 원인 분석 [5]
12226정성태6/11/202021639개발 환경 구성: 493. OpenVPN의 네트워크 구성 [4]파일 다운로드1
12225정성태6/11/202019567개발 환경 구성: 492. 윈도우에 OpenVPN 설치 - 클라이언트 측 구성
12224정성태6/11/202028258개발 환경 구성: 491. 윈도우에 OpenVPN 설치 - 서버 측 구성 [1]
12223정성태6/9/202024034.NET Framework: 908. C# - Source Generator 소개 [10]파일 다운로드2
12222정성태6/3/202017466VS.NET IDE: 146. error information: "CryptQueryObject" (-2147024893/0x80070003)
12221정성태6/3/202017243Windows: 170. 비어 있지 않은 디렉터리로 symbolic link(junction) 연결하는 방법
12220정성태6/3/202021061.NET Framework: 907. C# DLL로부터 TLB 및 C/C++ 헤더 파일(TLH)을 생성하는 방법
12219정성태6/1/202019845.NET Framework: 906. C# - lock (this), lock (typeof(...))를 사용하면 안 되는 이유파일 다운로드1
12218정성태5/27/202019162.NET Framework: 905. C# - DirectX 게임 클라이언트 실행 중 키보드 입력을 감지하는 방법 [3]
12217정성태5/24/202017266오류 유형: 615. Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1.
12216정성태5/15/202020817.NET Framework: 904. USB/IP PROJECT를 이용해 C#으로 USB Keyboard 가상 장치 만들기 [14]파일 다운로드1
12215정성태5/12/202026788개발 환경 구성: 490. C# - (Wireshark의) USBPcap을 이용한 USB 패킷 모니터링 [10]파일 다운로드1
12214정성태5/5/202018457개발 환경 구성: 489. 정식 인증서가 있는 경우 Device Driver 서명하는 방법 (2) - UEFI/SecureBoot [1]
12213정성태5/3/202019571개발 환경 구성: 488. (User-mode 코드로 가상 USB 장치를 만들 수 있는) USB/IP PROJECT 소개
12212정성태5/1/202016783개발 환경 구성: 487. UEFI / Secure Boot 상태인지 확인하는 방법
... 61  62  63  64  65  66  67  [68]  69  70  71  72  73  74  75  ...