블로그는 귀차니즘

  Diablo 라는 이름의 게임은 어지간히 게임을 한 번쯤 해보셨던 사람이라면 아실만한 게임이지요. 블리자드 라는 이름에 걸맞게 재미있는 게임이었습니다. 아시다시피 스타크래프트를 비롯하여 디아블2로 같은 게임이 벌써 근 10년이 되어가는 시점에 아직도 플레이하는 사람은 많습니다. 그만큼 인기가 있다는 것이겠죠?
  그런데 오늘 게임 페스티벌에서 드디어 공개가 된거 같더군요. 아래는 플레이 동영상의 스크린샷입니다.







  대화하는 장면이 약간 바뀐것과 밖 초원의 느낌이 WOW와 닮아있는 점이 기존의 디아블로2의 칙칙한 분위기와는 대조되는 장면이라고 할 수 있습니다. 동영상을 보다보니 꽤나 재미있게 보이긴 하더군요. 던전시즈2라는 게임을 재미있게 즐겼었기에 이 것도 기대가 꽤나 됩니다.
  공격방식은 약간 스피드틱하게 바뀐 것 같긴 합니다. 디아블로2를 한지가 오래되어서 기억에 잘 나지는 않지만 휠윈드와 체인 라이트닝같은 것으로 쓸고 다니는 그 지루함에서 벗어날 수 있을까가 제일 먼저 궁금하더군요. 있었던 일을 다시 반복할 정도로 어리석지 않은 회사다 보니 그런 것에 대한 문제점을 없애려 많이 노력할 것이라 생각됩니다.
  하지만 문제점은 역시나 스타크래프트2, 디아블로3가 나온다면 개인 스킬연마는 어떻게 될지 걱정이 앞서는군요^^. 나오기까지 시간은 무척 오래 걸리겠지만 걱정이 되는건 사실입니다.^^ 그럼 미래의 플레이를 상상하시며 오늘도 즐거운 하루 되세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  회사에서 Borland C++ 6.0 Enterprise 버젼으로 기존에 존재하던 프로그램을 수정해야 할 일이 생겼는데 어떻게 하다보니 기존에 없던 새로운 디자인의 컨트롤을 제작하여 사용해야 하는 것이었습니다. 그렇게 대단한 일도 아니고 고급 기능을 원하는 컨트롤도 아니라서 일단 제작을 하다보니 대충대충 해도 쉽게 되더군요. 그래서 정리해 보기로 했습니다.

1. Codegear Package 생성



  일단 VCL 컴포넌트를 만들기 위해서 Package를 생성해야 합니다. 그렇지 않고 따로 하는 것은 딱히 잘 모르겠네요. 일단 이 방법으로 하여 컴포넌트 설치까지는 무난하게 진행 되니 따라 하시면 될것 같습니다.

2. Package 프로젝트를 이름 지정하여 저장



  패키지를 선택하여 생성버튼을 누르면 해당 프로젝트에 대해서 VS.net 처럼 프로젝트의 이름을 바로 묻는 것이 아니기에 추가할 때는 임시로 이름을 붙이고, 저장할 때 해당 파일을 저장하게 되며, 그 파일 내부의 동일 클래스명은 자동으로 바꿔집니다. 일단 Codegear 에서는 추가하면 저장하는 기능을 먼저 생각하는 것이 좋더군요.

3. 컴포넌트 생성





  이제 컴포넌트를 생성해야 합니다. New -> Other 메뉴로 들어가시면 해당 창이 표시되며 해당 창에서 보나마나 설명할 것도 없이 Component 를 선택 후 OK 버튼을 살포시 눌러줍니다.

4. 기본 베이스 컴포넌트 선택하기





  컴포넌트를 제작하기 위해 기본 Base Class 로 사용할 컴포넌트를 선택하는 화면 입니다. 여기서 선택하는 클래스가 기본 클래스로 등록되며 이 클래스의 동작에 많은 영향을 받게 됩니다. 그래서 하나를 신중히 생각하고 비슷한 쪽으로 선택을 하면 되겠습니다. 전 일단 TGroupBox 를 선택해봤습니다.

5. 컴포넌트 이름 지정하기



  해당 컴포넌트를 생성했으므로 이 컴포넌트가 폼에 컨트롤을 배치할 때 어떤 팔레트 위치에 어떤 이름으로 존재하게 될 것인지를 지정하게 됩니다. 이 부분에서 이상하게 지어버린다면 평생 이 컴포넌트가 존재하고 사용되는한 이상한 이름으로 되겠죠^^ 신중히 선택해 줍시다.

6. 컴포넌트 저장하기

  프로젝트와 마찬 가지로 컴포넌트를 추가한 다음에도 따로 저장버튼을 눌러 파일을 저장해주어야 합니다. 저도 이게 맞는 건지 아님 다른 방법이 있는 것인지는 모르겠지만 약간 불편한 것 같긴 하군요.

7. 코드 추가하기

TTestGroupbox.h (Language : cpp)

1. //---------------------------------------------------------------------------
2.  
3. #ifndef TestGroupBoxH
4. #define TestGroupBoxH
5. //---------------------------------------------------------------------------
6. #include <SysUtils.hpp>
7. #include <Classes.hpp>
8. #include <Controls.hpp>
9. #include <StdCtrls.hpp>
10. //---------------------------------------------------------------------------
11. class PACKAGE TTestGroupBox : public TGroupBox
12. {
13. private:
14. protected:
15.     __fastcall void Paint();
16. public:
17.     __fastcall TTestGroupBox(TComponent* Owner);
18. __published:
19. };
20. //---------------------------------------------------------------------------
21. #endif
22. 
     

 

TTestGroupBox.cpp (Language : cpp)

1. //---------------------------------------------------------------------------
2.  
3. #include <vcl.h>
4.  
5. #pragma hdrstop
6.  
7. #include "TestGroupBox.h"
8. #pragma package(smart_init)
9. //---------------------------------------------------------------------------
10. // ValidCtrCheck is used to assure that the components created do not have
11. // any pure virtual functions.
12. //
13.  
14. static inline void ValidCtrCheck(TTestGroupBox *)
15. {
16.     new TTestGroupBox(NULL);
17. }
18. //---------------------------------------------------------------------------
19. __fastcall TTestGroupBox::TTestGroupBox(TComponent* Owner)
20.     : TGroupBox(Owner)
21. {
22. }
23. //---------------------------------------------------------------------------
24.  
25. void __fastcall TTestGroupBox::Paint()
26. {
27. Canvas->TextOutA( 0, 0, "테스트" );
28. }
29.  
30. namespace Testgroupbox
31. {
32.     void __fastcall PACKAGE Register()
33.     {
34.         TComponentClass classes[1] = {__classid(TTestGroupBox)};
35.         RegisterComponents("Samples", classes, 0);
36.     }
37. }
38. //---------------------------------------------------------------------------
39.  

  일단 GroupBox 자체에서 Paint 메소드가 virtual 함수로 지정되어 있었고, 수정이 가능하기에 간단하게 이를 override 하여 기존에 존재하던 그룹박스의 이미지를 제거하고 문자열을 간단히 추가하도록 해봤습니다. 그런 다음 컴파일을 하여 인스톨 하면 됩니다.

8. 컴파일 후 인스톨 하기

  Build 메뉴 혹은 Make 메뉴를 선택하시고 Install 메뉴를 선택하시면 해당 패키지가 설치 됩니다. 만약 에러가 있다면 문법적 에러가 있을 것이고 해당 에러를 제거하신 뒤, 다시 설치하시면 됩니다.

9. 컴포넌트 사용하기



  이제 컴포넌트를 사용해 보는 일이 남았군요. 일단 New -> Form 을 클릭하신 다음 폼이 새로 추가 되면 오른쪽 아래 Tool Palette에서 TTestGroupBox 를 찾아 선택 후 창에 배치를 해봅시다. 짜잔~ 해당 창에 우리가 만든 TTestGroupBox가 배치 되었습니다. 해당 작동 그대로 "테스트"라는 문자열도 출력이 되는군요.

  이러한 방법을 통한 컴포넌트를 쉽게 생성해서 추후 원하는 GUI작업을 편하게 할 수 있을것이라 생각이됩니다^^. 편리한 방법이 계속해서 늘어나는 군요. 그럼 오늘도 즐거운 하루 되세요^^.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  컴퓨터의 문자 표현체계에 대해서 얼마나 알고 계산가요? 혹 아스키 코드, 아스키 확장코드, 유니코드 이 정도로 알고 있는것은 아니신가요?? 부끄럽지만 저는 유니코드의 표현 종류가 한 가지 종류가 아닌것은 알고 있었지만 만 면밀하게 알고 있지는 않았고 오늘 필요에 의한 자료를 찾아보면서 많이 부족했었다는 것을 깨닫게 되었습니다. 유니코드에도 생각외로 많은 종류의 표시집합이 존재하더군요. 예를 들면 UTF-8, UTF-16, UTF-32, UCS2, UCS4 같은 것 말이죠.
  그래서 libiconv 라이브러리를 사용하기 위한 자료를 찾다보니 이 것에 대해서 꽤나 중요하다는 생각이 문득 들더군요. 그래서 일단은 간소하게나마 정리하는게 좋지 않을까 해서 올려봅니다.

1. 조합형( JOHAB )

  비운이라고 생각해야 할까요? 한글을 표시하는 여러가지 표현방법 중 하나 입니다. 아주 옛날 도스에서 텍스트 에디터 같은 프로그램을 사용해보셨다면 조합형 한글, 완성형 한글등의 한글 표현 방법이 있다는 것을 아실겁니다. 그 중 하나이죠. 그런데 이 표시방법은 최근엔 거의 쓰이지 않습니다. 왜냐하면 Microsoft가 조합형이 아닌 완성형 한글을 채택했기 때문이라고 하네요. 역시 글로업 기업답게 파워가 막강한가 봅니다.
  어쨌든 표현 방식은 16비트를 사용하게 되며, 최상위 비트는 1, 그 후엔 5/5/5로 비트를 나누어 초성, 중성, 종성을 표시하게 됩니다. 말 그대로 조합형이니 만큼  만약 초성에 ㄱ, 중성에 ㅏ, 종성에 ㅇ이라는 코드를 넣게 되면 해당 글자는 "강"이라는 글자를 표시하는 비트가 되게 됩니다. 무척 편리한 방법입니다. 예전 하드웨어 성능이 별로 좋지 않을때 한글 오토마타를 처리하는 것에 있어 완성형 보다 CPU도 덜 쓰고, 복잡하지도 않아 조합형이 좋다고 얘기될 때가 많았었는데 말이죠.
  위 방식은 일반적으로 자주 쓰였던 조합형의 종류이고, 조합형에도 여러가지 종류가 있었다고 합니다.

  1. N바이트 조합형

    이 형태의 출력 방법은 자음 모음을 각각 분리하여 보관된 문자 형태에 맞는 값을 가지고 저장하는 방법입니다. 예를 들면 다음과 같네요. "블로그" 라는 문자에 대한 표기방법은 "ㅂㅡㄹㄹㅗㄱㅡ" 가 됩니다. 초기 때 자주 사용되었다고 하네요. 최대 5바이트까지 사용될 수 있었기 때문에 비효율성 때문에 사라졌을것 같습니다.

  2. 3바이트 조합형

    이 방법은 위에 언급한 초,중,종의 방식을 하나의 바이트로 사용한 것입니다. 만약 종성이 존재하지않는 "나"와 같은 문자일 경우 채움 문자를 적어넣었다고 합니다. n바이트 조합형 보다 효율적이기는 하지만 그래도 비효율 적이죠?

  3. 2바이트 조합형

    흔히 조합형이라고 하면 일컫는 방식입니다. 최상위 비트가 1, 초,중,종성을 각각 5비트로 나누어 표시한 방식이죠. 문제점은 두 번째 바이트의 최상위 비트가 0일 수 있기에 문자열 검색에서 문제가 생긴다고 합니다. 뭐 데이터가 NULL값과 동일하게 되어 문제점이 생기는 것 같습니다.

2. 완성형( EUC-KR )

  이 문자 집합은 KS X 1001, KS X 1003 인코딩을 사용하는 문자형 입니다. EUC(Extended Unix Code, 확장 유닉스 코드)라는 이름에 걸맞게 확장 코드 중 KR 즉 한글을 표현하는 방식입니다. 표현 방식은 일반 아스키 코드들은 KS X 1003형식을 배당하고, 그 이상의 한글 코드들은 KS X 1001형식을 배당하게 됩니다. 보통 많이 들으셨던 것이 바로 이 방식일 겁니다. 문자 코드의 영역은 대충 아래와 같이 된다고 하는군요.

• 0x21 ~ 0x2C: 특수 문자(문장 부호, 그림 문자 등), 한글 낱자, 괘선 조각, 외국 문자(히라가나, 가타카나, 그리스 문자, 키릴 문자 등)
• 0x30 ~ 0x48: 한글 글자 마디 영역. 자주 쓰이는 2350자만 가나다 순서대로 배열
• 0x49: 사용자 정의 영역 A
• 0x4A ~ 0x7D: 한자 영역. 4888자를 한글 독음 순서대로 배열했으며, 독음이 다르고 모습이 같은 한자는 중복
• 0x7E: 사용자 정의 영역 B

  이 문자 표현 형식의 단점은 모든 한글을 표현할 수 없는 단점이 생깁니다. 위에 언급했다 시피 자주 쓰이는 2350자만 배열하였기 때문에 문제가 되는 것이죠.

B0	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
A0		가	각	간	갇	갈	갉	갊	감	갑	값	갓	갔	강	갖	갗
B0	같	갚	갛	개	객	갠	갤	갬	갭	갯	갰	갱	갸	갹	갼	걀
C0	걋	걍	걔	걘	걜	거	걱	건	걷	걸	걺	검	겁	것	겄	겅
D0	겆	겉	겊	겋	게	겐	겔	겜	겝	겟	겠	겡	겨	격	겪	견
E0	겯	결	겸	겹	겻	겼	경	곁	계	곈	곌	곕	곗	고	곡	곤
F0	곧	골	곪	곬	곯	곰	곱	곳	공	곶	과	곽	관	괄	괆

  위 표는 KS X 1003에 해당하는 한글 부분 표 입니다. 위키피디아에 존재하는 것인데, 저장하는 방식이 일괄적이더군요. 일단 FIRST BYTE에 해당하는 문자는 제일 왼쪽 상단에 존재하는 B0 이라는 문자입니다. 그리고 두 번째 BYTE는 해당 글자에 위치하는 행+열에 해당되는 값이죠. 만약 "걔" 라는 문자를 저장하여 Binary로 표기하게 된다면 B0 C2 라는 데이터로 걔의 표기가 가능하게 됩니다.

http://ko.wikipedia.org/wiki/KS_X_1001_%ED%95%9C%EA%B8%80_%EB%B6%80%EB%B6%84_%ED%91%9C 

3. 확장 완성형( CP949 )

  완성형에서 자주쓰이는 2350자만 표현 가능하게 된 점이 있기에 모든 한글을 표기하기 위하여 추가적으로 확장된 방식입니다. 윈도우 95부터 채택되어 사용이 되었다고 하네요. 이 형태는 완성형인 EUC-KR과 하위 호완성이 존재합니다. 그리하여 A1~FE까지 사용하는 범위의 EUC-KR 과 더불어 빈 공간에 표현하지 못하는 한글을 추가적으로 맵핑하여 한 형태죠. 일단 이 것의 문제는 한글에 대한 순서가 빈공간에 차례대로 끼워넣은 만큼 순서에 대한 정렬 문제가 발생하게 됩니다.
 
4. UCS2

  흔히 많이 보는 Windows에서의 Unicode라고 생각하시면 됩니다. 이 형태는 각국의 문자표기에 따른 문제점을 해소하기 위해서 바이트의 문자 표기를 위해 등장했고, 일률적인 형태를 위해 영문 문자 마저 2바이트의 공간을 사용하게 됩니다. 결국 영문 같은 경우 공간을 낭비하게 된다고 생각할 수도 있겠군요. 하지만 전체가 2바이트이기 때문에 기타 UTF 방식의 표현 형태보다는 처리가 간단하다고 할 수 있습니다. Windows 같은 경우엔 내부적으로 UCS2 문자열을 사용하는 것으로 알고 있습니다. 그 이유는 속도 처리가 빨라서라고 하는군요^^.
  그래서 일반적으로 Windows 에서 개발 프로그래밍을 할 때에 L"아아아"와 같은 형태의 문자을 사용하면 UCS2의 방식을 따르게 됩니다. 물론 인코딩은 별개로 생각되야 하구요^^.

5. UCS4

  2바이트를 사용하는 UCS2에 비해 UCS4는 하나의 글자를 4바이트로 표현합니다. 그 만큼 문자의 공간 낭비가 심하다고 할 수 있죠. 하지만 UCS2에서는 65,536개 이상의 문자 표현이 불가능하기 때문에 나타난 방식이라고 생각이 되네요 일단 기본적으로 UCS2로 표현이 되는 문자들은 UCS로 처리 표시되고 그 영역을 벗어나는 부분만 UCS4로 처리를 하게 됩니다. 그리고 GCC 같은 경우 유니코드 문자열은 Windows개발툴과 다르게 UCS2가 아닌 UCS4로 사용되므로 주의가 필요합니다. 이에 대한 소스코드의 호환성을 잘못 썼다간 아이쿠 하는 사태가 발생할 수도 있다는 아주 무시무시한 사실이 @0@

6. UTF-8

  최근 많이 들어보셨던 단어 인가요? 개발자가 아닌 일반 사용자 분들도 최근엔 자주 보셨던 단어 일 겁니다. 바로 "URL을 항상 UTF-8로 보내기" 라는 옵션 때문이죠. 이 것의 체크 여부에 따라서 한글로 되어있는 그림이 보였다 보이지 않았다 하는 점 때문에 조금 이러저러한 문제가 있을겁니다. 하지만 결과적으로 말하자면 일단 UTF-8 형식을 사용하는 것이 옳다고 얘기할 수 있습니다. 왜냐구요? 이 것은 UCS2에서 말했다 시피 영문 코드마저도 2바이트 공간을 항상 사용해야 하기 때문에 존재하는 낭비를 줄이기 위해서 나온 형태 중에 하나 이기 때문이죠. 다만 다른 점은 UCS2, UCS4는 형태 그대로의 문자집합인데 비하여 하나의 인코딩 방법이라고 할 수 있습니다.

000000-00007F	0xxxxxxx	ASCII와 동일한 범위
000080-0007FF	110xxxxx 10xxxxxx	첫 바이트는 110 또는 1110으로 시작하고, 나머지 바이트들은 10으로 시작함
000800-00FFFF	1110xxxx 10xxxxxx 10xxxxxx
010000-10FFFF	11110zzz 10zzxxxx 10xxxxxx 10xxxxxx	UTF-16 서로게이트 쌍 영역 (yyyy = zzzzz - 1). UTF-8로 표시된 비트 패턴은 실제 코드 포인트와 동일

  가장 왼쪽은 유니코드 의 범위이고 이 범위에 따라서 해당 문자열에 관련된 Binary 값이 변환될 수 있습니다. 그리하여 문자열에 대한 영어 공간을 절약할 수 있는 것이죠.
  여기서 일어날수 있는 문제점은 바로 Microsoft 문서 편집기와의 호환성 문제 입니다. 흔히 BOM 이라고 불리는 Byte Order Mark 라는 것이 UTF-8에서는 아스키와의 확장성을 띄기 때문에 실제로 사용되지 않는데 최고의 문서 편집기(?)인 Notepad를 보시면 텍스트파일을 읽을 때 UTF-8에 해당하는 BOM마크를 필수적으로 써주어야 합니다. 그로인해 문제점이 생길 수 있을것이라 생각됩니다.

7. UTF-16

  이 인코딩은 UTF-8과는 약간 의미가 다릅니다. UTF-8 같은 경우 아스키와의 호환성, 공간절약을 목적으로 사용한 것이지만 UTF-16은 65,536개의 문자 이상의 표현할 수 없는 문자를 표현하기 위한 인코딩 방식입니다. 고로 UTF-16은 UCS2와 거의 동일하다고 보시면 됩니다. 그래서 Notepad에서도 저장방식이 UTF-8 방식과 Unicode Big Endian, Unicode Little Endian 이 있는 것 같군요. 표현하지 못하는 기본 방식에 대해서는 위키피디아를 참조 하시면 좋을 것 같습니다.

  후.. 너무 많군요.. 단순히 몇개 밖에 안될 것이라 생각했던 것이 너무나 많습니다. 저도 자료를 찾아 정리해가면서 적은 것이라 부정확한 정보가 존재할 수도 있겠군요. 하지만 한 곳의 정보만 참조한 것이 아니라 여러군데를 찾으면서 한 것이라 꽤 정확하게 정리한 것 같습니다. UTF-32 와 같은 추가적인 인코딩방법도 존재하는데, 이 런 인코딩을 필요할 때 자세히 알아서 필요할 때 사용하면 될것 같습니다.
  FreeType을 사용하게 되면서 결과적으로 아주 많은 것을 공부하게 된것 같습니다. 문자열 셋에 대한 여러가지 인덱스 들과 변환 방법을 통한 여러가지 종류의 텍스트 지원을 생각하다 보니 이런 저런 문제점이 발견되고 그 것을 해결하기 위해 자료를 찾다보니 여기 까지 오게 된것 같군요. 나름대로 쓰기 편하게 FontLoader같은 클래스를 만들고 있으니 잘 된다면 공개를 해보도록 하겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  요새 들어서 맨 처음 PSP를 사면서 만들고자 했었던 프로그램 제작이 자꾸 뒤쳐지는것 같아 어제는 맘을 단단히 붙들어 매고 FreeType 라이브러리를 다시 만져봤습니다. 기존 PSP 에 컴파일 해서 올리고 테스트 하고 하는게 너무 오래 걸려 어차피 멀티 플랫폼으로 개발된게 PC에서 MFC로 App를 개발해 테스트를 하기로 했습니다.
  결과 라이브러리 정리도 어느정도 끝내고 괜찮게 만들어지는 것 같더군요. 그런데 역시나 한글 출력에 있어서 문제가 발생합니다. @0@ 문자를 바꿔주어야 할 텐데 참 아직 감이 잡히지 않는군요. 그래도 예전 TTF, OTF 문서를 조금이나마 봐서 그런지 이런 저런 해결점이 어느정도 보이긴 합니다만 그래도 아직은 귀차니즘이 덜 가셨는지 빠르게 진행이 안되는군요^^.



  대충 진행 되더군요. 에구 그래도 너무 대충 만들었더니 영 그렇습니다^^; 마음 같아서는 바로바로 후딱후딱 해치우고 싶은데 그게 또 잘 안되는군요. 일단 이번 주말엔 어느정도 해결하여 제대로 된 프로그램을 제작해봐야 겠습니다^^.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  이틀 의 공백기간 후 올리는 포스팅 이군요. 퇴근시간이 약간 늦어지는 것 때문에 막상 도착하니 짧은 시간에 무엇을 할까 고심을 많이 했습니다. 최근 계속해서 알고리즘 트레이닝 북에 있는 문제를 하나씩 풀어가고 있긴 했지만 워낙 남은 시간이 짧아 조금 그렇더군요.

  그래서 오늘 마침 빨리 퇴근한 김에 수정하고 있는 프로그램에서 쓰고 있는 boost::tokenizer 를 보기로 했습니다. 아주 예전 C 부터 사용하던 분들이라면 strtok 함수를 이용하여 토큰을 분리하거나, 직접 코드를 작성하여 코드를 분리하곤 했습니다. 파싱을 통한 토큰 분리를 수행해 주는 여타 클래스도 존재하긴 합니다.
  그런 김에 boost::tokenizer를 보니 stl과 비슷한 방법으로 토큰 분리를 해주는 클래스를 보니 무척 반갑더군요. 그런데 문제는 하나 있었습니다. 일단 코드를 한 번 보도록 하겠습니다.

Tokenizer.cpp (Language : cpp)

1. #include <iostream>
2. #include <boost/tokenizer.hpp>
3.  
4. int main( int argc, char **argv )
5. {
6.     std::string aa = "a bb ccc ddd";
7.  
8.     boost::tokenizer<> Token(aa);
9.     for(boost::tokenizer<>::iterator Iter=Token.begin(); Iter!=Token.end();++Iter)
10.         std::cout << *Iter << "\n";
11.  
12.     return 0;
13. }

  위 코드 수행시 결과는 a\nbb\rccc\nddd 입니다. \n는 뉴라인이라고 생각하시면 결과를 추측하실 수 있겠죠? 간단하게 출력을 수행하는 부분인데, 기본적인 이 방법으로는 std::string 형인 aa에 한글이 섞여있는 문자열을 적을경우 분리가 불가능하며 심지어 에러를 표시합니다.
  그래서 선언을 봤는데 token_functions.hpp에 있는 seperator를 기본으로 사용하듯이 한글이나 2바이트 확장 아스키에 대해서는 추가로 seperator 클래스를 구현해주어야 하더군요.

sjis_seperator.cpp (Language : cpp)

1. class escaped_list_separator_sjis
2. {
3.   private:
4.     bool last_;
5.  
6.     enum {
7.         QUOTE     = '\"',  // 囲み記号
8.         SEPARATOR = ',',        // 区切り記号
9.         ESCAPE    = '\\',       // エスケープ記号
10.     };
11.  
12.     // マルチバイトコードの1byte目判定
13.     bool is_multibyte1(char c_)
14.     {
15.         unsigned char c = static_cast<unsigned char>(c_);
16.         return ((c >= 0x81 && c <= 0x9f) || (c >= 0xe0 && c <= 0xfc));
17.     }
18.  
19.     // マルチバイトコードの2byte目判定
20.     bool is_multibyte2(char c_)
21.     {
22.         unsigned char c = static_cast<unsigned char>(c_);
23.         return ((c >= 0x40 && c <= 0x7e) || (c >= 0x80 && c <= 0xfc));
24.     }
25.    
26.     // エスケープ文字の処理
27.     template <typename iterator, typename Token>
28.     void do_escape(iterator& next, iterator end, Token& tok)
29.     {
30.         if (++next == end)
31.             throw boost::escaped_list_error(std::string("cannot end with escape"));
32.  
33.         switch (*next) {
34.           case 'n':
35.             tok += '\n';
36.             break;
37.           case QUOTE:
38.           case SEPARATOR:
39.           case ESCAPE:
40.             tok += *next;
41.             break;
42.           default:
43.             throw boost::escaped_list_error(std::string("unknown escape sequence"));
44.         }
45.     }
46.  
47.     // マルチバイト文字の処理
48.     template <typename iterator, typename Token>
49.     void do_multibyte(iterator& next, iterator end, Token& tok)
50.     {
51.         tok += *next;
52.  
53.         if (++next == end)
54.             throw boost::escaped_list_error(std::string("cannot end with multi byte"));
55.         if (is_multibyte2(*next)) {
56.             tok += *next;
57.         } else {
58.             throw boost::escaped_list_error(std::string("unknown multi byte code"));
59.         }
60.     }
61.    
62.   public:
63.     escaped_list_separator_sjis(void) : last_(false)
64.     {
65.     }
66.  
67.     void reset() {last_=false;}
68.  
69.     template <typename InputIterator, typename Token>
70.     bool operator()(InputIterator& next, InputIterator end, Token& tok)
71.     {
72.         bool bInQuote = false;
73.         tok = Token();
74.  
75.         if (next == end) {
76.             if (last_) {
77.                 last_ = false;
78.                 return true;
79.             } else {
80.                 return false;
81.             }
82.         }
83.  
84.         last_ = false;
85.  
86.         for ( ; next != end; ++next) {
87.             switch (*next) {
88.               case ESCAPE:
89.                 do_escape(next, end, tok);
90.                 break;
91.  
92.               case SEPARATOR:
93.                 if (!bInQuote) {
94.                     ++next;
95.                     last_ = true;
96.                     return true;
97.                 } else {
98.                     tok+=*next;
99.                 }
100.                 break;
101.  
102.               case QUOTE:
103.                 bInQuote=!bInQuote;
104.                 break;
105.  
106.               default:
107.                 if (is_multibyte1(*next)) {
108.                     do_multibyte(next, end, tok);
109.                 } else {
110.                     tok += *next;
111.                 }
112.                 break;
113.             }
114.                }
115.         return true;
116.     }
117. };

Token.cpp (Language : cpp)

1. vector<string> fromCSV2_3(const string& csv)
2. {
3.     vector<string> data;
4.  
5.     boost::tokenizer<escaped_list_separator_sjis> tok(csv);
6.  
7.     copy(tok.begin(), tok.end(), back_inserter(data));
8.  
9.     return data;
10. }

  위와 같은 클래스를 구현해주고, 해당 tokenizer에서 사용하는 TokenizerFunc Template 인자에 넣어주면 됩니다. 어차피 Template 이라는 자체가 결과적으로는 Define 치환결과하고 동일하다고 볼 수 있으니까요. 예전 strtok혹은 개별 토큰 기능을 구현하기 보다는 이런 클래스를 사용한다면 에러가 더 적게 발생하지 않을까요? 당연한 말이겠지만 이미 이런 클래스들은 여러사람이 사용하고 문제점은 이미 검증되었으니까요.
  만약 이런 클래스 구현을 통한 확장 아스키 지원이 조금 걸리면 Unicode 변환 -> Tokenizing -> 확장아스키 변환 이런 방법도 있겠네요. 사실 최근 대세가 Unicode로 돌아선지 꽤 되었다 보니, 이미 Unicode 형태로 처리를 하고 있을지도 모르겠습니다. 그래도 예전에 사용했거나 필요할 때 이 글을 보면서 구현을 하면 될 듯 하군요. 그럼 오늘도 즐거운 하루 되세요..^^

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.