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

... 121  122  123  124  125  126  127  128  129  130  131  [132]  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
1847정성태2/3/201526427기타: 50. C# - 윈도우에서 dropbox 동기화 폴더 경로 및 종료하는 방법
1846정성태2/2/201535548Windows: 102. 제어판의 프로그램 추가/삭제 항목을 수동으로 실행하고 싶다면? [1]
1845정성태1/26/201537238Windows: 101. 제어판의 "Windows 자격 증명 관리(Manage your credentials)"를 금지시키는 방법
1844정성태1/26/201534259오류 유형: 269. USB 메모리의 용량이 비정상적으로 보여진다면? [7]
1843정성태1/24/201525571VC++: 87. 무시할 수 없는 Visual C++ 런타임 함수 성능
1842정성태1/23/201549395개발 환경 구성: 255. 노트북 키보드에 없는 BREAK 키를 다른 키로 대체하는 방법
1841정성태1/21/201522942오류 유형: 268. Win32 핸들 관련 CLR4 보안 오류 사례
1840정성태1/8/201531216오류 유형: 267. Visual Studio - CodeLens 사용 시 CPU 100% 현상
1839정성태1/5/201523607디버깅 기술: 69. windbg 분석 사례 - cpu 100% 현상 (2)
1838정성태1/4/201544407기타: 49. 윈도우 내레이터(Narrator) 기능 끄는 방법(윈도우에 파란색의 굵은 테두리 선이 나타난다면?) [4]
1837정성태1/4/201530480디버깅 기술: 68. windbg 분석 사례 - 메모리 부족 [1]
1836정성태1/4/201530405디버깅 기술: 67. windbg - 덤프 파일과 handle 정보
1835정성태1/3/201531248개발 환경 구성: 254. SQL 서버 역시 SSL 3.0/TLS 1.0만을 지원하는 듯!
1834정성태1/3/201555797개발 환경 구성: 253. TLS 1.2를 적용한 IIS 웹 사이트 구성
1833정성태1/3/201532157.NET Framework: 490. System.Data.SqlClient는 SSL 3.0/TLS 1.0만 지원하는 듯! [3]
1832정성태1/2/201523706오류 유형: 266. Azure에 응용 프로그램 게시 중 로그인 오류
1831정성태1/1/201532532디버깅 기술: 66. windbg 분석 사례 - cpu 100% 현상 (1) [1]
1830정성태1/1/201531930오류 유형: 265. svchost.exe 프로세스(IP Helper: IPHLPSVC)의 CPU 100% 현상
1829정성태12/16/201435520VC++: 86. Windows Vista부터 바뀐 Credential Provider 예제 분석 (2) [2]파일 다운로드1
1828정성태12/15/201432139VC++: 85. Windows Vista부터 바뀐 Credential Provider 예제 분석 (1) [4]파일 다운로드1
1827정성태12/12/201428379VC++: 84. CredUIPromptForWindowsCredentials Win32 API 사용법 정리
1826정성태12/11/201432710.NET Framework: 489. Socket.Listen에 전달된 backlog 인자의 의미 [6]
1825정성태12/11/201480577.NET Framework: 488. TCP 소켓 연결의 해제를 알 수 있는 방법 [10]파일 다운로드1
1824정성태12/10/201429698.NET Framework: 487. Socket.Receive 메서드의 SocketFlags.Peek 동작을 이용해 소켓 연결 유무를 확인? [8]파일 다운로드1
1823정성태12/10/201426893.NET Framework: 486. Java의 ScheduledExecutorService에 대응하는 C#의 System.Threading.Timer [2]
1822정성태12/3/201428198개발 환경 구성: 252. Xamarin 라이선스 관리 [8]
... 121  122  123  124  125  126  127  128  129  130  131  [132]  133  134  135  ...