인터넷이 며칠 째 먹통이 되어 이런 캠페인을 하고 있다는 사실을 까맣게 몰랐군요. 한국 정보 문화 진흥원에서 웹 접근성 향상 캠페인을 하고 있습니다. 웹 접근성, 웹 표준, 상호 운용성 등에 대해 사람들이 말을 많이 하지만, 아직도 대다수의 사람들에게는 다른 나라 얘기이거나 도대체 무슨 이야기인지 모르는 것이 현실입니다. 그런 면에서 이런 캠페인은 보통 사람들에게 쉽고 평범하게 웹 접근성이 왜 중요하고 꼭 지켜야만 하는 것인지를 알려주는 중요한 역할을 하는 것 같습니다. 쉽고 빠르게 접근성에 대해 설명해주는 동영상, 강추입니다.
접근성에 대해 잘 아는 사람들조차도 장애인의 접근성에 대해 직접적으로 이야기 꺼내는 것을 두려워합니다. 대신에 좀 더 근사하고, 저항이 없는 국제 표준, 기술 표준, 상호 운용성, 구조와 표현의 분리, 모바일 웹, 최신 기술 등의 섹시한 단어로 포장을 해서 접근성을 간접적으로 강조하곤 합니다. 저도 그래왔었구요. 그만큼 장애인은 소수이고, 돈도 안 되고, 장애인의 문제를 가지고 제품 개발자들에게 설득하기가 쉽지 않기 때문이겠지요. 그러나 아무리 소수라고 해도 장애인들에게 “세상과 통하는” 매우 중요한 문인 웹을 닫아놓고 IT 선진국이라고 외치는 것은 자기 기만일 수도 있습니다. 사실 장애인이나 노인은 이제 소수도 아니지요.
얼마 전에 아버지에게 웹에 있는 씽크프리 오피스를 이용해서 주소록을 정리하는 것을 알려드렸던 경험이 있습니다. 접근성의 문제는 거창한 이론에서 나오지 않더군요. 접근성 지침에 있는 항목들을 다 지킨다고 되는 것이 아니라는 것을 알았습니다. 컴맹이 봐도, 누가 봐도, 장애인이 봐도 직관적으로 이해하고 교육받지 않아도 쉽게 쓸 수 있게 하는 것, 이것이 접근성입니다. 컴퓨터를 잘 모르는 아버지에게 씽크프리 오피스는 너무 복잡했고, 새롭게 익혀야 할 개념도 너무 많았습니다. 그러니 아직 갈 길이 먼 것 같습니다. 제 웹 사이트도 아직 먼 것 같습니다.
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를 쓸 수 있게 되어 다행입니다.
시스템을 변경하는 동안, 일부 데이터가 손상되었습니다. 한글 입력에 문제가 있는 줄 모르고 마구 에디팅을 하다가 날아간 것도 있고, 또 방문하신 분들이 한글로 코멘트를 입력했다가 날아간 것도 있습니다. 입력한 것을 날린 것에 대해 정말 죄송합니다.
|
|
Recent Comments