xcode에 따로 line number를 알려주는 기능은 없는듯 하다. 따라서 다음과 같이 wc를 이용해서 계산해야 할 듯.

find . \( -name '*.m' -or -name '*.c' -or -name '*.h' \) -print0 | xargs -0 wc -l

Think Fast with Firefox via Channy's

1. Unicode, UTF-8
Unicode에 대해 아주 피상적으로만 알고 있었는데, 이 위키피디아 문서는 한번 읽어볼 만하다. 원래 찾아보려던건, UTF-8은 유니코드를 표현하기는 하지만 유니코드가 아닌 유니코드의 변종인건가? 였는데, 결론은 UTF-8도 유니코드라는것. 좀더 정확히 표현하면 유니코드 표준 인코딩방식 중 하나다. 사실 유니코드 인코딩방식이 몇 개 안되고 그중에서 UTF-8이 가장 많이 쓰인다. 따라서 UTF-8이 가장 대표적인 유니코드 인코딩방식이다.

2. size
UTF-8이 가장 많이 쓰이게 된건 ascii와 호환되고, ascii가 1byte로 표현되니 용량이 작기때문이다. 한글은 UTF-8에서 3byte로 표현되니 size면에서는 효율적이지 않다. 같은 기준으로 본다면 한글은 euc-kr이 가장 효율적이다. euc-kr은 ascii와 호환되고, ascii가 1byte로 표현되며, 한글은 2byte로 표현된다.

3. 호환성
호환성 면에서는 UTF-8이 euc-kr보다 좋을 것이다. 외국에서 만들어진 소프트웨어들은 euc-kr을 지원하지 않을 확률이 클테니까. 물론 어차피 한글을 지원하는 소프트웨어는 euc-kr을 지원할 것이고(아직까지는) 한글을 지원하지 못하는 소프트웨어는 한글을 UTF-8로 인코딩해봐야 제대로 보여주지 못한다.
국내 컴퓨터 환경만 고려한다면 UTF-8을 지원하지 못하는 소프트웨어들이 꽤 있기때문에 아직까지는 euc-kr이 좀더 호환성이 높을 수는 있으나 모든 환경이 유니코드로 가고 있는 것은 분명하다.

4. 어떤 인코딩인지 정체를 밝혀라
유니코드를 사용한다고 해서 호환성 이슈가 다 해결되는건 아니다. 유니코드를 실제로 인코딩하는 방식이 여러 개라서 해당 문서가 어떤 인코딩방식을 쓰는지를 따로 명시해야만 한다. UTF-8인지 16인지 32인지, 혹은 유니코드가 아니라 euc-kr 등인지.

• XML 문서는 맨 첫 부분에서 인코딩을 명시하게 되어있다. 없다면 default는 ascii겠지.
• HTTP 프로토콜에서는 전달하는 데이타가 어떤 인코딩인지를 명시하는 필드가 포함되어 있다. 그럼에도 불구하고 웹브라우저는 사용자가 직접 인코딩을 바꿀 수 있는 기능을 따로 제공한다. 아마도 초기에 웹마스터나 웹프로그래머들이 html 파일의 인코딩방식을 제대로 명시하지 않는 경우가 많아서였을듯.
• MS 윈도우즈에서는 텍스트파일을 저장할때 유니코드 문서의 경우 첫 2~3 byte에 인코딩 정보를 추가한다. 이걸 BOM(Byte Order Mark)라고 부른단다.
• 텍스트 파일은 개발자에게는 중요한데, 왜냐하면 소스코드가 텍스트 파일로 저장되기 때문이다. 문제는 이 텍스트 소스파일에 인코딩정보를 표시할 마땅한 방법이 없다는 것이다. 없지는 않고 있기는 한데 표준화된 방법이 없다고 해야할까? ascii, UTF-8, euc-kr 어느 것이건 ascii 문자는 동일하다. 따라서 소스코드 자체는 별 문제가 없고, 한글로 달아놓은 코맨트만 깨져보이게 된다.
• 웹 URL. 즉 브라우저 창에 입력하는 주소는 ascii가 아닌 경우는 %로 시작하는 percent encoding을 하게 되어있다. percent encoding되어 있으면 ascii가 아니라는 것은 알 수 있지만 어떤 인코딩의 문자인지는 여전히 알 수 없다. 따라서 이건 웹서버 단위로 설정하게 되어있다.

어떤 인코딩인지 정체를 밝히는 일에는 문제가 많은데 앞으로는 UTF-8로 통일되면서 문제가 줄어들겠지만 깔끔하게 해결될때까지는 시간이 꽤 걸릴것 같다.