smores

https://www.google.com/intl/ko/inputtools/try/ https://ohi.pat.im/ http://colspan.net/hangulime/ https://www.branah.com/

일전에 apple 2 용 사랑의 별점 데이터 추출을 위해 n-byte 한글을 변환하기 위해 간단히 사용했던 툴이다. 헌데 우분투에 크롬을 새로 인스톨 한 후에는 크롬 스토어에서 찾기가 힘들었다. 구글을 해서 찾은 결과를 기록으로 남겨놓는다. http://newtype.pe.kr/417 위의 링크로 가면 다음 링크로부터 크롬 스토어의 링크로 연결해 준다. 헌데 크롬 스토어에서 별도로 검색을 할 때는 찾기가 힘들다. https://chrome.google.com/extensions/detail/mdkppbnnjcekjodocacfchkeeebebdpl 한편 위의 페이지에 있는 한글 변환 스크립트 관련 링크 로 가서 알려주는 한글 변환기 링크로 찾아가면 궂이 크롬 애드온이 없어도 원하는 작업을 할 수 있다. ..

지난번 글에서는 허큘리스 그래픽 카드를 가지는 시스템에서 GW-BASIC을 사용할 때 조합/완성형 한글과 그래픽을 함께 구현하는 방법에 대해 정리해 보았다. 이후 웹을 검색하면서 마이크로소프트에서 개발한 GW-BASIC 및 Quick Basic 의 경우 한글이 구현되는 버전이 따로 나왔음을 알게 되었고 열심히 구글링을 해서 일단 MS 한글 GW-BASIC 및 Quick Basic 4.5 을 입수했다. 역시 웹상에서 우연히 QB 도움말의 한글본을 보게 되었는데 놀랍게도 본인은 처음 보는 그래픽 모드들이 언급되어 있었다. 예를 들면 SCREEN 71 - 74 이 있다는 것이다. 다음은 한글QB45ADVR.HLP 에서 보여주는 내용의 스크린 샷이다. 사실 스크린샷은 본 글을 쓰기 위해 다양한 테스트를 다 마친..

고전 프로그램들을 가지고 놀다 보면 어느덧 옛 베이식 프로그래밍 시절의 추억이 다가온다. 본인 연배의 사람들의 IBM PC 호환기종과의 첫 만남은 보통 국산 청계천 복제품(또는 대기업 제품)에 허큘리스 모노 그래픽 카드와 흑백 또는 녹색 화면의 모니터가 많았을 것이다. VGA가 나오기 전까지는 당시 고가였던 CGA 또는 EGA 그래픽 카드들에 비하여 허큘리스 카드는 단색이기는 하지만 전자의 그래픽 카드들보다 월등히 높은 해상도 (720x348 또는 변형 모드로 640x400) 를 지원하였기에 한글 출력에 최적화 된 그래픽 카드로써 저렴한 가격까지 더해져 국내에서는 가장 인기있는 그래픽 카드였었다. 특히 허큘리스 카드의 640x400 변형 그래픽 모드는 16x16 도트의 한글 출력을 할 경우 40컬럼 (영..

잘 정리된 사이트를 링크하고 글을 갈무리하는 것으로 대체 http://heyjimin.tistory.com/14http://heyjimin.tistory.com/15

본 카테고리의 지난 마지막 포스트에서 무지막지하게 무식한 삽질을 했었다. 그런 짓을 한 이유는 파이썬으로 웹스크래핑 등을 할때 한글 키로 소스 내용 검색을 하고 싶어서였다. 지난 포스트에서 언급했던 웹파일(HTML 소스) 다운받아서 바이너리 형식으로 저장하는 코드를 동일하게 우분투와 윈도우즈에서 돌려보았다. 그것도 에디트플러스, Geany, 그리고 터미널에서 파이썬 호출하는 식으로... 먼저 윈도우즈에서는 실행 결과는 세가지 상황에서 완전히 동일하다. 코드는 EUC-KR로 노트패드에서 한글 완전히 잘 보인다. 에디트플러스도 다들 ANSI 코드로 인식한다. 다음은 우분투에서는 Geany 와 터미널상에서의 파이썬 호출로 직접 실행. 결과는 양쪽 완전 동일. cat 명령으로 터미널 상에서 리스트를 뽑아보면 양..

앞서의 포스트들에서 한글 인코딩과 관련한 이해를 위하여 여러가지 실험을 해 보았다. 간단히 정리하자면 윈도우즈 커맨드 프롬프트모드 및 전반적인 파일 시스템에서는 기본적으로 EUC-KR (CP949) 를 따르는데 비해 리눅스(우분투)는 UTF-8 을 기반으로 한글을 처리하는 것으로 보인다. 한편 대다수의 웹 페이지들은 오늘날은 UTF-8 인코딩으로 작성되어 있으나 일부 소수의 사이트는 예전방식을 따를 경우 웹브라우저에서 코딩 방식을 맞추어 주지 못하면 한글이 다 깨어져서 보이질 않는 상황이 발생한다. 이번 포스트는 웹페이지에 를 파이썬으로 다룰때 한글이 들어간 경우의 한글 코드 인코딩에 대한 를 어떻게 처리하는가에 대한 이야기이다. 일전에 어느분의 부탁으로 대법원의 판례 자료들을 파이썬 코드로 자동으로 다..

앞에서 ANSI (윈도우에서 Notepad로 작성하여 저장한 경우 한글코드는 EUC-KR) 로 저장된 파이썬 코드과 UTF-8 로 저장된 파이썬 코드에 인코딩 지시자를 EUC-KR, UTF-8, 그리고 생략했을 때의 두가지 에디터 (에디트플러스와 Geany) 상에서 매크로를 이용한 파이썬 실행시의 차이를 비교해 보았다. Geany의 경우 UTF-8 만으로만 저장해서 테스트해 보았고 테스트 환경은 윈도우즈와 우분투 두 OS 상에서 비교를 하였으며 에디터에 따른 다소 상이한 결과가 보였기에 에디터를 배제한 비교를 해 보기로 했다. 테스트를 위하여 동일한 테스트 코드를 사용했고 이를 윈도우즈에서 Notepad를 이용해서 각각 ANSI 와 UTF-8 포맷으로 저장을 했으며, 소스코드내에 인코딩 지시를 역시 3가..

앞서의 공부를 통해서 이제는 조금 코드 인코딩 관련 역사와 상황을 조금 이해한 듯 하다. 이제는 내가 직면한 파이썬 프로그램과 관련한 한글 문제들이다. 우선 구글링을 해서 조금 알게 된 내용은 파이썬 3 대 부터는 기본적으로 내부 라이브러리의 인코딩 체계가 유니코드로 통일되었다 한다 (맞나?) 나는 아직도 2.7.3 을 사용하는 사용자... 간혹 블로그등을 돌다 보면 맥 OSX 에서 파이썬 간단한 코드 작성하고 결과를 터미널에 보여주는 글들이 있는데 이건 뭐 특별히 인코딩 지시 없이도 한글 잘 나오는가보다. 그럼 나는? 똑같은 프로그램을 테스트하는데 이건 우분투에서 할때랑 윈도우즈에서 하는것 역시 달라 보인다. 게다가 사용하는 에디터 (주력으로 오랫동안 EditPlus 써 왔고 요즘 Geany 자주 쓰고..

유니코드 체계로 넘어가면서도 초기에는 다소 혼란스런 체계가 만들어졌나보다. UCS-2 라는 방식인 것 같은데 유니코드 체계의 기본개념인 코드포인트라는 것을 도입한다. 그리고 컴 시스템마다 다른 하드웨어 내부에서의 2바이트(16비트)의 처리 순서(endian? 예를 들면 X86 계열은 하위바이트 먼저, 68000 계열은 그냥 상위바이트부터 순차적으로 처리) 를 그대로 인정하겠다는 취지에 따라 문자열 선두에 BOM 이라는 것을 붙여서 유니코드임을 알리는데 이 부분이 엔디언 처리에 따라 FF FE 혹은 FE FF 순으로 나타내었다. 앞서의 포스트에서 보았던 unicode (little endian), unicode big endian 코딩에 따른 첫 두바이트가 이에 매칭한다. 이는 상당히 혼란을 가져오기 쉽다..