프로그램을 공부할수록 기초가 중요하다는 것이 느껴진다.
작년중순까지만 해도 나는 euc-kr이니 utf-8이니 그냥 아무생각없이 메타태그에 적어놓았다.
텍스트 파일을 저장할때 euc-kr로 저장한 것과 utf-8로 저장하는 것에 차이가 있는지도 몰랐다.

그러다가 이제 utf-8로 넘어가려고 생각하는 도중 폴더내의 euc-kr파일을 utf-8로 한꺼번에
변환하는 프로그램을 계획하게 되었다.

왠만하면 어플로 만들고 싶었는데 할줄아는 어플은 C, C++, VB

C, C++로 하자니 텍스트 화면의 비주얼하지 않은 인터페이스가 맘에 안들고 VB로 하자니
VB도 설치해야 하고 기왕하는거 VB.net으로 하고 싶은데 VB6으로 하더라도 다시 공부해야하고
dll과의 통신도 공부해야하니 이래저래 시간이 부족하겠다 싶어서 그냥 PHP로 정했다.

단순히 php로만 해버리면 재미없기 때문에 자바스크립트를 통해서 PHP와 데이터를 주고 받으며
진행상황도 표시 되도록 알고리즘을 구상했다.

인코딩이야 iconv가 알아서 해주니 나는 인터페이스 구현에만 충실히 작업했다.
거의 완성했다 싶었을때 큰 충격을 받고 말았다. 제대로 인코딩이 되지 못한 파일이 있었다.
이게 어찌된 일인가? 살펴본 결과 utf-8문서를 다시 utf-8로 변환하는 과정의 문제였다.

나는 단순하게 인코딩을 실패하면 iconv가 false를 리턴해줄 것이라고만 믿었는데 아니었다.
그리고 두개의 에디터가 만든 utf-8 파일이 서로 다르게 읽히고 바이트수도 틀렸다.

아~! 머리가 복잡해지기 시작했다.
문제가 발생하자 나는 utf-8에 대해 샅샅히 조사하기 시작했다.
내가 몰랐던 것들이 왜이리 많은 것인가 ㅡㅡ;
나는 단순 무식하게 영문, 숫자 1바이트, 한글 2바이트 이렇게 생각하고 있었는데 그것이
아니었다. 1~6바이트의 가변이며 한글은 대부분 3바이트를 차지하는 것을 알았다.

크아~! 머리가 더욱 복잡해진다. utf-8 문자열 자르는 문제도 생각해야 하는 것이었다.
그리고 에디터에 따라서 utf-8의 맨앞 3바이트에 BOM이라는 문자를 넣는다는 사실도 알았다.
이 부분은 앞의 3바이트를 검사해서 BOM일 경우 제거하는 코드를 적용시켰다.

utf-8에서 한문자의 첫번째 바이트가 몇바이트를 읽어오는지 나타낸다고 하는데 그 부분에
대한 자료만 구하면 utf-8 문자 자르기도 문제없을 듯 하다.

나도 나름대로 프로그래밍을 많이 했고 알고리즘 구현도 뒤쳐지지 않는다고 생각하지만
기술적인 부분에서 너무나 부족한것 같다. 거기다가 나는 이해력이 너무 부족하다. ㅠ_ㅠ

회사 프로그램도 쳐내야하고, 기술도 익혀야 하고, 알고리즘도 구현해야 하고 머리가 뽀개질것 같다.
초고수 프로그래머 밑에서 거저 배우고 싶은 생각이 간절하다.
자신이 찾아내서 공부하는 것이 중요하지만 익혀나가는 속도가 너무 느리다.
기술은 자꾸 발전하는데 꽁무니만 쫓아가고 있다.
누가 나 좀 이끌어줘~~~!