SSH 터미널, SCP에서 한글 사용

이 글은 동아리 linux 서버 사용을 위한 도움글로 작성되었습니다. MS Windows 환경에서 널리 사용되는 SSH 터미널인 PuTTY와 SCP 클라이언트인 WinSCP 를 기준으로 설명합니다.

현재 가동 중인 linux 서버인 그랑엘베르(IDC), 유리엘(넬방) 2대는 기본 설정에서 한국어(UTF-8)으로 설정되어 있다. 이 상태에서 쓴다고 가정하면 우선 터미널 셋팅은, (PuTTY 기준으로)

  • Window – Translation의 캐릭터 셋 항목을 UTF-8으로 해준다. (반면에 한국어 euc-kr; ko_KR.eucKR 을 쓰면 Font encoding으로)
  • Window – Appearance의 font를 한글이 가능한 고정폭 폰트로 설정한다. 그리고 스크립트가 한글인지 확인한다. (영어면 한글 입력이 보이지 않는다 )
  • 터미널 로그인을 한 후 쉘에서 $LANG, $LC_ALL † 환경 변수 값을 확인한다. 이 둘이 ko_KR.UTF-8 인지 확인할 것

여기까지 진행하면 PuTTY로 한글 입/출력이 가능한 상태로 서버에 로그인 할 수 있다.

덤으로 파일 이동을 위한 WinSCP 사용을 보자.

Continue reading “SSH 터미널, SCP에서 한글 사용”

검색어 인코딩 문제

현재 이 블로그는 wordpress 2.x 버젼으로 운영되고 있다. 한국어 번역 판이 있다는 것을 알지 못해서 그냥 영문판으로 쓰기 시작했었고, 그런 의미에서(?) 계속해서 그렇게 운영되고 있다.

그렇지만 UTF-8 기반이기 때문에 한국어 인코딩 문제는 없다 – 덤으로 서버로 사용되고 있는 유리엘이 최근 재설치 후에 기본 인코딩이 UTF-8이 되어서 파일 시스템 쪽과 호환성 문제도 없다. 사실 그래서 UTF-8이 아닌 방식으로 – 예를 들어 시스템 로케일(한글윈도우의 경우 UHC) 로 – URI를 보내는 구형 웹브라우져를 쓰는 경우 (혹은 호환성 모드에서 강제로 옛날방식으로 사용하는 경우), 이 홈페이지 전체에 있는 한글 이름 파일들 – 당연히 UTF-8으로 인코딩 된 이름 – 에 접근할 수 없게 된다.

잡설은 여기까지고, 이 블로그에서 사용되고 있는 몇 가지 플러그인 중에는 검색 엔진을 통해 유입된 트래픽을 추적해주는 유틸리티가 있다. 거기에서 검색어를 별도로 저장해주는데, 여기에 깨진 문자들이 한참 나타난다.

1 2000 search.naver.com : ����� id3 ���ڵ� vs. 윈도우 id3 인코딩
2 5074 search.naver.com : ����Ʈ���� vs. 벨라스트라즈
9 10052 web.search.naver.com : javascript select onchange ���� vs. javascript select onchange 막기
10 10892 search.naver.com : USB ���� vs. USB 붓팅
17 17796 search.daum.net : ȫ���Ա� �ϻ��� vs. 홍대입구 북새통
18 18209 search.daum.net : �ݵ�ط�Ͻ����� vs. 반디앤루니스사당점
19 18407 web.search.daum.net : �Ϳ� ������ vs. 와우 동인지
20 18795 search.daum.net : ¥��� ������� vs. 짜증나는 동부지검

(앞 자리는 다음/네이버를 통해 유입된 것들의 일련번호다; 빈 번호들은 영문 검색어만 있는 경우)

vs. 앞 쪽이 원래 문장, 뒷 쪽이 euc-kr로 풀어낸 후 utf-8 인코딩으로 재해석한 경우.
국제화된 – 그러니까 다국어를 다뤄야하는 – 세계에서 우리나라 사이트들만 다루니까 euc-kr로 버티는 건진 모르겠지만; 그런 의미에서 네이버랑 다음은 꽝이네효 가능하면 UTF-8만 쓰려고하는 이 블로그에선 좋지 않단 말이지[…]

그래서 간단한 PHP 코드를 짜서 해결하고 문제를 일으켰던 wp-slim-stats 에도 약간의 패치를 가했음 – 슬프게도 이 플러그인은 더 이상 업데이트가 이루어지지 않고 있음

$result = mysql_query("SELECT id, searchterms from wp_slim_stats where searchterms != ''
  and ( domain like  %daum%' or domain like '%naver%' )");
while( $row = mysql_fetch_array($result) )
{
    $id = $row['id'];
    $term = $row['searchterms'];
    $term = iconv( "euc-kr", "utf-8", $term );
    mysql_query( "Update wp_slim_stats set searchterms='$term' where id = $id" );
}

이런 코드로 해결. iconv가 킹왕짱 …짜 놓고보니 SQL 효율/보안이랑은 천만광년쯤 거리가 있을듯한 코드네(…)

wp-slim-stats 에선 naver, daum을 검색어 추출코드에서 따로 인식하게 하고, iconv를 한 번 적용시키는 걸로 했음.

결론: 네이버나 다음에서 다국어 검색을 할 생각이 있다면 – 없는 것 같지만 UTF-8 지원 좀 해줬으면 함.

Updated 2009-10-15: 네이버와 다음 모두 UTF-8을 지원하기 시작했다. 하지만 여전히 기존 시스템도 유지하고 있다. 검색엔진의 referrer 주소의 각 인자를 살펴보면 네이버는 ie=utf8 인 경우, 다음은 enc=utf8 인 경우 UTF-8로 인코딩된 검색어가 사용된다.

euc-kr로 인코딩된 곡명이 깨지고 있다

BMP (beep-media-player)를 사용해서 음악을 듣고 있는데, 곡명 중에 원래 한글 내지는 euc-kr (cp949) 호환으로 되어있던 곡명들이 깨지고 있었다. 근데 화면에 나오는 에러메시지가 `유효하지 않은 UTF-8′ 이어서 출력할 때 사용하는 encoding을 알 수 있었고 (지금와서 보니 LANG/LC_ALL가져다 쓰는 것 같지만), 윈도우 파티션에서 euc-kr로 된 태그들을 수정하는 코드를 짜기 시작했다.

taglib (http://developer.kde.org/~wheeler/taglib.html)과 POSIX iconv를 사용해서 슥슥 짰더니 대충 돌기시작 ID3v1 tag는 album 이름 부분에서 약간 문제가 있는 듯도하지만, 나머지는 잘 돌고 있음( –)
간단한 예로 밑에 스샷에서 보면 14번/16번 곡과 15/17번 곡은 각각 동일한 파일이었다. 단지 태그 정보를 읽어서 인코딩 바꿔준 결과 제대로 보이는 것 뿐 -_-; 12번 곡의 artist field는 지금 encoding이 뭔지도 추정하지 못하고 있다(그래서 지금도 여전히 깨진다) 도대체 뭘까;
conv.png