유니코드 한글의 각 음소를 분리하기

유니코드에서 한글은 0xAC00에서 0xD7A3 사이의 코드 값을 갖는다. 각 16진수값은 10진수로 표시하면 44032와 55203으로 총 11,172개이다. 유니코드 내 한글은 초/중/종성의 각 음소의 조합으로 표현된다. 즉 초성 19개, 중성 21개, 종성 28개를 조합하여 하나의 글자가 되는 것이다. 따라서 각 초,중,종성의 위치값을 계산하여 최종적으로 만들어지는 글자의 코드가 생성된다. 이 때 들어가는 값은 위치 값으로 0~해당 음소의 개수-1 만큼의 인덱스를 의미한다.

((초성 * 21) + 중성) * 28 + 종성 + 0xAC00

이를 역산하면 어떤 문자의 코드값으로부터 각 음소의 인덱스를 구할 수 있다.  즉 각 음소 중에서 몇 번 째 글자인지를 알 수 있게 된다.

초성 = ((문자코드 – 0xAC00) / 28) / 21
중성 = ((문자코드 – 0xAC00) / 28) % 21
종성 = (문자코드 – 0xAC00) % 28

이 때 계산된 값은 각 음소가 음소 문자 중에서 몇 번째 문자인지를 나타내는 위치값이다.
초성의 자모 코드 시작값은 0×1100, 중성은 0×1161, 종성은 0x11A8 이므로 이를 각각 더한다. 특히 종성이 없는 경우가 있기 때문에 종성에는 1을 뺀다.

초성의 자모코드 = 초성인덱스 + 0×1100
중성의 자모코드 = 중성인덱스 + 0×1161
종성의 자모코드 = 종성인덱스 + 0x11A8 – 1

구현

NSString에서 문자열 내 특정 글자를 뽑아오는 일은 characterAtIndex: 메소드를 사용하고 이 때 반환되는 값은 unichar 포맷이 된다. (unichar 는 unsigned short 타입의 변수형이다.)

unichar oneCode = [hangul characterAtIndex:i];

이를 위 과정을 통해 계산해서 초성 (및 중/종성)을 추출한 다음, 이를 다시 NSString으로 만들기 위해서는 stringWithFormat: 메소드를 사용한다. 이 때 포맷팅 파라미터는 %C (대문자)를 사용한다. 소문자 %c를 쓰는 것은 char 타입일 때 이다. (바꿔써도 무리는 없는 것 같더라)

코드

-(NSString *)getFirstCodeWithString:(NSString *)hangul
{
  NSString *result = @"";
  for ( int i=0; i<[hangul length];i++) {
    unichar oneCode = [hangul characterAtIndex:i];
    // 한글일 때만 처리한다.
    if ( oneCode >= 0xAC00 && oneCode <= 0xD7A3 ) {
      unichar firstCode = ((oneCode -0xAC00) / 28)/21;
      firstCode += 0x1100;
      result = [result stringAppendingString:[NSString stringWithFormat:@"%C",firstCode]];
    }
  }
  return result;
}

20120117 :: OSX의 메모리 상태 보는 법

맥은 얼마 쓰지도 않아서 메모리를 다쓴다?

윈도에서 맥으로 넘어와서 버리기 힘든 나쁜 습관 중 하나는 메모리의 상태를 걱정하는 일이다. 무슨 소린고 하니 마치 메모리 먹는 괴물처럼 맥은 시스템에 달린 램을 거의 대부분 써버린다. 시스템의 메모리는 활성상태보기(activity)라는 앱을 실행해서 확인할 수 있는데, 여기서 보면 “여유 메모리”에 진짜 여유가 있는 경우가 좀처럼 없기가 십상이다.

그래서 메모리의 여유 공간을 확보해주는 앱들도 유/무료로 많이 팔리고 있는 중인데, 꼭 이런 앱을 돌릴 필요가 있을까 싶은 생각이 든다. 물론 윈도에서의 메모리 확보 프로그램과는 달리, 이 앱들은 시스템에 해악을 끼친다고는 생각되진 않는다. 아무튼 이러한 일종의 ‘오해’는 맥의 메모리 관리 방법에 대한 무지에서 비롯된다고 생각되는데, 이런 메모리 정보를 어떻게 이해해야 할까?

먼저 활성상태보기 앱을 실행해보면 시스템 메모리가 현재 어떻게 사용되고 있는지를 보여준다. 각각의 내용은 다음과 같다.

  • 여유공간 : 말 그래도 여유공간이다. 시스템 메모리 중 사용되지 않고 있으며, 언제든 사용할 수 있는 공간이다.
  • 와이어드 : Wired 상태의 메모리는 특히 앱의 실행 코드가 올라가 있는 공간이다. 따라서 하드디스크 위의 가상메모리 공간으로 스와핑이 불가능하다.
  • 활성 : 활성 메모리 영역은 앱들이 정보를 올려두고 사용하는 공간이다. 메모리가 부족한 상황이 된다면 시스템은 이 영역의 데이터 중 당장 사용되지 않는 내용들을 가상 메모리로 옮겨주게 된다.
  • 비활성 : 아마 시스템을 사용하다보면 가장 많은 분량을 차지하게 되는 메모리 공간이다. 비활성 메모리는 최근에 종료한 앱이 사용했던 공간이다. 이 부분을 바로 해제해서 여유 공간으로 확보할 수 있지만, 실제로는 일반적인 사용자는 동일한 앱을 빈번히 종료/재시작하므로, 비활성 메모리에 이전 앱이 사용하던 정보를 남겨두면, 그 앱을 재실행할 때 빠르게 구동할 수 있다는 장점이 있다. 물론 메모리가 부족한 상황에서는 이 공간을 free 하여 필요한 메모리를 즉시 확보할 수 있다. 현재 시중에 나도는 메모리 확보용 앱은 이 비활성 메모리 영역을 해제해주는 것외에 하는 내용은 없다.

따라서 시스템에서 사용 가능한 메모리 공간은 “여유공간 + 비활성”의 크기 만큼이 되겠다. 그리고 이 두 영역을 합해도 필요한 메모리보다 부족하다면 시스템은 활성 메모리 중의 일부를 디스크로 옮겨서 필요한 메모리 영역을 확보하게 된다. 이 때 사용하는 가상 메모리의 크기가 VM이며, VM에 대해 얼마나 액세스했는가 하는 정보가 페이지출력/입력에 표시된다.

이 페이지 입력/출력의 양이 많으면 많을수록 더 많은 양의 메모리가 필요해서 그 만큼 페이징을 했다는 이야기이며, 하드디스크는 램에 비해 훨씬 더 속도가 느리므로 시스템의 전체적인 체감 성능이 떨어진 것처럼 느껴질 수 있다. 하지만 대부분의 경우에는 그 정도까지로 메모리를 사용하는 케이스는 좀 드물다.

맥이 메모리를 99%, 100%까지 쓰는 것은 메모리를 잘 못 관리하기 때문이 아니라, 그만큼 메모리를 잘 활용하고 있는 (그것도 극대화하여 사용) 증거이므로 굳이 메모리 관리 앱을 사용하여 여유 공간을 수동을 매번 잡아줄 필요는 없다.

덧 : 이는 몇 번 지적한 내용인데, 윈도용 메모리 확보 프로그램은 맥으로 치면 현재의 활성상태 메모리 영역에 있는 데이터를 디스크의 스왑공간으로 강제로 옮기는 기능을 수행한다. 따라서 일시적으로 여유공간이 증가하는 것처럼 보이지만, 필요이상의 하드디스크 액세스를 발생시키므로 오히려 앱을 사용하는 속도는 느려진다. 윈도에서의 메모리 관리도 시스템이 관리하는 것이 가장 낫다고 생각된다. 단, 윈도는 메모리 여유 공간이 제법 남아 있는 상황에서도 가상메모리로 페이징하는 일이 빈번하여 되려 같은 체감성능을 제공하는데 있어 더 많은 램 크기를 요구하는 경우가 많다.

참고자료 : http://support.apple.com/kb/HT1342?viewlocale=ko_KR&locale=ko_KR

20120109 :: [팁] 맥의 모니터만 잠자기

맥북 계열의 경우에는 화면 밝기를 최소로하면 거의 화면이 꺼진 것에 가까울만큼 어둡게 되지만 (이것도 꺼진 것은 아니고 아주 어둡게 켜지는 것임) 아이맥의 경우에는 화면 밝기를 최소로하더라도 어느 정도 밝기가 유지된다.

전력 소모를 줄이기 위해서 잠자기로 들어가게 해 두면, 무선 네트워크 연결이 해제되거나 돌아가던 작업이 중단되는 문제가 있어서 모니터만 재우는 기능이 꽤나 쏠쏠한데, 의외로 많은 커뮤니티에서는 이것을 터미널에서 셸 스크립트를 돌려서 구현하거나 하는 분들도 있더라.

그냥 Control + Shift + Eject를 누르면 화면만 잠자기 모드로 들어간다.

20120104 :: 애플스크립트로 주소록 일괄 수정하기

연락처에 많은 항목이 있더라도 사실 애플 스크립트를 써서 “성(Last Name)” 필드에 공백을 넣는 건 간단하다. 애플 스크립트 편집기를 열고 다음 코드를 입력한 후 실행해주면 모든 주소록에 등록된 성이 공백으로 바뀐다.

 

tell application "Address Book"
  repeat with anItem in every person
    set anItem's last name to " "
  end repeat
save
end tell

 

관련글 : 20111018 :: [OSX] Mail 앱에서 이름이 중복으로 들어가는 경우

20111222 :: 트위터 스팸DM 링크를 클릭 후 대처법

예전에도 한 번 올렸던 포스팅이지만, 트위터 세팅 페이지의 UI가 변경되어 다시 올려본다. 트위터에서 스팸 DM이 왔을 때 무심코 거기 링크를 클릭하면 자기도 모르는 사이에 스팸봇에게 자신의 트위터 계정을 연동시키는 결과를 초래한다. 덕분에 자신을 팔로하고있는 사람들도 스팸 DM에 시달리게 된다.

흔히, 이런 경우를 당하고 비밀번호만 바꾸라는 사람들이 있는데, 트위터의 외부 API는 토큰을 통해 인증을 하므로 한 번 인증되면 트위터 비밀번호와는 상관없이 계속 접근이 된다. 의심이 된다면 지금 한 번 트위터 비밀번호를 바꿔보시라. 그래도 아이폰 트위터 앱등을 통해서 그래도 트위터를 쓸 수 있다. 스팸봇도 똑같은 원리이므로 비밀번호를 바꾸는 것만으로는 스팸봇의 접근을 막을 수 없다.따라서 승인된 스팸봇의 연결을 해지하는 작업이 필수적이다.

트위터 우측 상단의 사람모양 아이콘을 클릭하여 Settings를 선택한다. 그러면 위의 그림과 같은 페이지가 나오는데, 여기서 Applications를 선택한다. 이 곳에는 자신의 트위터 계정과 연동되어 있는 앱들이 꽤 많이 나온다. 연동을 해제하고 싶다면 각 앱의 오른쪽에 있는 Revoke Access 버튼을 클릭하면 해당 앱의 접근이 차단된다. 사용하는 앱의 연결을 해제하면, 해당 앱에서 다시 비밀번호를 입력하고 승인 절차를 거치면 다시 사용할 수 있으므로 거침없이 클릭하자.

의외로 생각보다 엄청나게 많은 앱이 연동되어 있을 것인데, 종종 한 번씩 싹 해제해버리는 것도 나쁜 습관은 아닐 것 같다. 또한 간혹 스팸봇의 인증 과정에서 비밀번호를 털리는 경우도 있을 수 있으므로 비밀 번호도 바꿔주는 것이 좋다.

또한 참고로 페이스북에도 이런 스팸봇이 엄청나게 많다. 흔한 예로 최다 방문자 순위를 매겨준다는 앱들이 있는데, 모두 사기앱이다. 페이스북은 방문자 개념이 없는 듯 하고 (싸이와는 달리 다른 사람의 프로필을 꼭 가지 않더라도 소식 열람이 가능하므로) 있다 한 들 이를 앱에게 제공하는 API 따위는 없다. 그저 스스로를 홍보하는 글을 매일 올려 스팸 포스트만 양산하게 되므로 모두 지워버릴 것을 추천한다. (Privacy Setting의 Application 항목을 참고할 것)