Microsoft MVP성태의 닷넷 이야기
.NET Framework: 54. 한글이 포함된 ANSI, UTF-8, UNICODE 텍스트 파일 읽기 [링크 복사], [링크+제목 복사],
조회: 44747
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)

오늘은 개발자 한 분이... ASP.NET에서 한글이 포함된 HTML 텍스트를 로딩했는 데, 한글이 깨진다는 문제를 들고 왔습니다.

텍스트 파일의 특성상, 가볍게 다음과 같은 코드로 마무리를 지었던 것입니다.

string fileContent = null;
using (StreamReader sr = new StreamReader(filePath))
{
 fileContent = sr.ReadToEnd();
 sr.Close();
}

저 역시, 위의 코드를 보고 너무 표준적인 코드라 ^^ 문제가 없어 보였지요.

.NET에서는 문자열 처리를 명시적으로 지정하지 않는 한, 기본적으로 "System.Text.UTF8Encoding"으로 처리를 합니다. 문제는 거기서 발생을 하는데요.

해당 HTML 텍스트 한글 파일은 메모장에서 "ASCII" 형식으로 저장된 것이었고, 디코딩을 UTF-8로 해버리니 당연히 깨질 수밖에 없습니다.

한글이 포함된 ASCII 코드를 정상적으로 읽어들이기 위해서는 인코딩을 지정해야 합니다. StreamReader의 두 번째 인자에는 바로 그 인코딩 방식을 지정할 수가 있죠. 우리가 아는 것처럼 "KS_C_5601-1987" 인코딩 방식을 지정해야 합니다. 다음과 같은 코드로.

using (StreamReader sr = new StreamReader(filePath, Encoding.GetEncoding("ks_c_5601-1987")))
{
  fileContent = sr.ReadToEnd();
  sr.Close();
}

명시적인 Encoding 문자열 지정 대신에, Encoding.Default를 지정해도 됩니다. 시스템 레벨로 설정된 (제어판의 Regional Settings) code page 값이 한글 윈도우즈에서는 기본적으로 "KS_C_5601-1987"이기 때문입니다.

하지만, 여기서 끝이 아니죠. ^^
만약 해당 파일이 utf-8 또는 unicode로 인코딩된 텍스트 파일이라면? 당연히 위의 코드로 읽어들이게 되면 역시 한글이 깨지게 됩니다.

Unicode 또는 UTF-8 등의 텍스트 파일은 그 인코딩 방법을 표시하기 위해, 파일의 최초 2~3바이트에 BOM(byte order mark)를 표시해 둡니다. utf-8로 인코딩된 텍스트 파일을 윈도우즈의 "메모장"으로 열어보면 그러한 표시를 생략하고 순수 텍스트만 보여주지만, 2진 파일 형식으로 볼 수 있는 hexa 에디터 등을 통해서 보게 되면, 최초 2~3바이트의 내용이 인코딩에 따라서 달라지는 것을 확인할 수 있습니다.

UTF-8: EF BB BF
Unicode: FF FE

실제로, BOM을 통한 디코딩을 지원하지 않는 Editor로 UTF-8 인코딩된 파일을 열게 되면, 최초 3byte를 깨진 텍스트로 출력해 주는 것을 볼 수 있습니다.

아무튼... 그렇다면, 우리도 BOM을 읽어서 상황에 따라 StreamReader의 2번째 인자에 각각 해당하는 인코딩을 넣어주면 되겠지요. ^^; 아마도 C++이었다면 틀림없이 그렇게 해야 했을 것입니다. 하지만, 우리의 "친절한 .NET 씨"(이 표현은 Loner(http://simpleisbest.net)에서 빌려옴)는 그런 작업을 모두 해놓았습니다. 바로 StreamReader의 3번째 인자에서 그러한 역할을 대신해 줍니다.

public StreamReader(..., bool detectEncodingFromByteOrderMarks);

매개변수 이름부터 그런 태생임을 짐작하게 해줍니다. 해당 값을 true로 전달하면 BOM 마크가 없는 - 예를 들어 ANSI 파일 - 경우에는 2번째 인자에서 지정한 Encoding 방식으로 인식해서 디코딩을 하지만, BOM이 있으면 거기서 지정된 Encoding 방식으로 되어 있다고 인식해서 디코딩을 하게 됩니다.

그러니... 앞으로 국내에서의 .NET 개발자들은 텍스트 파일을 로딩하기 위한 표준 코드를 다음과 같이 해야 합니다.

using (StreamReader sr = new StreamReader(filePath, Encoding.GetEncoding("ks_c_5601-1987"), true))
{
  fileContent = sr.ReadToEnd();
  sr.Close();
}

또는

using (StreamReader sr = new StreamReader(filePath, Encoding.Default, true))
{
  fileContent = sr.ReadToEnd();
  sr.Close();
}

두 가지 모두, 경우에 따라서 논란의 여지가 있지만... 적어도 한글 윈도우즈에서 호스팅된다는 보장만 된다면, "Encoding.Default" 인자가 가장 좋을 것 같네요. ^^

-------------------------------- 유사한 문제 1 ------------------------------------------

파일 업로드 컴포넌트를 사용하는 중에 발생한 문제입니다. multipart/form-data 중에서 File을 제외한 일반적인 Form data를 전송할 때 value 값을 urlencode로 전송을 했습니다.

예를 들어, 한글로 "마이" 값을 urlencode하면,

%b8%b6%c0%cc

이 나옵니다. 한글 1자가 2byte이니까, 각각의 byte에 대한 hexa 처리를 하니 위와 같은 결과가 나오는 것이지요.

서버 측에서

string txt = Request.Form["key"];

로 받으면, txt == "%b6%b8%cc%c0" 값이 당연히 들어가 있겠지요.

그다음,

string value = Server.UrlDecode(txt);

라고 했더니, 값이 깨져 나오거나 아예 빈 문자열이 반환되는 것입니다. 이번 경우에도 여기 문자열 인코딩과 관계된 오류가 발생한 것입니다.

<globalization/>에서 기본적으로 utf-8로 설정되어 있었기 때문에, 실제로 "마이"라는 한글값은 utf-8로 하게 되면 한글 1자당 3byte가 할당되게 됩니다. 즉, UTF-8 인코딩 기준으로 "마이"를 urlencode하면,

%eb%a7%88%ec%9d%b4

가 나옵니다. 위의 결과값을 urldecode해야 정상적으로 "마이"가 나오게 되는 것이지요.

자, 이제 문제를 알았으니... ^^ UrlDecode 관련해서 System.Text.Encoding 변수를 받는 메서드가 있는지 검사해봐야 할 것입니다. Server.UrlDecode를 Reflection으로 보게 되면 HttpUtility.UrlDecode를 그대로 호출하는 것을 볼 수 있습니다. 그런데 ^^ 거기에 Encoding을 같이 지정하는 것을 볼 수 있습니다.

public string UrlDecode(string s)
{
      Encoding encoding1 = (this._context != null) ? this._context.Request.ContentEncoding : Encoding.UTF8;
      return HttpUtility.UrlDecode(s, encoding1);
}
 
답은 나왔네요. ^^

mode = HttpUtility.UrlDecode(Page.Request["key"], System.Text.Encoding.Default); // regional settings에서 Korean으로 지정된 경우
또는
mode = HttpUtility.UrlDecode(Page.Request["key"], System.Text.Encoding.GetEncoding("ks_c_5601-1987"));


-------------------------------- 유사한 문제 2 ------------------------------------------

역시 같은 문제입니다. 이번에는 읽기가 아닌 저장할 때 발생합니다. 개발자 한 분이, 소스 파일을 읽어서 저장하는 코드를 다음과 같이 작성했습니다.

using (StreamWriter sw = File.CreateText(Page.MapPath("~/test.txt")))
{
  sw.Write("한글");
  sw.Close();
}

저장하면,,, 다음과 같은 바이트 배열이 나옵니다.

0xed,0x95,0x9c,0xea,0xb8,0x80

일단, 한글 1자에 3byte씩이니까, UTF-8이 맞는 것 같습니다.
그런데, BOM 영역이 없습니다. 이렇게 된 파일을 "메모장"이나 "VS.NET IDE"에서 읽어들인다 해도 한글이 깨지지는 않습니다.(아마도, 그런 에디터는 BOM에 의존하지 않는 것 같습니다.) 문제는, 부모글에서 알려드린 방법으로 읽을 때 나타납니다.

using (StreamReader sr = new StreamReader(filePath, Encoding.Default, true))
{
  fileContent = sr.ReadToEnd();
  sr.Close();
}

BOM 영역이 없기 때문에, 기본적으로 Encoding.Default에 명시된 인코딩이 되었다고 가정을 하게 되니 - 한글 윈도우즈에서는 "ks_c_5601-1987" - 당연히 글자가 깨져 버리게 됩니다.

읽어들이는 쪽에서 별도로 수정을 해줄 수도 있겠지만, 근본적인 원인은 저장하는 쪽에서 발생했기 때문에 마찬가지로 Encoding 방식을 지정해서 저장을 해주는 것이 바람직하겠습니다.

using (StreamWriter sw = new StreamWriter(Page.MapPath("~/test.txt"), false, System.Text.Encoding.UTF8))
{
  sw.Write("한글");
  sw.Close();
}

이렇게 저장하면, 바이트 코드로 다음과 같이 파일이 구성됩니다.

0xef,0xbb,0xbf,0xed,0x95,0x9c,0xea,0xb8,0x80

첫 글에서 살펴봤었던, "0xef,0xbb,0xbf" UTF-8 BOM 영역이 분명하게 들어간 것을 볼 수 있습니다.

만약, 위와 같이 문제를 해결하지 않았다면... 아마도 해당 사이트의 <globalization />에는 "euc-kr" 또는 "ks_c_5601-1987"이 있겠지요.


[연관 글]






[최초 등록일: ]
[최종 수정일: 6/27/2021]

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

비밀번호

댓글 작성자
 



2005-11-21 09시40분
[minimango] 토픽 잘 읽어 보았습니다. 감사합니다..^^..
[guest]
2008-03-27 08시48분
UTF-8 and Unicode FAQ for Unix/Linux
; http://www.cl.cam.ac.uk/~mgk25/unicode.html

아직도 UTF-8을 안 쓰십니까?
; http://blog.naver.com/saltynut/120020091973
kevin25
2015-03-18 12시30분
[오곡] 잘 배우고 갑니다~
[guest]

1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13667정성태7/7/20246624닷넷: 2273. C# - 리눅스 환경에서의 Hyper-V Socket 연동 (AF_VSOCK)파일 다운로드1
13666정성태7/7/20247703Linux: 74. C++ - Vsock 예제 (Hyper-V Socket 연동)파일 다운로드1
13665정성태7/6/20247889Linux: 73. Linux 측의 socat을 이용한 Hyper-V 호스트와의 vsock 테스트파일 다운로드1
13663정성태7/5/20247499닷넷: 2272. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)의 VMID Wildcards 유형파일 다운로드1
13662정성태7/4/20247494닷넷: 2271. C# - WSL 2 VM의 VM ID를 알아내는 방법 - Host Compute System API파일 다운로드1
13661정성태7/3/20247415Linux: 72. g++ - 다른 버전의 GLIBC로 소스코드 빌드
13660정성태7/3/20247526오류 유형: 912. Visual C++ - Linux 프로젝트 빌드 오류
13659정성태7/1/20247869개발 환경 구성: 715. Windows - WSL 2 환경의 Docker Desktop 네트워크
13658정성태6/28/20248249개발 환경 구성: 714. WSL 2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법 - 두 번째 이야기
13657정성태6/27/20247923닷넷: 2270. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)을 위한 EndPoint 사용자 정의
13656정성태6/27/20248108Windows: 264. WSL 2 VM의 swap 파일 위치
13655정성태6/24/20247869닷넷: 2269. C# - Win32 Resource 포맷 해석파일 다운로드1
13654정성태6/24/20247789오류 유형: 911. shutdown - The entered computer name is not valid or remote shutdown is not supported on the target computer.
13653정성태6/22/20247938닷넷: 2268. C# 코드에서 MAKEINTREOURCE 매크로 처리
13652정성태6/21/20249257닷넷: 2267. C# - Linux 환경에서 (Reflection 없이) DLL AssemblyFileVersion 구하는 방법파일 다운로드2
13651정성태6/19/20248490닷넷: 2266. C# - (Reflection 없이) DLL AssemblyFileVersion 구하는 방법파일 다운로드1
13650정성태6/18/20248411개발 환경 구성: 713. "WSL --debug-shell"로 살펴보는 WSL 2 VM의 리눅스 환경
13649정성태6/18/20247974오류 유형: 910. windbg - !py 확장 명령어 실행 시 "failed to find python interpreter" (2)
13648정성태6/17/20248295오류 유형: 909. C# - DynamicMethod 사용 시 System.TypeAccessException
13647정성태6/16/20249345개발 환경 구성: 712. Windows - WSL 2의 네트워크 통신 방법 - 세 번째 이야기 (같은 IP를 공유하는 WSL 2 인스턴스) [1]
13646정성태6/14/20247766오류 유형: 908. Process Explorer - "Error configuring dump resources: The system cannot find the file specified."
13645정성태6/13/20248207개발 환경 구성: 711. Visual Studio로 개발 시 기본 등록하는 dev tag 이미지로 Docker Desktop k8s에서 실행하는 방법
13644정성태6/12/20248868닷넷: 2265. C# - System.Text.Json의 기본적인 (한글 등에서의) escape 처리 [1]
13643정성태6/12/20248331오류 유형: 907. MySqlConnector 사용 시 System.IO.FileLoadException 오류
13642정성태6/11/20248206스크립트: 65. 파이썬 - asgi 버전(2, 3)에 따라 달라지는 uvicorn 호스팅
13641정성태6/11/20248675Linux: 71. Ubuntu 20.04를 22.04로 업데이트
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...