오늘은 개발자 한 분이... 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"이 있겠지요.