Microsoft MVP성태의 닷넷 이야기
.NET Framework: 54. 한글이 포함된 ANSI, UTF-8, UNICODE 텍스트 파일 읽기 [링크 복사], [링크+제목 복사],
조회: 44810
글쓴 사람
정성태 (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]

... 46  47  48  [49]  50  51  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12715정성태7/17/202122471오류 유형: 736. Windows - MySQL zip 파일 버전의 "mysqld --skip-grant-tables" 실행 시 비정상 종료 [1]
12714정성태7/16/202115824오류 유형: 735. VCRUNTIME140.dll, MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll이 없어 exe 실행이 안 되는 경우
12713정성태7/16/202117236.NET Framework: 1077. C# - 동기 방식이면서 비동기 규약을 따르게 만드는 Task.FromResult파일 다운로드1
12712정성태7/15/202116187개발 환경 구성: 579. Azure - 리눅스 호스팅의 Site Extension 제작 방법
12711정성태7/15/202116180개발 환경 구성: 578. Azure - Java Web App Service를 위한 Site Extension 제작 방법
12710정성태7/15/202118831개발 환경 구성: 577. MQTT - emqx.io 서비스 소개
12709정성태7/14/202114354Linux: 42. 실행 중인 docker 컨테이너에 대한 구동 시점의 docker run 명령어를 확인하는 방법
12708정성태7/14/202118575Linux: 41. 리눅스 환경에서 디스크 용량 부족 시 원인 분석 방법
12707정성태7/14/202185771오류 유형: 734. MySQL - Authentication method 'caching_sha2_password' not supported by any of the available plugins.
12706정성태7/14/202116949.NET Framework: 1076. C# - AsyncLocal 기능을 CallContext만으로 구현하는 방법 [2]파일 다운로드1
12705정성태7/13/202117379VS.NET IDE: 168. x64 DLL 프로젝트의 컨트롤이 Visual Studio의 Designer에서 보이지 않는 문제 - 두 번째 이야기
12704정성태7/12/202116151개발 환경 구성: 576. Azure VM의 서비스를 Azure Web App Service에서만 접근하도록 NSG 설정을 제한하는 방법
12703정성태7/11/202121508개발 환경 구성: 575. Azure VM에 (ICMP) ping을 허용하는 방법
12702정성태7/11/202117273오류 유형: 733. TaskScheduler에 등록된 wacs.exe의 Let's Encrypt 인증서 업데이트 문제
12701정성태7/9/202116795.NET Framework: 1075. C# - ThreadPool의 스레드는 반환 시 ThreadStatic과 AsyncLocal 값이 초기화 될까요?파일 다운로드1
12700정성태7/8/202117261.NET Framework: 1074. RuntimeType의 메모리 누수? [1]
12699정성태7/8/202115797VS.NET IDE: 167. Visual Studio 디버깅 중 GC Heap 상태를 보여주는 "Show Diagnostic Tools" 메뉴 사용법
12698정성태7/7/202120028오류 유형: 732. Windows 11 업데이트 시 3% 또는 0%에서 다운로드가 멈춘 경우
12697정성태7/7/202115113개발 환경 구성: 574. Windows 11 (Insider Preview) 설치하는 방법
12696정성태7/6/202116047VC++: 146. 운영체제의 스레드 문맥 교환(Context Switch)을 유사하게 구현하는 방법파일 다운로드2
12695정성태7/3/202116111VC++: 145. C 언어의 setjmp/longjmp 기능을 Thread Context를 이용해 유사하게 구현하는 방법파일 다운로드1
12694정성태7/2/202118035Java: 24. Azure - Spring Boot 앱을 Java SE(Embedded Web Server)로 호스팅 시 로그 파일 남기는 방법 [1]
12693정성태6/30/202114974오류 유형: 731. Azure Web App Site Extension - Failed to install web app extension [...]. {1}
12692정성태6/30/202115446디버깅 기술: 180. Azure - Web App의 비정상 종료 시 남겨지는 로그 확인
12691정성태6/30/202115669개발 환경 구성: 573. 테스트 용도이지만 테스트에 적합하지 않은 Azure D1 공유(shared) 요금제
12690정성태6/28/202116697Java: 23. Azure - 자바(Java)로 만드는 Web App Service - Tomcat 호스팅
... 46  47  48  [49]  50  51  52  53  54  55  56  57  58  59  60  ...