VisualStudio 2005 C++ 단축키 포스터 (첨부파일)

출처 :


출처 :


BSTR test( BSTR bstrVal )
  char* pszVal;
  하면 pszVal 안에 BSTR문자열값이 들어간다.

  BSTR bstrCopy;
  하면 pszVal값이 bstrCopy에 들어간다. SysAlloc된 상태

  SysFreeString(bstrCopy);해야 함

  BSTR bstrRet;

  return bstrRet;    // ATL컴포넌트 메소드가 BSTR리턴시
}                    // SysAlloc후 리턴한다.
                     // VC Client에서 SysFreeString해야함
                     // VB Client에서는 알아서 프리시킴

BSTR<->char* 컨버팅이 간편한


1. ATL Project
 -> 그냥 쓸수 있다.

2. MFC Project
 -> #include <comdef.h>
    #include <afxpriv.h>

3. Win32 Dll Project
#include <comdef.h>
#include <CRTDBG.H>
#include <atlconv.h>

를 하면 된다. ( 하나씩 찾아봤음 -_-;)

COM에서 WideChar와 AnsiChar 바꾸는 매크로

VARIANT에 문자열 넣기

// com support class
#include <comdef.h>
#include <AFXPRIV.H>    // USES_CONVERSION 이 정의된 곳

var.vt = VT_BSTR;
var.bstrVal = SysAllocString(A2W("하하하하하"));

*웹페이지에서는 문자열은 VARIANT를 써야 한다.

다음은 ASP서포트 상태에서 BSTR과 char*사이의 변환이다.

    if( m_piServer )
        BSTR bstrLogicPath, bstrPhysicPath;
        bstrLogicPath = SysAllocString(A2W("/NstChart"));
        m_piServer->MapPath( bstrLogicPath, &bstrPhysicPath)

        SysFreeString( bstrLogicPath );
        char* pszPhysicPath = W2A(bstrPhysicPath);
        m_plgManager->fnSetPlugPath( pszPhysicPath );


참고 테크니컬 노트
TN059: Using MFC MBCS/Unicode Conversion Macros
This note describes how to use the macros for MBCS/Unicode conversion which are defined in
AFXPRIV.H. These macros are most useful if your application deals directly with the OLE API or for
some reason, often needs to convert between Unicode and MBCS.


In MFC 3.x, a special DLL was used (MFCANS32.DLL) to automatically convert between Unicode and MBCS
when OLE interfaces were called. This DLL was an almost transparent layer that allowed OLE
applications to be written as if the OLE APIs and interfaces were MBCS, even though they are always
Unicode (except on the Macintosh). While this layer was convenient and allowed applications to be
quickly ported from Win16 to Win32 (MFC, Microsoft Word, Microsoft Excel, and VBA, are just some of
the Microsoft applications that used this technology), it also had a sometimes significant
performance hit. For this reason, MFC 4.x does not use this DLL and instead talks directly to the
Unicode OLE interfaces. To do this, MFC needs to convert to Unicode to MBCS when making a call to
an OLE interface, and often needs to convert to MBCS from Unicode when implementing an OLE
interface. In order to handle this efficiently and easily, a number of macros were created to make
this conversion easier.

One of the biggest hurdles of creating such a set of macros is memory allocation. Because the
strings cannot be converted in place, new memory to hold the converted results must be allocated.
This could have been done with code similar to the following:

// we want to convert an MBCS string in lpszA
int nLen = MultiByteToWideChar(CP_ACP, 0,lpszA, -1, NULL, NULL);
LPWSTR lpszW = new WCHAR[nLen];
MultiByteToWideChar(CP_ACP, 0,
lpszA, -1, lpszW, nLen);
// use it to call OLE here
// free the string
delete[] lpszW;

This approach as a number of problems. The main problem is that it is a lot of code to write, test,
and debug. Something that was a simple function call, is now much more complex. In addition, there
is a significant runtime overhead in doing so. Memory has to be allocated on the heap and freed
each time a conversion is done. Finally, the code above would need to have appropriate #ifdefs
added for Unicode and Macintosh builds (which don’t require this conversion to take place).

The solution we came up with is to create some macros which 1) mask the difference between the
various platforms, and 2) use an efficient memory allocation scheme, and 3) are easy to insert into
the existing source code. Here is an example of one of the definitions:

#define A2W(lpa) (    ((LPCSTR)lpa == NULL) ? NULL : (           _convert = (strlen(lpa)+1),        AfxA2WHelper((LPWSTR) alloca(_convert*2),
lpa, _convert)    ))

Using this macro instead of the code above and things are much simpler:

// use it to call OLE here

There are extra calls where conversion is necessary, but using the macros is simple and effective.

The implementation of each macro uses the _alloca() function to allocate memory from the stack
instead of the heap. Allocating memory from the stack is much faster than allocating memory on the
heap, and the memory is automatically freed when the function is exited. In addition, the macros
avoid calling MultiByteToWideChar (or WideCharToMultiByte) more than one time. This is done by
allocating a little bit more memory than is necessary. We know that an MBC will convert into at
most one WCHAR and that for each WCHAR we will have a maximum of two MBC bytes. By allocating a 
little more than necessary, but always enough to handle the conversion the second call second call
to the conversion function is avoided. The call to the helper function AfxA2Whelper reduces the
number of argument pushes that must be done in order to perform the conversion (this results in
smaller code, than if it called MultiByteToWideChar directly).

In order to for the macros to have space to store the a temporary length, it is necessary to
declare a local variable called _convert that does this in each function that uses the conversion
macros. This is done by invoking the USES_CONVERSION macro as seen above in the example.

There are both generic conversion macros and OLE specific macros. These two different macro sets
are discussed below. All of the macros reside in AFXPRIV.H.

Generic Conversion Macros

The generic conversion macros form the underlying mechanism. The macro example and implementation
shown in the previous section, A2W, is one such “generic” macro. It has no relation to OLE
specifically. The set of generic macros is listed below:

A2CW        (LPCSTR) -> (LPCWSTR)
A2W        (LPCSTR) -> (LPWSTR)
W2CA        (LPCWSTR) -> (LPCSTR)
W2A        (LPCWSTR) -> (LPSTR)

Besides doing text conversions, there are also macros and helper functions for converting
TEXTMETRIC, DEVMODE, BSTR, and OLE allocated strings. These macros are beyond the scope of this
discussion ? refer to AFXPRIV.H for more information on those macros.

OLE Conversion Macros

The OLE conversion macros are designed specifically for handling functions which expect OLESTR
characters. If you examine the OLE headers you will see many references to LPCOLESTR and OLECHAR.
These types are used to refer to the type of characters used in OLE interfaces in a way that is not
specific to the platform. OLECHAR maps to char in Win16 and Macintosh platforms and WCHAR in Win32.

In order to keep the number of #ifdef directives in the MFC code to a minimum we have a similar
macro for each conversion that where OLE strings are involved. The following macros are the most
commonly used:


Again there are similar macros for doing TEXTMETRIC, DEVMODE, BSTR, and OLE allocated strings.
Refer to AFXPRIV.H for more information.

Other Considerations

Don’t use the macros in a tight loop. For example, you do NOT want to write the following kind of

void BadIterateCode(LPCTSTR lpsz)
for (int ii = 0; ii < 10000; ii++)
pI->SomeMethod(ii, T2COLE(lpsz));

The code above could result in allocating megabytes of memory on the stack depending on what the
contents of the string lpsz is!  It also takes time to convert the string for each iteration of the
loop. Instead move such constant conversions out of the loop:

void MuchBetterIterateCode(LPCTSTR lpsz)
LPCOLESTR lpszT = T2COLE(lpsz);
for (int ii = 0; ii < 10000; ii++)
pI->SomeMethod(ii, lpszT);

If the string is not constant, then encapsulate the method call into a function. This will allow
the conversion buffer to be freed each time. For example:

void CallSomeMethod(int ii, LPCTSTR lpsz)
pI->SomeMethod(ii, T2COLE(lpsz));

void MuchBetterIterateCode2(LPCTSTR* lpszArray)
for (int ii = 0; ii < 10000; ii++)
CallSomeMethod(ii, lpszArray[ii]);

Never return the result of one of the macros, unless the return value implies making a copy of the
data before the return. For example, this code is bad:

LPTSTR BadConvert(ISomeInterface* pI)
LPTSTR lpszT = OLE2T(lpsz);
return lpszT; // bad! returning alloca memory

The code above could be fixed by changing the return value to something which copies the value:

CString BetterConvert(ISomeInterface* pI)
LPTSTR lpszT = OLE2T(lpsz);
return lpszT; // CString makes copy

The macros are easy to use and easy to insert into your code, but as you can tell from the caveats
above, you need to be careful when using them.

완성형과 조합형
완성형은 글자 자체를 하나의 형태로 보고 코드화한 것이고
조합형은 총 한 글자로 표시되는 바이트(보통 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이란 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(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은 localization(지역화)의 약칭이다. 개발자들이 긴 낱말이 싫어해서 약어로 사용하는 말이다. 소프트웨어가 localization되어 있다는 말은 소프트웨어를 사용하는 사용자를 위해 한 언어에 맞추어 개발이 되어 있다는 것이다. 그래서 이 경우에는 한번에 다중 언어를 사용할 수 없다.
현지화는 어떤 제품이나 서비스를 특정한 언어나, 문화, 그리고 현지의 정서에 맞추는 과정을 말한다. 이상적으로는 한 제품이나 서비스는 현지화가 비교적 쉽게 달성될 수 있도록 개발된다. 예를 들면, 설명서의 경우에는 기술적인 삽화 등을 사용함으로써 그 안에 있는 글자들을 다른 나라의 언어로 쉽게 바꿀 수 있도록 하고 이러한 목적을 위해 어느 정도의 확장성을 감안하고 있다. 이러한 권능을 부여하는 과정을 국제화라고도 부른다. 그러므로 국제화된 제품이나 서비스는 현지화하기가 더욱 쉽다.
관용적인 언어들의 번역 외에도 현지화되고 있는 제품에서는 시간대 조정, 통화, 해당 국가의 휴일, 현지의 색상 감각, 제품이나 서비스의 이름, 성별 역할, 그리고 지정학적 요인 등이 반드시 고려되어야할 요소들의 예이다. 성공적인 서비스나 제품의 현지화는 현지의 문화 속에서 개발된 것처럼 보여지는 것이다.

현지화의 커다란 부분 중 하나인 언어의 번역은 때로 자동 번역으로 쉽게 할 수 있다. 그러나 대체로 많은 추가 작업이 소요된다.

i18n은 internationalization(국제화)의 약칭이다. software가 internationalization되었다는 말을 들을려면 여러 언어를, 예를 들면, 한국어든 중국어든 동시에 입력해서 사용할 수 있어야 한다. multiligual system이란 말과 i18n system은 동일한 말이다.
국제화는 제품이나 서비스를 특정 지역의 언어나 문화에 맞추는 즉, 현지화라고 불리는 과정을 쉽게 할 수 있도록 계획하거나 이행하는 과정을 말한다. 국제화는 때로 번역 및 현지화 능력 부여 작업이라고도 불리는데 여기에는 다음과 같은 것들이 포함된다.

- 하드웨어 레이블이나, 도움말 페이지, 그리고 온라인 메뉴 등 사용자 인터페이스를 설계할 때 더 많은 수의 글자가 들어갈 때를 대비하여 여유를 둔다.
- 웹에디터나 저작 도구 등과 같은 제품을 개발할 때 국제 문자셋 즉, 유니코드를 지원할 수 있게 한다.
- 인쇄용 그래픽 이미지나 웹사이트를 만들어서 텍스트 레이블을 번역할 때 비용이 많이 들지 않게 한다.
- 전세계적으로 통용될 수 있는 예시를 사용한다.
- 소프트웨어의 경우에는 메시지들이 영어와 같은 단일 바이트 문자 코드에서, 한글과 같은 다중 바이트 문자 코드로 변환될 수 있도록 데이터 공간을 확보한다.

모든 글자 표현 체계를 하나로 통합하겠다는 뜻으로 영문권에서 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을 사용한다. 즉 혼용해서 사용하는 것이다.


유니코드는 미래에 나올 글자들까지도 모두 코드화 하자! 그래서 유니코드는 코드이다.
코딩할 때의 그 코드가 아니라 글자 하나하나에 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

   UCS-4 range (hex.)      UTF-8 octet sequence (binary)
   0000 0000-0000 007F     0xxxxxxx
   0000 0080-0000 07FF     110xxxxx 10xxxxxx
   0000 0800-0000 FFFF     1110xxxx 10xxxxxx 10xxxxxx

   0001 0000-001F FFFF     11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   0020 0000-03FF FFFF     111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   0400 0000-7FFF FFFF     1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

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 범위만을 문자 코드로 간주한다고 이해하면 된다.

컴퓨터속의 한글
KSC-5601에 관한글

출처 : MSDN
Visual Studio 2005 IDE 팁과 트릭


James Lau
Microsoft 프로그램 관리자

2007년 2월

적용 대상: Microsoft Visual Studio 2005

요약: 개발자 도구 중에 가장 인기 있는 Visual Studio 2005를 더욱 효과적으로 활용할 수 있는 몇 가지 팁과 트릭을 소개하고자 합니다. 어떤 도구든 최대한 활용하려면 익숙해지는 것이 중요한데, 개발 도구와 IDE 역시 다르지 않습니다. 그러나 C# 2.0, ASP .NET 2.0, Windows Workflow Foundation, Windows Presentation Foundation, Windows Communication Foundation과 같은 신기술이 쏟아져 나오므로 정작 Visual Studio를 익힐 시간을 내기가 어렵습니다. 10분 정도만 시간을 내어 이 기사를 읽고 Visual Studio를 보다 즐겁고 생산적으로 사용할 수 있는 유용한 정보를 얻기 바랍니다.


유용한 바로 가기 키

필자가 자주 사용하는 바로 가기 키

Visual Studio에서 프로그램을 개발할 때 키보드만 사용하면 더 편할 거라고 생각한 적이 있으십니까? 고급 사용자라면 분명히 키보드 바로 가기 키를 자주 사용하여 여러 가지 작업을 보다 빠르게 수행할 것입니다. 독자들도 대부분 Debug.Start를 실행하는 F5 키, Debug.StepOver를 실행하는 F10 키, View.Properties를 실행하는 F4 키 등에는 이미 익숙할 것이라 생각합니다. 그러나 그 밖에도 잘 알려져 있지 않았지만 유용한 바로 가기 키가 몇 가지 있습니다. 아래 표에는 필자가 자주 사용하는 몇 가지 바로 가기 키가 나와 있습니다.

바로 가기 키 설명
F7 디자인 보기와 코드 보기 사이를 전환합니다.
F9 중단점을 설정하거나 해제합니다.
F12 변수, 개체 또는 함수의 정의로 이동합니다.


정의로 이동 스택에서 앞/뒤로 빠르게 이동합니다.
Shift+F12 함수나 변수의 참조를 모두 찾습니다.
Ctrl+M, Ctrl+M 편집기에서 코드 개요를 확장하거나 축소합니다.
Ctrl+K, Ctrl+C

Ctrl+K, Ctrl+U

코드 줄에 주석을 추가하거나 제거합니다.
Shift+Alt+Enter 전체 화면 모드와 표준 모드 사이를 전환합니다.
Ctrl+I 증분 검색을 실행합니다.

바로 가기 키 참조표 만들기

대부분의 사람들이 모르고 있지만 사실 Visual Studio에는 450개가 넘는 기본 바로 가기 키가 있습니다. 그러나 Visual Studio의 모든 바로 가기 키를 손쉽게 찾을 수 있는 방법은 없습니다. 모든 바로 가기 키를 열거하는 간단한 매크로를 작성하면 기본 바로 가기 키를 모두 찾아볼 수 있습니다. 다음(코드 1)은 이러한 기능을 수행하는 코드입니다.

Public Module Module1

    Public Sub ListShortcutsInHTML()

        'Declare a StreamWriter
        Dim sw As System.IO.StreamWriter
        sw = New StreamWriter("c:\\demo\\Shortcuts.html")

        'Write the beginning HTML

        ' Add a row for each keyboard shortcut
        For Each c As Command In DTE.Commands
            If c.Name <> "" Then
                Dim bindings As System.Array
                bindings = CType(c.Bindings, System.Array)
                For i As Integer = 0 To bindings.Length - 1
                    sw.WriteLine("<td>" + c.Name + "</td>")
                    sw.WriteLine("<td>" + bindings(i) + "</td>")

            End If

        'Write the end HTML

        'Flush and close the stream
    End Sub
Public Sub WriteHTMLStart(ByVal sw As System.IO.StreamWriter)

        sw.WriteLine("Visual Studio Keyboard Shortcuts")

        sw.WriteLine("<h1>Visual Studio 2005 Keyboard Shortcuts</h1>")
        sw.WriteLine("<font size=""2"" face=""Verdana"">")
        sw.WriteLine("<table border=""1"">")
        sw.WriteLine("<tr BGCOLOR=""#018FFF""><td 

    End Sub

    Public Sub WriteHTMLEnd(ByVal sw As System.IO.StreamWriter)
    End Sub

End Module

코드 1. HTML로 바로 가기 키를 생성하는 매크로

이 매크로를 사용하려면 도구에서 매크로를 선택한 다음 매크로 IDE. . .를 선택하여 매크로 IDE를 실행합니다. MyMacros 프로젝트, MyMacros 네임스페이스를 차례로 확장한 다음 Module1을 두 번 클릭합니다. 코드 1을 매크로 IDE에 복사하고 매크로를 실행하기만 하면 됩니다. 매크로를 실행하고 나면 Visual Studio에 사용할 바로 가기 키 참조가 생성됩니다. 결과물인 C:\demo\Shortcuts.html을 열어 보십시오. 그림 1은 이 페이지의 일부입니다. 페이지를 인쇄하여 컴퓨터 옆에 붙여 두고 바로 가기 키를 익혀 보십시오.

그림 1. Visual Studio 2005 바로 가기 키 목록의 일부

바로 가기 키 사용자 지정

기본적으로 매핑되어 있지 않은 바로 가기 키도 언제든지도구 > 옵션... > 환경 > 키보드 메뉴를 통해 사용자 지정할 수 있습니다(그림 2 참조). 그러나 많은 수의 바로 가기 키를 추가하는 경우에는 자동 저장 설정 파일을 직접 편집하는 방법으로 추가하는 편이 더 쉽습니다. 이 방법을 사용하려면 다음 단계를 수행하십시오.

그림 2. 옵션 대화 상자 - 바로 가기 키 사용자 지정

1단계: 현재 바로 가기 키를 내보냅니다. 도구 > 설정 가져오기 및 내보내기. . .로 이동하여 가져오기/내보내기 설정 마법사를 시작합니다. "선택한 환경 설정 내보내기"를 선택하고 다음을 클릭합니다. "모든 설정"을 클릭하여 모든 확인란의 선택을 취소한 다음 옵션, 환경 노드를 차례로 확장하여 "키보드" 확인란을 선택합니다(그림 3). 다음을 클릭하여 마법사의 마지막 페이지로 이동합니다. 새 설정 파일의 이름을 "MyKeyboardShorcuts.vssettings"로 지정하고 경로는 기본 디렉터리로 둡니다(그림 4). 마침을 클릭합니다..

그림 3. 내보낼 키보드 설정 범주만 선택

그림 4. 설정 파일 이름을 MyKeyboardShortcuts.vssettings로 변경

2단계: 설정 파일을 열어 편집합니다. 이 파일은 My Documents\Visual Studio 2005\Settings\MyKeyboardShortcuts.vssettings에 있습니다. Visual Studio 설정 파일은 XML 파일이므로 아무 텍스트 편집기에서나 열 수 있습니다. 하지만 구문 색 지정 기능과 문서 서식 지정 기능을 사용할 수 있도록 Visual Studio 자체에서 이 파일을 여는 것이 좋습니다. 파일을 연 후에는 "Ctrl+K, Ctrl+D"를 눌러 Visual Studio가 서식을 자동으로 지정하도록 합니다. 그런 다음 <UserShortcuts> 태그를 찾습니다. 이 XML 요소에 자신만의 바로 가기 목록을 추가할 수 있습니다. 아래 코드 2에서 예를 볼 수 있습니다.

   <Shortcut Command="View.CommandWindow" Scope="Global">
Ctrl+W, Ctrl+C
   <Shortcut Command="View.SolutionExplorer" Scope="Global">
Ctrl+W, Ctrl+S
   <Shortcut Command="View.ErrorList" Scope="Global">
Ctrl+W, Ctrl+E
   <Shortcut Command="View.TaskList" Scope="Global">
Ctrl+W, Ctrl+T
   <Shortcut Command="View.Output" Scope="Global">
Ctrl+W, Ctrl+O

코드 2. 설정 파일에 바로 가기 직접 추가

이 예의 XML은 이해하기 쉽습니다. 추가하려는 각 바로 가기에 대한 <Shortcut> 요소가 있을 뿐입니다. 바로 가기 자체를 이 요소의 내용으로 지정하고 Shift, Ctrl, Alt 등의 한정자 키를 "+" 문자로 연결하여 함께 사용할 수 있습니다(예: Ctrl+Alt+J). Command 특성에는 바로 가기에 바인딩할 명령의 정식 명령 이름을 지정합니다. Scope 특성은 거의 항상 Global로 사용되므로 이에 대해서는 자세히 다루지 않겠습니다. 이 과정에서 가장 어려운 부분은 아마도 특정 명령의 정식 이름을 알아내는 부분일 것입니다. 명령의 정식 이름은 최상위 메뉴 이름과 "." 문자, 그리고 공백 없이 대/소문자가 섞인 명령 이름이 연결된 형식입니다.

바로 가기를 모두 추가한 후 파일을 저장합니다.

3단계: 설정 파일을 가져옵니다. 설정 파일에 바로 가기를 추가했으므로 이제 사용 환경으로 다시 가져올 수 있습니다. 물론 설정 파일을 다른 사람과 공유할 수도 있습니다. 설정 가져오기 및 내보내기 마법사를 다시 시작하되, 이번에는 "선택한 환경 설정 가져오기"를 선택하고 다음을 클릭합니다. "아니요, 새 설정을 가져와 현재 설정을 덮어씁니다."를 선택하고 다음을 클릭합니다. "My Settings" 폴더에서 "MyKeyboardShortcuts.vssettings"를 선택하고 다음을 클릭합니다. 기본 선택 항목을 그대로 두고 마침을 클릭합니다.

도구 설명에 바로 가기 표시

도구 모음의 명령 위로 마우스를 이동할 때 도구 설명에 바로 가기가 표시되도록 환경을 설정할 수 있습니다. 도구 > 사용자 지정. . .에서 스크린 팁에 바로 가기 키 표시 옵션이 선택되어 있는지 확인합니다.

그림 5. 도구 설명에 바로 가기 키 표시 옵션 설정

창 레이아웃 선택기

Visual Studio는 여러 가지 작업과 용도에 사용되는 다양한 도구 창을 제공하는 강력한 환경입니다. 특히 VS 2005에서 새로 제공되는 Team System 기능이 이러한 측면을 잘 보여 줍니다. 많은 사용자들이 현재 수행 중인 작업에 맞게 여러 창 레이아웃 사이를 신속하게 전환할 수 있는 기능이 있으면 좋겠다는 의견을 전해 왔는데, 사실 VS 2005에서 직접 이 기능을 구현할 수 있지만 이를 위해서는 다음과 같은 단계를 수행해야 합니다.

1단계. 설정 파일을 만듭니다. Visual Studio 2005에는 사용자가 환경 설정을 가져오거나 내보낼 수 있는 새로운 기능이 있습니다. 환경에서 사용자 지정할 수 있는 항목은 거의 모두 파일로 내보내 다른 사람과 공유하거나 다른 컴퓨터로 가져오거나 백업 파일로 저장할 수 있습니다. 가져오거나 내보낼 수 있는 설정에는 창 레이아웃, 바로 가기 키, 메뉴 사용자 지정, 글꼴 및 색, 그리고 옵션 대화 상자(도구 > 옵션. . . )의 설정 대부분이 포함됩니다. 또한 언제든지 필요에 따라 환경 설정을 모두 내보내거나 일부만 내보낼 수 있습니다.

창 선택기를 만드는 첫 단계는 사용하려는 각 창 레이아웃마다 별도의 설정 파일을 만드는 것입니다. 이 예제에서는 사용할 3개의 창 레이아웃에 해당하는 CodeWriting, CodeBrowsing 및 FormsDesign이라는 3개의 설정 파일을 만듭니다.

먼저 코드를 작성할 때 선호하는 형태로 창 레이아웃을 배치합니다. 필자의 경우 도구 창을 모두 자동 숨김 모드로 설정하여 코딩 공간을 최대한 확보한 상태로 작업할 때가 많습니다. 그림 6은 필자가 이러한 창 레이아웃에 맞게 도구 창을 어떻게 배치했는지 보여 줍니다. 각자 선호하는 방식대로 수정하여 사용하면 됩니다. 다음으로 도구 > 설정 가져오기 및 내보내기로 이동하여 설정 가져오기 및 내보내기 마법사를 시작합니다. 선택한 환경 설정 내보내기를 선택하고 다음을 클릭합니다. 창 레이아웃 확인란만 선택하고 다음을 클릭합니다. 설정 이름을 CodeWritingWinLayout.vssettings로 지정하고 마침을 클릭합니다. 필요한 세 가지 설정 파일 중 첫 번째 파일을 만들었습니다. 위 단계를 반복하여 나머지 두 가지 설정 파일을 만듭니다. 물론 창 레이아웃을 변경하고 파일 이름을 서로 다르게 지정해야 합니다. 필자의 경우 CodeBrowsingWinLayout.vssettingsFormsDesignWinLayout.vssettings로 지정했습니다.

큰 이미지를 보려면 클릭하십시오.

그림 6. 코딩 작업에 적합한 창 레이아웃(큰 이미지를 보려면 클릭하십시오.)

2단계. 설정 파일을 가져오는 매크로를 만듭니다. 설정 파일을 만든 후에는 각 설정 파일을 가져오는 매크로를 3개 만들어야 합니다. 아래 코드 3을 보면 이 코드가 얼마나 간단한지 알 수 있습니다.

Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics
Imports System.IO

Public Module Module1

  Public Sub ImportWinLayoutCodeWriting()
  End Sub

  Public Sub ImportWinLayoutCodeBrowsing()
  End Sub

  Public Sub ImportWinLayoutFormsDesign()
End Sub

End Module

코드 3. 설정 파일을 가져오는 매크로 코드

3단계. 도구 모음에 단추를 추가합니다. 이제 창 레이아웃을 변경하는 실제 단추를 만들어야 합니다. 도구 > 사용자 지정. . .을 차례로 클릭하고 명령 탭을 클릭합니다. 범주 목록 상자에서 매크로를 선택한 다음 목록을 아래로 스크롤하여 방금 작성한 세 가지 매크로를 찾습니다. 이 세 개의 매크로는 각각 MyMacros.Module1.ImportWinLayoutCodeWriting, MyMacros.Module1.ImportWinLayoutCodeBrowsing, 및 MyMacros.Module1.ImportWinLayoutFormsDesign으로 표시됩니다(그림 7 참조). 각 명령을 클릭하여 Visual Studio 도구 모음으로 끌어 놓습니다. 이제 도구 모음에 새로 추가한 명령을 마우스 오른쪽 단추로 클릭하고 명령의 이름을 좀 더 간단하게 바꿉니다.

그림 7. 사용자 지정 대화 상자를 사용하여 도구 모음에 매크로 추가

사용자 지정 대화 상자를 닫아 사용자 지정 내용을 저장합니다. 이제 여러분만의 창 레이아웃 선택기가 완성되었습니다. 도구 모음에서 새 단추를 클릭하여 사용해 보십시오. 도구 > 옵션. . . > 환경 > 키보드 페이지로 이동하여 이 명령에 바로 가기 키를 할당할 수도 있습니다..

코드 조각

코드 조각은 Visual Studio 2005에 새로 추가된 생산성을 크게 향상시키는 기능 중 하나로, 이를 통해 for 루프 입력과 같은 지루한 입력 작업 없이 코드 조각을 빠르게 추가할 수 있습니다. 또한 이 기능은 네트워크로 데이터를 전송하는 등의 특정 작업을 수행하는 방법을 보여 주는 템플릿을 제공합니다. 기본 제공 C# 조각은 대부분 반복적인 입력 작업을 최소화하는 데 도움이 되는 첫 번째 유형이고, 기본 제공 VB 조각은 대부분 특정 작업에 대한 코드를 보다 쉽게 작성할 수 있게 해 주는 두 번째 유형입니다.

코드 조각은 두 가지 방법으로 삽입할 수 있습니다. 코드 편집기에 코드 조각의 별칭을 입력하고 Tab 키를 두 번(VB의 경우 한 번) 누르면 코드 조각을 바로 삽입할 수 있습니다. 코드 조각을 삽입한 후에는 Tab 키와 Shift+Tab을 눌러 코드 조각의 여러 필드로 이동할 수 있습니다. 이 기능을 사용하면 수정이 필요한 코드 부분을 신속하게 변경할 수 있습니다. C#의 코드 조각 별칭에는 IntelliSense도 지원됩니다. IntelliSense 목록에서는 코드 조각 아이콘을 통해 코드 조각 항목을 구별할 수 있습니다.

그림 8. 코드 조각을 완벽하게 지원하는 IntelliSense

코드 조각을 삽입할 때 코드 조각의 별칭이 기억나지 않는 경우에는 코드 편집기에서 "Ctrl+K, Ctrl+X"를 누르거나 마우스 오른쪽 단추를 누르고 코드 조각 삽입...을 선택하면 됩니다. 그러면 코드 조각 선택기가 표시되며, 여기에서 현재 프로그래밍 언어에 사용할 수 있는 모든 코드 조각을 탐색하고 삽입할 코드 조각을 선택할 수 있습니다. 이 코드 조각 삽입 방법은 C#과 Visual Basic에서 모두 사용할 수 있습니다. Visual Basic 사용자는 이 방법 외에도 코드 조각 별칭의 앞부분 몇 글자와 "?"를 입력한 다음 Tab 키를 눌러 코드 조각을 삽입할 수도 있습니다. 그러면 모든 코드 조각 별칭이 사전순으로 나열된 목록이 표시되며 입력 항목과 가장 근접한 코드 조각 별칭이 강조 표시됩니다. 이 기능은 Visual Basic 사용자에게만 제공됩니다.

큰 이미지를 보려면 클릭하십시오.

그림 9. C#에서 코드 조각 삽입(큰 이미지를 보려면 클릭하십시오.)

필자는 코드 조각 기능에서 가장 흥미로운 부분은 자신만의 코드 조각을 만들어 개인적으로 사용하거나 커뮤니티와 공유할 수 있는 점이라고 생각합니다. 물론 다른 개발자가 만든 코드 조각을 다운로드할 수도 있습니다.

Visual Studio에서 손쉽게 자신만의 코드 조각을 만들 수 있습니다. 자세한 방법은 예제를 통해 살펴보도록 하겠습니다. 필자는 작업에 도움이 될 만한 간단한 유틸리티를 자주 작성합니다. 이러한 유틸리티 중 상당수는 파일을 열고 몇 가지 처리 작업을 수행한 후 파일을 닫는 공통적인 패턴을 가집니다. 필자가 코드 조각을 만드는 방법은 다음과 같습니다.

1단계: XML 파일을 만듭니다. 각 코드 조각은 XML 파일에 들어 있습니다. Visual Studio에서 파일 > 새로 만들기. . . > 파일. . .로 이동한 다음 XML 파일 형식을 선택합니다.

그림 10. 새 XML 파일 만들기

2단계: 코드 조각을 정의합니다. 흥미롭게도 코드 조각을 만들기 위한 코드 조각도 있습니다. 파일의 둘째 줄에서 Ctrl+K, Ctrl+X를 누르고 Snippet 코드 조각을 선택하면 코드 조각 파일의 템플릿이 자동으로 삽입됩니다.

큰 이미지를 보려면 클릭하십시오.

그림 11. XML 코드 조각을 사용하여 다른 코드 조각 만들기(큰 이미지를 보려면 클릭하십시오.)

제목, 만든 이, 바로 가기 및 설명 필드는 이름만으로도 쉽게 이해할 수 있으므로 자세히 설명하지 않겠습니다. <Snippet> 태그 내의 내용에 대해서는 설명이 필요한데, 아래 예제를 살펴보는 편이 가장 이해가 빠를 것입니다.

기본적으로 </Code> 태그 내에 있는 <![CDATA[...]]> 태그에 모든 코드를 삽입하게 됩니다. 사용자가 쉽게 필드를 바꿀 수 있도록 하려면 해당 필드를 "$" 문자 한 쌍으로 감싸면 됩니다. 아래의 예제에서는 코드 조각 사용자가 StrmReader, FilePath, Line의 세 가지 리터럴을 쉽게 바꿀 수 있도록 했습니다. 이 세 가지 리터럴은 CDATA 섹션 내에서 "$" 문자 쌍과 함께 사용되었습니다. 또한 이 세 개의 리터럴은 <Declarations> 요소 내에 각각 정의해야 합니다. 각 리터럴에는 ID와 기본값(옵션)을 지정합니다.

예리한 독자는 코드 조각에 $end$라는 정의되지 않은 리터럴이 있다는 점을 알아차렸을 것입니다. 이 리터럴은 사용자가 코드 조각 필드를 모두 채운 후에 Enter 키를 눌렀을 때 커서의 위치를 지정하는 특수 리터럴입니다. 예제에는 나와 있지 않지만 $selected$라는 특수 리터럴도 있습니다. $selected$ 리터럴은 코드 조각이 SurroundsWith 유형인 경우에만 의미가 있으며 코드 감싸기...를 사용하여 이러한 유형의 코드 조각을 삽입했을 때 선택한 코드 조각이 들어갈 위치를 정의합니다.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippet Format="1.0.0" xmlns="">
    <Title>File Processing</Title>
    <Author>James Lau</Author>
    <Description>Opens a file, does some processing, and then closes the file.</Description>
    <Code Language="CSharp">
   StreamReader $StrmReader$ = null;
      $StrmReader$ = new StreamReader($FilePath$);
      string $Line$;
      while (($Line$ = $StrmReader$.ReadLine()) != null)
         // Perform some processing
   catch (IOException ioex)
      // Handle exception

코드 4. 샘플 코드 조각 내용

Visual Studio 시작 페이지 사용자 지정

Visual Studio 2005의 새로운 시작 페이지에는 MSDN 뉴스의 최신 정보를 제공하는 라이브 RSS 피드 외에 다른 기능도 포함되어 있습니다. 시작 페이지에서 다른 RSS 피드를 읽으려는 경우 도구를 선택하고 옵션. . ., 환경을 차례로 선택한 다음 시작 페이지를 선택하여 시작 페이지 뉴스 채널에서 URL을 편집하는 방법으로 RSS 뉴스 채널을 사용자 지정할 수 있습니다. Visual Studio를 실행할 때마다 자동으로 시작 페이지가 표시되지 않도록 하려면 같은 옵션 페이지의 시작 시에서 빈 환경 표시를 선택하여 이 동작을 변경하면 됩니다.

팀 설정

Visual Studio 2005에는 팀 설정이라는 잘 알려지지 않은 새로운 기능이 있습니다. 대부분의 개발자는 팀 환경에서 작업하는데, 이 경우 팀 설정 기능을 사용하면 보다 빠르게 팀 코딩 규칙을 적용하거나 Visual Studio를 설정할 수 있습니다.

팀 내에 코드 서식에 대한 기본 규칙 집합을 적용하려는 경우를 가정해 봅시다. 규칙을 지정하고 각 팀원이 해당 규칙에 맞게 IDE 옵션을 사용자 지정하도록 하는 대신 설정 파일을 만든 다음 팀원이 이 파일을 가리키도록 하면 간단히 해결됩니다. 팀 설정 파일이 업데이트되면 사용자가 다음 번 Visual Studio를 시작할 때 설정 파일이 자동으로 기존 설정을 덮어 씁니다. 이 기능을 활용하는 방법은 다음과 같습니다.

1단계: 설정 파일을 만듭니다. 팀 설정을 사용하여 원하는 모든 IDE 사용자 지정 내용을 적용할 수 있습니다. 개발자가 팀 설정 기능을 사용하는 가장 일반적인 설정은 코드 서식 지정 설정이겠지만 글꼴 및 색, SourceSafe 설정, 바로 가기 키, 메뉴 사용자 지정 등 내보낼 수 있는 모든 Visual Studio 설정에 이 기능을 사용할 수 있습니다. Visual Studio에서 원하는 설정을 사용자 지정한 다음 도구 > 설정 가져오기 및 내보내기. . .를 사용하여 알려진 위치로 내보내면 됩니다. 이때 다른 팀원과 공유하려는 설정 집합만 내보내는 것이 중요합니다.

2단계: UNC 경로에 설정 파일을 넣습니다. 팀원이 액세스할 수 있는 네트워크 경로에 1단계에서 내보낸 설정 파일을 복사합니다. 필자의 경우 \\jameslau\public\teamsettings.settings에서 팀 설정 파일을 공유했습니다.

3단계: 팀 설정 경로를 변경합니다. 팀원이 팀 설정 경로를 변경하여 팀 설정 파일을 가리키도록 합니다. 이 작업은 도구 > 옵션. . . > 환경 > 설정 가져오기 및 내보내기에서 수행할 수 있습니다. 팀 설정 파일 사용 확인란을 선택하고 팀 설정 파일의 경로를 지정하면 됩니다.

그림 12. 팀 설정 경로를 변경할 수 있는 옵션 대화 상자

/resetuserdata 스위치

필자가 소개할 마지막 팁은 /resetuserdata 스위치와 관련이 있습니다. 이 스위치는 Visual Studio가 복구할 수 없는 상태로 손상되었을 때 Visual Studio를 기본 상태로 재설정하는 데 사용됩니다. 이러한 문제의 예로는 창 레이아웃 파일 손상, 메뉴 사용자 지정 파일 손상 또는 바로 가기 키 파일 손상 등이 있습니다. 책임의 부인: 이 스위치를 사용하면 모든 환경 설정 및 사용자 지정이 손실됩니다. 따라서 이 스위치는 공식적으로 지원되지 않으며 Microsoft에서도 이 스위치를 공개적으로 알리지 않습니다. 즉, 명령 프롬프트에서 devenv.exe /?를 입력하더라도 이 스위치는 표시되지 않습니다. 이 스위치는 환경 문제가 발생한 경우 최후의 수단으로만 사용해야 하며, 스위치를 사용하는 경우 먼저 환경 설정을 내보내 백업해야 합니다.

이 스위치를 사용하려면 다음을 수행합니다.

  1. Visual Studio 2005의 인스턴스를 모두 종료합니다.
  2. 시작을 클릭하고 실행...을 선택합니다.
  3. "devenv.exe /resetuserdata"를 입력합니다.

이 명령을 사용하면 몇 분 동안 Visual Studio가 정리되고 처음 상태로 설정됩니다. 이때 작업 관리자를 열어 devenv.exe 프로세스가 실행 중인지 여부를 확인할 수 있습니다. 실행이 종료되면 Visual Studio를 다시 시작할 수 있습니다. 그러면 컴퓨터에서 Visual Studio를 처음으로 실행할 때처럼 처음 실행 대화 상자가 다시 표시됩니다.


Microsoft는 Visual Studio에서 유용한 생산성 기능을 제공하기 위해 끊임없이 노력하고 있습니다. 여기에서 소개한 팁을 유용하게 사용하여 Visual Studio 고급 사용자가 될 수 있기를 바랍니다. Visual Studio IDE에 대한 의견이나 피드백 또는 제안 사항이 있는 경우 언제라도 jameslau@microsoft.com으로 연락하시기 바랍니다.