SQLite3는 간단히 보기에는 너무나 성능이 좋은 local RDB 이다.
C++에서 직접 엑세스도 가능하고 dbexpress 로 간접 엑세스도 훌륭하다.
그래서 유명한 어플에서 SQLite를 쓰는 경우가 많아지고 있고, public domain 라이센스라
상용 사용에도 전혀 지장이 없고, WinCE 같은 플렛폼에서도 쓸수 있다니 알아둘 만한  가치가 있는 DB다.

그런데 한글 문제에 있어 여러 사람들이 고심하는 경우가 많다.
한글을 DB에 저장하는 방법은 크게 3가지다.

1. ansi : 지금 보고 있는 바와 같은 완성형 한글 코드를 그대로 넣는 방법.
2. UTF-8 : UTF-8로 엔코딩해서 넣고, 불러올때는 디코딩해서 보는 방법.
3. 유니코드 : 유니코드 자체를 넣는 방법.

때로 유니코드를 그냥 저장하려고 하는 경우도 있는데 이 경우는 좀 문제가 된다.
유니코드는 wchar_t 형으로 USHORT 형과 같다. 메모리 내에서 리틀엔디안으로 배열되는
문자열로 당연히 char나 byte 입장으로 보면 0 값이 많이 포함된다.
그러므로 기본적인 필드 입출력을 char * 타입으로 처리하는 SQLite 내부 라이브러리 함수의 asciiz 형 C/C++ 문자열 스타일에 있어서는 문자가 잘리는 현상이 생기기 때문이다.
하지만, 최근 유니코드가 대세이기 때문에 유니코드를 처리할 수 있는 함수를 SQLite 내부에 준비해 두고 있다.
...16 이라고 이름붙은 함수들인데, 이를 이용하면 유니코드를 다룰 수 있다고 한다.

늘상 다루는 멀티바이트 코드를 그냥 변환없이 그냥 저장하면 ansi 형이고 이 경우 거의 문제가 없다.
하지만 크게 2가지 문제가 있는데

1. GUI 툴에서 깨져 보인다.
2. 검색에서 있어 오검색이 나온다.

첫번째 문제는 GUI 툴에서는 기본 UTF-8로 엔코딩된 결과를 보여주기 때문에, UTF-8이 아닌 ansi
한글은 깨져 보이게 된다. 
GUI 툴에는 다음과 같은게 있는데, SQLite를 쓰는 사람이면 다 구비할 필요가 있다. 모두 공짜다.
(물론 유료 버전이 따로 있고 훨씬 기능이 좋다)
- SQLite Expert Personal
- SQLite3Manager
- SQLiteSpy
(이 외도 SQLite용 GUI 툴이 있다. 일단 필자가 설치해 본 것만 열거 했다.)

이 중에서 SQLite Expert Personal 가 기능이 제일 좋은데, 옵션에 보면 기본 문자를 ansi 형 ascii 로
다룰 것인지, UTF-8로 다룰 것인지. 선택할 수 있다.
기본 UTF-8로 되어 있는 것을 ansi 로 바꾸고 다시 프로그램을 기동해서 DB를 보면 한글이 그냥 보인다.
물론 sql 문에 한글을 쓰고 쿼리하는데 지장이 없다.

두번째, 검색에 있어 오검색이 있는데, 이는 SQLite의 문제라기 보다는 완성형 한글의 특성 때문에 발생하는 문제이다.
완성형 한글은 한글자가 2바이트로 구성되어 있고 각 바이트의 MSB가 ON 상태이다.
그로 인해, SQLite 가 검색할때는 한글 여부가 아니고 2바이트 ascii 코드로서의 한글을 찾게 되는데
앞 한글 반자와 뒷 한글 반자가 같은 패턴으로 매칭되는 현상이 생긴다.
이는 SQLite 뿐만 아니라 일반적인 ansi 자료의 text 검색에서도 늘 발생할 수 있는 문제이다.
(물론 한글의 경우를 구분해서 글자 단위로 검색해주는 경우에는 전혀 문제가 없지만 SQLite 경우는 한글인지 뭐 인지 전혀 구분하지 않는다)
SQLite 는 select  문에 검색을 의존하므로, 이 경우는 매우 드물지만 가끔 나타나기 때문에 매우 신뢰성 있는 검색이 요구된다면 ansi 가 아니라 UTF-8로 변환해서 한글을 저장하고 찾을 때도 UTF-8로 변환해서 찾으면 된다.
그러면 한글 문제는 깔끔하게 해결 된다. 물론 ansi 로 그냥 해도 일반적인 응용에는 전혀 문제가 되지 않는다.

그럼.