Thanks to one of the smartest guys, Jungshik (my brother at Google), I could come back to the better future! He found that the hosting service provider just generated the MySQL 3.x dump as it had been. It was actually encoded with utf-8 with no explicit encoding direction in it. One mistake I made is that I did not set the DB character set as utf-8 but it was still in euc-kr in WordPress configuration file in the WordPress root directory. Big mistakes the hosting provider made include that they set the default DB and connection character set as euc-kr and all collations configured for all tables were also euc-kr. Luckily enough, combining all these mistakes, the existing data displayed correctly while newly imported data cannot be stored properly. People tried to enter data with utf-8 encoding according to the web page encoding scheme and the DB interpreted them as euc-kr data which was wrong.
What Jungshik did was to backup the existing tables first. He found that the MySQL has a bug (that is, the last about 20 bytes were trimmed or tangled when exporting its tables to a local SQL file). He just made a shell script to fix this bug and also he converted the dumped SQL to a genuine utf-8 certainly specifying all necessary character sets using his script. Then he just changed the default table names for WordPress because it could be dangerous to replace directly with the old tables. (WordPress provides a configuration file for you to change the default table name prefix.) After successfully restoring the new tables, he and I tested writing, editing, and searching, etc. However, I came to have more tables than necessary. Just after identifying that everything worked fine, he finally replaced the old tables with the new tables.
All things are ok but some works including visitors' comments made during transition period were unrecoverable. I truly apologize for your efforts to enter your message which had gone away.
드디어 워드프레스 업그레이드를 모두 마쳤습니다. 호스팅 업체에 부탁해서 MySQL 4.1이 있는 서버로 옮기고 나서 한글이 입력되지 않을 뿐만 아니라, 기존 데이터를 수정하는 순간 그 데이터도 손상되는 문제가 생겨 호스팅 업체에 몇 번씩 전화와 게시판을 통해 문의했지만 워드프레스의 문제일 뿐 자기들은 아무 것도 잘못한 게 없다고 했습니다. 사실은 처음에는 기존에 입력한 데이터가 화면에 보이는 것도 깨져서, 이게 한글의 문제가 아니라 진짜로 다른 문제인 줄 알았습니다. MySQL 3.x 대는 문자 인코딩 방식을 지정하는 것이 없었지만 사실 워드프레스는 유니코드를 사용하고 있었고, 그것을 호스팅 업체가 서버를 이전하면서 euc-kr로 가져와버린 것입니다. 이 문제를 미국에 있는 형에게 물어봤더니, 일단 호스팅 업체는 손대지 못하게 하라고 말하더군요. 그렇게 하고 형이 작업을 했는데, 간단한 셸 스크립트를 짜서 새롭게 덤프받은 DB의 문자셋을 변경했습니다. 변경하는 과정에서 MySQL 4.1의 버그도 발견했는데 그것도 셸 스크립트를 이용해 복원했습니다. 혹시나 해서 변경된 테이블을 바로 옛 테이블에 덮어쓰지 않고 새로운 테이블을 생성하였습니다. 그리고 워드프레스에서 새로운 테이블을 인식할 수 있게 테이블 이름 기본값을 바꾸어주었습니다. 데이터 입력이 제대로 되는 것을 확인한 후, 마지막으로 기존 테이블에 새로운 테이블 내용을 덮어쓰고, 다시 테이블 이름 기본값을 바꾸었습니다. 그리고 이제 쓸모없게 된 테이블들을 다시 지웠구요.
놀란 가슴을 이제야 진정시킵니다. 호스팅 업체에서는 이런 문제를 해결해주었을 리가 만무하고, 형의 도움이 있어서 천만 다행이었습니다. 형은 구글에서 제품의 세계화(internationalization)와 지역화(localization)를 담당하고 있거든요. 아무튼 이렇게 요란하게 소란을 피운 후에라도 완전한 유니코드 체계로 정착이 되었고 워드프레스 2.2를 쓸 수 있게 되어 다행입니다.
시스템을 변경하는 동안, 일부 데이터가 손상되었습니다. 한글 입력에 문제가 있는 줄 모르고 마구 에디팅을 하다가 날아간 것도 있고, 또 방문하신 분들이 한글로 코멘트를 입력했다가 날아간 것도 있습니다. 입력한 것을 날린 것에 대해 정말 죄송합니다.
