유용하게 사용할수 있는 단축키 조합들입니다, 윈7과 유사한 부분도 있고 추가된것도 있고...
윈도우 키 + B - 윈도우 데스크탑 전환 후 트레이 아이콘 알림 영역 선택 윈도우 키 + C - 참 바 표시 윈도우 키 + D - 바탕화면 보기/데스크탑 모드 윈도우 키 + E - 윈도우 탐색기 윈도우 키 + F - 메트로 파일 브라우저 및 검색 도구 윈도우 키 + H - 공유 패널 표시(앱 공유 가능할 경우) 윈도우 키 + I - 설정 패널 윈도우 키 + J - 스냅된 메트로 애플리케이션 전환 윈도우 키 + K - 장치 패널을 표시(화면 출력 옵션을 변경) 윈도우 키 + L - 컴퓨터 잠금 윈도우 키 + M - 모든 창 최소화 윈도우 키 + O - 태블릿 화면 전환 윈도우 키 + P - 사용 가능한 외부 디스플레이 선택 윈도우 키 + Q - 검색 참/앱 검색 윈도우 키 + R - 실행 윈도우 키 + U - 접근성 센터 윈도우 키 + W - 설정 화면 검색 윈도우 키 + X - 빠른 실행 모음 윈도우 키 + Y - 데스크탑 엿보기 윈도우 키 + Z - 앱 바 표시 윈도우 키 + + 줌 인 윈도우 키 + - 줌 아웃 윈도우 키 + 1~9 - 작업 표시줄 프로그램 실행 윈도우 키 + Page Up / Down - 타일 화면 이동 윈도우 키 + Tab - 메트로 애플리케이션 전환 메뉴 표시 후 애플리케이션 전환 윈도우 키 + Shift + . (마침표) 현재 메트로 애플리케이션을 화면의 한쪽(좌측)으로 이동 윈도우 키 + Space - 언어와 키보드 레이아웃 전환 윈도우 키 + Enter - 윈도우 내레이터 실행 윈도우 키 + Arrow Keys - 데스크톱 전환 후 에어로 화면 활성화 Ctrl + Shift + Esc - 작업 관리자 실행
완성형과 조합형 완성형은 글자 자체를 하나의 형태로 보고 코드화한 것이고 조합형은 총 한 글자로 표시되는 바이트(보통 2바이트)를 비트로 나누어 초성, 중성, 종성으로 할당해 글자를 표현하는 방식이다. 완성형은 현재 KSX-1001(옛 표준이름 KSC-5601)이라는 표준이 많이 쓰이고 있으며 조합형은 요즘 거의 쓰이지 않는다.
조합형도 여러 가지가 있어 논란이 되다가 결국엔 1987년에 완성형만이 표준으로 되었다.
후에 상용 조합형도 표준으로 들어갔으나 이미 표준이된 완성형만이 널리 쓰이게 되었고 2350자밖에 표현이 안되는 완성형이 윈도우즈에서 쓰이므로 지금까지도 가장 널리 쓰이는 글자 표현 체계가 되었다.
Character set, Character encoding, Code set, Code page Character set이란 문자의 집합이다. 단, 이때 각 문자에는 숫자 코드가 부여된다. 그렇지만 숫자 코드가 컴퓨터 상에서 어떻게 표현되는 가는 정해지지 않은 상태라고 보면 된다.
Character encoding이란 Character set에 좀 더 제약이 강해서 컴퓨터 상에서 어떻게 표현되는 가까지 정해진 상태의 문자의 집합이다. 같은 그림이라도 압축 방법에 따라 gif, png, bmp 등등의 파일 형식이 있듯이 Character set과 encoding의 차이를 이해할 수도 있을 것이다. 실제 예를 들면 완성형 한글인 KSC-5601 Character set은 UNIX에서는 EUC-KR이란 encoding으로 표현되고 윈도우즈에서는 CP-949란 encoding으로 표현된다. 오래 전에는 Character set과 Character encoding이 같은 말이었다. 그러나 언젠가부터 시스템의 종류도 많아지고 다국어 시스템의 지원 등등 여러 여건들에 의해 Character set에서부터 Character encoding이 분리된 것이다.
Code set이란 말은 어쩔 때는 Character set의 의미로 어쩔 때는 Character encoding의 의미로 사용된다. 그렇다 보니 문맥을 보고서 적당히 해석해서 사용해야 한다.
Code Page는 IBM에서 사용하던 말로 Character encoding과 같은 것으로 보면된다. MICROSOFT에서 DOS를 만들 때 IBM과 같이 만들었기 때문에 MICROSOFT에서는 Code page라는 말을 많이 사용한다.
MBCS, SBCS, DBCS MBCS이란 Multi Byte Character Set으로 하나의 문자를 표현하는데 코드가 문자에 따라 한 바이트로도 여러 개의 바이트로도 표현되는 encoding을 의미한다. 완성형 한글인 경우 영문은 1바이트로 표현되고 한글/한자는 두 바이트로 표현된다.
SBCS이란 Single Byte Character Set으로 하나의 문자를 표현하는 code가 항상 한 바이트로 표현될 수 있는 encoding을 의미한다. 즉, 우리가 흔히 아는 ASCII라고 생각하면 된다. DBCS은 Double Byte Character Set으로 하나의 문자를 표현하는 코드가 한 바이트나 두 바이트인 encoding을 의미한다.
윈도우즈 환경에서는 SBCS와 DBCS가 MBCS의 특수한 경우로 처리된다.
KSC-5601, UHC, UNICODE, UTF 프로그램을 하다 보면 문자셋에 대해서 많이 고민을 하게 된다. 이는 KSC-5601(KSX-1001)로 대표되는 완성형 한글은 2350 자가 정의 되어 있으며, UHC(Unified Hangul Codeset)는 KSC-5601과 완벽히 호환이 되며 총 11172개의 한글이 정의되어 있다. 대부분 사용하는 한글 윈도우즈에서는 통합 완성형(UHC)이라고 하는 확장 형태의 완성형 한글('가'->0xB0A1)을 지원한다. 이와는 별도로 ISO에서 전세계의 문자를 UNICODE('가'->0xAC00)라고 불리는 통합적인 체계로 만들었다. 현재 UCS2와 UCS4로 불리우는 2Byte 유니코드와 4Byte 유니코드가 있다. 영어 1문자를 표현는데도 2개의 문자가 필요한 단점이 있어서 이 이상적인 유니코드를 표현하는 방법으로 UTF-8('가'->0xEAB080)이라고 하는 문자가 있다. 그러므로 UCS문자와 UTF-8문자는 1대1로 대응이 가능하다.
완성형과 CP-949, EUC-KR EUC 계열은 유닉스 계열에서 나온 것으로 윈도우즈보다 더 오랫동안 지역화 및 한글화 문제를 겪어서 빨리 대처를 할 수 있었다. 그래서 EUC-KR하면 한국 코드인데 완성형과 일치한다. 즉, EUC-KR = 완성형이다.
윈도우즈에서는 Code Page 949가 완성형인데 변화를 한번 겪어서 UHC(Unified Hangul Codeset, 통합 완성형)라는 이름으로 불리고 있다. CP-949 = UHC로 보면 된다.
l10n l10n은 localization(지역화)의 약칭이다. 개발자들이 긴 낱말이 싫어해서 약어로 사용하는 말이다. 소프트웨어가 localization되어 있다는 말은 소프트웨어를 사용하는 사용자를 위해 한 언어에 맞추어 개발이 되어 있다는 것이다. 그래서 이 경우에는 한번에 다중 언어를 사용할 수 없다. 현지화는 어떤 제품이나 서비스를 특정한 언어나, 문화, 그리고 현지의 정서에 맞추는 과정을 말한다. 이상적으로는 한 제품이나 서비스는 현지화가 비교적 쉽게 달성될 수 있도록 개발된다. 예를 들면, 설명서의 경우에는 기술적인 삽화 등을 사용함으로써 그 안에 있는 글자들을 다른 나라의 언어로 쉽게 바꿀 수 있도록 하고 이러한 목적을 위해 어느 정도의 확장성을 감안하고 있다. 이러한 권능을 부여하는 과정을 국제화라고도 부른다. 그러므로 국제화된 제품이나 서비스는 현지화하기가 더욱 쉽다. 관용적인 언어들의 번역 외에도 현지화되고 있는 제품에서는 시간대 조정, 통화, 해당 국가의 휴일, 현지의 색상 감각, 제품이나 서비스의 이름, 성별 역할, 그리고 지정학적 요인 등이 반드시 고려되어야할 요소들의 예이다. 성공적인 서비스나 제품의 현지화는 현지의 문화 속에서 개발된 것처럼 보여지는 것이다.
현지화의 커다란 부분 중 하나인 언어의 번역은 때로 자동 번역으로 쉽게 할 수 있다. 그러나 대체로 많은 추가 작업이 소요된다.
i18n i18n은 internationalization(국제화)의 약칭이다. software가 internationalization되었다는 말을 들을려면 여러 언어를, 예를 들면, 한국어든 중국어든 동시에 입력해서 사용할 수 있어야 한다. multiligual system이란 말과 i18n system은 동일한 말이다. 국제화는 제품이나 서비스를 특정 지역의 언어나 문화에 맞추는 즉, 현지화라고 불리는 과정을 쉽게 할 수 있도록 계획하거나 이행하는 과정을 말한다. 국제화는 때로 번역 및 현지화 능력 부여 작업이라고도 불리는데 여기에는 다음과 같은 것들이 포함된다.
- 하드웨어 레이블이나, 도움말 페이지, 그리고 온라인 메뉴 등 사용자 인터페이스를 설계할 때 더 많은 수의 글자가 들어갈 때를 대비하여 여유를 둔다. - 웹에디터나 저작 도구 등과 같은 제품을 개발할 때 국제 문자셋 즉, 유니코드를 지원할 수 있게 한다. - 인쇄용 그래픽 이미지나 웹사이트를 만들어서 텍스트 레이블을 번역할 때 비용이 많이 들지 않게 한다. - 전세계적으로 통용될 수 있는 예시를 사용한다. - 소프트웨어의 경우에는 메시지들이 영어와 같은 단일 바이트 문자 코드에서, 한글과 같은 다중 바이트 문자 코드로 변환될 수 있도록 데이터 공간을 확보한다.
UNICODE 모든 글자 표현 체계를 하나로 통합하겠다는 뜻으로 영문권에서 i18n을 위해서 만든 Character set이다. unicode 1.0에서는 몇 가지 문제가 있어서 표현이 잘안되는 글자가 있었으며 unicode 2.0에서는 완벽하게 한글이 표현된다(고어 포함). 현재는 unicode 5.0이다. unicode 자체는 어떤 특정한 바이트 형태를 지정하지 않는다. 따라서 encoding이라는게 필요하다. 그러니까 unicode != UTF-8이다. unicode encoding 중에 하나가 UTF-8은 될 수 있다. 예를 들면, unicode "위"(U+C704)를 UTF-8로 표현하면 EC 9C 84가 된다. 현재 unicode에서 널리쓰이는 encoding은 UTF-8, UTF-16, UCS2, UCS4 등이 있다. 유니코드에서 정의하는 Character set은 UCS2와 UCS4가 있다. 우리가 보통 일반 프로그램을 개발할 때는 UCS2를 기반으로 만들게 된다. UCS4는 산스크리트어나 옛 이집트 고어와 같은 것까지 포함한다. 그러므로 보통 유니코드라고 말할 때는 UCS2를 지칭한다. UCS2/UCS4는 Character set이면서 encoding으로도 존재한다. 이 encoding의 특징은 UCS2 경우에는 영문을 포함한 모든 문자가 두 바이트로 표현되고 UCS4 경우에는 네 바이트로 표현된다. 이렇게 고정된 길이의 encoding을 쓰면 장점은 문자열 내의 특정 문자를 index로 쉽게 접근할 수 있다는 것이다. MBCS처럼 문자마다 길이가 다른 경우에는 n번째 문자를 접근하려면 문자열의 처음부터 검색을 해야 한다는 점을 생각한다면 문자열 처리에 이점이 있다. 그러나 UCS2 encoding에 장점만 있는 것은 아니다. 문제는 기존의 ASCII 기반으로 된 모든 소프트웨어와 데이터베이스를 UCS2로 업그레이드해야만 UCS2와 호환된다는 것이다. 그래서 이러한 단점을 보완하기 위한 encoding이 UTF-7, UTF-8아다. 이 encoding들의 특징은 기존 MBCS처럼 한 문자가 1바이트도 여러 바이트도 가질 수 있다. 그래서 현재는 UTF-8이 주도적으로 쓰인다. UTF-8은 흔히 말하는 숫자, 영문자 (ascii 대역)에서는 그대로 1바이트로 쓸 수 있고 나머지는 가변이라서 공간을 아끼면서도 실리를 찾을 수 있다. 즉, ascii 파일은 그냥 UTF-8 encoding이 되어있다고 가정해도 상관없는 것이다. UTF-8은 ASCII로 표현 가능한 영문자는 1바이트로 표현을 하고 다른 문자들은 2~3바이트로 표현을 한다. UTF-16은 4바이트까지 사용한다. 그래서 실제적으로 프로그램이 유니코드를 지원한다고 하면 내부적으로는 UCS2/UCS4 encoding을 사용하고 파일/데이타베이스 같은 외부 자원에 대해서는 UTF7/UTF8과 같은 encoding을 사용한다. 즉 혼용해서 사용하는 것이다.
UTF-8
유니코드는 미래에 나올 글자들까지도 모두 코드화 하자! 그래서 유니코드는 코드이다. 코딩할 때의 그 코드가 아니라 글자 하나하나에 1, 2, 3, 4, ... 식으로 번호(코드)를 매기는 것이다. 숫자는 끝이 없으므로 미래에 새로운 문자가 생겨도 유니코드에 새로 등록만 시키면 된다(그러므로 유니코드는 2바이트라는 것은 잘못된 것이다).
다시 말하면 유니코드는 개념이자 철학에 불과하며 모든 글자를 포함하는 글자들의 코드 집합니다.
그럼 UTF-8은 무엇인가 하면, 유니코드는 말 그대로 코드 맵핑일 뿐 이를 그대로 소스 코드 상에 구현하기에는 무리가 있다. ASCII 코드와의 호환성도 그렇지만 무작정 두 바이트로 표시한다 하더라도(이것이 UCS-2이다) 메모리 낭비도 심해진다. 그래서 나온 뛰어난 인코딩 방식이 UTF-8이다. UTF-8은 바이트 길이가 문자에 따라 다양해 질 수 있다. 가장 좋은 점은 1바이트일 경우는 ASCII 코드와 동일하다는 것이다. 덕택에 C-like 스트링에서는 문자열의 끝을 표시하기 위해 '\0'을 쓰더라도 문제가 없다. UCS-2 같은 경우는 무조건 두 바이트니 이것조차 '\0\0'으로 표시해야 하는 난감함이 있다.
UTF-8에서 한 바이트로 표시될 수 있는 문자는 ASCII와 호환되므로 당연히 최상위 비트가 0이 된다. 두 바이트로 표현되는 문자면(유니코드 0x80~0x7FF) 첫 바이트는 110xxxxx의 형태의 비트가 된다. 세 바이트로 표현되는 문자면(유니코드 0x800~0xFFFF) 첫 바이트는 1110xxxx의 형태의 비트가 된다. 네 바이트로 표현되는 문자면(유니코드 0x80000~0x10FFFF) 첫 바이트는 11110xxx의 형태의 비트가 된다. 그리고 두 바이트 이상의 문자 중 첫 바이트 외의 문자는 모두 10yyyyyy 형태가 된다.
이 방법으로 알레프()를 UTF-8로 인코딩해 보겠다(알레프는 히브리어 문자의 첫 글자이다). 알레프는 유니코드로 0x5D0, 즉 U+05D0의 코드를 가진다. 5D0은 위의 범위에 따르면 두 바이트로 표현될 수 있다(110xxxxx, 10yyyyyy의 형태). 0x5D0은 이진수로 바꾸면 101 1101 0000의 11비트로 나타낼 수 있다. 5개의 x와 6개의 y에 순서대로 써 주면 된다. 즉 11010111, 1010000이 UTF-8로 인코딩 된 알레프가 되는 것이다.
사실 유니코드를 UTF-8로 표현하는 것은 실제 코딩에서는 크게 활용도가 없을 지도 모른다. UCS-2와 UTF-8을 같이 다루는 경우는 거의 없다. 유니코드 UCS2에서 UTF8로 변환
윈도우즈 API에서 보면 WideCharToMultiByte라는 함수가 있다. 이 함수의 인터페이스는 다음과 같다. int WideCharToMultiByte( UINT CodePage, // code page DWORD dwFlags, // performance and mapping flags LPCWSTR lpWideCharStr, // wide-character string int cchWideChar, // number of chars in string LPSTR lpMultiByteStr, // buffer for new string int cbMultiByte, // size of buffer LPCSTR lpDefaultChar, // default for unmappable chars LPBOOL lpUsedDefaultChar // set when default char used ); 이 함수의 첫 번째 매개변수 CodePage에 CP_UTF8를 할당하여 사용한다.
아래는 UCS와 UTF-8의 변형 방법이다. 보는 것과 같이 7비트 이하 문자들은 한개의 문자로 표현이 가능하며 유니코드로 0xFFFF까지는 3byte를 이용하여 표현이 가능하다(즉, 한글 1글자(2byte)가 UTF-8로 표현시 3byte가 된다).
RFC 2279 : UTF-8, a transformation format of ISO 10646
Windows 9x와 Windows NT 계열 OS의 차이 Windows 9x (Windows 95, 98, me) 계열은 Windows API를 표준적으로 ANSI 버전을 지원한다. 즉, UNICODE를 Windows API에서 직접 지원하지 않고 MBCS만을 직접 지원한다. 이때, ANSI는 MBCS라고 생각해도 무방하다.
Windows NT (Windows NT, 2000, XP)계열은 Windows API를 ANSI 버전과 UNICODE 버전을 모두 지원한다. ANSI버젼의 API를 쓰는 경우에는 OS가 API를 다시 UNICODE 버전으로 변환한다. 그러므로 UNICODE 버전으로 만들어진 프로그램은 windows NT계열에서 약간의 속도 향상을 가져올 수 있다. 그러나 windows 9x에서 동작하지 않는 단점이 있다. 그래서 Microsoft에서는 Windows 9x계열에서 UNICODE 버젼으로 개발된 소프트웨어를 손쉽게 동작하게 하기 위해서 Windows 9x용 UNICODE 지원 dll을 제공한다. 컴파일시 이 dll을 이용하면 UNICODE 버전으로 개발되었어도 Windows 9x계열에서 동작 가능하다.
C/C++의 표준 문자열 정의
"안녕"이라고 literal을 표현하면 이것은 MBCS (언어 규격 표준 용어로는 mcs)이다.
L"안녕"이라고 literal을 표현하면 이것은 UCS encoding (언어 규격 표준 용어로는 wcs)이다.
어떤 encoding을 따르는 것인 가는 Compiler와 OS에 따라 다르다.
예를 들어 Windows에서 Visual Studio 6.0 한글 버전을 사용하는 경우 MBCS로 컴파일시 CP-949를 따르게 된다.
char 데이터 표현은 MBCS의 문자를 표현하는데 사용한다. char는 사실 1바이트로 고정되어 있으므로 MBCS의 문자는 한 char 또는 두 char로 표현된다.
wchar_t 데이터 표현은 UCS의 문자를 표현하는데 사용한다. 많은 경우 2바이트이지만 시스템에 따라 4바이트거나 8바이트일 수도 있다. 이러한 UCS 문자를 언어 규격 표준 용어에서는 wide character라고 한다.
"한글abc"가 유니코드로 써있다면 한글과 영어 구분
영어와 한글은 code range가 다른 영역에 위치하므로 영역 검사로 충분히 구분 가능하다.
자세한 것은 www.unicode.org에 있는 문자 테이블을 참조하시오.
참고로 MBCS로 컴파일된 경우 완성형을 쓰기 때문에 영문 검사시 if (ch < 0x80)해도 무리가 없다.
유니코드와 파일
유니코드 switch로 compile을 처음 해보는 경우 마추치게 되는 문제의 하나가 왜 파일에 저장시 유니코드로 저장되지 않는가 하는 점이다. 앞에서 말했듯이 유니코드라고 하더라도 다양한 encoding이 있으며 유니코드 switch는 API 함수와 자료들을 위한 ucs2 encoding만을 지원한다는 점이다. 즉 파일에 저장한다던지 UTF encoding 등으로의 변환 등은 여전히 전적으로 개발자의 몫으로 남는다는 점이다.
파일로 저장시에는 많은 경우에는 UTF8 encoding을 사용하게되는데 이때는 WideCharToMultiByte API를 사용해서 변환하면 된다.
UTF 계열이 아니라 UCS를 바로 저장하는 경우에는 조심해야 하는 것이 byte order이다. 이것은 CPU에 따라 다르게 되어있는데 intel 계열은 little endian이라 불리우는 바이트 순서로, 그 외 mac이나 workstation 계열은 많은 경우 big endian으로 불리우는 바이트 순서를 가진다. 그러므로 CPU와 OS에 따라 big endian format으로 little endian format으로 저장하는 것에 차이가 있다.
유니코드 용어의 이해 유니코드 관련 문서를 읽다보면 가장 많이 마주치는 용어들이 UCS2, UCS4, UTF8, UTF16, UTF32 등과 같은 단어들이다.
기본언어판, BMP (Basic Mulitilingual Plane) 유니코드의 첫 65,536개의 코드를 의미한다.
언어판, Plane (256x256 즉 65,536 개씩의 코드 묶음) 유니코드에서는 현재 17개의 언어판을 사용할 수 있다. 모두 그룹 00에 포함된다.
언어판 그룹, Group (256개씩의 언어판을 묶어 하나의 그룹) 유니코드의 17개 언어판은 모두 Group 00에 있다. 유니코드는 17개의 언어판에 한정되어 정의된다. 반면 ISO 표준(UCS-4)에서는 모두 128개의 언어판 그룹이 정의될 수 있다. 1 Plane = 65,536 code points 1 Group = 256 planes = 256 x 65,536 = 16,777,216 code points UCS-4 = 128 groups = 128 x 16,777,216 = 2,147,483,648 code points
인코딩, Encoding (문자 집합을 표현하는 방식) 유니코드는 코드 체계 또는 문자 집합을 명명하는 것이며 이를 표현하기 위해서는 UTF-8, UTF-16, UTF-32 등과 같은 인코딩이 필요하다.
UCS-2: Universal Character Set 2(octets) 좀 더 정확하게는 Universal Multipe-Octet Coded Character Set 2이다. ISO/IEC 10646의 용어로 BMP의 65,536 코드를 정의하며, 2바이트로 표현된다. 1개의 언어판, BMP만이 이에 해당한다. UCS-2는 인코딩 방법이 아니며 문자코드 자체이다. 여기서 octet이라는 용어를 사용했는데 이 용어는 ISO 쪽에서 사용하는 용어로, 유니코드 진영에서 사용하는 바이트와 같은 뜻이다
UCS-4: Universal Character Set 4(octets) ISO/IEC 10646의 용어로 4바이트로 표현된다. 모두 128개의 언어판 그룹, 즉 128 * 256 언어판 = 32,768 언어판을 정의한다. 이는 대략 231 = 2,147,483,648개의 코드에 해당한다. UCS-4는 인코딩 방법이 아니며 문자코드 자체이다.
UTF-8: UCS Transformation Format, 8-bit form Unicode 표준의 인코딩 방식 중의 하나이다. 표준에서는 17개 언어판의 문자만을 표현할 수 있으나 기술적으로는 UCS-4 전영역의 문자를 표현할 수 있다. 문자에 따라 1 ~ 4(또는 6) 바이트로 표현된다.
UTF-16: UCS Transformation Format, 16-bit form 유니코드 3.0에서는 16을 16비트로 해석한 것이 아니라, 그룹 00의 16개 언어판이라고 써 놓았군요. UTF-32의 32가 32비트를 지칭하므로 통일성을 위해 16비트로 이해하시는 게 좋습니다. 16비트로 표현한다는 점에서는 UCS-2와 흡사하지만 대행 문자 영역(Surrogates)을 이용하여 16개의 보충 언어판 코드를 표현할 수 있는 인코딩이다. 대행 문자 영역 2개로 16개의 보충 언어판을 표현할 수 있다. UCS-2에서는 65536개의 코드만을 정의할 수 있으나 UTF-16에서는 1백만여자를 더 표현할 수 있다.
UTF-32: UCS Transformation Format, 32-bit form 32비트 즉 4바이트로 각 문자를 표현한다. 이점에서 UCS-4와 동일하지만 17개의 언어판만을 정의한다는 점에서는 UCS-4의 부분집합으로 간주하면 된다. UCS-4와 동일하나 0x00000000 ~ 0x0010FFFF 범위만을 문자 코드로 간주한다고 이해하면 된다.
class A {
public static void main(String[] arg) {
System.out.println(
Character.isDefined('가'));
// 한글문자 '가'가 Unicode로 정의되어 있는지 알아본다.
// 만약 정의되어 있다면 true를 리턴한다.
int i = '가';
// 문자 '가'를 int 형 변수인 i에 대입한다.
// 실제로 문자는 정수와 같다.
System.out.println("'가'의 int형은 " + i);
System.out.println("'가'의 unicode는 "
+Integer.toHexString(i));
// Integer의 static method인 toHexString()을 이용하여
// 10진수를 16진수를 표시하는 문자열로 바꾼다.
System.out.println("'가'의 unicode는 "
+Integer.toHexString(i).toUpperCase());
// 문자열로 바뀐 것은 소문자로 나온다. 대문자로 바꾸기 위해서
// String의 static method인 toUpperCase()를 사용한다.
}
}
Gil wrote:
>
> >: "F900-FFDF 에 CJK Unified Ideographs 라고해서 유니코드에 있는데 이미
> >: 4E00~9FA5 까지 (모두 20902개 , 계산이 맞는지..) 이미 한자 영역이 있습니다.
> >: 그런데 왜 저 곳에 또 무슨 "호환성문자" 라고 해서 넣었는지 모르겠습니다."
> >
> >: 라고 질문했었는데 아직도 모르겠습니다, 다시한번 여기에 :)
> >
> >Compatibility는 말 그대로 호환성이죠.
> >이는 기존의 encoding을 unicode에 대부분 수용하면서 있는 부분입니다.
> >
> >일례로 한글 완성형의 경우 한자가 음을 기준으로 나열이 되어 있습니다.
> > 그래서 중복되는 한자가 있습니다. 이를 수용하기 위해서 이러한 영역이 있습니다.
>
> 그렇네요, 惡를 예로들면,
>
> 악할 악(惡) : 완성형에서 E4C2 : 유니코드에서 60E1
> 미워할 오(惡) : 완성형에서 E7F7 : 유니코드에서 F9B9
>
> 악할 악字가 먼저나와서 그런지 그 다음에 나오는것이 호한성문자영역으로
> 들어가는군요.
>
> 읽어보니 268개의 그런 중복된 경우가 있고 Big5의 경우에는 2개 있고 나머지는
> 잘 모르겠습니다.
> GIL
> http://soback.kornet.nm.kr/~chlang
질문하신 문제에 대하여 그 의미 및 문제점을 파악하기 위해서는
유니코드의 기본 목적을 먼저 확실히 이해하는 것이 중요합니다.
==== 유니코드의 소개 ==========
다음에서 기술하는 유니코드의 목적은 첨부하는 참고문헌의 내용과
상이하며, 제가 나름대로 생각하기에 정말 중요하다고 생각되는 목적만을
나름대로 정리한 것이므로 이점 착오없으시기 바랍니다.
첫째, 통합 문자 세트.
다양한 나라가 서로 동일한 혹은 비슷한 의미의 문자를 저마다 다른 인코딩
방식을 사용함으로써, 자료 및 프로그램의 호환성 및 확장성에 문제를
일으키는 관계로 이를 하나의 문자 세트인 유니코드로 통합시켜
표현함으로써 해결한다는 것입니다.
둘째, 문자 세트 변환의 중심 역할.
기존 문자 세트 표준 (KS C 5601 혹은 일본의 JIS X 0208등등)이 N개가
존재한다고 할 경우, 다양한 문자 세트 표준사이의 변환을 위해서는 N *
(N-1)개의 변환 테이블이 필요하나 이는 구현상 상당한 부담으로
작용합니다. 따라서, 기존 문자 세트 표준사이의 변환을 할 때, 일단
유니코드로 변환한 후 다른 문자 세트 표준으로 변환하게 되면, 변환
테이블이 2 * N개만 필요하게 되므로, 문자 세트 변환을 다루는
프로그래밍이 상당히 간편해진다는 것입니다. 유니코드가 이와같이 문자
세트 변환의 중심을 차지하기위해서는, 기존 문자 세트의 문자를
유니코드로 변환한 후 다시 원래의 문자 세트로 변환하여도 원래의 자료가
변경되지 않고 그대로 복구되어야 한다는 것입니다. 이를 round-trip
conversion compatibility 혹은 source separation rule이라고 합니다.
======= 기존 표준 문자 세트와의 호환성 ==========
참고문헌의 페이지 2-8과 2-9의 내용을 인용하면,
``The Unicode Standard avoids duplicate encoding of characters by
unifying them within scripts across languages; characters that are
equivalent in form are given a single code.
... (중략) ...
The Unicode Standard avoids duplication of characters due to specific
usage in different languages, duplicating characters to support
compatiblity with base standards.
... (중략) ...
In determining whether or not to unifiy variant ideograph forms across
standards, the Unicode Standard follows the principles described in
Section 6.4, CJK Ideographs Area. Where these principles determine
that two forms constitue a trivial (wazukana) difference, the Unicode
Standard assigns a single code. Otherwise, separate codes are assigned.
... (중략) ...
Identifying a character A as a compatibility variant of another
character B implies that generally A can be remapped to B without loss
of information other than formatting. Such remapping cannot always
take place because many of the compatibility characters are in place
just to allow systems to maintain one-to-one mappings to existing code
sets. In such cases, a remapping would lose information that is felt
to be important in the original set. Compatiblility remappings are
called out in Section 7.1, Character Names List. Because replacing a
character by its compatibly equivalent character or character sequence
may change the information in the text, implementation has to proceed
with due caution. A good use of these mappings may not be in
transcoding, but in providing the correct equivalence for searching
and sorting.''
질문하신 문제와 위 인용된 문구와 연관시켜 해석해보면 다음과 같습니다.
KS C 5601에는 한자가 우리나라 한자 발음순으로 배열되어 있습니다.
따라서, `수레 차'를 의미하는 한자의 경우, `수레 거'로 읽을 수 있으므로
실제로는 동일한 한자에 대하여, KS C 5601에서는 이들을 인위적으로
`수레 거' 와 `수레 차'로 나누어 각각 0xCBE7, 0xF3B3으로 인코딩되어
있습니다.
이와 같이 인위적으로 나눈 이유는, 한자의 정렬 (sorting) 및
해당 한자 발음의 한글과의 변환에 모호성이 없어지기 때문으로 보입니다.
그러나, 한중일 통합 한자 영역에는 `수레 차'와 `수레 거'가 동시에
들어갈 수는 없습니다. 이러한 구분은 우리나라에서만 의미 있는 것이므로
`수레 차'의 의미와 `수레 거'의 의미를 구분하지 않는 대표적인 한자
한개만이 들어가야합니다.
KS C 5601과 유니코드의 대응 테이블을 찾아보면, KS C 5601의 `수레 차'는
유니코드의 한중일 통합 한자 영역에 있는 0x8ECA에 대응되고, `수레 거'는
KS C 5601 표준과의 호환 한자 영역내에 있는 0xF90E로 대응되어 있습니다.
즉, `수레 차'는 해당 한자를 대표하는 것으로 간주되고, (아마, `수레
차'가 더 일반적인 발음이므로 그렇게 선택한 것으로 생각됩니다.) `수레
거'는 유니코드로부터 KS C 5601로 다시 역변환해도 round-trip conversion
compatiblity에 의해서 그대로 복구되기 위해 존재하는 것입니다.
하지만, 때로는 `수레 거,차' 구분없이 하나의 유니코드 문자 (0x8ECA)로
대응 (compatibility remapping)시킬 필요가 있습니다. 즉, 구분없이 해당
한자를 탐색 (search)하거나, 어떤 순서 (가령 부수순)로 정렬 (sorting),
혹은 다른 문자 세트 표준과의 보다 적절한 변환이 필요한 경우입니다.
가령, JIS X 0208과 유니코드와의 변환 테이블을 찾아보면 `수레 차'에
대응하는 유니코드 값이 JIS X 0208의 해당 한자에 대응되어 있으나,
`수레 거'에 대응하는 유니코드 값은 해당 한자에 대응되어 있지 않습니다.
(이유는, 2개의 유니코드 값이 하나의 JIS X 0208로 대응될 경우,
1:1 대응이 깨져서 약간 다른 의미의 round-trip conversion
compatibility를 유지하지 못하기 때문으로 보입니다.)
즉, KSC 5601과 JIS X 0208사이의 한자 변환은 compatibility remapping을
하여야만 `수레 거'도 변환이 된다는 것입니다.
이러한 remapping된 값은 참고문헌의 페이지 7-470의 테이블을 보시면,
`수레 거'에 대응하는 유니코드 값이 0xF903이지만 바로 위에 compatiblity
remapping된 유니코드 값인 0x8ECA (KS C 5601의 `수레 차'에 대응하는
유니코드 값)가 적시되어 있습니다.
(시스템마다 다르겠지만, 이런 remapping을 해주는 함수가 제공될 가능성이
있습니다.)
그러나, compatibility remapping을 하게 되면 `수레 거'와 `수레 차'를
구분한 본래의 의미를 상실하게 되어서 무조건 이와 같이 remapping할 수는
없는 것이므로, 특정 application이 상황에 맞는 경우에만 remapping을
하는 것이 적절하여 보통의 변환 함수를 사용하게 되면 remapping을 하지
않을 것입니다.
그런데, 여기서 한가지 주의 해야할 점이 있는데,
유니코드 값 0x8ECA만이 주어졌을 때,
`수레 거'와 구분 되는 `수레 차'의 의미를 갖는 것으로 볼 수도 있고,
`수레 거' 혹은 `수레 차' 2개를 대표하여 이 둘 사이를 구분하지
않는 의미를 갖는 것으로 볼 수도 있는 약간 상반된 2가지 의미론을 동시에
갖는다고 해석됩니다.
제가 이해하기 곤란한 부분이 바로 여기에 있습니다.
유니코드가 이와 같이 모호한 의미론을 갖고 있는 것인지,
아니면, 제가 참고문헌을 제대로 이해하지 못했다거나 더 엄밀한 문서가
혹시 있는 지, 저로서는 모르겠습니다.
또, 정부에서 제정한 KS C 5700이 유니코드 사양과 완전히 동일한 것인지,
아니면 보다 구체적인 사양이 추가되어있는 지, 그래서, 유니코드의
KS C 5601 호환 한자 영역은 가능하면 사용하지 말고 mapping시키도 말
것을 권장하는 지침같은 것이 있는 지도 모르겠습니다.
아시는 분이 계시면 posting 바랍니다.
하지만, 제 개인적인 소견으로는, 유니코드가 다루고 있는 한자의 수
(2만여자)가 KS C 5601 (4888자)보다 휠씬 많고, KS C 5601에 포함되지
않은 한자 중에서, 2개이상의 우리나라 발음을 갖는 한자가 많이 있을
것이므로, 이들에 대하여 모두 호환 한자 유니코드 값을 새로이 할당할
계획이 없다면 (아마, 없겠죠?), 유니코드의 사용이 확대되는 시점에
이르렀을 때, 호환 한자 영역의 사용을 자제하도록 (즉, compatibility
remapping이 default 변환이 되도록) 하고, 따라서, 유니코드 값 0x8ECA의
의미론을 `수레 차', `수레 거'를 대표하는 것으로 의미론을 고정시키는
것이 바람직하다고 봅니다.
============== 유니코드와 UTF-8 인코딩 ====================
한가지 더 제 의견을 개진하고 싶은 것은, 유니코드는 여러가지로
따져보았을 때 프로그램 내부에서 사용하거나 특정 프로그램만이 이해하는
화일 혹은 교환되는 자료의 인코딩으로 적당할 뿐, 일반 텍스트 문서의
인코딩, 혹은 다양한 프로그램 사이에 전달되는 텍스트 자료의
인코딩으로서는 부적당하다는 것입니다. 따라서, 현재와 같이
우리나라에서 일반화된 인코딩 표준인 KS C 5601 (좀더 정확히는 EUC-KR)을
대체하기는 곤란하며, 유니코드와 1:1 대응할 뿐만 아니라, 여러가지
우수한 성질을 갖는 UTF-8 인코딩이 KS C 5601의 대체 인코딩 방법이라는
것입니다. 따라서, 우리나라가 가능하면 빨리 UTF-8로 이행하는 것이
바람직하다고 생각합니다.
============== 참고문헌 ========================
[1] ``The Unicode Standard, Version 2.0,'' The Unicode
Consortium, Addison Wesley, 1996
(평가) 유니코드에 대하여 자세하고 전반적인 설명과 함께, 모든 정의된
유니 코드 문자의 일반적인 특징 및 출력된 모양이 소개되어
있다.
p.s. 유니코드에 대한 오해의 소지를 최소화하고 논의를 활성화하기
위하여 Unicode, Inc. 및 Addison Wesley의 허락 없이 함부로 인용한
점에 대하여 Unicode, Inc. 및 Addison Wesley에 사과의 뜻을
표합니다.
================== 첨부 ============================================
첨부하는 프로그램은 유니코드와의 변환을 제공하는 자바 프로그램입니다.
(JDK1.1 버전)
char 자료형 및 String 자료형이 모두 유니코드이므로, 유니코드의 첫째 및
둘째 목적에 부합하는 프로그래밍이 자연스럽고 손쉽습니다.
-------- HanjaTest.java ----------
// KSC5601내의 한자 범위: 0xCAA1 ~ 0xFDFE (4888 자 = 52 * 94)
public class HanjaTest
{ public static void main(String args[])
throws java.io.UnsupportedEncodingException
{
for( int high = 0xCA; high <= 0xFD; ++high )
for( int low = 0xA1; low <= 0xFE; ++low )
{
String unicode = new String(
new byte[] {(byte) high, (byte) low}, "KSC5601");
byte[] eucjis = unicode.getBytes("EUCJIS");
In Reply to: 유니코드와 UTF-8, 그리고 자바... posted by 김덕태 on July 02, 1997 at 10:01:40:
Jungshik Shin wrote:
> 이 부분은 조금 오해의 소지가 있는 듯 합니다. 워낙 이 부분의 용어가
> RFC나 표준 문서마다 제각각이어서 혼동을 초래할 수 밖에 없기B 합니다.
> 이를 정리하기 위한 노력의 일부인 RFC 2130에 비추어 볼 때 위의 단락은
> 좀더 조심스럽게 용어를 사용해서 쓰였으면 좋지 않을까 생각합니다.
>
> RFC 2130의 정의에 의하면 KS C 5601, KS C 5636(US-ASCII), Unicode 등은
> 문자셋(Coded Character Set=CCS)입니다. 이 문자셋(CCS)을 구체적으로
> 표현하기 위해 octet에 대응시키는 인코딩 방법(Character Encoding
> Scheme=CES)이 EUC-KR, ISO-2022(-KR), UTF-8(UTF-FSS), UTF-7,UTF-1 등이
> 있겠지요. 앞의 2개는 KS C 5601과 KS C 5636(US-ASCII)라는 2개의
> 문자셋(CCS)을 인코딩하는 방법(CES)이고 뒤의 세 개는
> Unicode(ISO-10646에서 BMP)라는 문자셋(CCS)을 인코딩하는
> 방법(CES)이겠지요.
>
> 따라서, "KS C 5601을 대체하는 인코딩으로 UTF-8을 쓴다"는 표현은 서로
> 개념적으로 다른 차원의 두 가지를 -KS C 5601은 CCS이고 UTF-8은 CES이므로
> - 같은 차원에 놓은 것으로 보입니다. 마찬가지로 'Unicode와 UTF-8을 같은
> 위치에 놓고 비교하여 어느 한 쪽이 다른 쪽보다 어떤 용도에 보다
> 적합하므로 더 우월하다 '고 하는 것도 혼동의 소지가 있습니다. UTF-8은
> 독립적인 문자셋(CCS)이 아니라 Unicode의 여러 가지 인코딩 방법(CES) 중
> 하나에(위에 적으신대로 'File System Safe'한 특성을 지녔기에
> UTF-FSS라고도 불리며 파일 저장 등에 적합한 CES로 알고
> 있습니다) 불과하니까요. 위의 글에서 Unicode란 단어를 Unicode란 CCS의
> '가장 자연스러운 인코딩' 방법의 의미로 사용하신 듯 합니다. 즉, "Unicode를
> network byte order에 따라 두 개의 octet의 나열로 표현한 인코딩
> 방법(CES)"의 의미로 사용하신 것으로 짐작합니다. 역시, KS C 5601도
> 사람들이 흔히 쓰듯이 KS C 5601과 KS C 5636(US-ASCII)란 2 개의 CCS를
> 전자는 G1에 후자는 G0에 두고 G0은 GL에 G1은 GR에 고정시킨 (ISO-2022 등에
> 대해 전혀 모르는 이라도 쉽게 생각할 수 있는 '자연스러운') 인코딩
> 방법의 의미로 쓰셨으리라 봅니다. 하지만, 이것은 이미 위의 괄호 안에서
> 지적하신 바처럼 EUC-KR로 정확히 부르는 것이 이런 종류의 논의를 할 때에는
> 혼동의 여지가 없으리라고 봅니다.
이런 복잡한 문제에 끌려(?) 들어가고 싶지는 않았지만 짚고 넘어가야 되는
문제로 생각되어 말씀하신 RFC 2130을 뒤져보았습니다.
관련 링크가 잘못되었더군요.
참고문헌 [1]에 가보니 관련 내용을 볼 수가 있었습니다.
======= RFC 2130 ========
RFC 2130은 인터넷 환경에 적합하고 호환성에 문제를 덜 일으키는 octect
(8 bit를 의미, `바이트'의 의미보다 더 엄밀함)를 기준으로 해서 문자
세트 및 인코딩과 관련된 사항을 다음과 같이 3 부분으로 나누어 놓았고,
각종 인터넷 표준을 정의하는 데 있어서 사용되는 용어, keyword등의
의미의 엄밀성과 일치성, 호환성을 기하기 위한 것이 목적일 것이며, 모든
프로그램과 자료가 인터넷만을 목적으로 하지 않는 이상, 이 분류에 맞지
않는 의미의 용어가 나름대로의 가치를 가지고 이와 구분되어 사용될 수
있는 것이라 생각됩니다.
1. A Coded Character Set (CCS) is a mapping from a set of abstract
characters to a set of integers. Examples of coded character sets
are ISO 10646 [ISO-10646], US-ASCII [ASCII], and ISO-8859 series
[ISO-8859].
여기서 정의하는 Coded Character Set의 의미는 각 추상적인 문자에
대하여 정수값을 할당하는 것이고, 정수라는 개념은 몇 비트로 표현한다는
것까지 정의하는 것은 아니므로, 인코딩과는 아무런 관련이 없는 추상적인
개념으로 볼 수가 있습니다.
2. A Character Encoding Scheme (CES) is a mapping from a Coded Character
Set or several coded character sets to a set of octets. Examples of
Character Encoding Schemes are ISO 2022 [ISO-2022] and UTF-8 [UTF-8].
A given CES is typically associated with a single CCS; for example,
UTF-8 applies only to ISO 10646.
말씀하신 대로 EUC-KR은 2개의 CCS (KS C 5601과 KS C 5636)의
CES입니다. 또한, UTF-8은 ISO 10646 CCS의 CES입니다.
KS C 5601을 각 정수 코드 값에 대하여 2 바이트 값으로 매핑한다고
가정한다면 CES로도 볼 수 있겠으나, 그와 같이 사용되는 경우가 거의
없으므로 (아스키문자도 섞어서 쓰므로), KS C 5601이라고만 한다면
CES를 의미하는 것이라고 볼 수 있을 것입니다.
또한, EUC-KR이 해당하는 KS C 5601과 KS C 5636의 합집합을
의미하는 CCS로도 볼 수도 있겠으나, 해당 CCS를 의미하는
용어가 이미 있으므로 EUC-KR이라고만 할 때는 CES를 의미하는 것이
적당할 것입니다. 하지만, 이는 해당 용어 및 keyword가 사용되는
context에 의해 결정되어야 할 것입니다.
참고문헌 [1]을 보면,
``Also, in MIME, the Coded Character Set and Character Encoding
Scheme are specified by the Charset parameter to
the Content-Type header field, and Transfer Encoding Syntax is
specified by the Content-Transfer-Encoding header field.''
즉, MIME에서는 charset 값은 CCS와 CES 둘다 의미하는 keyword이어야
하므로, EUC-KR이 사용된 경우에는 그 의미가 ``CCS는 KS C 5601과
KS C 5636의 합집합을 지정한 것이고, CES는 EUC-KR 인코딩이
나타내듯이 (NULL, 0) ~ (DEL, 127)은 해당 1 바이트로 매핑시키고,
(first_ksc5601_char, 0x2121) ~ (last_ksc5601_char, 0x7d7e)은
그 코드값을 x라 하면, x + 0x8080을 network byte order로 2 바이트로
매핑시키는 것을 의미한다.''라고 해당 표준 문서에 명기할 것을 추천하는
의도로 파악됩니다.
우리나라에서 현재 논란이 되고 있는 ISO-2022-KR의 경우도
MIME charset으로 지정된다면 마찬가지로 ``CCS는 KS C 5601 및 KS C
5636의 합집합을 지정한 것이고, CES는 ISO-2022-KR이 나타내는 CES를
지정한 것이다.''를 의미하는 것으로 정의해야 겠지요.
그러나, 유니코드 2.0이 의미하는 가장 일반적인 의미는 ISO 10646 BMP
및 plane 1 ~ plane 16의 문자를 16 비트 환경으로 인코딩하는 scheme
이라는 의미가 강하므로, RFC 2130의 정의를 따른다면 CCS로도 CES로도
보기 어렵다고 보고 있습니다.
3. Transfer Encoding Syntax
is frequently necessary to transform encoded text into a format
which is transmissible by specific protocols. The Transfer Encoding
Syntax (TES) is a transformation applied to character data encoded
using a CCS and possibly a CES to allow it to be transmitted.
Examples of Transfer Encoding Syntaxes are Base64 Encoding [Base64],
gzip encoding, and so forth.
TES는 CCS 및 CES와는 다소 독립적이며 특정 프로토콜이 이해하고
처리할 뿐 일반 사용자에게는 드러나지 않는 인코딩을 의미하는 것으로
CES와 구분되는 것 같습니다.
하지만, `possibly a CES'라고 되어 있는 점이 좀 비논리적인 것으로
보이는 군요.
CCS와 CES 둘다 정의되어 있지 않으면, 엄밀하게 octect stream
(간단하게 말하면, 바이트 열)으로 변환할 수 없고, 그렇다면, Base64
나 gzip 인코딩 또한 불가능하기 때문입니다.
==== 유니코드 2.0의 정의 =========
참고문헌 [2]의 페이지 1-1을 인용하면,
``The Unicode Standard is a fixed-width, uniform encoding scheme for
written characters and text.
... 중략 ...
The Unicode Standard is modeled on the ASCII character set, but uses a
16-bit encoding to support full multilingual text.''
즉, 유니코드 2.0은 16 비트 인코딩이 가장 정확한 의미라는 것입니다.
16 비트가 나타내는 코드 값으로 추상적인 문자와의 매핑을 정의하는
것으로 볼 수 있다면 CCS라고도 볼 수 있겠으나, 문제는 surrogate
area의 두개의 유니코드 값으로 하나의 추상적인 문자를 나타낸다는
것입니다. 이 surrogate area의 값은 ISO-10646의 plane 1 ~ 16부분에
해당하는 문자 (ISO-10646의 부분집합)로 매핑되게 됩니다. 따라서, 그
코드값을 정수로 표현하게 되면 0 ~ 65535의 범위를 넘어가게 됩니다.
이런 이유로, ISO 10646 BMP와 유니코드를 동일시할 수가 없습니다.
CES로도 볼 수 없는 이유는, 16 비트 인코딩이므로, 유니코드 코드 값의
상위 바이트와 하위 바이트가 어떤 순서로 저장 및 전송될지를
정의하지 않고, 각 시스템에 적합한 순서를 사용할 수 있게 한 것입니다.
그래서, 고정된 octect stream으로 만들어 낼 수 없으므로, 8 bit
인코딩이 될 수 없고 따라서 CES의 정의에 부합하지 못합니다.
참고문헌 [2]의 페이지 3-1을 보면, 바이트 순서에 대한 대한
어느 정도의 언급이 있지만, 완전한 것이라고 보기 어렵습니다.
따라서, 유니코드 + network byte order (big endian)이라고 말한다면
ISO-10646의 부분집합 CCS와의 매핑을 정의하는 CES라고 할 수 있습니다.
Unicode 라는 용어를 ISO-10646의 그 부분집합 CCS를 의미하는 것으로도
쓰일 수가 있겠지만, 이는 Unicode라는 용어가 함축하는 의미의 일부에
지나지 않는 것이므로, Unicode가 그와 같은 CCS를 나타내는 것으로
고정시킬 수도 없습니다. 혼란을 막기 위해서는 뭔가 다른 용어를
만들어 사용하여 해당 CCS를 의미하는 것으로 사용하는 것이 적당할
것으로 생각될 뿐입니다.
또한, 8 비트 인코딩 방법이 16 비트 인코딩 방법보다 더 구체적이라고
보지는 않으며, 단지 가정하는 환경이 다른 것이므로, 문자 자료가 16
비트 환경과 8 비트 환경을 넘나들 때, 문제가 발생할 소지를 안고 있는
것으로 파악하고 있습니다.
이는 7 비트 환경을 가정하는 ISO-2022-KR이 8 비트 환경을 가정하는
EUC-KR보다 더 구체적이라고 말하지는 않는 이유와 같습니다.
물론, 인코딩 방법이 가정하는 비트 수가 적을 수록 호환성에 문제가
적지만 내부적으로 처리하는 자료의 형식으로는 불편해지는 것으로
보아도 좋을 것입니다.
따라서, 유니코드와 UTF-8은 둘다 인코딩이므로, 프로그래밍 하는
사람의 입장에서는 적절한 인코딩을 사용하여 상황에 맞게 선택하여
사용하는 문제일 것입니다.
유니코드 인코딩을 사용할 경우에는, 바이트 순서가 문제가 되지 않는
경우에는 의미 있는 인코딩 방법이기 때문입니다.
(즉, 같은 바이트 순서를 가정하는 환경사이의 자료 저장, 교환 및
바이트 순서를 알아낼 수 있는 적절한 방법이 채용될 경우등등.
가령, 유니코드에서는 0xFEFF라는 값을 바이트 순서 표식 (Byte Order
Mark)라고 하여 자료를 읽은 쪽에서 0xFFEF라고 읽히면, 서로 가정하는
바이트 순서가 뒤집혔다고 판단, 바이트 순서를 뒤집어서 읽도록
하고 있습니다.)
유니코드와 UTF-8을 비교한 것은 16 비트 인코딩 방법으로서의
유니코드 인코딩 및 유니코드 + network byte order등을 모두 포함하고,
이들 방법과 UTF-8과 비교해 볼 때, UTF-8이 안전하고 잇점이 많다라는
것을 말하려는 의도였습니다. 그러나, 이미 RFC 2130에서 UTF-8을
표준 인코딩으로 추천하고 있더군요.
인코딩 방법으로서의 유니코드를 의미한다면 UTF-16이라고 하는 것이 더
엄밀했을 것입니다.
따라서, 제가 의도하고자 했던것을 좀 더 엄밀하게 나타낸다면,
- KS C 5601은 한글을 다 못 나타내는 등 문제가 많아 ISO 10646 문자
세트 (CCS)로 전이하여야 한다.
- 이때, 인코딩 방법으로 UTF-16이 사용될 수 있으나,
-- 바이트 순서에 문제가 발생할 수 있고,
-- 기존 아스키 문서와의 호환성이 문제가 되며,
-- 아스키 문서의 경우, 문서의 크기가 2배가 되며,
-- 아스키 기반의 기존 환경 (운영체제, 프로그램등)과 충돌하며,
-- 차후, 유니코드의 4 바이트 확장판이라고 볼 수 있는 ISO-8859
UCS-4와도 그대로 호환되는 것이 아니다.
따라서, 이와 같은 이슈가 문제가 되지 않는 경우에 해당하는
내부적인 문서의 형식 및 내부적인 처리 용도로 UTF-16을 사용하고,
이외에는, 이러한 문제를 하나도 갖지 않는 UTF-8을 사용하여
인코딩하는 것이 바람직하다.
라는 것이었습니다.
=== 자바에서의 인코딩 이름 =====
언급된 이유로, 자바에서 16 비트 인코딩 이름으로 Unicode 및 8
비트 인코딩으로서 KSC5601, EUCJIS, 8859_1, UTF8등등 여러가지가
동급으로 사용되는 것은 잘못된 게 아니라 생각됩니다.
물론, 여기서 EUC-KR을 사용하지 못하고, 대신 KSC5601을 사용해야만 하는
것은 다소 논란거리가 될 수 있습니다.
그러나, EUC-KR이 우리나라에서 폭넓게 받아들여지고 있는 인코딩 이름이라고
주장할만한 증거 문서를 대기가 곤란하여, 썬사에 bug report를 내기도
곤란하더군요.
p.s. 역시, 이런 문제를 다루는 것은 재미없군요. 또, 저 역시 이쪽
방면으로 전문 지식을 갖고 있는 것은 아니라서...
1983년에 시작한 ISO 10646의 네 바이트 가운데 두 바이트 기본다국어 판(UCS-2)과 1985년에 비공식으로 발족되어 두 바이트 코드계를 추구하여 온 유니코드와는 91년 프랑스 르노회의에서 통합의 발판을 마련한 다음 92년 ISO 22차 서울회의에서 통합된 형태로 발전하였다[18]. 유니코드는 기본적으로 ISO 2022의 제어문자영역과 도형문자 영역의 구별을 없애고 두 바이트 전체 65536을 문자코드판으로 하여 92년 유니코드 버젼 1.0이 출판되었다[19]. ISO 10646의 기본 다국어 문자판(BMP) 역시 16비트 전 체를 문자코드판으로 하고 제어문제영역 사용을 금지시켰으며, 92년 국제 표준으로 확정되고 93년 5월에 국제표준으로 정식 출판되었다. 곧 이러 한 국제표준을 채택한 소프트웨어가 개발될 것이며 실제로 마이크로 소프 트는 개발을 진행하고 있다.
두코드계는 모두 세계의 모든 문자를 표시할 것을 목표로 하고 있다. 그런데 여기서 문제가 되는 나라의 문자가 곧 한자를 쓰는 극동의 삼국 한국, 중국, 일본이다. 한국은 더욱 문제가 되는 나라로 지목되고 있는 데 그것은 한글의 글자집단이 커기 때문이라 한다. 이것은 문제가 아닐 수 없다. 세계에서 가장 과학적이고 독창적이라는 문자가 어떻게 문제의 문자인가? 그것은 조건제시법이 아니라 원소나열법으로 한글을 취급하려 는 태도 때문일 것이다.
"KSC 5700"의 제정 의미와 전망
(전자신문 95년 12월 7일자)
일명 유니코드로 통하고 있는 국제문자부호계(UCS)가 드디어 KS표준규격으 로제정됐다. 국제문자부호체계란
한마디로 만국공통의 컴퓨터용 문자코드를 말한다. 이 코드는 지난 9월 국제표준기구(ISO)의
문자코드분과위(JTC1.SC2) 에서 통과된 것으로서 정식명칭은 "ISO.IEC 10646-I"(약칭 10646-I). 공업진 흥청이 이번에
"KSC 5700"으로 제정한 코드는 바로 "10646-I"과 내용적으로 일치하는 것이다. "KSC 5700"제정의 의미와 전망 등을
알아보려면 우선 이 " 10646-I"이 어떤 코드시스템인가를 알아볼 필요가 있다. "10646-I"은 문자 하나에 부여되는
데이터 값을 모두 16비트로 통일、 문자간 호환성을 중시하 고 있는 것이 가장 큰 특징이다. 이를테면 영어 알파벳
문자와 한글문자 하 나의 값이 모두 16비트라는 얘기다. 이는 현재 각국이 사용중인 코드의 1문 자당 값이 영어의
경우 7비트、 비영어는 8비트、 한글이나 일본어는 16비트 등 제각각 다르다는 데 따른 불합리성을 해소、
다국어호환성을 제고하기 위 한 것이다.
"10646-I"의 문자판(Plane)에는 영어.일본어.중국어(일부).히브리어.태국 어.아랍어.말레이어 등 전세계에서 사용하고
있는 26개 언어의 문자와 특수 기호 등 4만7천2백68자에 대해 일일이 코드값을 부여하고 있다(최대 수용문 자수는
6만5천5백36자).
이 가운데 한글에 부여된 코드체계는 현대 한글에서 구현할 수 있는 최대 글자수 1만1천1백72자를 가다다순으로
배열해놓은 완성형 부분(HANGUL、 AC 열)、 일명 첫가끝조합형으로 알려진 한글자모 2백40자 부분(HANGUL
JAMO、 11열)、 현재 표준인 KSC 5601의 조합형 한글자모 94자 부분(HANGUL COMPATI BILITY、 31열) 등
3덩어리로 돼 있다. "KSC 5700" 제정에는 바로 이 복수코 드를 모두 표준으로 인정했다는 것을 의미한다.
"10646-I"을 그대로 수용하는 "KS 5700"의 제정은 표면적으로 2가지 의미 가있다. 하나는 국제적으로
외국소프트웨어(SW)、 특히 영문판SW의 한글화 가크게 간편해졌으며 반대로 국산SW의 외국어판 제작도
쉬워지게 됐다. 물론 이것은 각국이 "10646-I"을 자국 표준으로 정하고 이를 토대로 SW를 다량 으로 개발하는 것을
전제로 한 것이다.
두번째로는 이 코드 제정으로 그동안 구심점이 없던 한글코드체계 논쟁이 일단 몇 개의 큰 줄기로 방향이 잡혔다는
점이다.
그러나 분명한 것은 "KSC 5700"이 제정됐다 해서 당장 현재의 한글코드 논 쟁이 불식되는 것은 아니라는 사실이다.
"KSC 5700"의 제정에 의해 논쟁의 방향이 잡히게 될 부분은 우선 한글이 표현할 수 있는 모든 글자수인
1만1천1백72자를 가나다순 배열로 코드값을 부여함으로써 일단 기존 "KSC 5601"과 "한글윈도우95" 통합형 코드의
문제점 을극복할 수 있는 길이 열렸다는 것이다.
물론 이같은 문제점이 극복되려면 세계적으로 "10646-I"의 채택이 보편화 되고 국내 SW회사들도 이를 전폭적으로
지원해야 한다.
반면 "KSC 5700"으로도 풀릴 수 없는 매듭은 컴퓨터에서의 한글 구현을 조 합형 방식으로 할 것인가、 완성형
방식으로 할 것인가라는 점이다.
앞서 지적했던 것처럼 "KSC 5700"에는 완성형 방식의 1만1천1백72자뿐 아 니라 기존 조합형 자모94자、 새로운
첫가끝조합형 자모 2백40자가 동등한 자격으로 들어 있다.
이같은 사실은 줄기차게 조합형을 옹호해온 이들에게 오히려 지금까지의 논쟁에서보다 훨씬 강도 높은 주장을 펼칠
수 있는 단서를 제공하고 있는 셈 이다. 이런 단서는 반대로 완성형 주장자들에게도 똑같이 제공되고 있다. 결 국"KSC
5700"이 정착된다 하더라도 논쟁의 불씨는 수그러들지 않고 오히려 화력이 더 세질 가능성이 있다는 얘기가 된다.
이런 상황에서의 변수가 바로 "한글윈도우95"와 같은 운용체계를 공급하는 마이크로소프트(MS)의 역할이다. MS는
"KSC 5700"시대에도 여전히 자의반 타 의반으로 완성형과 조합형 논쟁에 대한 캐스팅보드를 쥐게 될 것으로 보인 다.
즉 MS가 운용체계 수준에서 어떤 방식을 지원하느냐에 따라 대세가 결정 될수 있다는 것이다.
그런데 지금까지 공식.비공식으로 드러난 바에 따르면 MS가 앞으로 새로 개발할 "한글윈도우9 " 및 "한글윈도우NT"
차기버전에서 "KSC 5700" 내의
조합형을 지원하게 될 가능성은 거의 없어 보인다. 이와 관련해 MS는 현재 " 한글윈도우95"에 채택하고 있는 통합형
코드가 기존 2천3백50자의 "KSC 5601 "완성형과 국제문자부호계 기반의 새로운 "KSC 5700"을 연결시켜주는 징검다
리라고 믿어 의심치 않고 있는 상황이다.
이에 따라 새로운 국가표준코드가 제정됐음에도 불구하고 우리 정부나 업 계의 입장은 여전히 지금처럼 MS의
캐스팅보드에 따라 좌우될 수밖에 없을 전망이다. 이는 "KSC 5700"의 모태가 된 "ISO.IEC 10646-I" 자체가 미 MS에
의해 주도된 유니코드 규격에 기반하고 있다는 태생적 한계 때문이다. <서현진기자> 발 행 일 : 1995/12/08
전세계 주요 컴퓨터회사들이 업계표준으로 규정한 만국공통 문자코드 "유니코드" 설명회가 본사 주최로 16일 서울 롯데호텔에서 열렸다. 주제는 지난8월 스위스 국제표준화기구(ISO)가 국제문자부호계(UCS)로 받아들인 최신 "유니코드2.0"과 이를 토대로 지난해 12월7일 공업진흥청이 확정한 "KSC 5700"에 관한 내용이었다.
주요내용을 소개한다. <편집자주>
<>"유니코드2.0"의 개요(어스무스 프라이택박사/유니코드 컨소시엄)
유니코드 컨소시엄은 91년 만국공통의 문자코드를 제정, 보급하기 위해 창설됐으며 현재 북미.유럽.아시아등에서 45개 주요기업이 참여하고 있다. 최근 "유니코드2.0"을 출판했으며 국가 단위의 국제기구인 ISO와 공동표준규격 마련 및 개발자 기술지원서비스를 병행하고 있다.
"유니코드2.0"에는 모두 6만5천5백36자(OXOOOO~OXFFFF)의 코드영역이있는데 이 가운데 3만8천8백85자는 주요 국가언어 구현용으로 이미 할당돼있고6천4백자는 사용자 정의 영역(Private Use Area)으로, 2만2백49자는 향후새로 추가될 언어영역(Future Use Area)으로 각각 비워두고 있다. 현재할당된 주요 언어는 아스키(미국표준정보교환코드).그리스어.라틴어.시릴문자.히브리어.타이어.기호문자(Symbols).함수문자(Punctuation).아 랍어.가나.
자모(Hangul Jamo).CJK(중.일.한 공통한자)영역.표의문자(한자).한글(HangulSyllables).대용문자(Surrogates) 등이다.
코드할당비율을 보면 한자가 39.89%(2만9백2자)로 가장 많고 그 다음이한글 17.04%(1만1천1백72자), 아스키 및 기호문자 10.39%(6천8백11자)등의순이다.
"유니코드2.0"의 설계원리는 16비트코드를 기본으로 모든 언어의 완전코드화와 코드체계 단일화, 코드의 등가성, 코드간 호환성 등이다.
<>"유니코드"와 서체(이재훈이사/한양시스템)
서체(Font) 제작시 고려돼야할 "유니코드"의 특징으로는 새롭게 개정된코드매핑, 한글 1만1천1백72자의 지원 다국어서체 호환가능성 등이다.
"한글윈도우95"에서 구현되는 서체는 기존의 트루타입(TTF)과 유니코드규격, 1만1천1백72자의 한글 등이 고려돼야 할 것이다. "한글윈도우95"에서 사용되는 글자수는 영문 1백28자, 기호문자 9백86자, 한글
1만1천1백72자, 한자4천8백88자 등 총 1만7천1백74자나 된다.
현재 한글문자코드로는 기존의 완성형과 조합형 및 "유니코드2.0"기반의 "KSC 5700"등이 있다. 서체의
글리프(Glyph)구성방식으로는 완성자형(Simple), 자소조합형(Composite)등이 있다. 바람직한 한글서체를
개발하기 위해서는서체품질의 향상과 기하급수적으로 증가하는 글리프 데이터의 양을 억제하는방안 등이
강구돼야할 것이다.
"유니코드"용 한글서체 개발시 선결해야 할 문제들로는 "KSC 5700"의 경우자모 및 고어부문의 구현을 비롯,
고어의 자소조합문제 해결과 자소축소분야의 중복부문 제거, 글리프 데이터의 최소화, 한자의 자소조합형화
등이다. 일본의 리코사와 대만의 다이나랩사의 문제해결방법은 좋은 예가 될 것이다.
<>"유니코드"와 "KSC 5700"(강태진이사/한글과컴퓨터)
한글코드는 74년 7비트코드와 8비트 보조코드로 된 "KSC-5601-1974"로 처음제정됐고 82년에는 74년 버전에
16비트 보조코드를 포함시킨 "KSC-5601-1982"가 나왔다. 이어 87년에는 16비트코드를 준수(ISO 2022)하는
완성형 2천3백50자의 "KSC 5601-1987"이 제정됐다. 이 코드는 89년 개정에 이어 92년조합형을 수용하는
"KSC5601-1992"로 발전됐다.
유니코드와 한글코드의 관계를 보면 유니코드 컨소시엄이 91년 "유니코드1.0"을 제정했을 때 우리나라는
여기에 "KSC 5601"의 2천3백50자와 낱자(자모) 94자를 포함시켰다. 93년에는 ISO가 유니코드를 기반으로 "ISO
10646I"을제정했고 우리나라는 완성형자 6천6백56자와 자모 2백40자(일명 첫가끝)를포함시켰다.
95년 미국 실리콘밸리에서 있었던 유니코드 컨소시엄회의에서는 개정되는"유니코드2.0"에 한글완성형
1만1천1백72자를 포함시켰고 이어 8월 스위스 ISO회의에서 이 안이 통과돼 국제문자부호계로 채택됐다.
"유니코드2.0"과 국제문자부호계에 채택된 한글 1만1천1백72자는 모든 현대한글을 표현할수 있고 자소분리가
쉽다는 특징을 가지고 있다. 그러나 미완성 형태의 한글음절 표현이 어렵다는 단점이 있다. <서현진기자>
수년 전에 필자가 연 한글 1.0이라는 조잡한 프로그램을 천리안에 올려놓은 적이 있습니다. 그때의
목적은 코렐 드로우 등과 같이 한글이 들어가지 않는 프로그램에서 어떻게든 한글을 쓰고자 하는
것이었고, 스스로 글자꼴을 그려가며, 따라서 엉성할 수밖에 없었습니다. (하여간 코렐에서 한글을
쓰자는 기본 목적은 달성했었음.) 세월이 바뀌어 NT가 개인용 컴에서 돌아갈 수 있고, 또 NT가
유니코드를 사용하면서부터 언젠가는 새로운, 좀 쓸만한 한글을 만들었으면 하는 것이 개인적인
바램이었습니다.
하지만 11,172자라는 엄청난 수의 글자꼴을 그려야 한다는 중압감 때문에 감히 손도 못 대다가 NT용
MSIE의 한글용 팩을 받아서 사용하던 중, 굴림체라는 유니코드가 들어있는 것을 발견하고 짬을
내어 작업에 들어가 이렇게 새 판을 내놓게 된 것입니다.
한 마디로 말해서 연 한글은 유니코드만을 사용합니다. 따라서 현재 많은 사람들이 사용하는
95에서는 사용할 수 없음을 미리 밝혀두는 바 입이다. 또한 기존의 완성형 문서와는 전혀 호환성이
없습니다. Microsoft 사에 의하면 95도 유니코드를 사용할 수 있다지만, 현재 필자는 그 방법을 전혀
알지 못하고 또 알고싶은 생각도 없습니다.
높이 나는 새가 떨어지면 더 아프다고, 95가 나오기 전까지 기대했던 만큼 실망이 크기 때문입니다.
다행히 한글 95가 비교적 안정된 작업을 해 준 덕분에 많은 사람들이 한글 95를 잘 쓰고 있기
때문입니다. NT 4.0이 95보다 월등하거나 동등한 성능을 내어주기 때문입니다. 또한 어차피 기존의
조합/완성형 문서는 조만간 모두 유니코드로 바뀌어질 것이기 때문입니다.
연 한글의 장점
필자의 실험에 의하면 만족하게 동작합니다.
앞으로 전 세계의 표준이 될 유니코드를 사용합니다.
윈도우즈 폴더안을 전혀 건드리지 않습니다. 따라서 언인스톨을 하고 싶으면 간단히 연 한글
폴더만 날려버리면 됩니다. (설치하는 굴림체 폰트는 제외)
연 한글의 단점
장점이자 단점. 유니코드를 사용하므로 기존의 문서와 호환성이 없고, 95에서 동작하지
않습니다.
연 한글의 숙제
그림은 스스로, 단추는 좀 예쁘게 그려야 합니다. (저는 예술가가 아닙니다.)
세벌식 자판을 지원하지 않습니다. 다음 판에선 혹시....
한자를 지원하지 않습니다. 이는 기술적 측면이기보다는 필자의 한자실력이 너무 부족하기
때문입니다. 또한 한글을 한자로 변환하는 공식이 없다는 것입니다. 한자씩 손으로(?) 변환해
주어야 합니다.
연 한글의 문제점
현재 유니코드를 사용하는 프로그램이 전무(필자가 테스트했던 제한된 경우)하다는
것입니다. 내부적으로는 유니코드로 동작한다는 NT에서 조차도 유니코드를 받아들이는 곳은
아무도 사용하지 않는 Notepad 와 Paint 뿐입니다. 이 두 군데서라도 유니코드를 쓸 수 있다는
것에 만족해야 되는 것인가요? 최소한 Wordpad에서는 동작하리라 기대 했었는데.... 시간이
해결해 주겠지요. (Office 97 에선 아직 실험하지 못했음.)
글자꼴이 적다는 것입니다. 아직 한글 NT를 접하지 않아서 알 수는 없지만, 현재 필자가
가지고 있는 글자꼴은 굴림체 하나 뿐 입니다. 역시 시간이 해결해 줄 것입니다.
4. CJK Ideograph Compatibility & Other compatibility (F900-FFDF)
F9XX-FAXX Some Hanja
FFA0-FFBE : Halfwidth Fill + Final
FFC2-FFDE(6blank): Halfwidth Vowel with Sambo Code
======================================================================
Unicode, ISO10646 - BMP
======================================================================
No characters are currently assigned to codepoints (bit combinations) outside
of UCS2 (also called the Basic Multilingual Plane or BMP for short). Out
of the 65,536 distinct bit combinations in UCS2, 34,168 are assigned to
characters, 6,467 are reserved, and 24,901 are available for future assignment.
The UCS2 encoding space is divided into sections, whose contents are
characterized below:
Private Use Area (E000-F8FF)
CJK Ideograph Compatibility (F900-FA2D?)
Presentation Compatibility
Other Compatibility & Specials
---
Sorry to write in English. My typing in Hangul is very poor.
Once upon a time, there were two big guys named
International Standard Org (ISO) and Unicode Consortium
(A US software and hardware vender consortium). Each of
them though he is the only one who can make a universal
code set so he planed to make it. DIS-10646 from ISO,
Unicode 1.0 from Unicode consortium were the names.
DIS-10646 was a super set of various National standards
in 32-bit space and Unicode 1.0 merges all Hanja used
in China, Korea and Japan and save the code space so
they can fit all possible characters in 16-bit space.
There couldn't be two suns in the sky and they reallize
that they should work together instead of fighting
against each others. May 1991 they agree to make one code set.
At this point, every work was done. Draft of International
standard becomes an IS-10646 by defining 16-bit space char(UCS-2)
(among 32-bit full-possible work space) identical to Unicode 1.1.
And Unicode 1.0 was added with more characters defined in old DIS.
So strictly speaking, Unicode 1.1 is just an implementation of
IS-10646 UCS-2 level 3.
Unfortunately Hangul space was restricted to 6566 Chars
(less than 19*21*28 ~ 11KB to cover all modern syllables).
In addition to 6566 "Precomposed Hangul Syllables"
(WanSungHyeong Hangul in common name in Korea),
240 Modern and Ancient Hangul Jamos (in 1100-11FF)
(90+1 Choseong, 1+66 Jungseong, 82 JongSeong)
were allocated in Alphabet space (0000-1FFF).
This Jamos will be combined to make a graphical
representation of un-precomposed hangul syllables.
Two volume books, Unicode 1.0, were the only information
published but Hangul part was changed so much that
you can't use the book. Changes from Unicode 1.0 to
Unicode 1.0.1 and some more informations can be found
from ftp@unicode.org. Two Mailing list, ISO10646@jhuvm.bitnet
and unicode@sun.com are alive but no so useful.
Final document, IS-10646 is in printing process.
이 글은 최근 관심의 대상이 되고 있는 Unicode/ISO10646-BMP중에서
한글에 관한 간략한 해설을 세부분으로 나누어 설명한 것입니다.
A. 한글 Code Points
B. Unicode와 ISO10646-BMP의 관계
C. ISO10646의 level 1-3의 정의
도움이 되시기를.
이 준엽. at Courant Institute in New York Univ.
A. 한글 Code Points in ISO 10646-BMP/Unicode 1.1
-----------------------------------------------------------------
. BMP is a 2byte char set in ISO 10646 and chars set in Unicode 1.1
has been changed to be identical with ISO 10646-BMP
. Spacing and nonspacing consonant and vowel
has been deleted in the final IS.
1. And we have the following codepoints in BMP:
6656 Precomposed chars : 3400 - 4dff (26pages*256char/page)
2. the codepoints of 240 hangul jamos are as follows accoreding to N868:
choseong (syllable-initial): 1100 - 1159 (90 chars)
choseong filler 115f
jungseong filler 1160
jungseong(syllable-peak) : 1161 - 11a2 (66 chars)
jongseong(syllable-final) : 11a8 - 11fa (82 chars)
^^^^ cf) 11f9-should be
From: kskim@hyowon.pusan.ac.kr(kyongsok kim)
B. Unicode와 ISO10646-BMP의 관계
------------------------------
Unicode 1.1 is an implementation of level 2 (new level 3).
From: "K. Smith-Yoshimura" <BL.KSS%RLG@Forsythe.Stanford.EDU>
C. ISO10646의 level 1-3의 정의
----------------------------
장형규님 글 중에서,
C:우형님> 제가 잘 모르는 점은 아래와 같습니다.
C:우형님>
C:우형님> Unicode Level 1 과 Unicode Level 2이 Exclusive한지?
C:우형님> Unicode Level 1 과 Unicode Level 2의 합이 Unicode Level 3인지?
C:
C:준엽님> Unicode는 3개의 level을 가지는데, level1에서는 6656개의
C:준엽님> Precomposed syllable과 240개의 한글 자모를 쓸 수 있고,
C:준엽님> level2에서는 6656개의 Precomposed syllable 로 표현 되지
C:준엽님> 않는 한글을 240의 Jamo로 Combine합니다. level3에서는
C:준엽님> 한글을 precomposed syllable이나, 240 Jamo combination
C:준엽님> 어느 것으로나 쓸수 있읍니다.
C:
C:> Date: Wed, 19 Aug 92 15:19:38 PDT
C:> To: unicode@Sun.COM
C:> From: "K. Smith-Yoshimura" <BL.KSS%RLG@Forsythe.Stanford.EDU>
C:> Subject: Hangul support
C:>
C:> Combining jamo are allowed in the new implementation level "1.5"
C:> adopted (as requested by the UK), as well as level 2 (unrestricted
C:> use of combining characters.) Implementation level 1 is unchanged
C:> (precomposed only). The new level 1.5 (which will be the new level
C:> 2, with current level 2 becoming level 3) creates a separate level
C:> for scripts where no precomposed characters normally exist, and,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:> therefore, combining marks are mandatory, e.g., Indic scripts, Thai,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C:> Arabic, Hebrew, etc. Korea specifically requested that combining
C:> jamos be included in this new level 2. Some of this was discussed
C:> on the ISO10646@JHUVM listserv.
C:
C:준엽님, 제가 그동안 국제 동향에 좀 무관심했었기에 여쭈어봅니다.
C:위에 있는 Smith Yoshimura의 오래된 편지에는 레벨 2에서는 완성형
C:글자가 하나도 없다고 되어있는데 지금은 바뀐 모양이죠? 최근의
C:동향에 대해 hangul@cair와 sg-inet으로 posting을 해주시면 감사하겠습니다.
92년 6월 Seoul Meeting에서 최종 IS 10646이 나오기 직전에,
비공식적으로 level 1에 있는 모든 precomposed(완성형) 한글을
삭제하고, level 2에서 combining jamo들로만 Hangul을 쓰자는
의견이 있었읍니다. 그러나, 이 안은 한번도 공식적인 ISO/unicode
spec이 된 적이 없읍니다. 위에서 보듯이, final IS10646 level 2에서의
jamo comination은 완성형 글자가 없는 경우에 한하여 (scripts where
no precomposed characters normally exist) 사용되도록 되어있읍니다.
즉 모든 code point는 unique합니다. 'Kak'을 'K','a','k'으로
사용하는 것은 level 2에서는 허용되지 않읍니다. 하지만,
'KK','yu','lm'과 같이 완성형이 BMP에 없는 경우는
3code points * 2byte/code points = 6byte로 표현 합니다.
보다 정확한 level 해설은 다음의 discussion에서 볼 수 있읍니다.
-------------------------------------------------------------
S:>- Does level 2 only allow combined characters ?
S:> For example, can you use "A with Diaeresis (code point C4)" in level 2 ?
S:Level 2 includes all characters from Level 1. "A DIAERESIS" is in level2.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ISO 10646 level1,2,3 는 upward compatible scheme입니다.
S:>- If you mix precomposed characters and combined characters,
S:> is it always considered level 3 ?
해답은 combined characters가 precomposed set in BMP에
속해 있느냐, 그렇지 않으냐에 따라 달라집니다.
combined character 들이 BMP에 없었다면 대답은 NO 입니다.
그러나, S:Practically YES.
S:Level 2 is simply defined by a list of combining characters which
S:are allowed in this level. But the combining characters in this list
S:have been chosen from the scripts where precomposed are not usually
S:used, for example, Thai and Indic scripts. But theoretically, if
S:tomorrow some precomposed Thai characters will be added, Thai combining
S:characters will still remain in level 2. Essentially the same effect
S:could be achieved by using subsets.
S:>- If someone chooses to use only combined characters in korean
S:> implementation, do you say "level 2" or do you still say "level 3"
S:> only because there are code points for some korean precomposed
S:> characters in ISO-10646?
S:
S:Yes, it is still level 3. This level 2 & 3 scheme is far from perfect,
S:and, personally, I would rather do without.
S:
S:>Note that not all Korean syllables can be represented by precomposed
S:>characters.
S:
S:Yes, I know. The same is true for Latin script. This is why we have
S:level 3.
S:
S:-Isai
끝으로 우형님의 질문에 답하면, level 1,2,3 는 upward compatible
scheme입니다. 그러나, 그 사용 방법이나 목적이 상이하여 level 3
를 level 2의 upgraded version으로 사용하지는 않을 것이라는 것이
제 추측입니다. level 3은 precomposed와 combining jamo를 random하게
섞어 쓰는 scheme 이라기 보다는, level2 scheme이나 combination method
둘 중의 어느 것이나를 사용자가 정하도록 허용하는 sheme이 될것 같읍니다.
ISO/IEC-10646 Universal Multiple-Octet Coded Character Set (UCS)에
대해서
1. 개요
흔히 Unicode로 알려져 있는 ISO-10646 UCS (원명: ISO/IEC-10646:1993 Information technology -- Universal Multiple-Octet
Coded Character Set, 이하 ISO-10646이라 칭한다.)는 4바이트로 한 문자를 나타냄으로써, 보다 일반적인 문자 처리가
가능한 문자 집합과 그 부호화를 정의한다.
2. Canonical form과 BMP
ISO-10646은 문자집합의 보다 일반적인 적용을 위해서 canonical form이라는 개념을 사용한다. 각 문자는 문자들끼리
서로 구분되기 위해 4 옥텟의 16진수 이름을 갖게 되는데, 이것을 canonical form이라 한다. 각 문자는 실제로 사용되기
위해 canonical form으로부터 적당한 방법으로 부호화 될 수 있다.
이것은 ISO-2022와 같은 종전의 문자 표준이 코드영역에 직접 문자를 대응함으로써 문자 체계 자체에 제약이 주어진
것과는 달리, canonical form으로 문자 집합을 정해 놓고 그 사용환경에 따라 부호화 하는 방법을 바꿈으로써 코드
사용환경이 바뀌더라도 문자집합 자체는 변경되지 않도록 한 것이다.
그림 1. ISO-10646의 전체 부호화 영역
Canonical form의 부호 영역이 그림 1에 나타나 있다. 한 문자는 4바이트의 이름을 가지며, 각 옥텟은 그룹, 평면, 행,
셀의 의미를 가진다. 이 중에서 특히 그룹 00, 평면 00인 부분을 BMP(Basic Multilingual Plane)이라 부른 다. 현재
ISO-10646에서 문자가 실제로 할당된 부분은 BMP 뿐이다.
BMP는 다시 4개의 영역으로 나누어 지는데 각 영역의 특징은 다음과 같다.
A-zone:
alphabetic and syllabic scripts together with varios symbols
I-zone:
Chinese/Japanese/Korean (CJK) unified ideographs (unified East Asian ideographs)
O-zone:
reserved for future standardisation
R-zone:
restriced use zone (private use characters, presentation forms, compatibility characters, etc.)
그림 2. BMP(Basic Multilingual Plane)
Canonical form은 그 자체로서 하나의 32-bit 부호화가 될 수 있는데 이것 을 UCS-4라 한다. BMP역시 그 자체로서 16-bit
부호화가 될 수 있는데 이것 을 UCS-2라 한다.
3. UCS Transformation format (UTF)
ISO-10646은 현재의 기술 상황을 고려하여 한 글자를 4-octet으로 표현하도 록 하였다. 그러나 현재 환경은 한 글자를
한 바이트로 가정하고 있고, 또 한 그 가정을 기반으로 한 표준들도 있는 상황이다. (대표적인 예 ISO- 2022) 따라서,
ISO-10646에서 규정한 문자집합을 실제로 사용하려면 어느정 도의 변환이 필요하다. 이것은 UTF(UCS Transformation
format)이라 한다. 현재 제정되었거나 제정되고 있는 UTF들은 다음과 같다.
* UTF-1
ISO-2022에서 사용을 금하고 있는 C0, SPACE, DEL, C1 문자들을 사용하지 않도록 부호화 하는 방법이다.
ISO/IEC-10646:1993의 Annex G로 포함되어 있다.
* UTF-7
인터넷 메일과 같은 7 비트 ASCII 문자 전송을 원칙으로 하는 환경에서 사용하도록 고안되었다. 특히
US-ASCII에 해당하는 글자들은 변환을 해도 사람이 읽을 수 있도록 고안되었다. RFC-1642로 등록되어 있다.
* UTF-8 (UCS Transformation Format 8-Bit Form)
이것은 FSS-UTF(File System Safe Universal Character Set Transformation Format)이라고도 불린다.
UFS와 같은 화일 시스템에서, ISO-10646 문자집합을 화일 이름 또는 화일의 내용으로 사용하려면 ASCII
코드로 봤을때 NUL(0x00)문자나 slash(/)문자에 대한 처리가 필요하다. 또한 C언어의 문자열로서 사용하려면
중간에 NUL이나 backslash 문자가 포함되어서는 곤란하다. 이와 같은 문제를 해결한 것이 UTF-8이다.
이것은 ISO/IEC JTC1/SC2/WG2 N 1036 Amendment 2 to ISO/IEC 10646-1:1993 UCS Transformation Format 8
(UTF-8)으로 제출되어, ISO-10646 다음 버젼의 Annex P에 포함될 예정이다.
* UTF-16 (Transformation Format for 16 Planes of Group 00)
초기에는 UCS-2E(Extended UCS-2)라고 불렸다.
ISO-10646은 원칙적으로 4 옥텟이 한 글자이므로 16비트를 한 글자로 잡는다 하더라도 ISO-10646의 문자
집합을 제대로 사용한다고 볼 수 없다. 따라서 BMP이외의 평면을 사용할 경우를 고려하여 고안한 것이
UTF-16이다.
현재 ISO/IEC JTC1/SC2/WG2 N 1035 Amendment 1 to ISO/IEC 10646-1:1993 Transformation Format for 16 Planes of
Group 00 (UTF-16)로 제출되어 있다.
4. Unicode와 ISO-10646의 관계
ISO 10646은 국제표준기구 (ISO; International Standard Organization )와 국제전자기술위원회(IEC; International
Electrotechnical Commission )의 산하 위원회인 ISO/IEC JTC 1 (Information Technology) SC 2 (Coded character sets) WG 2
(Multiple-octet codes)에서 제정 중이던 국제표준이었다. 그에 비하여, Unicode 는 Apple, Metaphor, RLG, Sun, Xerox등이
1989년에 결성하여 만든 Unicode Working Group에서 컴퓨터에서 쉽게 지원해 줄 수 있는 다국어 지원을 목적으로
제정하던 업계 표준이었다.
1991년 Unicode Working Group은 Unicode, Inc.로 조직체계를 바꾸고, 지지부진하고 있는 ISO-10646의 다국어 부분을
Unicode사에서 제정하는 표준을 그대로 사용할 것을 국제표준기구에 제안, ISO-10646의 BMP부분은 Unicode와
동일한 내용을 가질 것을 결의하였다. 결국, ISO-10646중에서 UCS-2 BMP부분은 Unicode와 동일하다.
JTC: Joint Technical Committee
SC: Subcommittee
WG: Working Group
넷스케이프 3.0 이하 및 JDK 1.0은 내부적으로는 유니코드 문자로
처리하나, KSC5601을 비롯한 다양한 문자세트로 적절하게 변환시키지
못한다.
유니코드 문자를 출력할 때는, 유니코드 문자의 코드 값중 상위 바이트
값을 단순히 잘라내고, 입력할때는 입력 바이트에서 상위 바이트 값으로
0을 붙여 유니코드 문자를 만든다. 이는 실질적으로 한글을 포함한 모든
문자가 "8859_1" 인코딩으로 인코딩되어 있다고 가정하는 것과 같으며,
자바가 내부적으로 유니코드로 처리해봤자 아무런 의미를 갖지 못한다.
일부 유니코드 문자와 바이트 배열로 변환하는 메쏘드 중 이와 같이 잘못
변환을 하는 메쏘드는 JDK 1.1에서는 모두 deprecate시켰다.
따라서,
이러한 메쏘드를 계속 사용한다면, 한글이 깨지게 되므로, 한글에 문제가
발생할 경우에는 모두 찾아내서 다시 작성하는 것이 바람직하다.
(JDK 1.1에서 컴파일할 때 경고 메쎄지가 나오므로 이를 쉽게 찾아낼 수
있으며, 별로 많지는 않다.)
print 메쏘드와 println 메쏘드도 역시 이와 같이 잘못 처리했었으나, 너무
많이 사용되고 있으므로, JDK 1.1에서는 deprecate 시키는 대신에 디폴트
인코딩으로 변환시켜 출력하는 것으로 그 의미를 변경하였다.
=== JDK 1.1에서의 문자세트/인코딩 변환 메쏘드
JDK 1.1 (JDK 1.1 이후 버전 포함)은 문자를 내부적으로는 모두 유니코드 (2
바이트 코드 체계)문자로 변환하여 처리하며, 다양한 인코딩 방식으로
인코딩된 문자를 입출력하고 처리할 수 있도록 이들 인코딩과 유니코드 내부
인코딩사이의 변환을 수행해주는 메쏘드를 제공하며, 이러한 메쏘드는 크게
다음과 같이 2가지로 나뉘어진다.
1.인코딩 이름을 매개변수로 하지 않는 메쏘드
PrintStream 클래스의 print(...), println(...)와 같이 자주 사용되는 기본적인
메쏘드를 비롯하여 상당히 많다. 이들은 디폴트 인코딩과 내부 유니코드
인코딩으로 변환한다. 자바 프로그램 (애플리케이션이든 애플릿이든)이
실행될 때의 실행 환경에 의해서 결정된다. 일반적으로 한글 환경이면
디폴트 인코딩이 "KSC5601"이다.
2.인코딩 이름을 매개변수로 갖는 메쏘드:
인코딩 이름을 매개 변수로 지정해 줄 수 있는 메쏘드는 다음과 같이
몇가지 밖에 없으며, 이들을 사용하여 임의의 인코딩과 변환할 수 있다.
디폴트 인코딩과 상관없이 특정 인코딩 (예: "KSC5601")을 가정하고
입출력하는 등의 특정 인코딩과 반드시 변환해야 하는 경우에는
반드시 인코딩을 지정해 줄 수 있는 다음 메쏘드를 이용하여야 한다.
new String(byte[] bytes, String enc)
new String(byte[] bytes, int offset, int length, String enc)
String 클래스의 byte[] getBytes(String enc)
new java.io.InputStreamReader(InputStream in, String enc)
new java.io.InputStreamReader(InputStream in, String enc)
new java.io.OutputStreamWriter(OutputStream out, String enc)
java.io.ByteArrayOutputStream 클래스의 String toString(String enc) 메쏘드
이들 메쏘드 중 특정 인코딩에서 유니코드 인코딩으로 변환하는 경우는
모두 바이트 배열 혹은 바이트 스트림으로부터 유니코드 문자 배열 혹은
유니코드 문자 스트림으로 변환하는 메쏘드들이다.
이들 메쏘드 중 유니코드 인코딩에서 특정 인코딩으로 변환하는 경우는
모두 유니코드 문자 배열 혹은 유니코드 문자 스트림으로부터 바이트
배열 혹은 바이트 스트림으로 변환하는 메쏘드들이다.
=== 디폴트 인코딩과 시스템 디폴트 인코딩
- 디폴트 인코딩
인코딩을 매개변수로 하지 않는 메쏘드들은 디폴트 인코딩과 변환하는
데, 디폴트 인코딩은 "file.encoding" 이라는 시스템 프로퍼티 값을
의미하며, 이 시스템 프로퍼터 값은 System.getProperty("file.encoding")
메쏘드를 호출하여 읽을 수 있다. 이 디폴트 인코딩은 다시 시스템
디폴트 인코딩에 의해 초기화된다.
- 시스템 디폴트 인코딩
한글 환경일 경우, 디폴트 인코딩이 "KSC5601"이 되는 이유는 시스템
디폴트 인코딩이 KSC5601이기 때문이다. 시스템 디폴트 인코딩은
윈도우즈 95의 경우에는 설정 탭에서 언어 설정을 한국어로 선택하거나
(한글 윈도우즈 95에서는 그렇게 되어 있음), 유닉스에서는 쉘에서
setenv LANG ko라고 실행해주면, 시스템 디폴트 인코딩이 "KSC5601"이
된다.
- 디폴트 인코딩의 변경
시스템 디폴트 인코딩이 자신이 원하는 디폴트 인코딩이 아닌 경우 자바
프로그램을 실행시킬 때, 명령행 옵션 -Dfile.encoding=KSC5601를 주어
명시적으로 디폴트 인코딩을 지정할 수 있다.
(예: java -Dfile.encoding=KSC5601 JavaApplication)
그러나, 웹 브라우저에서는 애플릿이 이를 변경할 수 없으며, 웹 문서의
META 태그에 의해서도 영향받지 않고, 사용자의 인코딩 선택에 의해서도
영향을 받지 않는다. 따라서, 애플릿의 경우는 시스템 디폴트 인코딩과
디폴트 인코딩이 같은 것으로 볼 수 있다. (이부분은 좀 더 조사 필요)
익스플로러 4.0 프리뷰 2 한글판과 넷스케이프 4.01 (문자세트 지원 패키지로
업그레이드한 버전)은 모든 JDK 1.1의 모든 인코딩을 지원하지 않으며, 이들
2
브라우저가 공통적으로 지원하는 인코딩은 UTF8, KSC5601, SJIS, JIS, Big5,
GB2312, 8859_1, Cp1250, Cp1251, Cp1252, Cp1253뿐이다.
Encodings which can only be converted TO Unicode:
JISAutoDetect,
Encodings which can only be converted FROM Unicode:
UnicodeBigUnmarked, UnicodeLittleUnmarked,
- 넷스케이프 4.01 (문자세트 패키지로 업그레이드 한버전)
일부 문자세트 변환을 실행할 때, 경우에 따라
UnsupportedEncodingException이
발생하는 대신에 SecurityException이 발생하는 점이 좀 특이함 (정확한
이유를 알 수 없음)
한동안 잊고 지냈던 한글 처리문제가 자바에서 다시 등장하고 있다. 어떻게 하면 한글이 보이고, 한글을
쓸 수 있을까? 새로운 환경과 새로운 소프트웨어, 새로운 개발 언어 들이 나올 때 마다 우리는 항상 한글
문제에 대해서 고심하지 않을 수 없다. 오늘 여기 조그만 지면을 빌어 어떻게 자바에서는 한글을 쓰게
되며, 한글을 출력하게 되는지 바른 방향을 모색해 보기로 한다.
자바의 문자 체계
이미 많이 알려진 바와 같이 자바는 플랫폼 독립적인 소프트웨어를 개발할 수 있는 언어로 잘 알 려져
있다. 이러한 것이 가능한 근본적인 이유는, 자바는 운영 체계 위에 자바 가상 기계(Java Virtual Machine)가
있어 자바 클래스를 실행 시키므로, 자바 클래스(자바 프로그램)는 플랫폼에 는 상관없이 이미 이식되어
있는 자바 가상 기계에 의해 실행된다.
이러한 구조적인 특징 덕택으로, 자바 언어의 기본 자료형 역시 어떠한 플랫폼에서든 공통으로 사용된다.
예를 들어 C언어의 정수 자료형 'int'에서 DOS는 16비트를 할당하고 UNIX에서는 32비트를 할당하므로,
같은 C 프로그램이지만 서로 다른 환경에서는 서로 다른 결과값 을 출력하는 문제가 발생할 수 있다.
그렇지만, 자바에서 정수형 'int' 는 공통적으로 32비트를 할당하고 있으므로, 다양한 플랫폼에서 확실한
프로그램을 할 수 있다.
또한 자바에서 문자 자료형 'char'에 해당되는 문자 표현은 아스키 (ASCII) 코드를 사용하지 않고, 보다
국제 표준에 가까운 유니코드 (UNICODE) 체계를 사용한다. 유니코드 문자 세트는 표준 아스키 코드를
대신한 것으로서, 한 문자를 나타내는데 필요한 비트수가 아스키 코드에서는 8비트였으나
유니코드에서는 16비트로 확장된 형태이다. 유니코드는 수많은 비 영어권 언어들의 문자를 쓸 수 있도록
문 자 세트를 확장한 것이다.
자바에서는 유니코드를 지원하므로, C언어를 배울 때 아스키 코드 체계를 배우듯이 자바 프로그래머는
이제 유니코드에 익숙해져야 한다. 그러나, 인터넷의 수많은 문서들 중에 모든 문서가 유니코드로
되어있는 것만은 아니다. 따라서, 자바에서 1바이트 형태의 아스키 코드 입출력이 가능한데 다음과 같은
프로그래밍 기법으로 유니코드 입출력과 아스키 코드 입출력 기법을 구분할 수 있다.
// 유니코드를 유니코드로 출력
FileOutputStream ufos = new FileOutputStream("test.ucd");
DataOutputStream udos = new DataOutputStream(ufos);
udos.writeChars("ABCDE"); // 유니코드 출력
udos.close();
// 유니코드를 아스키 코드로 출력
FileOutputStream xfos = new FileOutputStream("test.xxx");
DataOutputStream xdos = new DataOutputStream(xfos);
xdos.writeBytes("ABCDE"); // 아스키 코드 출력
xdos.close();
유니코드와 컴파일러
Windows95 자바 개발 환경에서 위의 소스 코드를 저장하면 분명 아스키 코드 형태로 저장될 것이다.
그렇다면, 어떻게 유니코드가 아닌데 유니코드로 간주되어 다시 유니코드 형태와 아스키 코드 형태로
출력 된다는 것일까? 그것은 바로 컴파일러가 비록 소스 코드는 아스키 코드지만 유니코드로 바꾸어
인식해서 컴파일 한다는 것이다. 그렇지 않고, 소스 코드가 유니코드 일 때에는 그대로 유니코드로
인식한다. 따라서, 현재 자바 개발 환경은 유니코드와 아스키 코드를 혼돈하며 사용할 여지가 있다는
것이다. 주의해야 한다. 따러서, 제대로된 한글 2바이트 체계에 따른 컴파일러의 유니코드의 변환은
다음과 같이 이루어 져야한다.
순서 완성형 조합형 유니코드Ver2.0 발음
글자수 (2350자) (6656자) (11172자)
1 B0A1 8861 AC00 KIYEOK A
2 B0A2 8862 AC01 KIYEOK A KIYEOK
3 - 8863 AC02 KIYEOK A SSANGKIYEOK
... ... ... ... ...
11170 - D3BB D7A1 HIEUH I THIEUTH
11171 - D3BC D7A2 HIEUH I PHIEUPH
11172 - D3BD D7A3 HIEUH I HIEUH
그러면, 현재 공개된 자바 개발툴로써 JDK와 Visual J++의 컴파일 형태를 알아보겠다. Visual J++은 위
테이블의 형태에 따라 제대로 컴파일 하고 있다. 즉 'KIYEOK A'에 해당하는 완성형코드 "BOA1"은
유니코드 2.0에 따라 "AC00"로 변환한다. 그런데, JDK는 자바를 만든 제임스 고슬링의 한글에서의
2바이트 코드 체계의 이해 부족으로 잘못 변환하고 있다고 한다. 즉, "B0A1"을 영문코드 처리하듯이 "00"을
앞에 붙여 확장한 형태의 "00B0", "00A1" 두개의 코드를 생성한다.
그러면, 어떻게 제대로 컴파일도 되지 않은 자바 프로그램이 브라우저에서 실행되는 것일까? 그것은
Netscape과 JDK의 appletviewer역시 마찬가지로 위와 같은 잘못된 방식으로 코드변환이 이루어지기
때문이다. 한편, Visual J++과 IE(Internet Explorer3.0)는 제대로 유니코드 변환을처리하고 있다. 따라서,
여태까지 JDK로 컴파일된 한글 애플릿이 IE에서 실행되지 않았던 것이다. 그러면, JDK는 고치지 않고
그대로 놔둘것인가? 그렇지 않다. 올해 하반기, 즉 9월에서 12월 사이에 JDK 1.1에서는 이러한 문제를
해결해서 나올 것이다. 따라서, 그동안, JDK로 컴파일된 애플릿은 새롭게 컴파일할 필요성이 있다. 지금
당장은 Visual j++로 컴파일 해야할것이고, 차후에는 JDK 1.1로 컴파일 하면 된다.
자바에서 한글 입력
자바로 개발할 때 여러 컴포넌트를 사용할 수 있습니다. 이들 컴포넌트 중에는 'TextField"라고 하는
에디터와, "TextArea'라는 멀티라인 에디터가 있습니다. 그런데, 여기에는 한글 입력이 불가능 합니다.
따라서, 자바로 개발된 모든 프로그램은 한글 입력이 되질 않습니다. 그렇다면, 이러한 문제는 어떻게
해결할 수 있을까요? 가장 좋은 방법은 표준화된 한글 라이브러리를 배포하는 것입니다. 한글 입력기를
만들려면 한글 코드 테이블이 있어야 하는데 크기가 아주 큽니다. 그런데, 표준화가 되지 않으면,
공통적인 이러한 리소스를 따로 사용함으로써 쓸데없이 리소스를 낭비하게 되는 결과를 초래할 수
있습니다.
한글 라이브러리에 대한 표준은 시급하다고 할 수 있습니다. 지금 자바로 프로그램을 만들었는데,
한글처리 때문에 당장에 고심하는 사람도 있을지도 모릅니다. 그렇다면, 이것은 JDK나 Visual J++에
기본적으로 제공될까요? 그렇지 않고, 제이씨현시스템, 엘림네트 자바 프로젝트팀은 JDK 1.1과 Visual J++
1.0 정식 버전이 나오는 시점에서 여러 가지 유용한 유틸리티들과 한글 코드 변환기 및 입력기를 제공할
것이다. 조만간 이 한글 라이브러리 개발이 완료되면 더 이상 한글 입력에 대해서는 크게 신경 쓰지
않아도 될 것이다.
하나같이 모두 영문 폰트 이름이다. 한글 폰트 이름은 없다. 그렇지만, 한글 Window95의 경우에는 이들
폰트를 사용하면 한글이 나온다. 물론, X-Motif환경에서는 한글이 전혀 나오지 않다. 그러면 어떻게
해결할 것인가? 한글 입력기와 마찬가지로, 한글 출력을 위한 라이브러리와 한글 폰트를 배포한다?
그것은 별루 좋은 생각이 아니다. 왜냐하면, 한글 폰트의 크기는 실로 어마어마 하기 때문이다. 따라서,
한글 폰트는 시스템에 있는 한글 폰트를 사용해야 한다. 그래서, 자바가 실행되는 시스템에는 한글 폰트
이름을 추가해야 하고, 영문 폰트는 영문만 출력되고, 한글 폰트는 한글만을 출력하도록 제공해야 할
것이다.
따라서, 한국 Microsoft사와 한국Sun사는 이들 한글 폰트에 대한 표준을 만들어 자바에서 한글 폰트를
제공할 것이라 이야기 하고 있다.
이제 프로그래머가 할일만 남아있다. 프로그램을 개발할 때 영문 폰트를 이용해서 한글 출력을 해도
되는가? 이것은 바른 한글 출렵 방법인가? 그렇지 않다. 영문 폰트를 이용해서 확장된 한글을 사용하게
되면, 폰트 정보가 다르므로 폰트가 삐뚤어지거나, 줄이 맞지 않는 결과가 발생할 수 있다. 따라서,
표준적인 자바에서의 한글 폰트 이름을 제대로 사용하고 영문 폰트와는 구분해서 개발해야 할 것이다.
결론
위 그림은 지금까지 설명한 프로그래머가 완성형 한글 코드 또는 유니코드로 작성한 소스코드를
컴파일하고, 실행 할 때 코드의 변환 과정을 보이고 있다.
한편, 프로그래머가 해야 할 일을 정리해본다. 현재, JDK 1.0.2로 컴파일된 기존의 애플릿은 한글 유니코드
체계를 제대로 제공하는 Visual J++로 컴파일 해서 웹에 공개 해야 한다. 그리고, 한글 입력기는 되도록
표준적인 라이브러리를 사용해야 하고, 한글 출력시 폰트이름을 (차후에 제공될 때까지 기다려본다),
영문 폰트 이름과 한글 폰트 이름으로 구분해서 프로그래밍 해야 한다는 것이다. 마지막으로, 제대로된
자바에서 한글 구현 방향에 대한 인식으로 성능 좋은 한글 자바 애플릿이 많이 쏟아져 나왔으면 하는
바램이다.
;레지스트리의 백업&복구하는 방법
;시작->실행->regedit 치고 엔터
;내컴퓨터를 선택하고->파일메뉴->내보내기->레지스트리 내보내기
;->파일이름 입력 및 저장위치 선택->저장 : xx.reg 파일 생성
;만약 원래대로 되돌리고 싶다면 생성된 레지백업파일에 마우스 오른쪽클릭 후 병합을 클릭하면 됩니다.
;윈도우 자동으로 로그온 하기
;암호가 있는경우 실행=>control userpasswords2를 통해 자동로그인 설정
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoAdminLogon"=dword:00000001
"AutoLogonCount"=-
;로그온방식을 고전방식으로 변경(이 방식이 빠름)
"LogonType"=dword:00000000
;환경변수 입력
;(물리적인 두개의 하드를 가지고 있다면 임시폴더를 C가 아닌 다른 하드로 지정해 놓으면 하드의 데이터량이 분산되어 속도가 올라갑니다)
[HKEY_CURRENT_USER\Environment]
"TEMP"="c:\temp"
"TMP"="c:\temp"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"TEMP"="c:\temp"
"TMP"="c:\temp"
;부팅시 자동실행 프로그램 run 사용 안하기(00000001값은 사용안하기 00000000은 사용하기)
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"DisableLocalMachineRun"=dword:00000000
"DisableLocalMachineRunOnce"=dword:0000000
"DisableCurrentUserRun"=dword:00000000
"DisableCurrentUserRunOnce"=dword:00000000
;최대절전모드 사용 안함
;(노트북이 아니라면 비추. 하드용량 500MB나 차지하고 최대절전시 다운받던것도 멈춰버리죠)
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Power]
"Heuristics"=hex:05,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,3f,42,0f,00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power]
"Heuristics"=hex:05,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,3f,42,0f,00
;시스템 복원 사용 안하기
;고스트나 트루이미지등으로 백업시켜 사용하는 분들에게는 필요 없습니다(1=끄기, 0=켜기)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore]
"DisableSR"=dword:00000001
;서비스 끄기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\srservice]
"Start"=dword:00000004
;윈도우 내장 방화벽 서비스 끄기(공유기 쓰는 사람이나 따로 방화벽 쓰는 사람들에겐 불필요))
;Application Layer Gateway Service 끄기(인터넷 연결 공유 및 Windows 방화벽에서 필요함)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ALG]
"Start"=dword:00000004
;NLA(Network Location Awareness)(인터넷 연결 공유시 윈도우 내장 방화벽에서 필요하다)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NLA]
"Start"=dword:00000004
;Windows Firewall/Internet Connection Sharing (ICS)(방화벽서비스)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess]
"Start"=dword:00000004
;ZIP 폴더 기능 제거
[-HKEY_CLASSES_ROOT\.zip\CompressedFolder]
[-HKEY_CLASSES_ROOT\CLSID\{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CompressedFolder]
;WINDOWS에서 기본적으로 공유되는 폴더 제거하기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"AutoShareWks"=dword:00000000
;예약된 작업 기능 사용 안하기(실행시 확인하기에 로딩속도가 늦게됨, 필요없는 기능)
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{2227A280-3AEA-1069-A2DE-08002B30309D}]
;고정키 기능 제거(shift키 다섯번 누르면 Alt Ctrl shift가 고정되는 기능이나 쓰는사람 없음)
[HKEY_CURRENT_USER\Control Panel\Accessibility\StickyKeys]
"Flags"="506"
[HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response]
"Flags"="122"
[HKEY_CURRENT_USER\Control Panel\Accessibility\ToggleKeys]
"Flags"="58"
;시작메뉴 검색에서 바로 고급 검색 사용하기
[HKEY_CURRENT_USER\Software\Microsoft\Search Assistant]
"UseAdvancedSearchAlways"=dword:00000001
"Actor"=""
"SocialUI"=dword:00000000
"UsageCount"=dword:00000000
;깨진 바로가기에 대한 검색 사용 안함(귀찮기만함)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoResolveTrack"=dword:00000000
;CD 및 DVD 미디어 정보 검색 금지
"PreventCDDVDMetadataRetrieval!"=dword:00000001
;음악 파일 미디어 정보 검색 금지
"PreventMusicFileMetadataRetrieval!"=dword:00000001
;라디오 방송국 미리 설정 검색 금지
"PreventRadioPresetsRetrieval!"=dword:00000001
;서비스 거부 공격에 대비한 TCP/IP 스택 강화
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"SynAttackProtect"=dword:00000002
"TcpMaxHalfOpen"=dword:00000100
"TcpMaxHalfOpenRetried"=dword:00000080
"EnableICMPRedirect"=dword:00000001
"NoNameReleaseOnDemand"=dword:00000001
"EnableDeadGWDetect"=dword:00000000
"KeepAliveTime"=dword:00300000
"PerformRouterDiscovery"=dword:00000000
;DCOM 지원을 중지하여 웜바이러스 대비하기
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"EnableDCOM"="N"
;하드디스크 소음잡고 오래 사용하기 주기적으로 드르륵 거리는 소리를 잡아줌
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction]
"Enable"="N"
;윈도우 파일 시스템의 옵션과 호환성을 조절하여 속도를 높이기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
;NTFS에선 파일에 마지막 접근일자를 기록하고 그 파일이 있는 폴더와 상위폴더까지 갱신하기에 속도가 느려진다 1이 끄기(서버가 아니라면 불필요한 기능)
"NtfsDisableLastAccessUpdate"=dword:00000001
;과거엔 확장자를 3글자만 입력할수 있었는데 버젼이 올라가면서 변경되었습니다 호환기능끄기0
"Win95TruncatedExtensions"=dword:00000001
;이 옵션을 1로 설정하면 모든 FAT 볼륨들이 윈도우 3.1 볼륨처럼 행동합니다
"Win31FileSystem"=dword:00000000
;NTFS에서 구형 윈도우나 도스 등의 호환성을 위한 8+3 문자 형식의 파일 이름 생성을 중지
"NtfsDisable8dot3NameCreation"=dword:00000001
;키패드 숫자판으로 사용하기 (0=방향키로 사용 2=숫자패드로 사용, NumLook키와 동일)
[HKEY_USERS\.DEFAULT\Control Panel\Keyboard]
"InitialKeyboardIndicators"="2"
[HKEY_CURRENT_USER\Control Panel\Keyboard]
"InitialKeyboardIndicators"="2"
;바탕 화면에 입력 도구 모음 표시 안함
[HKEY_CURRENT_USER\Software\Microsoft\CTF\LangBar]
"ShowStatus"=dword:00000003
[HKEY_CURRENT_USER\Control Panel\Input Method]
"show status"=dword:00000000
[HKEY_USERS\.DEFAULT\Control Panel\Input Method]
"show status"=dword:00000000
;네트웍 카드의 내장 프로세서 사용하기 (0=켜기 1=끄기)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DisableTaskOffload"=dword:00000000
;숨김파일 및 숨김폴더 표시하기
[HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\ADVANCED]
"ShowSuperHidden"=dword:00000001
;아웃룩, 핫메일 사이트 접속시 자동으로 메신져 실행되지 않게 하기
[HKEY_CLASSES_ROOT\CLSID\{F3A614DC-ABE0-11d2-A441-00C04F795683}\LocalServer32]
@=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Outlook Express]
"Hide Messenger"=dword:00000002
[HKEY_CLASSES_ROOT\CLSID\{FB7199AB-79BF-11d2-8D94-0000F875C541}\InProcServer32]
@=""
"ThreadingModel"=""
[HKEY_CLASSES_ROOT\CLSID\{FB7199AB-79BF-11d2-8D94-0000F875C541}\LocalServer32]
@=""
;주소창에 한글 입력시 넷피아로 자동 이동 안되게 하기
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\URLSearchHooks]
"{CFBFAE00-17A6-11D0-99CB-00C04FD64497}"=-
;바탕화면 60일정리 마법사 기능 제거
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\CleanupWiz]
"NoRun"=dword:00000001
;마이크로소프트 제품 설치창 없애기
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MSIServer]
"Start"=dword:00000003
;자원부족 메시지 없애기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"DisablePagedPoolHint"=dword:00000001
;자동 시스템 재부팅 끄기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
"AutoReboot"=dword:00000000
;MS사이트로 오류보고 기능 끄기
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting]
"DoReport"=dword:00000000
;Windows Tour 팝업 제거
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Applet!s\Tour]
"RunCount"=dword:00000000
;윈도에 내장된 CD굽기 사용 안함(전부 네로나 이지시디등의 프로그램 사용함 필요없음)
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoCDBurning"=dword:00000001
;Alert!er 끄기(관리자가 선택된 컴퓨터에게 경고 메시지는 보내는 서비스 개인사용자는 필요없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Alert!er]
"Start"=dword:00000004
;ClipBook 끄기(원격 컴퓨터와 정보를 공유하는 서비스 필요없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClipSrv]
"Start"=dword:00000004
;Fast User Switching Compatibility 사용안하기(이거 역시 다중사용자를 위한 서비스)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FastUserSwitchingCompatibility]
"Start"=dword:00000004
;Help and Support 수동으로 만들기(도움말 및 지원 센터는 항상 필요하지 않기에 수동으로 설정)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\helpsvc]
"Start"=dword:00000003
;IMAPI CD-Burning COM Service 끄기(윈도우 자체 CD 굽기기능인데 필요없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ImapiService]
"Start"=dword:00000004
;메신저 서비스 끄기(Windows 메신저나 MSN 메신저와 상관없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Messenger]
"Start"=dword:00000004
;MS Software Shadow Copy Provider 끄기(MS백업 소프트웨어에 필요하나 쓰는 사람 없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SwPrv]
"Start"=dword:00000004
;윈도우 시큐리티 센터 중지하기(보안기능은 없고 귀찮게 메시지만 띄움)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wscsvc]
"Start"=dword:00000004
;Task Scheduler 자동으로 설정
;Prefetch를 사용하는데는 필요함 따라서 이 기능을 쓰는분들은 자동으로 설정
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Schedule]
"Start"=dword:00000002
;Telephony 끄기 (모뎀 xDSL을 사용하지 않는다면 불필요)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TapiSrv]
"Start"=dword:00000004
;TCP/IP NetBIOS Helper 끄기(NetBIOS를 쓰지 않는다면 불필요)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LmHosts]
"Start"=dword:00000004
;터미널 서비스 끄기(원격컨트롤 관련 서비스입니다, 위에 Fast User Switching Compatibility를 사용하기 위해서 필요함)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService]
"Start"=dword:00000004
;유니버설 플러그 앤 플레이 서비스 끄기 (플러그 앤 플레이와 상관없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\upnphost]
"Start"=dword:00000004
;무정전 전원공급장치 끄기(설마 이런걸 집에 가지고 계시는분 없겠죠?)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UPS]
"Start"=dword:00000004
;Volume Shadow Copy끄기(MS백업 소프트웨어에 필요하나 쓰는 사람 없음)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS]
"Start"=dword:00000004
;Windows Media Player Network Sharing Service (미디어 장치와 Windows Media Player 라이브러리를 공유)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WMPNetworkSvc]
"Start"=dword:00000004
;Windows Time 시간을 맞추는 프로그램 역시 불필요
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time]
"Start"=dword:00000004
;Wireless Zero Configuration 사용하지 않음(무선랜을 쓰지않는다면 필요없음)
;시각 효과 최적성능으로 바꾸기(비주얼효과를 전부 끄는 겁니다)
;사용자 모드=dword:00000000, 최적 모양=dword:00000001, 최적 성능=dword:00000002
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects]
"VisualFXSetting"=dword:00000003
;시작 메뉴에서 보여질 프로그램 갯수 설정
"Start_MinMFU"=dword:00000005
;풍선 도움말 및 툴팁 전부 없애기
"EnableBalloonTips"=dword:00000000
"FolderContentsInfoTip"=dword:00000000
"ShowInfoTip"=dword:00000000
"StartButtonBalloonTip"=dword:00000000
"NoSMBalloonTip"=dword:00000000
;미리보기 캐쉬 사용 안함
"DisableThumbnailCache"=dword:00000001
;익스플로러의 즐겨찾기 자동 감추기 기능 비활성화
"IntelliMenus"=dword:00000000
;보호된 운영 체제 파일 숨기기 해제.
"ShowSuperHidden"=dword:00000001
;숨김파일 및 숨김폴더 표시하기
"ShowSuperHidden"=dword:00000001
;시스템 폴더 내용 표시.
"WebViewBarricade"=dword:00000001
;알려진 파일 형식의 파일 확장명 숨기기 해제.
"HideFileExt"=dword:00000000
"HideIcons"=dword:00000000
;IoPageLockLimit 값 지정하기
;이값은 "특정시간에 물리적인 메모리에서 잠금이 될 수 있는 응용 프로그램메모리의 최대량을 나타냅니다"
;작은 값(16KB)으로 설정되어 있다면 10MB짜리 데이터를 하드에 쓸때
;16KB 용량 단위로 Lock을 한 후, 데이터를 하드에 저장한 후 UnLock을 합니다.
;이 과정을 계속해서 반복하게 되는데 무려 640번을 반복해야 하죠.
;반면 16777216(16MB)로 설정된 경우 1번만 반복하면 되기에 시스템의 성능 향상을 가져옵니다
;MS에서는 이 값을 물리적 램의 1/8로 설정하기를 권고하고 있습니다
;보통 다른 팁들에서는 이값은 매우 적은 값으로 설정하여 하드를 혹사시키지요
;하지만 이 캐시를 정상값으로 돌릴경우 하드의 드르륵거리는 소리부터 사라지며 시스템 성능이 상승합니다
;설정값 = 램용량 | 16진수값
;128MB | 01000000 , 192MB | 01800000 , 256MB | 02000000
;512MB | 04000000 , 1024MB | 08000000 , 2048MB | 01600000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"IoPageLockLimit"=dword:04000000
;시스템 캐시의 범위 설정(256MB이상)
;0은 I/O기능에 대해서만 캐시사용, 1은 공유파일에 대해서도 캐시사용
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"LargeSystemCache"=dword:00000001
;윈도우 커널을 메모리에 바로 띄우기 - 가상메모리로 로드되면 시스템 성능이 떨어짐(256MB이상)
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management]
"DisablePagingExecutive"=dword:00000001
;메모리로부터 빠르게 DLL 제거하기(프로그램은 느려지지만 메모리를 더 확보가능)
;00000000이 꺼놓은 상태니 메모리 적은 분들만 켜서 사용하세요
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]
"AlwaysUnloadDLL"=dword:00000000
;롱혼이 사용하는 Superfetch 활성화하기
;Prefetch보다 메모리 관리기능이 좋아진다고 하는데 켜놔도 작동 안된다는 분들도 있음
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters]
"EnableSuperfetch"=dword:00000001
;자동 미리읽기(Prefetch) 사용 설정하기
;Prefetch기능은 Task Scheduler 서비스를 자동으로 해놓아야 제대로 동작합니다
;1=응용 프로그램만 미리 읽기(ntosboot.pf 제외), 2=부팅프리패치 ntboot.pf만 미리 읽기
;3=응용프로그램과 ntboot.pf 둘다 미리읽기
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters]
"EnablePrefetcher"=dword:00000003
;웹브라우져에서 자동완성 기능 사용하지 않기
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Use FormSuggest"="no"
"FormSuggest Passwords"="no"
"FormSuggest PW Ask"="no"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoComplete]
"AutoSuggest"="no"
"Append Completion"="no"
;자동 피싱 필터 해제(시간만 걸리고 효과는 미지수?)
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\PhishingFilter]
"Enabled"=dword:00000000
;Messenger Sharing Folders USN Journal Reader service 끄기(메시져에서 공유를 위해 구성해 놓은 서비스)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usnjsvc]
"Start"=dword:00000004
;Windows Live Setup Service(요것도 불필요)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLSetupSvc]
"Start"=dword:00000004
;URL을 항상 UTF-8로 보냄 끄기(이걸 끄면 한글로된 이미지나 사운드가 브라우져에서 안보이니 알아서 설정 1이 끄기)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"UrlEncoding"=dword:00000001
;프록시 연결을 통해 HTTP 1.1 사용 끄기 (프록시를 쓰지 않는 유저만)
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings]
"EnableHttp1_1"=dword:00000000
레지스트리가 탄생하게 된 배경에는 한글 윈도우 3.1에서 사용되는 초기화 파일인 ini파일이 있었습니다. 한글 윈도우 3.1의 경우는 프로그램에서 특정한 정보를 기록할 경우 윈도우즈 디렉토리 아래에 초기화 파일인 ini파일을 사용해 정보를 기록하곤 했습니다. 그 중 대표적인 것이 win.ini, system.ini파일입니다. 물론 이 초기화 파일들 말고도 각각의 프로그램은 독자적인 ini파일을 가질 수 있었습니다. 덕분에 한글 윈도우 3.1을 오래 사용한 사용자들은 윈도우즈 디렉토리에 수많은 ini파일이 널려 있게 되어서 실제로 프로그램을 사용하다 삭제한 경우라도 초기화 파일은 지워지지 않아 커다란 문제가 되곤 했습니다. 또한 어떠한 프로그램은 직접 win.ini파일과 system.ini파일의 내용을 마구 건드리게 되므로(실제로 한글 오피스 4.2는 이러한 작업을 하는 대표적인 프로그램입니다.) win.ini파일과 system.ini파일 역시 쓸데없는 내용이 첨가되어 파일 크기가 커지는 경우가 발생했습니다.
더군다나 이러한 초기화 파일들의 내용은 모두 텍스트로 처리되어 있어 누구나 쉽게 바꿀 수 있었기 때문에 보안상에 문제가 되었을 뿐만 아니라 시스템을 부팅하는 과정에서 과다한 텍스트 파일을 읽어들여야 하기 때문에 한글 윈도우 3.1의 경우 사용하면 사용할수록 시스템의 속도가 느려지는 결점을 가지고 있었습니다. 한글 윈도우 3.1에서 win이란 명령어를 내리면 하드디스크가 엄청나게 돌아가며 시스템 시작이 늦다는 느낌을 받은 분들이 많을 것입니다. 이러한 일의 주범은 바로 ini파일이라고 해도 과언이 아닙니다.
이러한 결점을 보완하고자 한글 윈도우 95에서는 레지스트리라는 것을 도입했습니다. 물론 한글 윈도우 3.1과의 호환성을 위해서 ini파일들 역시 사용할 수 있습니다.
결국 레지스트리는 한글 윈도우 3.1의 ini 파일처럼 개개의 정보를 갖고 있는 환경 설정 파일인 셈입니다. 그렇기 때문에 레지스트리는 한글 윈도우즈의 95의 화면 구성에서 시스템 제어까지의 모든 특징을 갖고 있습니다.
결론적으로 말하면 레지스트리는 한글 윈도우 95의 설치 시에 생성되는 정보 파일입니다. 이 파일들의 항목들은 하드웨어, 소프트웨어, 유저, 그리고 PC나 네트워크의 특성들 나타내는 값들로 구성되어 있습니다. 그리고 사용자가 제어판에서 세팅을 하거나 새로운 소프트웨어를 설치하게 되면 레지스트리는 그 변화를 반영하여 바뀌게 됩니다. 이 레지스트리 세팅은 레지스트리 에디터(REGEDIT.EXE)에 의해 볼수 있는데 이것은 CD-ROM 에서 한글 윈도우 95를 설치하는 경우는 windows/system 디렉토리에 저절로 설치되어지며, 플로피 디스크로 설치하는 경우는 설치되지 않습니다.
레지스트리는 계층적인(hierarchical) 형태를 가지고 있기 때문에 폴더 구조로 꾸밀 수가 있습니다. ini 파일에서는 이러한 작업을 할 수가 없었습니다. 이러한 많은 이점 때문에 네트 워크 환경에서 사용자는 네트워크상의 어느 PC 에나 마치 자신의 데스크탑 PC 같이 드나들 수가 있습니다. 그리고 다수의 사용자가 하나의 컴퓨터에 환경정보를 저장하는 것도 가능합니다. (한글 윈도우 95에서 여러 사용자가 각각의 환경을 사용할 수 있게 한 것은 좋은 예입니다.)
2. 레지스트리의 구성
레지스트리는 크게 다음의 여섯 개의 서브트리로 이루어져 있습니다.
2.1 .HKEY_CLASSES_ROOT
이 곳에 저장되는 것은 OLE 데이터와 파일의 각 확장자에 대한 정보 그리고 각 파일과 프로그램간의 연결에 대한 정보가 들어있는 부분입니다. HKEY_CLASSES_ROOT를 더블클릭해서 보면 맨 처음 보이는 것이 파일의 확장자들인데, 한글 윈도우 95에서 사용되는 모든
형식의 확장자가 서브디렉토리 구조로 구성되어 있습니다. 일반적으로 각 확장자는 파일 타입과 연결되어 있습니다. 왼쪽 윈도우의 한 파일 타입을 선택하면 오른쪽 윈도우에는 그 타입의 파일이 어떤 프로그램과 연결되어 있는지 나타납니다.
예를 아래아 한글을 설치했다면 HWP를 선택했을 때에 오른쪽 윈도우에는 아래아한글과
연결되어 있다는 정보가 보일 것이다.
2.2 .HKEY_CURRENT_USER
한글 윈도우 95가 설치되어 있는 컴퓨터의 환경 설정들에 대한 정보를 담고 있는 곳입니다.
하나의 한글 윈도우 95를 여러 명의 사용자가 사용할 경우, 한 사용자가 자신의 ID와 패스워드를 이용해서 자신의 환경으로 한글 윈도우 95에 접속했을 때, 접속한 사용자가 맞춰놓은 세팅을 윈도우 95에 반영하기 위한 곳입니다. 따라서 각 사용자가 자신의 세팅을 다르게 바꾼다면 그 정보는 HKEY_USER라는 곳에 저장됩니다. 이곳을 더블클릭하면 여섯 개의 서브 메뉴가 나옵니다.
AppEvent는 현재 윈도우 95를 사용하는 사용자가 정의해 놓은 이벤트들의 리스트입니다.
Control Panel은 제어판과 동일한 설정을 할 수 있는 곳입니다. 이곳에서의 설정은 레지스트리를 변경하는 것보다 제어판에서 직접 바꾸는 것이 더 편리합니다.
InstallLocationsMRU는 최근에 새로 설치된 프로그램들의 위치를 알려줍니다.
Keyboard Layout에는 현재 사용하고 있는 키보드의 사용 언어와 키보드 형식이 Dvorak인지 혹은 Qwerty 방식인지에 대한 정보가 담겨 있습니다.
Network는 최근에 이용했던 네트워크 드라이브에 대한 정보 등을 담고 있는 곳인데, 네트워크 기능을 이용하지 않는 사용자들은 아무 값도 설정되어 있지 않습니다.
끝으로 Software에는 설치된 한글 윈도우 95용 프로그램들에 대한 정보가 담겨 있습니다.
이 프로그램들이 32비트를 지원하지 않는다면 별다른 정보가 기록되지 않고 프로그램의 이름만 등록됩니다.
2.3 .HKEY_LOCAL_MACHINE
HKEY_LOCAL_MACHINE은 컴퓨터에 설치된 하드웨어와 하드웨어를 구동시키는데 필요한 드라이버나 설정 사항에 관련된 정보를 모아 둔 곳입니다. Config에는 프린터와 화면 설정 같이 컴퓨터를 켜고 윈도우 95를 구동시킬 때 필요한 설정에 대한 정보가 담겨 있습니다. 이 부분 역시 레지스트리 값을 변경하지 않고 윈도우 95의 제어판에서 설정해 줄 수 있습니다.
Enum은 사용자의 컴퓨터에 설치된 하드웨어에 관한 정보를 갖고 있습니다. 예를 들어 IDE 하드디스크 드라이브나 플로피 드라이브에 관한 정보 등이 이 곳에 저장됩니다. 플러그앤플레이를 지원하는 하드웨어가 설치되면 Root라는 키에 저장됩니다.
Software는 디바이스 드라이버나 시스템에서 사용하고 있는 소프트웨어에 관한 전반적인 정보를 담고 있습니다. 각종 응용프로그램들은 각 파일들과 연계되어 있는 것이 보통입니다.
2.4 .HKEY_USERS
HKEY_CURRENT_USER에 저장된 정보 전체와 데스크탑 설정, 네트워크 연결등의 정보가 저장되어 있으며, USER.DAT에 그 내용을 저장합니다. 윈도우 95를 사용하는 사람이 한 명일 경우에는 모든 설정 사항이 HKEY_CURRENT_USER의 내용과 일치합니다.
2.5 .HKEY_CURRENT_CONFIG
HKEY_CURRENT_CONFIG는 레지스트리 가운데 가장 단순한 부분입니다. 여기에는 위에서 설명한 HKEY_LOCAL_MACHINE에 서브로 존재하는 Config의 내용만을 담고 있다. 따라서 디스플레이와 프린터에 관한 설정만을 볼 수 있습니다.
2.6 HKEY_DYN_DATA
HKEY_DYN_DATA는 Config Manager와 PerfStats라는 두 개의 서브키를 갖고 있습니다. PerfStats는 윈도우 95의 모니터 역할을 합니다.
3. 레지스트리를 바꾸면 윈도우가 달라 보인다.
◆ 레지스트리 편집기의 실행
%주의 : 레지스트리를 편집할 때에는 항상 주의를 기울여야 한다.
레지스트리 편집기는 C:WINDOWS 라는 디렉토리에 regedit.exe 라는 이름으로 존재한다. 시작 버튼을 누른 후 '실행'을 선택하여 이 파일을 실행하게 되면 레지스트리 편집기가 실행된다.
레지스트리 편집기를 실행하면 화면상에는 여러 가지 이름 모를 문자들이 디렉토리 구조로 표현되어 있을 것이다. 각각의 항목마다 모두 존재하는 이유가 있지만 우리가 목적하는 것이 아니라면 건드리지 않는 것이 좋다.
레지스트리를 편집하는 방법은 아주 간단한데, 새로운 키(대상)를 추가하고자 할 때는 원하는 부분을 선택한 후 마우스 오른쪽 버튼을 누르고 '등록'을 선택한 후, '키'라고 되어 있는 것을 선택한 다음, 키의 이름을 입력해 주면 새로운 키가 생성된다. 키가 추가되었다고 해서 모든 작업이 끝난 것은 아니고 여기에 각각의 값을 넣어주어야 한다. 값을 넣어줄 키를 선택하고 마우스 오른쪽 버튼을 눌러보자. 그러면 여기서 방금 전에 키를 만들 때와 같은 메뉴가 나올 것이다. 여기서 문자열 값, 이진 값, DWORD 값 등 원하는 값의 종류를 선택하고 새 값을 넣으면 값이 등록된다. 만일 이미 존재하는 값을 변경하고자 할 때는 변경하고자 하는 값을 마우스 왼쪽 버튼으로 더블클릭하면 값을 변경해 줄 수 있는 상태가 된다.
다시 한번 주의 사항
레지스트리 편집이라는 것이 중급 이상의 사용자라도 상당히 조심스러운 작업이라 상당한 위험이 따른다. 그러나 윈도우즈 95를 재미있고 다양하게 활용하기 위해서 레지스트리 편집 작업이 뒤따라야 하는 것 또한 어쩔 수 없는 사실이다. 안전한 작업을 하기 위해서 WINDOWS 디렉토리 안에 있는 레지스터 파일인 SYSTEM.DAT , SYSTEM.DA0 , USER.DAT , USER.DA0 이 네개의 파일을 미리 백업 해 두는 것이 좋다. 만일의 사태를 대비해서 꼭 해 두는게 좋을걸요.......
* 레지스터 파일 백업 방법
MDIR상에서 WINDOWS 디렉토리로 이동한후 ALT+Z를 누른다.
그 다음 SYSTEM.DAT , SYSTEM.DA0 , USER.DAT , USER.DA0 이 네개의 파일을 스페이스바로 선택한후 적당한 디렉토리에 복사해둔다. 압축을 해두는 것 도 좋은 방법
1. 시작 메뉴 속도 높이기
[시작]을 눌렀을 때 메뉴가 나타나는 속도(프로그램을 눌렀을때도임.)를 빨리 해준다.
HKEY_CURRENT_USER⇒Contral Panel⇒Desktop으로 이동한다. MenuShowDelay 키가 없다면 오른쪽 창에서 마우스 오른쪽 버튼을 눌러 ‘등록-문자열 값’을 누른 다음 ‘MenuShowDelay’ 키를 새로 만든다. 만들어진 문자열 값을 더블클릭하여 ‘값의 데이터’에 값을 ‘0’ 으로 하면 매우 빨라진다. 이미 존재한다면 그냥 새 값을 입력한다.
2. 자동 메뉴 확장 기능 제거
시작 버튼에 등록되어 있는 프로그램에 마우스 포인터를 위치시키면 자동으로 하위 메뉴가 나온다. 이것을 자동 메뉴 확장 기능이라고 하는데, 때로는 이 기능이 불편할 때가 있는데 이 기능을 없앨 수 도 있다.
HKEY_CURRENT_USER⇒Control Panel⇒Desktop 으로 이동한다. 우측 화면에 MenuShowDelay 라고 하는 키를 등록한 후, 여기에 ‘65534’ 라는 값을 넣어 준다. 이제 윈도우즈를 재시작 하면 마우스로 클릭하기 전까지는 하위 메뉴들이 저절로 나오는 일은 없을 것이다.
3. 바탕화면 단축 아이콘 왼쪽 밑에 있는 화살표 없애기
컴퓨터를 조금 알게 되면 화살표 붙은 것은 단축아이콘이라는 것을 누구나 안다. 단축 아이콘 밑에 나오는 화살표는 별 필요도 없는데 화면만 지저분하게 한다. 윈도우를 좀더 깔끔하게 하기를 원하는 사람은 이 방법을 쓰는 것도 좋을 듯 하다.
HKEY_CLASSES_ROOT⇒lnkfile로 이동한다. 또는 ‘편집-찾기’에서 찾을 문자열에 ‘IsShortCut’이라고 입력한다. 화면의 우측에 나타나는 내용 중에 IsShortCut이라고 되어 있는 부분이 있을 것이다. 이것을 삭제한다. 혹시 다음에 다시 보고 싶다면 삭제하지 말고 오른쪽 버튼을 눌러 이름만 바꾸어 주어도 (IsShort라고 몇 자만 지워도) 된다. 재부팅을 하면 깨끗한 단축아이콘이 보일 것이다.
4. 아이콘에 256컬러 이상의 컬러 입히기
플러스 팩을 설치하면 바탕화면 테마와 함께 256컬러 이상의 아이콘을 보여준다. 그러나 굳이 플러스를 설치하지 않고도 256 이상의 아이콘을 볼 수 있다. 단, 현재의 해상도에서 16비트 컬러나 24비트 컬러가 가능해야한다. 플러스가 설치되어 있다면 만질 필요는 없다.
HKEY_CURRENT_UER⇒Control Panel⇒Desktop⇒windowmetrics 으로 이동한다. ‘Shell Icon BPP’란 문자열값을 추가한 후(방법은 1번과 같다.)데이타 값을 16 또는 24로 값을 주면 256 컬러 이상의 아이콘을 사용할 수 있다. 여기서 16‘이라는 숫자는 16비트 색상을 의미한다.
5. 바탕화면 아이콘 크기변경
바탕화면의 아이콘 크기변경은 ‘디스플레이 등록정보-화면배색-항목-아이콘’에서도 조절해 줄 수 있다. 왜 힘들게 레지스트리까지 오냐고 묻는다면, 필자도 답변이 없다. 하지만 레지스트리에서도 크기를 변경하는 방법을 알고 있다고 해서 나쁠 건 없다고 본다.
HKEY_CURRNET_User⇒Contorl Panel⇒desktop⇒windowsmetrics으로 이동해서 ‘shell icon size'에서 오른쪽 버튼을 눌러 ’수정‘을 선택한 후 64정도로 늘려보자. 윈도우를 재부팅 하면 바뀐 내용을 확인 할 수 있다. 단, 아이콘이 너무 크면 윈도우의 속도가 느려진다는 점에 주의해야 한다.
6. '프로그램 추가/삭제' 목록에서 지워지지 않는 항목 제거
대부분의 프로그램은 설치돼 있는 상태에서 언 인스톨을 하면 목록에서 지워진다. 하지만 사용자가 수동으로 제거하였거나 혹은 프로그램은 삭제되었더라도 목록에는 그대로 남아 있는 경우가 가끔 있다. 이런 경우에 활용할 수 있는 레지스트리 편집방법이 있다.
HKEY_LOCAL_MACHINE⇒software⇒Microsoft⇒Windows⇒CurrentVersion⇒Uninstall이라는 항목으로 이동하면 현재 설치되어 있는 프로그램들의 이름이 출력되는 것을 볼 수 있다. 이 상태에서 제거하고 싶은 목록을 삭제한다.
7. 윈도우즈 사용자 등록정보 변경하기.
윈도우95를 직접 설치하지 않았다면 시스템 등록정보에 자기의 이름이 아닌 다른 이름으로 되어 있을 것이다. 이 설정은 다른 응용프로그램에도 영향을 끼칠 수 도 있는데 이 정보(사용자, 회사)를 변경하여 보자.
HKEY_LOCAL_MACHINE⇒Software⇒Microsoft⇒Windows⇒CurrentVersion으로 이동하면 우측 화면에 윈도우등록번호와 사용자에 관련된 여러 가지 정보가 출력된다. 여기서 값의 데이터를 바꾸어주면 된다.
8. 자동으로 최신 정보로 고치기
탐색기에 어떤 디렉토리를 만들어 넣었다든지 혹은 내용을 변경하였을 경우, 변경된 내용이 곧바로 화면에 적용되지 않고 F5 새로 고침을 눌러야지만 적용된다. 즉 디스크의 라벨을 바꾸었다든지, 새로운 폴더를 등록하거나 이동시켰을 때 화면에 나타나는 정보가 갱신되지 않는 것이다. 이때 레지스트리를 변경하여 바로 적용되도록 하자.
HKEY_LOCAL_MACHINE⇒System⇒CurrentControlSet⇒Control⇒Update으로 이동한다. 화면 오른쪽에 보이는 UpdateMode의 값을 01에서 00으로 바꿔준다.
9. 창이 뜨는 속도 높이기
윈도우즈95의 속도를 조금이라도 높이고 싶은 사람에게는 창의 최대화, 최소화에 따른 애니메이션도 속도를 떨어뜨리는 원인이 될 것이다. 여기서는 그 속도를 빨리 해주는 방법을 소개한다.
HKEY_CURRENT_USER_⇒Control Panel⇒desktop⇒windowmetrics으로 이동한다. 우측 화면에서 마우스 오른쪽 버튼을 누른 후 ‘등록-문자열 값’을 선택하고 ‘MinAnimate’라고 입력한다. 그 다음 이 값을 더블클릭하여 값을 '0'으로 설정한다. 이것으로 창이 열리거나 닫힐 때 최대화, 최소화 애니메이션표시가 되지 않아 창의 표시속도가 눈에 띄게 빨라진다.
10. 폴더 아이콘 모양 바꾸기
HKEY_CLASSES_ROOT를 선택하고 ‘FOLDER' 항목의 ’DefaultIcon'으로 이동한 뒤, 오른쪽 내용 창에서 기본 값을 선택한다. 그리고 ‘편집(E)’메뉴에서 ‘수정(M)'을 선택한다. 그러면 나타나는 ’문자열 편집‘ 대화상자에서 ’값‘의 데이터 상자에 원하는 모양의 아이콘 파일의 경로와 파일명을 기입해 주면 윈도우95의 폴더 아이콘이 변경된다.
11. 휴지통의 이름 바꾸기
데스크탑상의 대부분의 아이콘이나 단축아이콘 이름은 마음대로 바꿀 수 있다. 하지만 [휴지통]은 언제나 (노턴이 설치되었다면 [노턴안전휴지통]) 휴지통이다. 단축메뉴에도 이름 바꾸기가 없고 F2를 눌러도 아무런 반응이 없다. 난 이름을 “분리수거 할 것”이라고 바꾸고 싶다.
레지스트리 편집기를 실행시킨다. 편집-찾기 (또는 )를 누르고 “휴지통”이라고 입력한 후 다음 찾기를 누르면 오른쪽 창에 (기본값) ‘휴지통’ 이 (왼쪽은 신경 쓰지 말자) 보인다. (기본값)을 더블클릭하면 문자열 편집대화상자에서 값의 데이터를 바꾸어 주면 된다.
HKEY_CLASSES_ROOT에서 CLSID로 이동해서 찾아도 되는데 아주 어려울 것이다. 자신 있으신 분은 {645FF040-5081-101B-9F08-00AA002F954E}를 찾으면 된다. 아주 어렵죠
참고로 다른 것 몇가지도 함께 적어봅니다.
{20D04FE0-3AEA-1069-A2D8-08002B30309D} : 내 컴퓨터
{208D2C60-3AEA-1069-A2D7-08002B30309D} : 네트웍 설정
{00020D75-0000-0000-C000-000000000046} : 받은 편지함
{85BBD920-42A0-1069-A2E4-08002B30309D} : 서류가방
{3DC7A020-0ACD-11CF-A9BB-00AA004AE837} : 인터넷
{992CFFA0-F557-101A-88EC-00DD010CCC48} : 전화 접속 네트워킹
{21EC2020-3AEA-1069-A2DD-08002B30309D} : 제어판
{2227A280-3AEA-1069-A2DE-08002B30309D} : 프린터
{00028B00-0000-0000-C000-000000000046} : The Microsoft Network.
12. 시작메뉴에 제어판/휴지통을 추가해 보자.
레지스트리 편집과는 상관없지만... 제어판은 자주 이용되는 항목이다. 그런데 꼭 설정으로 가서 제어판을 눌러야한다. 시작과 함께 제어판의 내용을 모두 보자.
[시작]에서 오른쪽 버튼을 눌러 [탐색]을 누른다. [파일(F)]메뉴에서 새로 만들기 , 폴더 명령으로 새 폴더를 만든다.
새 폴더의 이름을 “제어판.{21EC2020-3AEA-1069-2ADD-08002B30309D}"으로 만들어 주면 시작에 제어판메뉴가 생긴 것을 확인 할 수 있다. 휴지통도 여기에 놓고 싶다면,”휴지통.{645FF040-5081-101B-9F08-00AA002F954E}“라고 추가해 주면 된다.
13. 바탕화면에서 휴지통 없애기
더 이상 바탕화면에 휴지통이 필요 없을 때가 있다. 이 역시 레지스트리를 이용해 간단히 제거 할 수 있다.
레지스트리 편집기를 실행시킨다. ‘HKEY_LOCAL_MACHINE⇒SOFTWARE⇒Microsoft⇒Windows⇒CurrentVersion⇒explorer⇒Desktop을 따라 내려간다. 하위 목록 중에 NameSpace를 선택한 뒤 {645FF040-5081-101B-9F08-00AA002F954E}에서 오른쪽 버튼. 항목의 키 값을 삭제하면 재부팅 후 휴지통이 사라진다. 오른쪽 버튼의 삭제는 그대로 있다. 물론 Delete키를 이용해도 된다. 사용하지 않는 인터넷 아이콘도 삭제 할 수 있다.
14. 바탕화면에서 네트워크환경 삭제하기.
바탕화면의 ‘네트워크 환경’ 아이콘은 두 가지 문제점을 가지고 있다. 첫째, 진짜 네트워크에 연결되지 않은 많은 사람들은 원하지 않아도 이 아이콘을 바탕화면에 두어야 한다. 둘째, 이 아이콘을 다른 폴더로 옮길 수 있는 방법이 없다. 따라서 이를 쓰지 않는 사람들은 이 아이콘을 바탕화면에서 추방하고 싶다고 생각할 것이다.
이 아이콘은 바탕화면에서 제거해도 네트워크 연결에 영향을 주지 않고, 또한 네트워크 드라이브를 UNC(Universal Naming Conventions)에서 지정해야 하는 것도 아니다. 다만 ‘네트워크 환경’의 이름을 바꾸거나 바탕화면에서 없애면 네트워크 연결이 안 되는 것이 아니라 네트워크 드라이브를 찾는 것이 약간 불편할 뿐이다.
네트워크 환경을 바탕화면에서 없애려면 레지스트리 편집기를 열고 다음을 찾는다.
HKEY_CURRENT_USER⇒Software⇒Microsoft⇒Windows⇒CurrentVersion⇒Policies⇒Explorer ‘편집’ 메뉴에서 ‘등록-DWORD'값을 선택한다. NoNetHood라고 입력하고 엔터키를 두 번 친다. 그리고 기본값에 1을 입력한다 이제 윈도를 다시 시작하면 바탕화면에서 ’네트워크 환경‘가 없어진 것을 확인할 수 있다. 원래대로 바꾸려면 NoNetHood값을 지우고 다시 윈도를 다시 시작하면 된다.
이러한 작업을 더 쉽게 하려면 마이크로소프트 파워토이에 포함된 Tweak UI를 이용하면 된다. 제어판의 Tweak UI아이콘을 두 번 클릭하여 열고 Desktop화면에서 Network Neighborhood항목을 클릭하여 체크 표시(v)를 없애주고 ‘확인’ 버튼을 누르면 된다.
15. 시작 때마다 자기만의 팁 보기
윈도우95를 처음 설치하였을 때, 실행할 때마다 윈도우 활용 팁이 표시되던 것을 기억 할 것이다.( 나지 안으면 어쩔 수 없죠.) 윈도우에서는 48가지 팁을 준비하여 두었다가 사용자가 윈도우를 시작 할 때마다 바꿔가면서 화면에 출력해 주는 재미있는 기능을 가지고 있다. 하지만 이 팁을 모두 보고 나면 더 이상 사용하지 않게 된다. 이럴 때 자기만의 명언이나 월간계획, 좋아하는 문장을 넣어두면 보다 재미있게 활용 할 수 있을 것이다.
레지스트리 편집기를 실행시킨다. HKEY_LOCAL_MACHINE⇒Software⇒Microsoft⇒Windows⇒CurrentVersion⇒explorer⇒Tip을 선택한다. 오른쪽에 0에서 47까지 팁이 표시되어 있다. 여기에 오른쪽 버튼을 눌러 각각의 팁을 수정해 주면 된다. 너무 많은 문장을 입력하면 레지스트리의 크기가 커지므로 필요한 만큼(?)만 입력하자.
16. BMP 그림 파일을 아이콘처럼 보기
탐색기에서 파일, 폴더 등의 개체를 보여줄 때 각 파일의 종류마다 고유의 아이콘 그림을 보여준다. 탐색기는 파일의 종류를 확장자로 판단한다. 예를 들어, txt파일은 공책처럼 생긴 그림으로 표시하고, doc파일은 마이크로 소프트 워드의 W글자 모양의 그림으로 표시한다. 또한 bmp파일은 컬러풀한 그림으로 표시한다.
이렇게 아이콘은 파일과 연계되어 있다. 이를 다른 아이콘으로 바꿔보자. 탐색기에 들어가 ‘보기’메뉴에서 ‘옵션’명령을 내린다. ‘옵션’ 대화상자에서 ‘파일 형식’탭을 누른다. 원하는 파일 종류를 선택한 다음 ‘편집’버튼을 누른다.
‘파일 형식 편집’창에서 ‘아이콘 변경’버튼을 누른 다음 ‘아이콘 변경’창에서 원하는 아이콘을 고르면 된다.
파일안에 있는 아이콘을 뽑아내 쓰려면 탐색기가 어떻게 작동하는지 알아야 한다.
예를 들어, ico파일은 파일 안에 들어 있는 아이콘 그림이 탐색기 상에서 아이콘으로 표시된다. ani파일도 역시 그 파일에 들어있는 작은 커서 모양으로 표시되고, exe 파일도 내부 아이콘 그림으로 표시된다. 다음 다섯 단계를 통해 bmp파일도 원래 그림 모양의 썸네일 아이콘으로 바꿀 수 있다. 썸네일은 원래 엄지손톱이란 뜻이다. 그래픽에서는 아이콘처럼 작은 조각 그림을 썸네일 이라고 부른다.
우선, 레지스트리 편집기를 실행시킨다. HKEY_CLASSES_ROOT⇒Paint.Picture⇒DefaultIcon라고 되어 있는 항목을 선택한다. 그런 다음 화면 오른쪽으로 이동하여 default 오른쪽 창에 이 값이 %1로 되어 있을 것이다. %1의 의미는 탐색기가 파일안에 있는 그림을 아이콘으로 쓰라는 뜻이다.
백업을 한다. 키를 백업하려면 레지스트리 편집기의 ‘레지스트리’메뉴에서 ‘등록 파일로 저장’ 명령을 내리면 된다. ‘등록파일로 저장’ 대화상자가 나오면 ‘OldBMPPictures.txt'와 같은 이름을 입력하고 ’저장‘버튼을 누른다. ‘기본값’이라고 써 있는 부분을 두 번 클릭하여 열고 ‘문자열 편집’ 대화상자에서 값을 데이터를 %1로 바꿔준다. 저장한 다음 레지스트리 편집기를 빠져 나온다 : 이제 탐색기를 시작하면 모든 bmp파일 아이콘이 썸네일 형태로 바뀌어 있는 것을 볼 수 있다.
♣주의♣
썸네일을 표시하려면 많은 디스크 읽기와 연산이 필요하므로 시스템 속도가 떨어질 수 있다. 따라서 이 기능을 너무 남용해서는 안된다. 만일 bmp파일에 대해 썸네일이 아닌 일반 아이콘을 다시 쓰고 싶다면, 레지스트리 편집기를 열고 레지스트리 메뉴에서 ‘등록 파일 읽어오기’ 명령을 내린 다음 저장했던 OldBMPPictures.txt 파일을 불러오면 된다.
17. 사운드 이벤트의 추가
어떤 프로그램을 실행할 때마다 특별한 소리를 내고 싶다면 사운드 이벤트 추가 방법에 대해 눈여겨보기 바란다. 아래아-한글과 같은 프로그램을 실행하게 되면 실행과 동시에 소리가 연주되는 것과 같은 기능을 다른 모든 응용 프로그램들에서도 만들어 놓을 수 있다.
우선, 레지스트리에서 HKEY_CURRENT_USER⇒AppEvents⇒Schemes⇒Apps라는 항목을 선택한다. 여기서 마우스 오른쪽 버튼을 눌러 '등록'을 선택한 후 새로운 키를 추가하도록 한다. 키의 이름은 사운드와 함께 실행하고자 하는 실행 파일명을 적어 주면 된다.
다시 마우스 오른쪽 버튼을 누른 후 '등록'을 선택하여 'OPEN' 과 'CLOSE'라는 키를 실행 파일명의 하위 키로 만들어 넣는다. 다시 'OPEN' 과 'CLOSE'에서 마우스 오른쪽 버튼을 눌러 .Current 라는 키를 만들어 넣는다. 그런 다음 화면 오른쪽으로 이동하여 프로그램의 시작(Open의 경우)과 끝(Close의 경우)에 지정하고자 하는 사운드 파일의 경로와 이름을 값으로 지정하여 넣으면 된다. Open과 Close 이외에도 Minimize, Maximize 등의 작업에 모두 사운드를 만들어 넣을 수 있지만 대부분 시작과 끝나는 부분에만 사운드를 추가하는 것이 보통이므로 생략하도록 한다.
18. 긴 파일이름을 보기 좋게 표시하기
안되는 컴퓨터가 더 많더라구요, 그래서 삭제했습니다.
19. 모니터 절전 기능 시간 늘리기.
에너지 스타 모니터를 가지고 있다면 제어판의 디스플레이 등록정보에 있는 화면보호기 페이지의 ‘모니터 절전 기능’에서 일정 시간이 지나면 전력을 떨어뜨리는 ‘전력 저하 대비’와 전원을 완전히 차단해 주는 ‘모니터 끄기’ 기능을 설정할 수 있다. 그러나 이 기능은 1~60분 사이에 시간에서만 설정할 수 있다.
따라서 60분이 넘어가는 설정은 불가능하다. 그러나 레지스트리를 직접 조작하면 이러한 시간의 제약을 뛰어 넘을 수 있다.
HKEY_CURRENT_USER⇒Control Panel⇒desktop 오른쪽 창에서 다음과 같은 두 값이 있는 것을 발견할 수 있다.
전력저하 : ScreenSaveLowPowerTimeout
모니터 끄기 : ScreenSavePowerOffTimeout
이제 이 두 값을 바꾸어 주면 모니터 절전 기능을 시간 제약없이 설정할 수 있다. 단위는 초로 되어 있으므로 3시간 뒤에 모니터를 끄려면 ScreenSavePowerOffTimeout값을 7200으로 설정하면 된다. ‘확인’버튼을 누르면 새 설정이 바로 적용된다.
이때 디스플레이 등록정보의 수치는 60이상으로 바뀌지 않지만 실제로 절전 효과는 레지스트리에서 바꾼 대로 작동한다.
20. 디렉토리 리스트 출력하기
탐색기에서 디렉토리 리스트를 출력하는 기능은 없다. 폴더를 오른쪽 마우스 버튼으로 클릭하고 단축메뉴에서 그 폴더 안의 파일이나 서브 폴더를 프린터로 출력할 수 있다면 편리할 것이다. 이러한 기능은 많은 사람들에게 필요한 기능이면서도 탐색기에 빠져 있다는 것이 아쉽기만 하다. 어떤 책에는 윈도95에서는 이러한 출력이 불가능하다고 써있고, 어떤 책은 복잡한 레지스트리 수정을 통해 간략한 리스트를 뽑아낼 수 있는 방법을 제시하고 있다. 그러나 분명히 훨씬 더 효과적이고 빠른 방법이 있다.
HKEY_CLASSES_ROOT⇒Directory⇒shell
이 키를 레지스트리에서 직접 바꾸는 것이 아니라 탐색기의 파일 형식 탭에서 수정해 보기로 하자. 수정이 끝난 다음 이 노드가 어떻게 달라졌는지 확인해 보기 바란다.
메모장이나 도스 에디터를 이용하여 다음과 같이 PrintFileFolder.bat이라는 배치 파일을 만든다.
dir %1 /-p/a/o > "%temp%File List"
notepad /p "%temp%File List"
메모장(notepad)명령 뒤의 /p 스위치는 출력을 마친 뒤 메모장을 자동으로 끝내라는 의미이다. 탐색기를 시작하고 ‘보기’메뉴에서 ‘옵션’을 선택하고 ‘파일 형식’탭을 클릭한다.
‘파일 폴더’를 클릭하여 선택하고 ‘편집’버튼을 누르고 ‘등록’버튼을 누른다.
‘새 명령’ 대화상자에 다음과 같이 입력한다.
? 명령:Print File Listing
? 명령을 수행할 응용프로그램 c:PrintFileFolder.bat
‘확인’ 버튼을 누르고 빠져 나온다. 이제 탐색기에서 폴더 안의 파일 리스트를 출력하려면 폴더를 오른쪽 마우스 버튼으로 클릭하고 단축메뉴에서 Print File Listing명령을 내리면 된다.
21. 새로 만들기를 빠르게
윈도95는 새 파일을 빠르고 쉽게 만들 수 있다 .바탕화면, 폴더, 탐색기의 빈 공간을 오른쪽 마우스 버튼으로 클릭하면 단축메뉴가 나온다. 여기서는 폴더와 단축아이콘을 만들 수 있고, 여러 파일 리스트에서 원하는 종류의 파일을 선택하면 바탕화면이나 폴더에 새 파일이 만들어진다. 그러나 프로그램을 이것저것 깔다 보면 단축메뉴에 나오는 파일의 종류가 점점 늘어나게 되고, 따라서 리스트에서 원하는 파일을 찾기 어렵게 된다. 이럴 때 레지스트리를 이해하고 있으면 불필요한 파일 리스트를 없애 버릴 수 있다. 오른쪽 마우스 버튼을 누르고 ‘새로 만들기’명령을 내리면 윈도는 레지스트리의 HKEY_CLASSES_ROOT⇒.확장자 (예.TXT)⇒ShellNew키를 찾는다. 이 키의 ProID를 찾은 다음 HKEY_CLASSES_ROOT⇒ProgID의 ‘기본값’에 있는 설명 문자열을 찾는다. 예를 들어, HKEY_CLASSES_ROOT⇒.txt는 ShellNew키를 가지고 있다. HKEY_CLASSES_ROOT⇒.txt의 ProgID는 txtfile로 설정되어 있다. 윈도는HKEY_CLASSES_ROOT⇒txtfile의 기본값인 ‘텍스트 문서’를 읽어 들인다. ‘새로 만들기’ 단축메뉴를 보면 이 ‘텍스트 문서’항목을 찾아볼 수 있다. 다른 ShellNew키도 같은 방법으로 작동된다. ‘새로 만들기’명령에서 원하지 않는 항목을 지우려면 이에 해당하는 HKEY_CLASSES_ROOT⇒.extension(확장자)⇒ShellNew키를 찾아 이를 다른 이름으로 바꾸면 된다. 지우려는 항목의 확장자를 잘 모를 때는 단축메뉴의 ‘새로 만들기’명령을 내려 확인해 보면 된다.
예를 들어, 새로 만들기 메뉴에 나오는 텍스트 문서 항목을 수행하면 ‘새로 만들기 텍스트문서'라는 파일이 만들어진다. 따라서 이 항목과 연결되어 있는 확장자가 TXT라는 것을 알 수 있다. 따라서 이 항목을 없애려면 HKEY_CLASSES_ROOT⇒.txt⇒ShellNew키를 찾아HKEY_CLASSES_ROOT⇒.txt⇒ShellNewSave와 같은 다른 이름으로 바꾸면 된다. 이제 오른쪽 마우스 버튼을 누르고 ’새로 만들기‘명령을 내리면 텍스트 문서 항목이 없어진 것을
확인할 수 있다.
22. 즉석 URL
인터넷 익스플로러에서 http://www. yahoo. com에 접속하고 싶을 경우 어드레스 박스에 www. yahoo. com만 입력해도 나머지는 자동으로 인식된다. 이런 스마트한 기능이 어디에 숨어 있을까? 이 설정 값은 레지스트리에 담겨 있다. 레지스트리 편집기를 실행해 HKEY_LOCAL_MACHINE⇒SOFTWARE⇒MICRO SOFT⇒windows⇒currentversion⇒url키로 이동해보자.Prefixes 키에서 www. ftp 등등의 엔트리를 볼 수 있을 것이다. 예를 들어 www의 값은 http://www이다. 일치하는 것이 없으면 인터넷 익스플로러는 자동으로 DefaultPrefix키에 있는 prefix를 사용한다.(일반적으로 http://)
이를 이용해 자주 들르는 사이트의 약어를 입력해 놓자. 예를 들어 http://www. yahoo. com사이트를 자주 이용한다면 prefix에 m이라는 이름을 가진 키를 등록하자. 값은 익스플로러의 어드레스 박스에 m만 입력하면 자동으로 yahoo사이트가 뜰 것이다.
23. 파일 시스템 성능 볼륨 업 [필수]
제어판-시스템-성능 탭을 클릭한 다음 파일 시스템 버튼을 클릭한면 하드디스크 탭의 시스템 용도박스에 세 개의 설정값(데스크탑, 이동 또는 도킹 시스템 네트워크서버)이 있다. 이 기능은 패스와 파일 이름 캐싱을 처리하는 메인 메모리를 얼마나 설정할 것인지 결정하는 것이다. 기본 값인 데스크탑을 선택하면 32개의 Path와 677개의 파일명을 캐시한다.
반면 네트워크 서버를 선택하면 64개의 Path와 파일명을 2,729개까지 캐시해준다. 그러므로 자신의 컴퓨터가 데스크탑 애플리케이션용으로 사용된다고 할지라도 캐시 기능을 높게 하려면 네트워크 서버를 선택하는 것이 좋다. 그러나 윈도우 95 오리지널 버전을 사용하고 있다면 윈도우 95 레지스트리에서 버그를 수정하기 위한 한 단계를 더 거쳐야 한다. 네트워크 서버를 선택하면 윈래 64개의 Path와 2,729개의 파일명을 캐시해주는데 실제로는 그 값이 뒤바꾸어 있으므로 레지스트리 편집기에서 Path와 Name 캐시를 서로 바꿔줘야 한다.
HKEY_LOCAL_MACHINE⇒Software⇒Microsoft⇒Windows⇒CurrentVersion⇒FS Templates⇒Server NameCache는 a9 0a 00 00로, PathCache는 40 00 00 00으로 바꾼다.
24. 프로그램의 설치 경로
HKEY_CURRENT_USER⇒InstalLocationsMRU 키는 윈도우 95의 각종 드라이버가 있는 경로를 지정한 값을 가지고 있다. 윈도우 95의 경우 CD-ROM 드라이브나 비디오나 프린터의 드라이버가 A: 인 이유가 여기에 있다.
25. 각종 하드웨어 정보
사용중인 윈도우 95에 등록되는 하드웨어 정보는 다음 키에 등록되어 있다.
HKEY_LOCAL_MACHINEEnumBIOS 바이오스
HKEY_LOCAL_MACHINEEnumCTLSB16 사운드 카드
HKEY_LOCAL_MACHINEEnumESDI 하드웨어 정보
HKEY_LOCAL_MACHINEEnumFLOP 플로피 디스크
HKEY_LOCAL_MACHINEEnumISAPNP ISA용 PnP 정보
HKEY_LOCAL_MACHINEEnumMF 컨트롤러 정보
HKEY_LOCAL_MACHINEEnumMonitor 모니터 정보
HKEY_LOCAL_MACHINEEnumPCI PCI 정보
HKEY_LOCAL_MACHINEEnumRoot 윈도우 95에 등록된 각종 시스템 정보
HKEY_LOCAL_MACHINEEnumSCSI 스카시 관련 정보
IRQ 진단
구식에다가 결코 완벽하지도 않고, 윈도우95CD 속에묻혀있지만‘마이크로소프트진단 프로그램‘은 그 어디에서도 찾아볼 수 없는 정보의 원천이다. 이 프로그램은DOS용이기 때문에 특히 윈도우를 전혀 실행시키지 못할 경우 IRQ 충돌을 진단하는데 편리하다.
이제 생각만 하지 말고 윈도우 95CD-ROM상의 OtherMsd폴더에서 Msd.exe를 찾아 부팅가능한 플로피 디스크에다가 복사해두자. 나중에 꼭 필요할 것이다.
26. '시작'메뉴에 있는 '실행'을 없애기
HKey_Current_User⇒Software⇒Microsoft⇒Windows⇒CurrentVersion⇒Policies⇒Explorer우측창에서 우측버튼을 클릭하고 New → DWORD 값을 클릭한 후 이름을 NoRun이라고 변경한 후 값으로 1을 준다
27. Windows95 설치파일의 위치를 변경하기
윈도우 95는 처음에 설치파일이 있던 곳을 기억하여 새로운 파일을 복사 할 경우 그 위치에서 찾는다. 윈도우95를 하드에 복사한 후 설치하였거나(CD-ROM보다 빠르다.)씨디룸의 문자열이 변경된 경우도 다시 한번 찾아보기에서 원본의 위치를 찾아주어야 할 때가 있다. 이럴 경우 여기를 변경하여 작업을 한번으로 줄여보자.
HKEY_LOCAL_MACHINE⇒SOFTWARE⇒Microsoft⇒Windows⇒CurrentVersion⇒Setup우측 창에서 SourcePath를 찾아 더블클릭 한다. 변경하고자 하는 위치로 바꾼다.
28. CD-ROM의 자동 실행을 막는 방법
윈도우 95용 프로그램이나 오디오CD를 넣으면 윈도우 95는 CD-ROM타이틀을 바로 실행한다. 이는 윈도우 95에 자동실행(AUTO PLAY) 기능이 내장되어 있기 때문이다. 이 기능을 제어하는 방법이 있다. 물론 CD를 삽입 한 후 Shift키를 누른다거나, 시스템 등록 정보의 CD-ROM등록정보에서 삽입자동통지 항목을 제거해 주어도 되지만 여기서는 레지스트리를 이용한 방법으로 해 보겠다. 꼭 해볼 필요는 없다는 얘기겠죠!
HKEY_CURRENT_USER⇒Softwear⇒Microsoft⇒Windows⇒CurrentVersion⇒Policies⇒Explorer를 선택한다. 오른쪽 창에서 NoDriveTypeAutoRun을 선택한 뒤 마우스의 오른쪽 버튼을 누른다. 나타나는 단축 메뉴에서 '수정'을 선택한다. 잠시 후 나타나는 이진값 편집 창에서 '95 00 00 00'을 'BD 00 00 00'으로 수정한다.
29. 원하는 모뎀 초기화 명령 이용하기
모뎀의 성능에서 초기화 명령이 끼치는 영향은 지대하다. 그러나 윈도우 환경에서 사용자가 원하는 초기화를 제대로 이용할 수 없다. 물론 이야기97 같은 프로그램에서는 바람잡이를 이용하여 사용자가 원하는 초기화 명령을 사용할 수 있다. 하지만 인터넷을 이용할 때에는 이야기97에서 이용되던 초기화와는 달리 자체의 값으로 초기화를 하게 된다. 이렇게 이용되는 초기화는 레지스트리 편집기를 통해 사용자가 원하는 대로 변경할 수 있다.
HKEY_LOCAL_Machine⇒System⇒CurrentControlSet⇒Services⇒Class⇒Modem⇒0000⇒Init Init에 오른쪽 버튼을 눌러 나타나는 메뉴에서 ‘등록→문자열 값’을 지정하면 ‘New Value #1'이라는 항목이 나타나게 되는데 이 부분을 ’3‘ 으로 고친다. 그리고 이 ’3‘을 마우스로 더블클릭하거나 를 누르면 이용되는 값을 입력하는 화면이 나타나게 되는데 여기서 사용자가 이용하고자 하는 초기화 명령을 지정해 주면 된다. 주의할 점은, 모뎀의 상태를 보여주는 명령이나 정보를 보여주는 명령을 제외하고 입력해야 한다는 것이다. 입력을 마친 다음 맨 끝 부분에는 '' 이라고 반드시 입력해 주어야 한다.
30. 뚱뚱해진 레지스트리 최적화하기
레지스트리 정보는 윈도95 폴더에 있는 System.dat 파일과 User.dat 파일에 저장되어 있다. 그런데 문제는 윈도우를 실행할 때마다 이 파일의 크기가 조금씩 늘어난다는 점이다. 윈도우를 설치한 뒤 오랜 시간이 지나면 레지스트리 파일의 크기가 처음 설치했을 때 보다 엄청나게 커진 것을 볼 수 있는데 ,이렇게 크기가 늘어나는 것은 사용자가 응용 프로그램을 설치하고 지우는 동안 저장된 내용이, 프로그램의 삭제나 언인스톨에도 불구하고 레지스트리에 저장된 응용 프로그램과 하드웨어에 관한 정보가 완벽하게 삭제되지 않기 때문이다. 이런 경우 , 별도의 응용 프로그램을 이용하여 레지스트리에서 쓸모없는 정보를 삭제해 주어야 한다. 여러 가지 응용 프로그램 중에서 너츠 앤 볼츠(Nuts & Bolts) 라는 프로그램이 가장 효과적이다. 이 프로그램을 설치하면 여러 가지 응용 프로그램이 나타나게 된다. 그 중에서도 레지스트리 위자드(Wizard)라는 프로그램을 이용하면 레지스트리 파일에 대해 다양한 설정을 할 수 있다.
이 프로그램을 실행한 다음 하단에 있는 튠-업(Tune-up)항목을 지정하면 자동으로 레지스트리 파일의 불필요한 부분을 찾아 삭제하는 작업이 진행된다. 간단히 비대해진 레지스트리 파일이 최적화 된다. 단, 주의할 것은 이프로그램을 실행하기 전에 사용자가 사용하는 인터넷의 IP어드레스와 이용자 ID, 비밀번호 등을 다른곳에 저장해두는 것을 잊지 말아야 한다. 이 프로그램이 사용자가 이용하는 인터넷에 대한 정보까지 삭제하기 때문이다.
31. 내컴퓨터의 오른쪽 버튼을 바꾸자.
윈도우95에서 하나의 프로그램을 실행할 수 있는 방법은 무수리 많다. 가장 많이 사용하는 방법이 시작메뉴를 이용하는 것이며, 때론 시작메뉴의 실행을 이용해 원하는 프로그램을 실행하거나 바탕화면의 내컴퓨터를 이용하기도 한다. 그것이 폴더 창일 수도 있고, 탐색 창일 수도 있다. 또는 도스에서 실행하기도 한다. 만일 자주 사용하는 프로그램이 있다면 내컴퓨터의 오른쪽 버튼을 통해 좀더 빨리 실행할 수도 있다. 여기선 예를들어 새롬데이타맨프로를 내컴퓨터 오른쪽 버튼으로 실행하는 방법을 알아보자.
HKEY_CLASSES_ROOT⇒CLSID⇒{20D04FE0-3AEA-1069-A2D8-08002B30309D}⇒shell의 하위로 shell위에서 오른족버튼-등록-키에서 ‘새롬 데이터’라고 입력한다. 만들어진 ‘새롬 데이터’ 값에서 다시 오른쪽-등록-키에서 ‘command'키를 만든다. 오른쪽 기본값을 눌러 새롬데이타맨 프로가 설치되어 있는 디렉토리 위치를 (예. c:dmprodmpro.exe)적어준다. 이제, 내컴퓨터에서 오른쪽 버튼을 누르면 새롬데이타가 보일 것이다.
32. 윈도우 시작시 실행되는 프로그램 제거
시작 프로그램에는 윈도우95가 시작되면서 자동으로 실행될 프로그램이 등록된다. 이 프로그램들은 윈도우95의 바탕화면이 나타나면서 동시에 실행되기 때문에 속도를 즐이는 역할은 물론 시스템이 이용하는 메모리를 차지하게 된다. 그런데 시작 프로그램에도 등록되어 있지않는 프로그램은 어디에 있을까? 응용 프로그램을 설치하다 보면 WIN.INI파일의 RUN부분이 아닌 레지스트리의 RUN= 부분에 등록되어 자동으로 실행되는 경우가 있다. 이럴 경우
HKEY_LOCAL_MACHINE⇒SOFTWARE⇒Microsoft⇒Windows⇒CurrentVersion⇒run을 찾아가면 화면 우측에 자동으로 실행되는 프로그램 목록이 나타난다. 여기서 자신에게 필요없는 프로그램을 삭제 해 주면 된다.
33. MTU를 수정해 인터넷 속도 높이기
MTU(Maximum Transmission Unit)를 조정하면 약간이나마 인터넷의 접속 속도를 향상시킬 수 있다.(사실 체감속도는 입증안되는 것 같다.)
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesClassNetTrans002로 이동한다. 0002에서 오른쪽버튼-등록-문자열값을 선택하여 새로운 문자열 값으로 ‘MaxMTU'라고 입력한다. MaxMTU를 더블클릭하여 ’값의 데이터‘에 ’576‘을 입력함으로써 MSS(Maximum Segment Size)의 크기를 ’576‘으로 설정해 준다. 다시 Service 폴더아래 ’Vxd⇒MSTCP'폴더로 이동한다. 이 폴더에서 오른쪽 버튼-등록-문자열 값을 선택하여 새로운 문자열 값으로 ‘DefaultRcvWindow'를 입력한다. 이 문자열의 값으로 ’2144‘를 입력해준다. 시스템을 재부팅 하면 속도가 높아진 것(?)을 느낄 수 있을 것이다.
전문 유틸리티를 이용한 레지스트리 편집
♣ 윈해커95 2.0 (http://www.winhacker.com/)
윈해커95 버전2.0은 이용자 정보를 몇가지 입력해야 제대로 쓸 수 있어서 조금은 번거롭다. 하지만 같은 일을 하는 프로그램들과는 비교할 수 없을 만큼 편리한 기능을 가지고 있다 기본 화면은 윈도우95에 있는 탐색기와 비슷하다. 왼쪽 창에 여러 항목이 자리잡고 있고, 오른쪽에는 왼쪽에서 선택한 항목의 세부 내용을 보여주는 그림이 있다.
1. 익스플로러 (Explorer)
윈도우 탐색기와 관계된 부분이다. 여기에는 확장자의 내용을 소개하는 ‘파일 타입’과 특정 드라이브가 화면에 보이지 않도록 하는 ‘하이드 드라이브’가 있다.
‘메뉴 아이템’은 파워토이에 있는 ‘도스 프롬프트 히어’나 ‘익스플로러 히어’등의 기능이 있고, ‘숏컷’은 단축 아이콘의 모양과 표시방법을 ‘비주얼’은 Bmp 확장자를 갖는 그림 파일의 아이콘 모양을 바꾼다. 마우스로 오른쪽 창에 있는 on 과 off를 고르면 된다.
2. 쉘 (Shell)
시스템을 켰을 때 작업 표시줄에 나타나는 ‘시작하려면 여기를 누르십시오’ 메시지가 눈에 거스릴 때는 ‘Animated "Click Here to Begin" at startup'을 선택한 뒤 오른쪽 창에 있는 off를 누르면 메시지가 없어진다. 또 CD를 넣으면 자동으로 음악이 흐르는 ’자동 플레이‘와 바탕 화면 디렉토리 설정, 그날의 팁 보기, 윈도우즈 애니메이션 켜기 등을 없애거나 바꿀 수 있다.
3. 데스크 탑 (Desktop)
바탕화면에 있는 시스템 폴더를 원하는 곳에 넣는 일을 한다. 원하는 시스템 파일을 마우스 하나로 바탕화면이나 내컴퓨터, 시작 메뉴에 쉽게 넣을 수 있다.
4. 스타트 메뉴 (Start Menu)
'메뉴 스피드‘는 시작 메뉴의 이름을 바꿀 수 있다. 영문 윈도우즈95의 Start라는 시작메누 이름을 바꾸려면 ’스타트 메뉴 타이틀‘을 누르고 새로운 단어를 입력한다. 단 5글자 내의 영문만 쓸 수 있다.
5. 스타트업 (StartUp)
루트 디렉토리의 msdos.sys파일의 내용을 수정해서 윈도우95의 부팅을 이용자 마음대로 바꾸는 메뉴다. 여기에는 윈도우95/도스 부팅 선택, 부팅 대기시간 설정, 부팅때 로그 파일 생성, 이전 도스로 부팅하기 등이 있다.
6. 시스템 (System)
제어판의 프로그램 추가/삭제를 써서 프로그램을 지웠는데도 화면 어딘가에 아직 그 프로그램이 남아있을 때, 시스템 작동에 문제가 생길 때 울리는 ‘삐삐’소리가 듣기 싫으면 ‘비프 온 시스템 에러’를 off로 한다. ‘셋업’의 ‘태스크 메니저’는 작업 관리자에 나타나는 프로그램의 행과 열의 수를 바꿀 때 이용한다. 또 윈도우95의 이용자 등록정보를 바꿀 수 있다.
♣ 셋미업 (http://www.omniquad.com/)
'셋미업‘은 윈해커와 비슷한 인터페이스를 가지고 있다.
1. 시스템 스타트업 (System StartUp)
부팅과 관련된 여러 가지 옵션을 설정하는 메뉴다. 시작 프로그램에 남아있는 필요없는 정보를 삭제 할 수 있다.
2. 로고 (Logos)
켜지거나 꺼질 때의 로고 화면을 마음대로 바꾸는 항목이다.
3. General
윈도우 설치 디렉토리 변경, 이용자 등록정보 변경, 그날의 팁등을 꾸밀 수 있다.
4. Explorer
시스템 폴더의 위치를 옮기는 아이템이다. 비트맵 파일을 아이콘으로 보기. 시작메뉴의 속도 조절하기 등의 작업을 할 수 있다.
5. 유지 (Maintenance)
시스템 성능을 유지하고 문제가 생기면 이를 고칠 수 있도록 도와주는 항목이다.
6. 윈도우 툴과 시스템 세이버
윈도우나 시스템 디렉토리에 기본으로 설치되어 있지만 메뉴에 등록되지 않아서 눈에 띄지 않는 sysdit.exe, regedit.exe, grpconv.exe등의 유틸리티들을 수행하는 곳이다.
시스템 세이버는 시스템에 반드시 있어야 하는 프로그램을 백업하는 유틸리티다.
7. 보호
허술한 윈도우95의 보안상태를 강화하기 위해 자체적으로 암호를 설정하는 곳이다. 윈도우95가 부팅될 때 암호가 든 화면보호기가 뜨도록 할 수 있다.
8. 로그온
여러 이용작가 시스템에 접속하면 그 사람의 정보와 접속 시간을 문서 파일로 저장해 준다. 이 데이터만 보면 어떤 사람이 언제 작업했는지 알 수 있다.
처음에도 언급했지만 레지스트리는 잘못 만지면 윈도우를 다시 설치해야 하는 불상사(?)가 발생할 지도 모른다. 그런 일이 생기면 다음과 같이 해 보자.
※레지스트리의 복구******************************
윈도우 95는 가장 중요한 파일인 시스템 레지스트리의 파일(system.dat 와 user.dat)의 백업파일을 자동으로 만들어 주는데 이것이 system.da0와 user.da0이다.
복구하는 요령은 시작→ 시스템 종료→MS-DOS 모드에서 재시작을 선택한 후 ‘예’ 누름.
도스상태에서 C:windows로 가서
C:windows>attrib -h -r -s system.dat
attrib -h -r -s system.da0
copy system.da0 system.dat
attrib -h -r -s user.dat
attrib -h -r -s user.da0
copy user.da0 user.dat
이 작업이 끝난 후 반드시 속성을 원래대로 해 놓는다.
attrib +h +r +s system.dat
attrib +h +r +s user.dat
만일 이 두 파일조차 손상되어 복구가 불가능한 경우에는 system.1st 파일을 이용하는 방법이 있다. system.1st는 윈도95가 처음 설치될 때 만들어진 시스템 레지스트리 파일이다. 따라서 망가지기 바로 전의 상태로 복구하는 것은 불가능하지만, 윈도 95를 다시 설치하는 것보다는 훨씬 낫다. 도스 프롬프트 상태에서 다음과 같이 입력하면 된다.
c:>attrib -h -r -s c:system.1st
copy c:system.1st c:windowssystem.dat
attrib +h +r +s c:system.1st
attrib +h +r +s c:windowssystem.dat
-----------------------------------------------
윈도우 환경과 프로그램에 관련된 사항 등이 저장된 system.dat, user.dat 파일이 바로 레지스트리이다. 윈도우와 프로그램에 관련된 사항은 레지스트리 외에도 win.ini, system.ini 파일을 비롯한 각종 INI 파일에도 저장되지만, INI 파일들은 텍스트로 되어 있어 속도가 느리고 쉽게 고칠 수 있어 보안에 문제가 있다. 또, 16비트 프로그램을 위한 여러 개의 INI 파일이 존재하긴 하지만 윈도우의 표준을 지키는 32비트 프로그램에 관련된 설정값은 모두 WINDOWS 디렉토리에 있는 레지스트리 파일에 저장된다.
레지스트리는 텍스트가 아닌 16진수로 되어 있어 INI 파일보다 속도가 빠를 뿐 아니라 전용 프로그램(레지스트리 편집기, regedit.exe)을 이용하지 않으면 고칠 수 없다. 그리고 모든 프로그램 설정이 하나의 레지스트리에 저장되기 때문에 관리가 용이하다.
레지스트리에 있는 6개의 루트키에 저장된 내용
윈도우 레지스트리는총 6개로 구성되어 있습니다. [시작]-[실행]을 누른 뒤 빈칸에 'regedit'라고 입력하고 를누르면, 윈도의 레지스트리 내용을 보거나 편집할 수 있는 화면이 나옵니다. 이 화면이 바로 윈도의 [레지스트리 편집기]입니다. 마치 윈도 탐색기를 실행한 것과 같은 화면이므로 쉽게 이해할 수 있을 것입니다. 각각의 루트 키의 이름은 HKEY_로 시작됩니다. 이것은 'Key Handle'의 약자로 고유한 식별표지라고 생각하면 됩니다.
1. HKEY_CLSSES_ROOT
이 루트키에 해당하는 정보는 system.dat 파일에 저장됩니다. 윈도에서 사용하는 각종의 파일 정보가 기록됩니다. 따라서 임의로, 새로운 파일 확장자를 만들려면 이 루트 키를 편집해야 합니다. 파일 종료와 등록정보, 아이콘 이름 등이 기록되며, 마우스 오른쪽 단추에 입력되는 정보를 함께 기록하고 있습니다. 또한 ActiveX 구성 요소에 대한 정보도 들어 있습니다.
2. HKEY_CURRENT_USER
이 루트키에는 현재 로그인 중인 사용자에 대한 등록정보가 기록됩니다. 또한 응용 프로그램의 우선 순위, 화면색상, 보안 접근 허용 여부 등에 대한 정보도 담고 있습니다. 키의 하위 디렉터리를 열면 나타나는 서브키에는 특정한 상황에서 나오는 사운드 효과, 제어판 설정, 응용 프로그램이 최근에 설치된 위치, 키보드 레이아웃, 현재 사용자의 소프트웨어 설정 상태 등에 대한 정보가 담겨 있습니다.
3. HKEY_LOCAL_MACHINE
이 루트키는 사용자들이 가장 많이 접해 보았을 것입니다. 특히 게임을 즐기는 독자라면 베틀넷 등에서 접속 순서등을 바꾸기 위해 한 번쯤 들어가본 적이 있을 겁니다. 이 키에 있는 구성 값은 system.dat 파일에 기록됩니다. 이 키에는 사용 중인 하드웨어 및 소프트웨어에 대한 모든 정보가 기록됩니다. 하드웨어 구성 초기화 파일을 모아놓았기 때문에 제어판과 긴밀히 연관되며, 간단한 레지스트리 편집은 대부분 이 루트키 값을 바꾸는 것부터 시작합니다.
4. HKEY_USERS
이 키는 HKEY_CURRENT_USER와 비슷하지만, 전에 로그인했던 사용자들을 위해 이전 사용자 초기화 파일을 보관하고 있다는 점이 다릅니다. 만약 두 키 사이에 비슷한 내용이 있다면 HKEY_CURRENT_USER가 우선권을 가집니다.
5. HKEY_CURRENT_CONFIG
현재 사용중인 윈도의 디스플레이(화면 글꼴이나 해상도) 정보와 프린터 관련 정보를 가지고 있는 키입니다. 관련 정보는 system.dat 파일에 기록됩니다.
6. HKEY_DYN_DATA
윈도에서 사용하는 정보 중에서 메모리에 기록되어 빠르게 입.출력해야 하는 경우가 있습니다. 메모리에 기록되는 모든 정보는 이 루트 키에 기록되며, 윈도가 부팅할 때마다 새로운 값으로 바뀝니다.
레지스트리 백업하고 복구하기
레지스트리를 잘못 만지면 윈도가 치명적인 상처를 입어 PC가 제대로 작동하지 않습니다. 따라서 편집하기 전에 반드시 레지스트리를 백업해 놓습니다. 편집 작업이 끝난 뒤 시스템이 말썽을 부리면 백업해 놓은 것을 되살립니다.
1. 레지스트리 편집 창 띄우기
레지스트리를 편집하려면 [레지스트리 편집기]를 띄웁니다. [레지스트리 편집기]창을 열려면 [시작]-[실행]을 선택한 후 빈칸에 'regedit'라고 쓰고 [확인]단추를 누릅니다.
2. 레지스트리 백업하기
[시작]-[실행]을 눌러 창을 연뒤 [실행]칸에 'scanregw'라고 쓰고 [확인]단추를 누릅니다. 그러면 'C:WindowsSysbckup' 폴더에 백업 파일이 생깁니다. 백업 파일은 모두 5개가 보관됩니다. 이름은 rb001.cab, rb002.cab... 등입니다. 5개의 백업 파일이 있는 상태에서 레지스트리를 백업하면 날짜가 가장 빠른 것이 사라지면서 새파일이 저장됩니다. 이제 레지스트리를 백업해 봅시다.
1)[시작]-[실행]을 눌러 창을 띄운 뒤 [열기]칸에 'scanregw'라고 쓰고 [확인]단추를 누릅니다.
4)방금 백업한 레지스트리가 'rb005'라는 이름으로 'C:WindowsSysbckup' 폴더에 생겼습니다.
3. 레지스트리 되살리기
레지스트리를 되살리는 일은 DOS에서 합니다. 윕도 부팅 디스크로 스스템을 켠뒤 도스로 들어가서 'scanreg/restore' 라고 입력하고 를 누릅니다. [Microsoft Registry Checker]가 뜨면서 'sysbckup' 폴더에 있는 rb001.cab, rb002.cab등의 백업 파일을 보여주면, 날짜가 가장 최근인 것을 고르고 를 누릅니다. 그러면 레지스트리가 복구됩니다.
시작메뉴 편집하기
시작 메뉴에서 프로그램 그룹 삭제하기
윈도의 [시작]버튼을 누르면 즐겨찾기, 실행, 문서 등의 여러 가지 메뉴를 볼 수 있다. 일반 응용 프로그램이나 유틸리티들을 설치하면 프로그램 메뉴 항목에 등록되는데, 이 항목을 없애보자.
키 : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoCommonGroups
기본값 : 1
시작 버튼메뉴의 팝업 속도 올리기
시작 버튼에 있는 메뉴에 마우스 포인터를 위치시키면 약 1초 정도 시간이 흐르고 난 후에야 메뉴가 펼쳐진다. 이 지연 시간을 없애고 시작 버튼 메뉴가 빠르게 열리도록 하는 방법이 있다.
키 : HKEY_CURRENT_USER\Control Panel\desktop
문자열 : MenuShowDelay
기본값 : 0
* 반대로 기본값으로 65535를 입력하면 마우스로 클릭해야만 메뉴가 나타난다.
시작 버튼 메뉴의 항목 바꾸기
자주 실행하는 프로그램을 '빠른 실행' 에 등록하거나 바탕화면에 등록해 놓지 말고 시작버튼의 마우스 기능을 활용해보자. 즉, 시작 버튼 위에서 마우스 오른쪽 버튼을 눌렀을 때 나타나는 메뉴에 자주 실행하는 프로그램을 마음대로 등록시킬 수 있다.
① HKEY_CLASSES_ROOT\Directory\Shell 으로 이동한 다음, 등록할 프로그램의 이름을 서브키 로 등록하자. (예. 새롬 데이터맨)
② 등록한 키 아래에 'command' 라는 서브키를 하나 더 만들고, 기본값으로 해당 프로그램의 경로
(ex> c:\dataman98\dataman.exe)를 정확하게 입력해 준다.
'로그오프' 메뉴 없애기
시작 버튼에 등록되어 있는 '로그오프' 메뉴를 없애보자.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoLogOff
기본값 : 1
'즐겨찾기' 메뉴 없애기
윈도의 시작 메뉴에서 괜히 자리만 차지하고 별 쓸데가 없는 즐겨 찾기 메뉴를 없애보자.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoFavoritesMenu
기본값 : 1
'찾기' 메뉴 없애기
찾기 메뉴 역시 시작 버튼에서 나타나지 않게 할 수 있다.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoFind
기본값 : 1
'실행' 메뉴 없애기
실행 메뉴를 시작 버튼에서 없애려면 다음과 같이 한다.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoRun
기본값 : 1
'문서' 메뉴 없애기
문서 메뉴를 보이지 않게 만들면 다른 사람들에게 자신이 어떠한 문서를 작업했는지 흔적을 남기지 않는다.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoRecentDocsMenu
기본값 : 1
'시스템 종료' 메뉴 없애기
시작 버튼에 등록된 시스템 종료 메뉴까지 없애보자. 시스템 종료 버튼을 없애면 버튼을 눌러 시스템을 종료하여야 한다.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoClose
기본값 : 1
'제어판', '프린터' 메뉴 없애기
시작 버튼에는 '제어판' 과 '프린터' 메뉴가 있는 설정 항목이 있다. 이를 없애는 방법은 다음과 같다.
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
DWORD : NoSetFolders
기본값 : 1
설정메뉴 편집
'액티브 데스크톱' 항목 삭제하기
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies \Explorer
이진값 : NoSetActiveDesktop
기본값 : 01 00 00 00 (다시 보이게 하려면 '00 00 00 00')
'작업 표시줄 및 시작 메뉴' 항목 삭제하기
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
이진값 : NoSetTaskbar
기본값 : 01 00 00 00 (다시 보이게 하려면 '00 00 00 00')
'윈도 업데이트' 메뉴 삭제하기
키 : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
이진값 : NoWindowsUpdate
기본값 : 01 00 00 00 (다시 보이게 하려면 '00 00 00 00')
휴지통 편집
휴지통 이름 바꾸기
휴지통은 다른 아이콘과는 달리 레지스트리를 편집하지 않는 이상 이름을 바꿀 수 없다. 휴지통이라는 이름이 실증난다면 '쓰레기통'이라는 이름으로 바꿔보자.
키 : HKEY_CLASSES_ROOT/CLSID/{645FF040-5081-101B-9F08-00AA002F984E}
기본값 : 바꿀 문자열(예. 쓰레기통)
휴지통 메뉴에서 '이름 바꾸기'와 '삭제' 추가하기
앞에서 설명한 휴지통 이름을 더욱 쉽게 이름을 바꾸는 방법을 소개한다. 휴지통 아이콘을 삭제시키는 메뉴를 만들 수도 있다.
키 : 'HKEY_CLASSES_ROOT\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\ShellFolder
이진값 : Attributes
기본값 : 70 01 00 20
휴지통 메뉴 추가하기
이번에는 휴지통 메뉴에 복사, 잘라내기, 붙여넣기 등의 메뉴를 추가해보자.
키 : 'HKEY_CLASSES_ROOT\CLSID{645FF040-5081-101B-9F08-00AA002F954E}\ShellFolder
이진값 : Attributes
기본값 : 47 01 00 20
시스템 편집
윈도 9x의 설치 경로 바꾸기
윈도 9x의 설치 경로를 기본 C:\windows 가 아닌 다른 경로로 바꿔서 윈도의 구성 요소를 추가로설치하려할 때 어려움이 생길 수 있다. 이러한 경우에는 레지스트리에 기록된 윈도 9x의 설치 경로를 직접 수정해 주면 문제를 해결할 수 있다.
키 : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup
문자열 : SourcePath
기본값 : 변경하고자 하는 경로
탐색기 내용을 자동으로 새로 고침
현재 열려진 폴더에 새로운 파일을 복사했을 때 새로 고침(Refresh)가 늦어서 일일이 키를 눌러 현재까지 복사된 내용을 확인하는 이들이 많을 것이다. 새로 고침을 자동으로 해주는 기능을 이용해보자.
키 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Update
이진값 : UpdateMode
기본값 : 01 → 00
레지스트리에 등록된 시작 프로그램 지우기
새로 프로그램을 설치했을 경우, '프로그램' → '시작 프로그램' 에 단축 아이콘이 등록이 되어서 자동으로 시작되는 프로그램이 있는 반면, 레지스트리에 등록이 되어서 이래저래 지우지도 못하는 프로그램들이 있다.
이럴 때는 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\'로 이동해서 'Run, RunOnce, , RunOnceEx, RunServices, RunServicesOnceun'와 같은 서브키를 찾아보자. 이러한 키 값들 안에 등록되어 있는 문자열 값들이 레지스트리에 등록된 시작 프로그램들인데 더 이상 필요 없는 프로그램을 삭제하면 다음부터는 시동과 함께 프로그램이 실행되는 것을 막을 수 있다.
윈도우의 에니메이션 효과 없애기
윈두오에서 프로그램 창을 축소하거 확대할 때 창이 늘어나고 줄어드는 것이 보이는 애니메이션 효과를 없애 보겠다. 시스템 자원이 부족해 윈도우의 속도가 느린 사용자라면 윈도우의 속도를 향상시키는 데 상당한 효과를 볼 수 있다.
키 : 'HKEY_CURRENT_USER ⇒ Control Panel ⇒ desktop ⇒ WindowsMetrics' 로 이동한다.
문자열 : MinAnimate
기본값 : 0
윈도우 98 등록번호 알기
윈도 98 의 등록번호는 95 와는 달리 '시스템 등록정보'에 나오지 않는다. 가지고 있었던 윈도 98 원본 CD의 등록번호를 잊어버렸다면 정말로 낭패인데, 임시 방편으로 레지스트리를 이용해 이를 알 수 있다. 다음 항목의 내용을 잘 기억해두자.
키 : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
문자열 : ProductKey
윈도 사용자 등록하지 않고 윈도 업데이트 사용하기
윈도 98이 출시되면서 새롭게 도입된 윈도 업데이트는 사용자 온라인 등록을 해야 사용할 수 있다. 하지만 개인 정보가 유출된다는 꺼림직한 기분에 사용자 등록을 하지 않는 이들이 있다. 레지스트리 수정으로 등록을 하지 않고도 윈도 업데이트를 할 수 있는 방법을 소개한다.
① HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion으로 이동해서 'RegDone' 라는 문자열 이름을 새로 등록한다. 만든 문자열 이름을 더블클릭해서 값의 데이터에 '1'을 입력한다
② HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Welcome\ 으로 이동해서 RezWiz 라는 서브키 값을 새로 하나 만든다.
③ 이 작업으로 사용자 등록 절차를 거치지 않아도 윈도 업데이트 기능을 사용할 수 있다
화면보호기 나타나는 시간 늘리기
모니터를 일정시간 이상 쓰지 않으면 자동으로 화면보호기가 실행되게 되어있다. 설정하기 나름이지만 이 화면보호기를 실행시키도록 해 놓았다면, 설정시간은 1분에서 60 분으로 제한되어 있다. 이 제한된 시간을 레지스트리 수정으로 더욱 늘릴 수 있다.
키 : HKEY_CURRENT_USER\ControlPanel\desktop
문자열 : ScreenSaveTimeOut
기본값 : 시간(초단위로 입력한다. 예를 들어, 35분 후에 화면보호기를 실행하려면 35×60=2100이므로, 2100을 입력한다)
CD-ROM의 자동 실행을 막자
윈도 9x용 프로그램이나 오디오 CD를 넣으면 자동으로 재생되는 자동실행 기능은 때에 따라 불편할 때가 있다. 자동실행 기능이 동작하지 않도록 해보자. 물론 키를 누른 채로 CD를 넣어도 자동실행 기능은 동작하지 않는다.
키 : HKEY_CURRENT_USER\Softwear\Microsoft\Windows\CurrentVersion\Policies\Explorer
이진값 : NoDriveTypeAutoRun
기본값 : 95 00 00 00 → BD 00 00 00
모니터 절전 시간 늘리기
절전 모니터를 가지고 있다면 '제어판' → '디스플레이' 등록정보에 있는 화면 보호기 탭의 '모니터 절전 기능'에서 일정 시간이 지나면 전력을 떨어뜨리는 '전력 저하 대비'와 전원을 완전히 차단해주는 '모니터 끄기' 기능을 설정할 수 있다. 그러나 이 기능은 1~60분 사이에 시간에서만 설정할 수 있다. 하지만 레지스트리의 내용을 편집하면 절전 기능 시간의 적용을 늘릴 수 있다.
기본값 : ScreenSaveLowPowerTimeout(전력 저하), ScreenSavePowerOffTimeout (모니터 끄기) 단위는 초로 입력.
설치한 프로그램은 프로그램 추가/제거를 통해 제거하거나 자체의 UNINSTALL을 이용해서 제거해야 합니다. 그래야 레지스트리에도 흔적이 남지 않습니다.
다만 흔적이 남는 것은 레지스트리 편집기를 통해 없앨 수 있습니다.
레지스트리편집기를 실행시킵니다.
(시작버튼을 누르면 보이는 '실행'이라는 것을 누른 후 'regedit'를 입력합니다)
1. HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft - Windows - CurrentVersion - Uninstall 키를 찾아 더블클릭합니다.
2. Uninstall 키의 하위키 목록은 제어판의 '프로그램 추가/제거'목록에 남아 있는 삭제한 프로그램의 이름을 가지고 있는 키를 마우스 오른쪽 단추로 누른다음, 삭제를 선택하면 됩니다.
SLR 클럽의 회원이 된지 2년이 다되어 가면서 그 동안 받아먹기만하여서 미안함이 항상 맘 한편에 있었습니다. 더구나 요즘들어 사용기나 강좌에 "보은"을 빙자한 글들이 속속 올라오면서 뭔가는 해야겠다는 생각을 했지만 뭐 제대로 하는게 있어야 말이죠.
그동안 SLRCLUB에서 공짜로 배운지식 중 가장 도움이 되었던 것이 포토샵을 이용한 사진보정 이어서 클럽의 보정방에서 시간이 날때마다 연습을 하곤합니다. 보정방에 사진보정을 맡기신 대부분의 회원님들께서 하시는 말씀이 "포토샵 배워야 될 텐데..."입니다. 그말은 제가 1년전에 쓰던 말이기도 하구요. 여전히 초보딱지는 가슴에...
학원까지 다니면서 포토샵을 배우기에는 좀 그렇고 책방에서 간단한 포토샵 책을 하나 사봤지만 사진 보정하고 관련있는 기술은 못찾겠고... 그래 원본이 좋으면 보정은 필요없어 라며 스스로를 위로해 보지만 찍어준 사진 주지도 못하고 한숨만 쉬어본 아픈 기억이 발로 사진 찍는 우리 초보들에겐 다 있을겁니다.
그래서 강좌를 보면서 공부를 시작해 보겠다고 하나 이거 어디부터 시작해야 하는지도 모르겠고 뭘 좀 물어보면 돌아오는 답은 그저 "강좌에 있으니 검색해 보세요....검색의 생활화!!!" OTL "단어를 알아야 검색을 하지??" 많은 분들이 동감하시리라 생각해봅니다. 아니면 대략난감.... -_-
강좌 검색난에 "포토샵" 이라고 검색하면 대략 400개 정도의 강좌가 떠오릅니다. 흠...쪼까 많구먼... 그래서 제가 그동안 스크랩해놓은 강좌들을 간단히(?) 정리하여 리스트를 작성해봤습니다. 대충 70개쯤 되는군요. 여전히 많아 보이기는 하지만 주제별로 정리를 해놨으니 필요한 곳으로 GoGo...
여기에 있는 강좌들은 제가 아주 주관적인 입장에서 비슷한 여러 강좌중 한 두개씩만 뽑은 리스트들입니다. 물론 여기에 없는 강좌중에 주옥과 같은 강좌들이 더 많이 있구요. 똑같은 주제에 대해서 다루었지만 보정방법은 천차만별이기에 제목을 검색하면 비슷한 강좌들이 주루룩 뜰겁니다.
컴맹이다보니 그냥 주소를 그대로 올렸습니다. (주소를 클릭하면 해당 강좌가 열립니다.) 아래 있는 작가분들은 강좌 연작(10강좌 이상)을 하시는 분들입니다. 포토샵뿐 아니라 사진에 관한 전반적인 좋은 강좌들이 있어서 좋아하시는 스타일의 작가분을 검색해서 시리즈물을 공부하는 것도 좋을듯 해서 올려 봤습니다. 저는 그분들 중 어느 누구와도 개인적인 친분이 없습니다.
다시 한번 강조하지만 여기에 오르지 못한 더 자세하고 좋은 강좌들이 많이 있습니다. 그 작가분들이 섭섭해 하지 않았으면 합니다.
포토샵이라는게 공대를 다니신분들은 아시겠지만 그래프가 나오는 공학용계산기마냥 다루기가 복잡무식 해서 쓰지 않으면 사용방법을 잊어먹고 두꺼운 메뉴얼을 자꾸만 열어보는 것 처럼 쓰지않는 보정기법들은 잊어버려서 헤매기도 하더군요. 그래서 저는 제 스크랩을 자주 활용하게 됩니다. 제가 해놓은게 없기에 감히 추천이나 리플은 기대하지도 않지만 포토샵을 공부하는 많은 분들이 이 글을 스크랩해서 잘 활용하셨으면 합니다.
과거에는 온라인 쇼핑몰의 무형상품 거래가 공연티켓이나 여행상품을 매매하는 수준에 그치던 데 비해 최근에는 콘텐츠 유통에 강한 온라인의 특성을 살려 만화나 영화, 동영상강의 등 창작물부터 게임아이템까지 적극적으로 사업 영역을 넓혀가고 있는 것.
29일 관련 업계에 따르면 오픈마켓 G마켓은 인기 잡지와 운세보기, 영화 및 케이블방송, 만화 등 엔터테인먼트 콘텐츠, 교육 콘텐츠 등 다양한 무형상품을 `C2마켓` 카테고리를 통해 선보이고 있다.
메이크업과 요리 등 실생활에 유용한 생활정보를 전문가가 동영상으로 제작한 생활강좌 역시 회당 1천원선에 구입해 시청할 수 있다.
`C2마켓` 카테고리는 하루 평균 5만명 이상의 고객이 이용할 정도로 큰 호응을 얻고 있다.
오픈마켓 엠플은 최근 게임아이템 거래 서비스를 시작했다.
엠플은 무형상품 거래와 정보 제공 확대 차원에서 기존 업계에서 5% 상당 받던 수수료를 전면 무료화했다. 아울러 사업자 회원이 아닌 개인간 거래만 가능하도록 해 불법성을 차단하고, 구매확인 이후에 판매자에게 대금이 지급되는 에스크로 시스템을 적용해 거래 안전성을 높였다.
인터넷 쇼핑몰 인터파크에는 일대일 실시간 화상강의를 통해 원어민에게 직접 외국어를 배울 수 있는 `토크빈` 상품이 있다.
토크빈은 서비스 시작 당시 유형상품 거래에만 적용되던 C2C(소비자간) 기반의 오픈마켓 거래방식을 언어학습에 적용한 새로운 비즈니스 모델로 화제를 모았다.
고객들은 마음에 드는 강사를 자유롭게 선택할 수 있으며, 일대일 수업방식으로 관심 분야에 대한 깊이 있는 대화를 나눌 수도 있다.
토크빈은 또한 영어와 정보를 배울 수 있는 `화제의 UCC(손수제작물)`, `광고로 공부해요`, `무비잉글리시` 등 다양한 지식코너도 운영해 일반 교육포털 못지않은 콘텐츠를 갖췄다.
오픈마켓 옥션 역시 지난달부터 교육 콘텐츠 카테고리를 신규 오픈했다. 향후 토익과 토플, 영어회화 등으로 상품을 세분화해 외국어 중심의 온라인 강좌 콘텐츠를 강화한다는 방침이다.
옥션은 콘텐츠 강화를 위해 P2P사이트 `냐온`과 제휴해 교육, 방송, 음악, UCC 콘텐츠 제공에까지 나서고 있다.
인터넷 쇼핑몰 디앤샵의 경우 고객 라운지에서 구매를 포함한 활동 시 지급되는 사이버포인트로 다양한 엔터테인먼트 콘텐츠를 즐길 수 있도록 했다.
이를 이용해 쇼핑 중에도 잡지와 운세, 만화, 그리고 게임 등 서비스를 이용할 수 있어 고객의 호응도 높은 편이다.
G마켓 M&C 사업그룹 나영호 그룹장은 "콘텐츠 유통이 손쉬운 인터넷의 특성을 이용해 양질의 무형 상품을 저렴하게 제공하면서 이용자들에게 큰 호응을 얻고 있다"며 "온라인 콘텐츠에 대한 수요가 증가하는 추세에 맞춰 다양한 서비스를 지속적으로 개발할 것"이라고 말했다.
재료 우드락 2개, 드레싱지(기름종이), 하얀 전지, 스탠드 전등, 트라이포드(삼각대), 디지털 카메라(우드락, 드레싱지, 하얀 전지는 모두 문방구에서 구입할 수 있다).
만들기
1 아이템 사진을 촬영할 때 가장 먼저 벽에 하얀 전지를 붙인다. 인터넷 쇼핑몰에 올리는 사진은 아이템이 두드러져 보여야 하기 때문에, 배경색은 흰색이 가장 좋다.
2 준비한 우드락 2개 중 하나를 선택해서 일정 부분의 테두리만 놔두고 칼이나 가위로 큰 구멍을 뚫는다. 그 구멍을 준비한 드레싱지로 덮는다. 드레싱지는 조명의 색을 은은하게 만들어주는 역할을 한다.
3 우드락 2개를 전지가 붙여진 벽면의 양 옆에 세운다. 사진 촬영을 할 때 넘어가지 않게 잘 고정해야 한다.
4 집에서 쓰는 스탠드 전등을 드레싱지를 덮은 우드락 뒤편에 설치한다. 가정에서 쓰는 일반 스탠드 전등을 조명으로 쓰려고 하면 이렇게 사용하는 것이 효과적이다. 드레싱지를 통과한 빛은 부드러워져서 빛이 소품에 골고루 퍼지게 된다. 다른 한 면에 설치된 우드락은 빛을 강하지 않게 하기 위해서다. 사진 촬영에서 가장 중요한 것은 ‘빛’이다.
5 적당한 거리에 트라이포드를 세운 후 가지고 있는 디지털 카메라를 설치한다. 이 모든 것이 설치되면 사진촬영을 하는 공간의 형광등은 꺼주는 것이 좋다. 스탠드 전등 불빛 하나만으로 사진 촬영을 할 때 가장 필수적인 것은 트라이포드다. 실내에서 촬영할 경우에는 카메라가 필요한 빛의 노출량이 부족하게 마련이다. 빛이 부족하면 카메라의 셔터 스피드는 자연스럽게 느려진다. 일반인이 2~3초 동안 카메라가 흔들리지 않도록 들고 사진을 찍는 것은 불가능한 일. 이때 트라이포드는 흔들리지 않고 사진을 촬영할 수 있게 하는 강력한 무기다. 소품 촬영을 할 때는 카메라에 있는 플래시를 사용하지 않아야 한다. 카메라의 플래시를 사용하면 사진이 딱딱해 보인다.
6 준비가 모두 끝났으면 촬영을 시작하면 된다. 거리나 위치를 바꿔가면서 촬영해본다. 그 중에서 가장 잘 나온 사진을 선택하면 된다.
# 인터넷 쇼핑몰 디자인을 중요하게 생각하는 사람들이 많은데? “보기 좋은 떡이 먹기도 좋다”는 말이 있듯이, 쇼핑몰도 디자인이 중요하죠. 사람들의 시선을 끄는 데 중요한 역할을 하니까요. 하지만 디자인이 매출과 직결되지는 않아요. 메인 디자인에 너무 신경 쓰지 마세요. 회원들의 반응을 보면서 차츰 내실화시키는 것이 중요합니다.
# 상담을 하면서 황당했던 경험도 있는지? 아이템 선정이고 뭐고 간에 아무것도 안 되어 있는 상태에서 ‘어떤 것으로 해야 성공하느냐’라고 묻는 분들도 많아요. 우선 스스로 찾아보려는 노력을 하셔야 해요. 아니면 쇼핑몰 창업 교육을 미리 받아보는 것도 좋아요.
# 요즘 인터넷 쇼핑몰의 트렌드는 어떤가? 물건을 사고 파는 역할만 해서는 안 돼요. 쇼핑몰에서도 요즘은 좋은 정보를 주는 곳이 많아요. 인터넷 쇼핑몰에 오래 머물 수 있도록 볼거리와 놀거리를 제공해야 합니다. 요즘은 마우스로 스크롤을 내려서 봐야 할 정도로 정보가 길어지고, 아이템은 세분화되는 것이 추세입니다.
# 많은 운영자들을 접했을 것이다. 기억나는 운영자가 있다면? 2002년 창업한 운영자인데요, 일본풍 의류 쇼핑몰이었어요. 노점상으로 시작해서 쇼핑몰을 창업해서 패션상가에 입점까지 한 젊은이였는데, 시대를 앞서간 거에요. 꽃남방도 그 친구가 처음 시작했어요. 유행을 이끄니까 성공을 했죠. 쇼핑몰 운영으로 월 매출 2~3억 정도 올리니까, 대단한 거죠.
# 특이한 아이템의 쇼핑몰은 어떤 것들이 있나? 지금은 많이 알려졌지만, 피어싱, 파충류, 빅사이즈 의류 쇼핑몰이 특이하죠.
# 성공하는 쇼핑몰과 실패하는 쇼핑몰의 차이점은? 운영자의 마인드가 달라요. 성공하는 사람들은 뭐가 달라도 다르죠. 컨텐츠를 계속 만들어내는 노력을 하는 사람들이 성공합니다. 보통 처음 시작하고 2~3개월은 매출이 없다고 생각해야 하는데, 그것을 못 견디는 운영자들이 많아요. 6개월이면 실패냐 성공이냐가 판가름 나요.
# 2006년에는 어떤 아이템이 인기를 끌 것 같은지? 2004년에는 웰빙 관련 상품이 히트를 쳤죠. 2005년에는 액세서리나 비즈공예 같은 DIY(Do It Yourself) 제품이 인기를 끌었어요. 2006년에는 식품 관련 시장이 커질 것 같아요. 일본만 봐도 케이크, 회, 쿠키 같은 쇼핑몰 시장이 커지고 있거든요. 국 배달 쇼핑몰은 이제 시작단계입니다.
# 인터넷 쇼핑몰 창업을 준비하는 사람들에게 한마디 조언해준다면? 아이템 선정시 유행을 따라가면 절대 안 됩니다. 내가 잘 아는 것, 좋아하는 것, 즉 관심분야를 선택해야 돼요. 남들이 ‘틈새시장’을 노린다고 해서 그것에만 연연하면 실패합니다. 그리고 인터넷 쇼핑몰을 생계수단으로 이용하려면 시장조사가 생명입니다.
# 서류가방 인터넷 쇼핑몰 창업 예상 비용 #
항목 예상 비용 서류가방 30개 구입 (도매가 2~4만원, 합성피혁 제품) 60만~120만원 키워드 광고비(4대 포털) 40만~45만원 쇼핑몰 구축 비용 (초기 세팅비 + 1년 임대료) 50~60만원(메이크샵 이용시) 사업자등록 신고 세금 9만원 상품 포장지 및 사진촬영 도구 구입비 약 10만원 디지털 카메라 및 트라이포드 구입비 30~50만원 도메인 등록비(.com, co.kr) 5만원 총 예상비용 204만~299만원
(창업 예상 비용은 가장 기본적으로 들어가는 비용만을 산정한 것이다. 만일 쇼핑몰을 구축할 때 호스팅 업체의 패키지를 이용한다면 여기에 1백만원 이상이 더 포함되어야 할 것이다.)
전반적인 경기침체로 본업 외에 부업이나 개인 창업을 생각할 때 가장 쉽게 접근하는 분야가 바로 인터넷쇼핑몰 창업이다. 많은 사람들이 쇼핑몰 운영을 부업 정도로 쉽게 생각하는데 실제로 인터넷쇼핑몰을 운영해봤거나 현재 운영중인 사람들의 얘기를 들어보면 결코 만만한 사업이 아니라고 말한다.
2003년 통계청 자료에 의하면 쇼핑몰 창업자의 80%가 6개월을 기점으로 폐점하고 있으며, 실질적으로 매출을 올리는 쇼핑몰은 불과 10% 미만이라고 한다.
<인터넷쇼핑몰 사업이 어려운 이유> 1. 지속적이고 안정된 상품 공급라인 확보 2. 판매량에 대한 불명확성 3. 홍보 마케팅, 기획력 부족 4. 고객관리의 경험 미숙 5. 수익 안정화까지의 필요한 시간, 자금, 전문인력 확보
직접 인터넷 판매를 하다 보면 투자 광고비 대비 판매량을 생각하지 않을 수 없는데, 이 때쯤이면 가게에서 담배 한 갑 사는 것도 아깝다는 생각이 든다. 몇 달을 고생해서 만들고 홍보했는데 기껏 하나 팔아서 담배 한 갑 값 정도의 마진밖에 남지 않는다는 것을 알고 나면 기운까지 빠지고 최악의 경우 폐점으로까지 이어진다.
쇼핑몰사업 실패의 가장 큰 요인은 온라인 유통에 대한 정확한 정보나 지식없이 무작정 시작한다는 데 있다. 대부분의 창업자들이 처음 쇼핑몰 사업을 시작할 때 가장 먼저 쇼핑몰 제작업체부터 알아보는데, 참고로 쇼핑몰 사업의 성공 요인에서 솔루션의 기능이 차지하는 비중은 10%도 안 된다.
<쇼핑몰 성공 핵심 키워드> 1. 경쟁력있는 상품 2. 신속한 배송 시스템 3. 친절한 고객관리 4. 홍보 마케팅
특히 쇼핑몰 분양업체에 100만원 이상의 분양비를 투자해 경쟁력도 없은 상품으로 시작하는 사람들을 보면 안타까울 따름이다. 차리리 그 돈으로 직접 동대문 시장에 가서 티셔츠 한 장이라도 구입해 경매 사이트에서 몇 백 만명을 상대로 직접 팔아보는 것이 백 배는 낫다. 적어도 실전 경험이라도 쌓을 수 있으니까. 그런데 이마저도 쉽지가 않다.
온라인 유통 경험이 전혀 없는 상태에서 판매할 제품을 선택하는 것부터가 어렵고, 설령 제대로 선택했다 하더라도 현금으로 일정량을 사입(매입)했으나 판매가 부진하여 재고로 남게 되는 것도 부담스러울 뿐만 아니라, 직접 제품 촬영에 이미지 편집, 그리고 배송 관련 문제 해결 등 만만한 것이 없다.
사정이 이러하다 보니 쇼핑몰 사업을 시작하려는 초보자나 쇼핑몰 사이트를 만들어 운영중인 경험자나 단지, 쇼핑몰 사이트가 있느냐 없느냐의 차이가 있을 뿐 처지는 크게 다르지 않다.
쇼핑몰 사업에서 시작 시점의 적기는 따로 없다. 온라인 유통에 대한 정확한 정보와 지식으로 착실히 준비한다면 지금이 바로 적기가 되는 것이며, 그렇게 되었을 때에 기존 쇼핑몰 운영자를 충분히 따라 잡을 수 있으니 자신감을 갖고 시작하는 것이 중요하다.
쇼핑몰 창업, 제대로 알고 시작하자.
쇼핑몰 창업을 하기에 앞서 먼저 유통에 대한 기본 개념부터 정확히 알고 시작하는 것이 좋다. 쇼핑몰 사이트를 방문한 고객이 최종 구매결정을 내리기까지의 고객심리 파악을 제대로 하지 못하면 상품구성 및 운영에 있어서 실패할 확률은 그 만큼 높아진다. 인터넷쇼핑몰에서는 직접 상품을 만져보거나 입어보고 구매하는 것이 아니라 웹 사이트에서 제공한 정보에 의존해 구매결정을 해야 하는 특성때문에 첫 방문부터 구매를 결정하는 고객은 거의 없다.
<인터넷쇼핑몰 고객의 구매 성향> 1. 원하는 상품이 있는지 검색 2. 가격비교 사이트에서 가격 비교 3. 타 쇼핑몰과 비교 4. 가격은 만족스럽지만 중소형 쇼핑몰에서의 구매가 꺼려진다고 판단 5. 판매가격이 아주 낮은 가격이 아니면 결국 대형 쇼핑몰에서 구매 결정
이러한 소비자들의 구매 패턴 성향을 먼저 파악하고 사업을 시작해야 한다.
쇼핑몰 창업을 하려면 판매할 아이템 즉 상품이 있어야 한다. 하지만 신규 창업자가 최소 500만원 정도의 여유 자금없이 사업을 시작하기란 쉽지 않으며 또한 재고 부담에 대한 위험성을 생각하지 않을 수 없다. 이런 이유로 e도매시장의 상품공급 서비스의 목적을 정확히 이해하고 시작할 것을 권한다. 단순히 수동적인 자세로 제공된 상품소개 정보와 가격을 그대로 적용하려는 태도는 지양해야 한다.
일례로 e도매시장에서 상품을 받아가는 쇼핑몰 및 오프라인 매장이 2,500개 업체가 있다면 천편일률적으로 모든 정보를 그대로 활용했을 경우 최소한의 차별성도 없게 된다. 그럼에도 이러한 전략만 가지고 왜 내 쇼핑몰에서만 이렇게 매출이 없을까? 구매자가 늘지 않을까? 등 원인 분석은 하지 않고 온갖 걱정만 하는 경우가 대부분이다. 따라서 쇼핑몰 상품구성 및 판매가격 결정시 최소한 두 가지 목적을 고려해야 한다.
첫째, 방문자를 늘리기 위한 전략으로써 공급원가와 카드수수료 계산을 해서 손해를 보지 않을 정도의 판매가 정책을 세운다.
둘째, 실제 쇼핑몰 매출을 올리기 위한 전략으로, 쇼핑몰 매출을 주로 올릴 수 있는 고객층을 분석하여 타켓팅된 상품을 구성한다.
이와 함께 반드시 이루어져야 할 것이 상품 상세정보의 보강이다. 단순히 공급업체에서 제공한 상품정보만으로는 자신의 상점에 맞는 제품 구성할 수는 없다. e도매시장에는 수많은 회사들(온라인 쇼핑몰업체, 경매창업자, 오프라인 매장운영자)이 기본적인 상품정보와 가격정보가 똑같이 제공한다. 그러므로 이것을 토대로 하여 필히 자신만의 전략에 따라 적극적으로 활용할 필요가 있다.
e도매시장의 상품을 초기에 100% 이용했다면 3개월 정도 운영한 후에 20% 정도는 직접 매입(사입)을 해 자체 상품을 개발할 수 있어야 한다. 현재 e도매시장의 상품을 공급중인 회사중에는 실제로 초기에는 타업체의 상품을 받아 창업을 시작했다가 지금은 자체 개발한 상품으로 오히려 역으로 공급을 함께 하고 있는 업체들이 많다.
상품 소싱이 어려운 이유
2~3년 전만 하더라도 동대문 도매시장에 방문해 인터넷쇼핑몰 운영업체인데 상품을 팔려고 하니 공급계약을 맺을 수 있냐고 하면 쉽게 계약이 이루어지곤 했다. 하지만 최근에는 공급업체에서 더 이상 쇼핑몰 상품 공급에 대한 매력을 갖지 않아 공급 계약을 맺기가 힘들어졌다.
설령 거래가 성사되더라도 기본 매입수량 혹은 일정금액 기본 매입 조건이 붙거나 세금계산서를 발행하지 않고 반품과 교환이 불가능한 경우 등 신규 창업자에게는 부담스러운 조건들이 많다.
게다가 요즘 왠만한 제조업체들은 자체 직판 대리점망이나 인터넷 판매(경매 및 자체 독립쇼핑몰, 대기업 쇼핑몰 입점판매 등)를 진행하고 있어 상품을 공급해 주더라도 아예 가격 경쟁력이 되지 않을 정도의 조건을 제시하기도 한다. 또 자체 직판 가맹점을 가진 업체의 경우에는 대리점 보호 차원에서 다른 업체에는 절대 상품을 주지 않으며, 경매 사이트에서 일단 한 번 뜨고 나면 무차별 가격 붕괴가 시작되기에 아예 상품 공급 자체를 차단하기도 한다.
e도매시장의 상품 공급 서비스 목적이 어디에 있는지를 정확히 알고 시작하는 것이 좋다. 상품 개발 전문 MD를 고용하지 않고 직접 매입처를 물색하여 움직이더라도 최소한의 비용과 상품 구매 자금력이 없으면 상품 소싱은 힘들다고 봐야 한다.
인터넷쇼핑몰 창업은 분명 다른 어떤 창업에 비해 투자대비 손익분기점을 넘길 수 있는 기간이 짧고 제대로 알고 시작할 경우 다른 창업 아이템보다 매우 매력적이다.
동일한 조건에서 유독 빨리 성공하여 자리를 잡는 창업자들의 공통점은 끊임없이 배우고 노력한다는 점이다. 지금까지 수동적인 자세로 쇼핑몰 운영을 했다고 생각이 든 지금 바로 이 순간이 한 단계 더 발전할 수 있는 계기가 되어야 할 것이다.
1. 융화의 원칙 : "네티즌이 되어야 네티즌에게 팔 수 있다" 2. 선도자의 원칙 : "먼저 시작해야 살아남는다" 3. 6개월의 원칙 : "멀리 바라보는 자가 오래 간다" 4. 간결의 원칙 : "느린 속도는 판매의 적이다" 5. 업데이트의 원칙 : "세 번 같은 화면을 보면 더 이상 찾아오지 않는다" 6. 검색의 원칙 : "원하는 물건을 쉽게 찾게 하라" 7. 연관의 원칙 : "한 번 들어오면 한참을 돌아다니게 만들어라" 8. 맞춤의 원칙 : "고객 각각의 특성을 파악하라" 9. 커뮤니티의 원칙 : "고객끼리 정보를 주고받게 만들어라" 10. 비지떡의 원칙 : "싼 게 왕이다" 11. 정보의 원칙 : "만져보지 않고도 사게 만들어라" 12. 보안의 원칙 : "믿고 주문하게 하라" 13. 결제의 원칙 : "고객이 원하면 무엇이든 받아라" 14. 배송의 원칙 : "고객은 기다리지 못한다" 15. AS의 원칙 : "고객에게 잘 샀다는 느낌을 전달해라" 16. 이벤트의 원칙 : "홍보비용을 아끼지 마라" 17. 잠재고객의 원칙 : "물건을 사지 않아도 찾아오게 만들어라" 18. 다채널의 원칙 : "판매루트를 다양화하라" 19. 마일리지의 원칙 : "고객에게 이익을 돌려줘라" 20. 추천의 원칙 : "아는 사람을 소개하게 하라"
[상세 원칙 풀이]
1. 융화의 원칙 : "네티즌이 되어야 네티즌에게 팔 수 있다" 동네에서 장사를 잘하려면 그 동네를 잘 알아야 한다. 인터넷과 네티즌에 대해 알면 알수록 상품팔기가 쉬워진다. 네티즌의 눈높이·사고방식과 융화되어야 한다. 청소년이 주고객인 쇼핑몰 운영자는 청소년 사이트에 수시로 들어가보고 게시판에도 자주 들러야한다.
2. 선도자의 원칙 : "먼저 시작해야 살아남는다" 시장의 선도자가 되는 것은 인터넷에서는 1동의 새로운 동의어. 항상 새로운 것을 추구하는 네티즌의 취향을 빨리 파악하고 이와 조응하는 사업을 가장 먼저 시작해야 한다.
3. 6개월의 원칙 : "멀리 바라보는 자가 오래 간다" 한달 정도면 성공가능성이 확인되는 오프라인 상점과 달리 인터넷쇼핑몰은 보다 긴 기간을 필요로 한다. 성공하기 위해서 6개월간 참을 수 있는 인내심과 꾸준한 홍보·마케팅이 필수적이다.
4. 간결의 원칙 : "느린 속도는 판매의 적이다" 쇼핑몰에 찾아온 사람은 심심풀이로 들어온 것이 아니라 상품을 보고 구매하기 위한 사람들이다. 깔끔한 화면과 상품을 돋보이게 하는 화면구성, 잘 알아볼 수 있는 상품정보, 빠른 접속속도가 최고의 미덕이다. 너무 화려한 화면은 속빈 강정이라는 느낌을 주기 쉽다.
5. 업데이트의 원칙 : "세 번 같은 화면을 보면 더 이상 찾아오지 않는다" 많이 모이는 것도 중요하지만, 한번 찾아온 사람이 계속해서 방문하도록 하는 것이 더 중요하다. 즉 고객충성도를 높여야 한다는 것이다. 이를 위해서는 계속 신상품과 새로운 정보를 제공하여 신선한 모습을 보여주는 꾸준한 업데이트가 필수적이다.
6. 검색의 원칙 : "원하는 물건을 쉽게 찾게 하라" 강력한 검색엔진을 장착해야 고객의 만족도는 높아진다. 까다로운 고객을 위한 고급검색기능을 갖추는 것도 필수적이다. 검색 결과를 한눈에 들어오게 해 가격과 기능 등을 쉽게비교하고 선택할 수 있도록 해야한다.
7. 연관의 원칙 : "한 번 들어오면 한참을 돌아다니게 만들어라" 방문빈도를 높이기 위해서는 대대적인 광고가 필요하다. 그러나 한사람의 방문자가 많은 페이지를 방문하도록 유도하는 것은 사이트 구성만 잘하면 가능한 일입니다. 한명의 충실한 방문자가 뜨내기 백명보다 낫다.
8. 맞춤의 원칙 : "고객 각각의 특성을 파악하라" 특별한 대접을 받고 있다는 기분이 드는 고객은 구매할 확률이 높아진다. 최근 개발 러시를 이루고 있는 일대일 맞춤서비스 솔루션 등을 채택하는 것이 최선이지만, 회원이 로그인할 경우 구매성향에 맞는 상품을 추천하고 인사말 정도라도 띄우는 것이 바람직하다.
9. 커뮤니티의 원칙 : "고객끼리 정보를 주고받게 만들어라" 커뮤니티는 매출에 직접 도움을 주지않지만 고객을 오래 머물게할 뿐만아니라 지속적으로 정보를 제공하고 볼거리를 제공한다는 측면에서 상당히 중요하다. 특히 특정분야 매니아 커뮤니티는 매출에 직접적 영향을 준다. 다양한 인센티브를 부여해 이를 활성화해야 한다.
10. 비지떡의 원칙 : "싼 게 왕이다" 가격이 저렴하다는 소문나는 것이 최고의 홍보전략. 인터넷에서는 싼 게 비지떡이 아니라 싼 게 왕이 된다.
11. 정보의 원칙 : "만져보지 않고도 사게 만들어라" 눈으로 확인하고 손으로 만져봐야만 믿는 경향이 강한 우리나라 사람들을 인터넷쇼핑이라는 '모험'으로 끌어들이기 위해서는 만져보지 않고도 사게 만들 수 있는 꼼꼼한 상품정보가 필수적이다.
12. 보안의 원칙 : "믿고 주문하게 하라" 일반 상점에서는 카드를 주저없이 내밀면서도 인터넷쇼핑몰에서는 카드번호 입력을 주저하는 것이 현실. 보안기관 인증 사실을 사이트의 가장 잘 보이는 곳에 올리는 등 고객들을 안심시킬 수 있는 새심한 배려가 필요하다.
13. 결제의 원칙 : "고객이 원하면 무엇이든 받아라" 폰뱅킹, 무통장입금, 카드결제 등 고객이 원하는 결제수단은 어느 것이든지 수용하는 쇼핑몰이 성공한다. 결제대행 서비스를 제공하는 업체 중 신뢰할만한 업체를 선택해 초기 단계부터 결제가 불편한 쇼핑몰이라는 인상을 심어주지 않는 것이 필수적이다.
14. 배송의 원칙 : "고객은 기다리지 못한다" 1주일, 3일, 당일 등 고객들의 배송요구는 다양하다. 믿을만한 오프라인 퀵서비스-택배업체 등과의 업무제휴를 통해 고객들이 원하는 시간에 원하는 장소로 물품을 배달하는 '배달의 기수' 쇼핑몰이 되어야 한다.
15. AS의 원칙 : "고객에게 잘 샀다는 느낌을 전달해라" AS없는 쇼핑몰은 죽은 쇼핑몰이다. 기업으로 상품 발송시 영수증을 필히 보내 비용처리를 할 수 있도록 하는 것. 구매 후 일주일 정도의 간격으로 메일을 보내 불편사항을 체크하는 것, 불량이 발생할 경우 반품처리를 확실하게 하는 것 등은 필수선택사항입니다.
16. 이벤트의 원칙 : "홍보비용을 아끼지 마라" 사람들이 모이게 하고 사이트를 기억시키는 데는 역시 '화끈한' 이벤트가 필수요건. 거액의 상금을 내거는 일반적 이벤트가 아니더라도 타겟고객들의 취향을 분석해 그들에게 강한 이미지를 심어줄 수 있는 '맞춤형' 이벤트를 기획한다면 사업 성공가능성은 그만큼 높아진다.
17. 잠재고객의 원칙 : "물건을 사지 않아도 찾아오게 만들어라" 전시된 상품에 대한 정보만 있다면 단지 구경을 위해 사이트를 방문한 '잠재고객'은 초기화면만 보고 돌아간다. 당장 구매할 의사가 없다할지라도 그들이 관심을 가질만한 볼거리와 읽을거리를 풍부하게 갖춘다면 언젠가는 실제로 구매하는 고객이 될 수 있다.
18. 다채널의 원칙 : "판매루트를 다양화하라" 몇 퍼센트의 수수료를 감수하고서라도 연관성이 높은 타 사이트와 제휴를 맺고 배너를 교환하면 그 이상의 수익이 발생한다. 특히 사업초기일수록 운영자는 타 사이트 운영자에 대한 활발한 영업활동을 통해 인지도와 매출을 상승시키는 수완을 발휘해야 한다.
19. 마일리지의 원칙 : "고객에게 이익을 돌려줘라" 마일리지는 ON-OFF 모든 공간에서 일반적인 마케팅 기법으로 자리잡았다. 회원제를 정착시킨 후 회원들에게 구매액에 따라 적절한 마일리지를 부여하는 것이 바람직하다. 현금 또는 사이버머니를 적립해주는 캐쉬백 제도가 일반적이다.
20. 추천의 원칙 : "아는 사람을 소개하게 하라" 마일리지 제도와 함께 가장 일반적인 마케팅 기법. 비용면에서 좀 부담이 되는 방법이지만 가장 확실한 홍보수단인 '입소문의 급속한 확산'이 보장된다는 점에서 매력적이다. 현재 자금여력이 부족하다할지라도 어떤 시점에서 이 제도를 도입할 것인지를 미리 계획해놓는 것이 좋다.
PNG는 GIF이나 JPG 처럼 컴퓨터에서 그래픽 이미지를 저장하는 파일 형식으로 GIF 파일 형식의 문제점을 해결하면서 확장된 기능을 제공하기 위해 고안되었다. PNG는 GIF보다 10~30%정도의 압축률을 제공한다. 또한 투명도(alpha channel)을 지원하는 유일한 비트맵포맷이며, 이것이 Macromedia Fireworks의 원본 포맷이 되기도 했다. 단점으로는 다중이미지를 한 개의 파일에 저장할 수 없기 때문에 GIF와 같이 애니메이션 효과를 가질 수 없다는 점이다.
PNG를 이용하면 투명 이미지도 만들수 있다는군요..
PNG란 GIF와 JPG의 두 단점을 보완한 통합 파일이라고 보시면 됩니다. gif파일이 투명한 파일을 만들고 애니메이션을 지원하는 장점이 있지만 256색만 지원하는 단점이 있습니다. 다시 말하면 간단한 투명파일은 가능하지만 그림자와 같은 미세한 부분이나 투명도를 조절할수 없습니다. PNG는 이러한 gif파일의 단점을 보완하여 jpg처럼 트루컬러를 지원함과 동시에 다양하고 멋진 투명한 이미지를 만들 수 있습니다.
많은 분들이 PNG를 홈페이지 제작에 사용하는 jpg 이미지의 차세대 파일 포맷으로만 인식하고 있지만 파워포인트와 플래시에 삽입하여 사용해 보는것을 적극 권장하고 싶습니다.