UTF-8

UTF-8은, Unicode Transformaion Format-8의 줄인 말이다. 즉, ISO 10646 / Unicode에서 정의한 문자 집합을 8비트 바이트 스트림으로 인코딩하는 규약이다.

UTF-8

UTF-8은 모든 Unicode 문자를 1바이트에서 4바이트까지 가변폭 바이트 스트림으로 인코딩한다.

ISO JTC1/SC2/WG2

Unicode Technical Committee

하나의 Unicode 문자를 몇 바이트로 인코딩할지는 해당 글자에 할당된 코드값 (

Unicode Scalar Value)에 따라 결정할 수 있다. U+007F까지는 1 바이트, U+0080에서 U+07FF까지는 2 바이트, U+0800에서 U+FFFF까지는 3 바이트, U+10000에서 U+10FFFF까지는 4 바이트를 쓴다. 따라서 US-ASCII에 속하는 문자는 U+0000 (NULL)을 포함해서 UTF-8에서는 한 바이트로 표현할 수 있다. 이 특성은 US-ASCII와 호환성을 유지해야 하는 유닉스 파일 시스템¹, SMTP (인터넷 메일)를 비롯한 텍스트 기반인 여러 인터넷 프로토콜에서 쓰기에 적합하다.

Unicode를 인코딩하는 방법으로는 UTF-7, UTF-8, UTF-16, UTF-32 등 여러 가지 방법이 있다.
TeX에서는 주로 UTF-8을 사용하는데, CJK 문자는 U+0800 이후에 할당되어 있으므로 UTF-8에서 3 바이트를 써서 나타내야 한다. 반면에 UTF-16을 쓸 경우에는 CJK 글자를 포함해서 모든 BMP (Basic Multilingual Plane : Unicode 중 처음 65,536 코드 포인트)에 속하는 글자는 2 바이트로 나타낸다. 이런 이유로 UTF-16을 선호하는 경우가 있으나 (UTF-8이 UTF-16에 비해 최대 1.5배 더 많은 저장 공간/송신 시간을 요하므로) US-ASCII와의 호환성은 많은 경우에 대단히 중요하므로, Unix(Mac OS X)와 ?BeOS 등은 텍스트 형식과 그와 유사한 형식에서 UTF-8을 주로 쓴다. 같은 이유로 TeX/Omega에서도 UTF-8을 주로 쓴다. 반면에 Win32에서는 텍스트 문서 형식도 기본으로는 UTF-16을 사용한다.

텍스트 형식과 OS나 프로그램 혹은 라이브러리 내부에서 어떤 인코딩을 쓰느냐는 별개의 문제이다. Linux glibc는 UTF-32를 쓰고, Mac OS X, Win32, Omega, ICU (International Component for Unicode), Java, ECMAscript², Mozilla 등은 UTF-16을 쓰고, ?BeOS, glib, Perl 등은 UTF-8을 쓴다. Python은 UTF-32 혹은 UCS-2 (2byte 혹은 4byte를 쓰는 가변폭 인코딩인 UTF-16과 달리 UCS-2는 2byte 고정폭 인코딩으로 오직 BMP만 지원할 수 있다.)를 쓰도록 컴파일할 수 있다.
UTF-32는 가변폭 인코딩인 UTF-16을 다루는데서 오는 불편함³을 피할 수 있는 반면에 UTF-8에 비해 최대 4배의 공간(US-ASCII에 속하는 글자라면)을, UTF-16에 비해서도 최대 2배 (BMP에 속하는 글자의 경우)의 공간을 쓴다는 단점이 있다.

더 자세한 것은 다음 웹 페이지와 거기서 언급한 MS, Apache 등에 있는 관련 페이지를 참조하십시오 : -- 신정식

http://www.w3.org/International/questions/qa-utf8-bom.html
http://www.unicode.org/unicode/faq/utf_bom.html
UTF-8을 정의한 IETF RFC : RFC3629
UTF-8의 유래에 대한 Bob Pike의 이메일 :http://www.cl.cam.ac.uk/~mgk25/ucs/UTF-8-history.txt
Unicode Glossary: http://www.unicode.org/glossary/

____
¹[UTF-8]은 UTF-FSS라고 불리웠다. FSS는 여기서 File System Safe를 뜻한다.
²Javascript : ECMA 290, ECMA 327도 ECMAscript 관련 표준임
³그다지 큰 문제가 되지는 않는다. 많은 OS, 라이브러리, 응용 프로그램에서 이를 잘 쓰고 있다. 하지만, 개인적으로는 UTF-32를 선호한다.

UTF-8의 용례 및 다른 정보들

유니코드 UCS와 UTF

TeX과 UTF-8

UTF-8 인코딩 문서에서 US-ASCII에 속하는 글자는 1바이트로 표현된다. 그러므로 TeX 명령들은 보통의 ASCII 텍스트와 같은 코드를 가지므로 TeX/Omega가 명령을 인식하고 처리하는 데 코드 변환의 부담을 줄일 수 있다.
현재 UTF-8 인코딩의 한글 문서를 처리할 수 있는 TeX 또는 TeX Macro는 LaTeX을 그냥 이용하는 CJKLaTeX이나 LaTeX-ucs, 그리고 Omega/Lambda를 이용하는 HLaTeX/Lambda가 있다.
UTF-8 인코딩으로는 Unicode를 전부 쓸 수 있으므로 다국어 문서를 작성하는 데는 가장 좋은 해결책 가운데 하나가 된다. 유일한 문제는 Unicode 전체를 표현할 수 있는 글꼴이 있느냐는 것일 뿐이다.

UTF-8 문서의 편집

UTF-8 문서를 편집할 수 있는 편집기/워드프로세서는 NotePad, Wordpad, MS-Word, 아래아한글, UltraEdit, Yudit, EditPlus, jEdit, AcroEdit, SCUnipad, Windows용 Vim (VimEditor), Windows용 Emacs 등이 있다.
Unix (Linux, Mac OS X 포함)에는 UTF-8 문서 편집할 수 있는 편집기가 매우 많습니다. Vim, Emacs, ?TextEdit (Mac), Yudit, mined, gedit, kedit 등입니다. 일부 편집기는 locale를 정해야 합니다. XIM으로는 Nabi와 Ami 등을 사용해서 사용할 수 있습니다.

UTF-8 편집기를 이용한 LaTeX/Lambda 작업에서 BOM 문제

BOM, Byte Order Mark

BOM(Byte Order Mark) : 바이트가 기본 단위인 UTF-8과 달리 UCS-2와 UTF-16은 2 바이트가 기본 단위이고, UTF-32에서는 4 바이트가 기본 단위이므로 바이트 열로 바꿀 경우 최상위 바이트가 먼저 오느냐 (Big Endian) 나중에 오느냐 (Little Endian)에 따라 두 가지 다른 표현이 가능하다. 이 순서를 표시하기 위해 문서의 선두에 그 위치에서는 아무런 역할을 할 수 없는 U+FEFF (Zero Width Non-Breaking Space)를 두어서 바이트 순서를 자동으로 알아내도록 할 수 있다. 예컨대, UTF-16의 Little Edian에서는 BOM을 FF FE로 반면 Big Edian에서는 FE FF로 직렬화한다. UTF-32LE라면 FF FE 00 00이고, UTF-32BE라면 00 00 FE FF일 것이다. BOM(U+FEFF)은 UTF-8로 나타내면 EF BB BF이다.

UTF-16 LE	FF FE
UTF-16 BE	FE FF
UTF-32 LE	FF FE 00 00
UTF-32 BE	00 00 FE FF
UTF-8	EF BB BF

Win32의 일부 프로그램 (Notepad, Wordpad, MS Word) 등은 UTF-8 BOM을 Win 9x/ME에서 쓰이는 ANSI¹ code page (한국어 Windows라면 codepage 949 - 확장 완성형)로 작성된 텍스트 파일과 구별하기 위한 표지로 사용한다. 즉, UTF-16, UTF-32, UTF-8 BOM이 있으면 UTF-16, UTF-32, UTF-8로 인식하고 그렇지 않은 경우 ANSI code page를 쓴 것으로 간주한다. XML 표준에서도 UTF-8 BOM을 비롯한 BOM을 인코딩 결정을 위한 하나의 방법으로 명시하고 있다. 하지만, UTF-8 BOM은 POSIX 기반 OS에서 cat file1 file2 file3 | another_program과 같은 파이프를 쓸 때에 문제를 일으키므로 그다지 환영받지 못 한다. TeX/Omega 입장에서도 Notepad, Wordpad 등이 BOM을 UTF-8에 붙이는 것은 그다지 반가운 일이 아니다. TeX/Omega compiler는 .tex 파일 선두에 의미를 알 수 없는 글자가 있는 것으로 여기므로 경고를 낸다. 그냥 <Enter>를 치고 강제 컴파일하면 빈 페이지가 처음에 붙어 나온다. -- 신정식

____
¹[http://www.ansi.org ANSI]와 아무 관련이 없지만, MS는 이 용어를 쓴다

에디터와 BOM

NotePad, Wordpad, UltraEdit는 UTF-8로 저장하면 자동으로 BOM을 붙여준다. 반면 Windows용 Yudit에서는 Linux에서와 마찬가지로 BOM을 붙이지 않는다. 윈도 운영체제에서 UTF-8 엔코딩으로 LaTeX 문서를 만드는 사람들은 BOM 문제를 스스로 처리하여야 할 것이다.

UTF-8에서 BOM이 반드시 필요한가는 의문이다. 없어도 좋을 듯. NotePad나 UltraEdit으로 유니코드 .tex 소스를 편집한 경우라면 유니코드(UTF-16)로 저장한 다음 libiconv를 이용해서 UTF-8로 변환하면 귀찮은 UTF-8 BOM을 제거해준다.

Unicode

#!/usr/bin/perl -pi~ -0777 
   # program to remove a leading [UTF-8] BOM from a file
   # works both STDIN -> STDOUT and on the spot (with filename as argument)
   if ($] > 5.007) {
   require Encode;
   Encode::_utf8_off($_);
   }
   s/^\xEF\xBB\xBF//s;

UltraEdit의 경우 다음 옵션을 %SystemRoot%\UEdit32.INI에 넣어주면, BOM 없이 저장할 수 있다.

Write UTF-8 BOM = 0 
Write UTF-8 BOM NF = 0

?UEdit의 경우, Advanced -> General 에서 BOM 제거 선택여부를 지정할 수 있습니다.
Editplus의 경우는 기본설정이 'BOM 제거'입니다. -- 황재훈

그 외 Microsoft Visual Studio.NET에서 사용하는 IDE의 경우, 고급 저장 옵션으로 BOM을 붙일 것인지 지정할 수 있다. -- kheled

Yahon's Blackbox

UTF-8

UTF-8

UTF-8의 용례 및 다른 정보들

TeX과 UTF-8

UTF-8 문서의 편집

UTF-8 편집기를 이용한 LaTeX/Lambda 작업에서 BOM 문제

BOM, Byte Order Mark

에디터와 BOM

티스토리툴바

UTF-8

UTF-8

UTF-8의 용례 및 다른 정보들

TeX과 UTF-8

UTF-8 문서의 편집

UTF-8 편집기를 이용한 LaTeX/Lambda 작업에서 BOM 문제

BOM, Byte Order Mark

에디터와 BOM

'지식/Network' Related Articles

티스토리툴바