PROGRAM PARK

풀다운 메뉴의
        File/
        Save As(다른 이름으로 저장)/
에서 나온 대화상자에서

Encoding(인코딩)을 Unicode 나 UTF-8 로 지정한 후 "저장" 버튼을 누릅니다.





(윈도우에 기본으로 설치되어 있는) 메모장을 사용해 변환


풀다운 메뉴의
        파일/
        다른 이름으로 저장/
에서 나온 대화상자에서

"인코딩"을 "유니코드"나 "UTF-8"로 지정합니다. 특별한 이유가 없는 이상, "유니코드 (big endian)"은 선택하지 마세요.





울트라에디트(UltraEdit)를 사용해 변환:


풀다운 메뉴의
        File/
        Conversions(변환)/
에서

ASCII To Unicode : 현재 한글 문서를 유니코드로 변환

ASCII To UTF-8 (Unicode Editing) : 현재 한글 문서를 유니코드(UTF-8)로 변환



일반 아스키 텍스트 파일을 유니코드로 변환할 때에는 또는 그 반대로 변환할 때에는, 이엠에디터(EmEditor)로 변환하는 것이 가장 안정적입니다. 울트라에디터의 경우에는 버그가 있어서 글자들이 깨지는 경우가 많습니다.


http://mwultong.blogspot.com/2006/05/unicode-utf-8_20.html

http://ncanis.tistory.com/19  이글을 보면, ansi unicode utf8 에 대해 자세히 나오네요.



아래내용은 저가 이해한부분만 발췌,수정한거라서, 원본을 보시면 더 이해가 쉬울듯 하고요.

글 맨아래 링크글도 자세한 내용이 많네요....





character set(문자집합, 문자셋) - ASCII 코드, 유니코드
표준, 규정 - ANSI, ISO,
인코딩 종류 - UTF-7, UTF-8, UTF-16, EUC-KR,

character set
SBCS(Single Byte Character Set), 1바이트 -> ASCII, ANSI-949,
DBCS(Double), 2바이트 -> CP949, EUC-KR,
MBCS(Multi Byte Character Set), -> SBCS 와 MBCS 같이사용
WBCS(Wide Byte Character Set), 여러바이트 -> CP1200(unicode), CP65001(UTF-8),UTF-16,

문자셋
http://blog.naver.com/proai?Redirect=Log&logNo=20018729436
http://blog.naver.com/m30winjv/90037004637


http://ncanis.tistory.com/19

1. ASCII 코드

1byte로 표현하는 ASCII  코드
0~127 까지이다, (글자는 32~127로 표현한다.)

1byte는 -127~127 까지 총 2의 8승, 256개 이니 1byte로 된다. 물론 영어만.
2의 보수면 0~255까지, 총 7비트로 표현 가능하니 마지막 비트는 다른나라 사람들이 알아서 써라.
이 영어 문자를 제외하고 나머지 128~255를 맵핑하면서 문제는 시작된다.
예를들어서, 미국 pc의 128~255 bit 값에 대한 맵핑과 이스라엘의 pc의 맵핑이 틀리면
메일을 보내면 resume => ?????? 같이 보여지게 될 것이다.

즉, 서로 제각각으로 이 1bit를 사용했다는 것임.

이런 문제점을 통합해서 표준화 한것이 ANSI 이다. 128~256을 어떻게 사용할껀지에 대한 규약이다.
즉 이스라엘은 ANSI-862를 쓰고, 우리나라는 ANSI-949, 영어는 ANSI-437을 쓴다.

즉 코드페이지란 개념으로
코드페이지 949번은 128~255를 한글로 맵핑했다. 한글을 사용하는 사람들은 949로 맵핑해서 써라 이뜻이다.

2. 유니코드

아시아권의 글자(한글,일본어,중국어)는 1byte로는 택도 없다는것을 알죠?
그래서 나온게 DBCS 라네요
Dobule Bytes Character Set 즉, 나머지 모자라는 문자는 두번째 byte에 저장해라 이얘기다.

이제 유니코드다. 유니코드가 나옴으로써 위의 문제들이 모두 해결된 것이다.

유니코드가 하나의 "문자"를 무조건 2bytes 표현한다고 생각은 오류다.
2bytes 면 2의 16이니 65536까지 표현 가능하네.
자바에서는 하나의 문자(char)를 4byte로 표시한다, 아 C++은 2byte로 처리한다.

유니코드에서 글자는 코드 포인트라는 단순히 이론적인 개념으로 사상한다.
즉 A가 0100 0001  1byte로 이렇게 표현되지만,
만약 폰트가 달라지면 어떻게 할까
A 와 a 와 이상한 a 등등 A를 의미하는 것은 같지만, 모두 다르다.
즉 관념적인 A 다.
즉 폰트가 달라져도, 유니코드 페이지 값은 동일하다.
윈도우에서 실행>charmap 을 치면 이게 나온다.

보면 H 를 선택했는데 문자코드가 0x48 이라고 나온다.
만약 폰트를 다른걸 선택해도 관념적인 H는 0x48 동일하다. 이런 관념적인 문자 코드 번호를 코드포인트 라고 한다.
U+0048 이게 정확한 "H" 의 코드 포인트 인다.

이렇게 관념적으로 문자를 지정하니 폰트가 달라져도 모양만 바뀌게 되는것이다.
생각해보라. 우리가 사용하는 한글폰트들 얼마나 많은가. 그걸 몽땅 몇바이트에 넣어 사용한다면 ?
즉 H를 다른 폰트로 바꾸어도 코드포인트는 U+0048 동일하다.
여기서 문제가 있다. 이런 코드 포인트를 저장해야한다.
0048 이니 2byte에 저장하는 것이다.
즉 00(1byte), 48(1byte)

여기서 리틀 엔디안과 빅 엔디안의 개념이 나온다. 각 컴퓨터에서 좀더 빨리 돌리기 위해 이 순서를 바꾼것이다 . 네떡(네트워크)하시는분들 아시죠?
* 리틀 엔디안과 빅 엔디안은 조나단 스위프트의 걸리버 여행기에 나오는 이야기로 삶은 달걀을 둥근쪽을 깨서 먹는 사람 Big Endian 과
뾰족한 쪽을 깨서 먹는 사람들 Little Endian 로 나누어 정치적 대립을 벌이는 소인국 이야기에서 유래 되었다.

즉 00 48 대신에 48 00 으로 쓰는 것이다. (리틀엔디안, 빅 엔디안)

그럼 이렇게 되면 무엇이 필요할까, 이 문자가 과연 리틀인지 빅인지 알아야 할꺼 아닌가
그래서 문자열 맨앞에 유니코드 바이트 순서표시를 붙였다. 그래야 서로 호환해서 바꾸던지 말던지 할꺼다.


3. UTF - 8
  
자아 여기서 문제다. 미국국적 즉 영어권 프로그래머들은 머가 불만일까
그들은 영어라 1byte면 표현 가능하다. 근데 매 문자 마다 2byte로 표현해야 하니 불만인거다.
저장공간 낭비라면서..

그래서 나온게 UTF-8 이다.   UTF-8 은 0~127 사이에 존재하는 모든 코드 포인트들을 단일 바이트로 저장한다.
128이상인것은 2byte 째, 3byte째로 해서 최대 4byte 까지 확장해서 저장한단다.

이러면 영어권에서도 기존 ASCII와 똑같이 맞아 떨어지니 굳이 바꿀필요 없다는 거다.


4. 인코딩

항상 이게 문제다. 왜 한글로 메일을 보냈는데, 받는쪽에서 깨져보일까.
        => 이건 보낼때 이 문자열이 어떤 인코딩방식인지 안알려줘서 그렇다.
               (UTF-8, ASCII,  ISO 8859-1(라틴), 윈도우1252(유럽) 도대체 어느것?)

이메일인경우 헤더에 "Content-Type: text/plain; charset="UTF-8" 같이 적어주면 된다.
HTML도 마찬가지다.
  (근데 우낀게 태그선언을 안해도  한글로 보인다. 왜냐면, 윈도우가 자주쓰는 빈도를 파악해서 인코딩 해준단다.)

* 모든 문자를 표기하려면 UTF-8 을 써라. euc-kr로 표현 불가능한 문자 많다.
* euc-kr이나 ksc5601는 서로 같은 의미이다.

인코딩에서 코드 페이지 (CP) 번호

CP 949 Korean (UHC(통합완성형, 확장완성형)), 로마자 및 한국어(11,172 자), 일본어와 한자 표현
            한글을 표현하는데는 2바이트를 사용하며 첫번째 바이트는 0×81~FE 사이, 두번째 바이트는 0×41~5A, 0×61~7A, 0×81~FE 영역을 차지한다.  
CP 1200 Unicode, 전세계 모든문자 표현, 한국어(11,172 자)
CP 1201 Unicode (Big-Endian)
CP 1361 Korean (Johab)
CP 10003 Korean (Mac)
CP 12000 Unicode UCS-4 Little-Endian
CP 12001 Unicode UCS-4 Big-Endian
CP 20833 IBM EBCDIC (Korean Extended)
CP 20949 Korean Wansung (EUC-KR = 완성형), EUC(Extended Unix Code)계열은 unix에서 유래, 로마자 및 한국어(2,350자 정도), 일본어와 한자 표현
            한글을 표현하는데는 두 개의 바이트를 사용하며, 첫번째 바이트와 두번째 바이트 모두 0xA1~0xFE 사이의 값을 가진다
CP 50225 Korean (iso-2022-kr)
CP 50933 Korean Extended and Korean
CP 51949 Korean (EUC)
CP 65000 Unicode (UTF-7), unicode 의 mail safe version.
CP 65001 Unicode (UTF-8), 이론적으로 모든 unicode character 를 표현, 한글자에 1~4바이트,
               한글은 UTF-8 로 표현하게 될 경우 한 글자 당 3 바이트 씩을 차지하게 됩니다.한국어(11,172 자)
CP 65005 Unicode (UTF-32)
CP 65006 Unicode (UTF-32 Big-Endian)

한글과 관련된 토론
http://forum.standardmag.org/viewtopic.php?pid=3866

컴퓨터속의 한글
http://b.mytears.org/2005/01/101

위키백과, UTF-8
http://ko.wikipedia.org/wiki/UTF-8



유니코드 차트
http://www.unicode.org/charts/
[출처] ansi unicode utf8... (powerpro 정보 나눔터) |작성자 두부김치

C++의 다양한 string 타입 | C & C++

  
http://cafe.naver.com/newchany/623  



윈도우에서 C++로 코딩을 하다보면(물론 unix 에서도) String처리에 관련된 매우 다양한 타입의 데이타들을 보실 수 있습니다. 헷갈리는 여러 스트링 타입들을 정리해 보도록 합시다. 특정 스트링 타입과 제공되는 API를 사용할 때 생각해 봐야할 체크포인트는 세가지 정도 될 것 같습니다.

1. 인코딩 문제
2. 버퍼 오버 플로우 문제
3. 쓰레드 안전성 문제


기본부터 - char
언제나 시작은 기본부터. char부터 시작해 보도록 하겠습니다. 8bit를 담을 수 있는 자료형입니다. 안에 무얼 담아도 상관없지만 8비트 단위기 때문에 ASCII나, 각 인코딩 별 MBCS, UTF-8도 이곳에 담을 수 있습니다. C에서 지원하는 char 를 위한 api는 아래와 같은 것들이 있습니다.

구분 대상
길이 파악 strlen
문자열 복사 strcpy, strncpy, strcat, strncat
문자열 비교및 검색 관련 strcmp, strncmp, strchar, strstr,
파싱 관련 atoi, atof, atol, itoa
입 출력 함수 printf, sprintf, sscanf

토크나이징 관련 strtok

char 계열의 함수들을 사용할 때의 주의 사항들입니다. 사실 다국어 버전을 사용한다면 이 보다는 wchar_t를 사용하는 것이 좋습니다. MBCS를 이용해서 작성된 코드는 타 언어의 OS환경에서 수행하면 모든 글자들이 깨져서 보입니다.

strlen() 먼저 보겠습니다. 이 녀석은 단지 버퍼안에 0이 나타날때까지의 길이를 리턴해 주는 함수 입니다. 만약 MBCS 한글이 있다면 한글을 2글자로 처리할 것입니다. 해서 총 글자 수 보다 많은 값이 리턴 될 것입니다. 아래에서 더 살펴보도록 하겠습니다.

strcpy() 는 사용하지 않는 것이 좋습니다. 공간이 적은 목적지에 큰 데이타를 넣을라 치면 버퍼가 오버플로우 되서 문제가 발생합니다. 이보다는 strncpy() 를 사용하셔야 합니다.

strcat() 역시 strcpy()와 같은 이유로 strncat()을 사용하셔야 합니다. 한가지 더 고려해야할 부분이 있는데 strncat()은 뒤에 NULL문자를 붙여주지 않기 때문에 스트링의 끝을 찾을 수 없는 문제가 발생합니다.

strtok() 함수는 내부에 static변수를 사용합니다. 즉 쓰레드에 안전하지 않습니다.



유니코드 - wchar_t
wchar_t는 윈도우 환경에서 유니코드를 쓸 수 있도록 만든 데이타 형입니다. 크기가 컴파일러 별로 통일되지 않은 데이타 타입인데 자세한 내용은 문자열 인코딩 글에서 확인하실 수 있습니다. 어찌 되었건 윈도우 환경에서 wchar_t는 16비트이고 char를 위한 api와 비슷한 api를 아래와 같이 제공합니다.

구분 대상
길이 파악 wcslen
문자열 복사 wcscpy, wcsncpy, wcscat, wcsncat
문자열 비교및 검색 관련 wcscmp, wcsncmp, wcschar, wcsstr,
파싱 관련 _wtoi, _wtof, _wtol, _itow
입 출력 함수 wprintf, wsprintf, wsscanf

토크나이징 관련 wcstok


목록을 보면 str 부분이 모두 wcs 로 바뀌어 있습니다. atoi 와 같은 함수는 _wtoi로 바뀌었네요. 하여간 이함수들 역시 위에서 본 char용 api가 가지는 문제들을 그대로 가지고 있기 때문에 똑같이 주의해서 사용하셔야 합니다.

wcslen() 함수 하나만 살펴보도록 하겠습니다. 이 함수는 strlen()보다는 보다 똑똑한 출력값을 리턴합니다. 하지만 그렇다고 안심할 수는 없습니다. 코드를 보고 설명드리도록 하겠습니다.


char str1[] = "abc가나다";  
wchar_t str2[] = L"abc가나다";  


printf("char 문자열 길이 : %d \n", strlen(str1) );  
printf("wchar_t 문자열 길이 : %d \n", wcslen(str1) );  


/*
아웃풋은 다음과 같습니다.


char 문자열 길이 : 9
wchar_t 문자열 길이 : 6
*/


wchar_t는 한글이고 영문이고 모두 16비트 공간을 할당하기 때문에(윈도우 환경에선) 실제 길이에 맞는 글자 수가 리턴됩니다. 하지만 UNICODE는 16비트 BMP영역 밖의 문자도 있습니다. 일부 특수문자와 확장 한문이 그렇죠. UTF-16은 BMP영역 밖의 문자열에 대해서는 두 wchar_t를 합쳐 하나의 하나의 뜻을 내도록 합니다. 따라서 wcslen이 정말 글자 갯수를 리턴한다는 보장이 없습니다. 반면 gcc에서는 wchar_t가 32비트 할당이 됩니다. 이경우에는 wchar_t두개를 합치거나 할 필요가 없습니다. 이 때는 확실히 wcslen()이 글자 수를 리턴한다고 할 수 있습니다.

한가지 더 "L"에 대하 이야기 해보도록 하겠습니다. wchar_t str2[] = L"abc가나다" 바로 이부분인데요. 이 글을 보시는 많은 분들이 저 L이 다음에 나오는 스트링이 유니코드라는 것을 표시할 때 쓴다는 것을 알고 계실 겁니다. 그렇습니다. 다시 이야기하면 L은 컴파일러에거 뒤에나오는 스트링은 wchar_t 에맞는 UTF-16(윈도우의 경우)이거나 UTF-32(gcc의 경우)라는 것을 알려 줍니다.

하지만 여기서 짚고 넘어가야 할 것이 하나 있습니다. 실제 "abc가나다" 는 소스코드에 적힌 텍스트일 이 글자는 뭘로 인코딩 되어 있을까요!? 갑자기 멍~ 해지는 군요. 사실 이 텍스트는 시스템에 따라 달라집니다. 한글 윈도우의 경우에는 CP949형식으로 인코딩 되어 있습니다. 중국어나 일본어가 설치된 윈도우라면 다른 인코딩 방식으로 적혀 있을 테죠. 즉 컴파일러는 L이 나오면 뒤에 나오는 문자열을 UNICODE로 컨버팅 합니다. 한글 윈도우라면 CP949에서 UNICODE로 변환하겠죠. 한글로된 소스코드를 일본어가 깔린 컴퓨터에서 컴파일 한다면 어떻게 될까요? L""뒤에 적힌 한글을 제대로 변환해 줄까요? 컴파일러는 L""뒤에 있는 문자열이 SHIFT_JIS라고 생각할 것입니다.(CP932 나 EUC-JP 일지도;;) 당연히 엄하게 컨버팅 할테죠. 이런 현상을 막기 위해서는 아래와 같이 해주시면됩니다.


// 아래 함수를 이용하는 방법
setlocale(LC_ALL, ".949");


// VC의 경우 #pragma를 이용하는 방법
#pragma setlocale(".949")




TCHAR와 기타 매크로
간단히 char 와 wchar_t를 정리해봤습니다. 만약 유니코드로 작성된 코드를 MBCS로 고치고 싶다면 어떨까요? 또는 반대라면. 일일이 다 L을 붙이고 함수이름을 다 바꾸고 얼마나 귀찮겠습니까. 그래서 TCHAR라는 매크로가 있는데요. TCHAR는 프로젝트에 UNICODE사용이 설정되어 있으면 wchar_t 아니면 char로 정의 됩니다. 위에서 말한 모든 함수드로 _tcs 로 시작하는 함수를 사용하는 방법으로 대치 할 수 있습니다. 또 L 키워드 대신에 _T("문자열") 방법을 사용하시면 되구요. 이글에 관심을 가지시는 분들은 대부분 아시리라 생각 됩니다.

몇몇 매크로도 정리해보겠습니다. 아래는 윈도우에만 해당하는 이야기 입니다. 각 매크로를 따라가면 몇번에 걸처 typedef 되어 있긴 하지만 끝까지 따라가면 결국 아래와 같습니다.
매크로 뜻
LPSTR
LPCSTR
char *
const char *

LPWSTR
LPCWSTR
wchar_t *
const wchar_t *

LPTSTR
LPCTSTR
TCHAR *
const TCHAR *

LP는 포인터, C는 const, W는 wchar_t, T는 TCHAR 라고 생각하면 기억하기 쉽습니다.



string과 wstring
이 두놈은 STL 표준에 있는 스트링 처리 클래스(일종의,,)입니다. string은 char를 담을 수 있고, 이름에서도 알 수 있듯이 wstring은 wchar_t를 담을 수 있습니다. 다들 알고 계시겠지만 몇가지만 특징만 적어보자면..

스트링 길이에 맞게 크기가 알아서 조절 됩니다.
버퍼 사이즈와 이에 따르는 버퍼 오버플로우 문제가 해결됩니다.

+= 연산자를 지원합니다. strcat()에 의한 오버 플로우 문제가 없습니다.
기존 CAPI에서 사용할 수 있습니다. 단 읽기 전용으로만 가능합니다.

표준입니다! 어느 플랫폼에서도 컴파일 가능하고 올바로 동작합니다.
다양한 기능들에 대해서는 웹을 더 참고하시기 바랍니다. 여기서는 이정도만 다루고 인코딩 컨버팅 때에 좀더 이야기 해보도록 하겠습니다. STL의 string은 TCHAR용이 따로 없는데 사용하고 싶으시다면 아래와 같이 typedef 해서 쓰시면 됩니다.
typedef std::basic_string<TCHAR > _tstring;



CAtlString, CAtlStringA, CAtlStringW
이 둘은 MFC에 있던 CString과 CStringW가 ATL로 분리되서 나온 아이들 입니다. CAtlString은 TCHAR를 담고 CAtlStringA은 char를 CAtlStringW는 wchar_t를 담아서 씁니다. 이 아이들은 STL의 string과 비슷한 동작을 하는데 Format()이라던지 Trim()과 같은 몇몇 편리한 함수가 있습니다. 단 표준이 아니라 윈도우 환경에서만 쓸 수 있다는 것이 문제 입니다. 다양한 기능들에 대해서는 웹을 더 참고하시기 바랍니다. 여기서는 이정도만 다루고 컨버팅 글에서 좀더 이야기 해보도록 하겠습니다.



BSTR과 CComBSTR
이 아이는 Windows의 COM을 위해서 탄생한 아이입니다. 다른 언어로 개발된 프로그램과 문자열을 주고 받으려는 목적으로 개발되었죠. 기본적으로 wchar_t* 형태로 typedef된 UNICODE입니다만 특이한 점은 문자열의 길이를 문자열 가장 앞 4바이트 공간에 저장한다는 점입니다. 러시안 페인트공의 문제가 해결되지만 대신 숫자가 틀리지 않게 하는데 노력이 들어갑니다. 이를 좀더 사용하기 쉽게 감싼 녀석이 _bstr_t 과 CComBSTR 입니다. 역시 이 타입들도 컨버팅에 관한 이야기만 따로 하도록 하겠습니다.

[출처] C++의 다양한 string 타입 (차니의 컴퓨터 마을) |작성자 newchany

* 질문 : Full HD는 해상도가 1920*1080인 경우를 말한다고 하던데, 그렇다면 HD와 무슨 차이가 있는지 모르겠네요. 그리고 1920*1080이 어떻게 HD나 Full HD의 해상도가 되었는지도 궁금합니다.

* 답변 : HDTV의 개념은 1979년 일본의 NHK 방송국에서 더 좋은 화질을 위한 TV 시스템을 제안하면서 논의되기 시작했습니다. NHK가 최초로 제안한 스펙은 SDTV의 수직과 수평 해상도를 2배로 높이고, 15:9의 화면비율을 가지도록 하자는 것이었습니다만, 화면비율은 나중에 16:9로 수정됩니다. 쉽게 말해서 기존의 아날로그 방송과 같은 수준의 화질인 SDTV에 비해 2배 더 선명한 화질로 개선하기 위해 해상도를 2배 높이고 화각을 넓힌 것이 HDTV라고 생각하시면 되겠습니다.

SDTV 에는 크게 NTSC(북미)에 기초한 480i/29.97 스캐닝 방식과 PAL(유럽)에 기초한 576i/25 스캐닝의 2가지 다른 방식이 존재하고 있는데, HDTV에서는 이 둘과 모두 호환되도록 만들기로 했습니다. 컴포넌트 4:2:2 (Rec. 601)을 기준으로 할 때 480i/29.97 스캐닝의 총해상도는 858*525입니다만 유효해상도는 720*480이며, 576i/25 스캐닝의 총해상도는 864*625지만 유효해상도는 720*576입니다. 따라서 수직해상도는 다르지만 유효 수평해상도는 720으로 동일합니다.

이 러한 SDTV에서 먼저 수평해상도(720)를 2배로 높이면 1440이 되고, 이 1440에 대해 4:3의 화면비율을 구성하는 수직해상도는 1080라인입니다. 여기서 다시 16:9의 화면비율을 구성하기 위해 1440의 수평해상도에 4/3을 곱해주면 1920이 됩니다. 간단히 정리하자면 아래와 같이 적을 수 있습니다.

        ▶ 수평해상도 2배 향상  →  720  ×    2  = 1440
        ▶ 16:9로 화면비율 향상 → 1440 ×  4/3 = 1920
        ▶ 16:9의 수직해상도     → 1920 × 9/16 = 1080

하 지만 해상도만 1920*1080인 영상물이나 디스플레이를 모두 Full HD라고 부르지는 않습니다. Full HD는 이 1920*1080의 해상도를 순차주사(Progressive Scan) 방식으로 재현할 수 있을 때 사용하는 말입니다. 예를 들어, SD(480i)와 HD(1080i)는 1초에 30개의 프레임(Frame)을 비월주사(Interlace Scan) 방식으로 보여 주지만, Full HD는 1초에 60개의 프레임을 순차주사(Progressive Scan) 방식으로 보여 줍니다. 따라서 Full HD의 영상 데이타량은 HD의 2배가 되고, 특히 움직임이 많은 장면에서 보다 선명하게 재현해 줍니다.

        ▶ HD 화면의 초당 화소수 → 1920 × 1080 × 30fps =  62.2 Mpx/sec
        ▶ Full HD의 초당 화소수  → 1920 × 1080 × 60fps = 124.4 Mpx/sec

전문적인 용어로 설명하자면 HD(1080i) 는 SD(480i)의 공간주파수(Spatial Frequency)를 2배로 늘린 후에 16:9의 Wide 화면으로 개선한 것이고, Full HD(1080p)는 HD(1080i)의 시간주파수(Temporal Frequency)를 2배로 늘려 보다 선명하고 매끄러운 움직임을 보여 주는 것이라 하겠습니다.


----------------------------------------------------------------------------- LCD 패널

모니터의 가격에서 LCD 패널이 차지하는 비중은 60%가 넘는다고 한다. 삼성이나 LG에서 생산하는 패널이 아주 고급인것은 틀림없는 사실이지만..  거기서 만드는 모니터들이 모두 그 고급 패널을 사용하는건 아니다. 보급형 LCD에는 저가형 TN패널이 주로 들어가고, 심지어는 대만이나 중국산 패널을 사용하는 경우도 있다. 노트북에 사용되는 패널 또한 마찬가지이다.


따라서 LCD를 고를 때는 그 제품에 사용된 패널이 어떤 것인지를 꼼꼼히 잘 따져봐야 한다.



- TN(Twisted Nematic) 패널 -

일본 Fujitsu에서 개발된 기술로서 낮은 구동 전압과 빠른 응답 시간이 장점이다. 가장 큰 장점은 생산성이 높다는 점이다.

그러나 이 패널은 시야각(특히 수직 방향이 좁다)이 제한되어 있고, 24 비트 트루 컬러를 재생하지 못한다. TN 패널은 표현할 수 없는 색상을 모자이크처럼 시뮬레이션하여 화소를 조합하는 방법으로 24비트를 표현한다. 또한 빛이 새는 문제 때문에 광학 필름을 사용하기 때문에 IPS나 MVA, PVA 패널보다 화질이 훨씬 떨어진다.

방바닥에 누워서 영화를 즐겨보는 사람은 무조건 피해야할 패널이다. 시커먼 화면을 보게될 것이다.


- IPS(In-Plane Switching) 패널 -

1996년 Hitachi에서 TN 패널의 단점을 보완하기 위해 개발하엿다.

투과율이 균일하기 때문에 TN 패널처럼 광학 필름을 사용하지 않고도 넓은 시야각을 얻을 수 있다. 뛰어난 화질 때문에 고급 모니터에서 많이 사용되는 방식이다.

다만 고정된 화면을 장시간 유지할 경우 잔상이 남을 수 있고 응답 속도가 비교적 낮다.

1998년에는 IPS를 개량한 Super-IPS라는 기술이 개발되었는데, LG LCD에서 생산되는 패널이 바로 이 S-IPS이다.




- PVA(Patterned Vertical Alignment) -

1998년 후지쯔가 개발한 MVA를 개량하여 삼성이 만들어낸 방식이다.

이 방식은 빠른 응답 속도에 넓은 시야각, 휘도와 색 표현력의 효율성과 높은 명암비를 자랑한다.

단점으로는 위상차 필름을 사용했기 때문에 투과율이 저하되고,특히 외부 압력 작용시에 균일성과 안정성이 떨어진다.



쉽게 정리하자면 아래와 같다.

- 화질 -
IPS > PVA >>> 넘을 수 없는 벽 >> TN

- 시야각 -
IPS, PVA >>>넘을 수 없는 벽 >> TN

- 반응속도 -
TN > PVA > IPS

- 가격 -
IPS > PVA >>> TN


LG나 삼성은 모니터 무결점 정책을 펼치고 있다.

무결점이란 죽은 화소(데드 픽셀)와 백라이트의 균일성(빛샘현상)에 문제가 없는 제품을 말한다. 따라서 자신들이 생산한 패널중 약간의 결함이 있거나 응답속도가 떨어지는 물건은 중소 기업에 팔아넘기고, 보급형 모니터는 저가형 TN 패널이나 대만, 중국산 패널을 사용한다.

호주머니가 얇으면서도 좋은 화질을 누리고 싶은 사람들은 중소기업에서 삼성, LG 패널을 사용하여 만든 LCD를 구입하는 것이 좋다. 운이 좋다면 무결점 제품을 구입할 가능성도 있다.


대기업의 보급형 모니터를 구입하는건 그리 권장할 바가 못된다.