공공기관 사이트들을 포함한 한국 웹 사이트들의 심각한 웹 표준 규약 파괴현상을 몸소 체험하면서, (X)HTML 페이지의 첫 줄에 선언되는 DOCTYPE의 중요성을 다시 한 번 여기에도 기록해 두고자 한다.

World Wide Web Consortium (W3C)이 DOCTYPE의 중요성에 대해 강조하고 있는 것을 인용하면,

doctype을 추가해 주는 것을 잊지 마십시오.
뭘 추가해?
HTML에는 한 가지 형식만 있는 것이 아니고, 실제로는 여러 형식이 있는데, 여기에는 HTML 4.01 Strict, HTML 4.01 Transitional, XHTML 1.0 Strict 등 그 수는 여럿이랍니다. 이 모든 HTML 형식들은 각각의 W3C 규약에 정의되어 있으며, 기기가 읽을 수 있는 언어로서 HTML 형식의 적법한 구조와 구성 요소들 그리고 이러한 요소들의 해당 속성들로 정의되어 있습니다.
이러한 정의는 “Document Type Definition” 혹은 짧게 DTD라고도 불립니다.
HTML 문서들을 읽어들이는 웹 브라우저와 같은 도구들은 (X)HTML이 실제로 어떠한 DTD를 사용하고 있는지를 알아야 하고, 이것이 왜 (X)HTML 문서들의 맨 처음에 다음과 같은 DTD 선언문을 포함해야 하는지를 잘 설명해 줍니다:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

위에서 사용된 문법에서 보이다시피, DTD 선언문은 그냥 짧게 “Doctype”이라고도 불립니다.
그럼, 왜?
왜 DOCTYPE을 써야 하냐고요? 왜냐하면, 이것이 당신의 웹 문서가 어떤 버전의 (X)HTML로 쓰였는지를 정의해주고 웹 브라우저와 같은 도구들이 이 문서를 올바르게 읽어 드릴 수 있게 하기 위해서는 꼭 필요한 아주 중요한 정보이기 때문입니다.
예를 들어, 문서에 doctype을 지정해 두면, (X)HTML의 문법을 검사할 때 사용될 수 있는 Markup Validator와 같은 도구를 사용할 수가 있고, 그래서 기타 브라우저들에서도 올바르게 당신의 문서가 보일지를 확인해서 잘 못 된 오류들을 수정할 수가 있게 됩니다.
하지만, 무엇보다도 가장 중요한 것은 대부분의 웹 브라우저들이 doctype 선언문이 있음으로써, 불필요한 추측을 하게 만들지 않는다는 것입니다. 이것은, “표준” 분석 방식을 사용하게 하면서 문서가 화면에 표시되는 속도가 더 빨라질 뿐만 아니라, doctype이 없어서 생길 수도 있는 예기치 못한 문제들로부터 자유로워질 수 있습니다.

일반적으로, 웹 브라우저가 DOCTYPE이 선언되어 있지 않은 html 문서를 읽어들일 때는, 대충 짐작해서 읽어들이는 방식(“Quirks” mode)을 선택한다. (어쩌면 요새 개발/배포되는 웹 브라우저들이 너무 관대(?)해서 이런 상황이 고쳐지지 않고 있는지도…) 이렇게 되면, 브라우저는 옛날 90년대 말에 사용되었던 방식으로 웹 페이지를 해석하게 되며, 그야말로 대충 짐작해서 읽어들이게 되면서, 원래의 의도한 구조와는 다르게 페이지를 보여주게 되고 또한 브라우저마다 제각기 다른 결과물들을 표시해 줄 수밖에 없게 된다.

결국, 지금의 21세기에 와서도 그들의 HTML 문서에 DOCTYPE이 선언되어 있지 않았다면, 웹 표준을 깡그리 무시하겠다는 선언과도 같으며, 그 내용은 제쳐놓고서라도, 전달 방법은 20세기 과거의 것으로 남을 수 밖에 없다.

빨리 고쳐주세요! 😐

– 권장하는 추가 참고 글들

예정대로 WordPress가 2.0으로 갱신되었다는 소식과 함께 냉큼 내려받아 설치를 끝마쳤다.
물론 갱신 과정은 이전처럼 간단하였지만, 2.0을 위한 테마(theme)파일의 변화로 전에 쓰던 파일을 알맞게 수정하는 데만 오히려 대부분의 시간이 들었던 것 같다.
잠깐 둘러보면, 겉으로 들어나는 큰 변화는 없지만, 내부에는 많은 근본적인 구조의 개량이 있었다고 한다. 이로서, 개발자들에게는 plugin 개발이 더욱 용이해졌다고 하니, 이것은 곧 일반 사용자들에게도 희소식이리라.

WordPress 2.0에 와서 여러가지 개선된 것들 중에서, 개인적으로 가장 반가운 것들로는,

  • 개선된 글의 미리보기 – 항상 글을 쓸 때마다 제대로 표시되지 않았던 미리보기가 불만이었는데 이제는 실제로 글이 올려졌을 때의 모습 그대로 확인할 수 있게 되었다.
  • Ajax 사용 이야깃거리/연결고리 관리 – 한창 유행처럼 번지는 Ajax 응용 기술이 추가되었다. Ajax가 새로운 기술이라고 할 것도 없지만, 사용자 입장에서는 편리한 기능.
  • 간소화된 DB 접근 코드 – 부수적으로 얻어지는 빨라진 DB 접속 속도.

더불어서, 아쉬운 점도 몇 가지 들자면,

  • 글 작성시, Safari에서는 QuickTag들을 위한 단추가 여전히 보이지 않고, 글 쓰는 영역의 크기를 마우스로 조절할 수도 없다. – 문제의 원인은 Safari에 있으며 임시 해결책은 있으나, 역시 찜찜하다.
  • 예정되었던, Atom 발신 신호가 아직 1.0으로 갱신되질 않았다. – 이것은, 이전에 썼던 글을 참고하면 해결 가능.

집안 수선을 마쳤으니, 새로 갱신될 plugin들 소식을 기다리자. 🙂

꼬리표:

 없음.

Applications 폴더를 꿰차고 있는 프로그램들이 하나 둘 씩 늘어날 수록, 쌓여만 가는 우편물 수거함의 우편물들처럼, 메워지는 곳이 또 하나 있다.
바로, 설치된 프로그램들마다 자신들만의 유용성을 주장하며 은근슬쩍 등록해 둔 Services 메뉴 항목들.
물론 간혹 유용하게 사용하는 반가운 것들도 있지만, 무슨 프로그램에서 등록했는지도 알 수 없는, 전혀 사용할 것 같지도 않은 것들이 눈에 뜨이기 마련이다.

결국, 화면의 세로 폭을 훨씬 넘어 빽빽이 들어 찬 Services 메뉴 항목들을 정리하기 위한 방법을 찾던 중, Services 메뉴 항목들을 관리하고 수정하는데 꼭 안성맞춤인 도구를 찾아 내었다. 그것은 바로 Service Scrubber.

Service Scrubber's main window

필요없는 Service 메뉴 항목(1)을 간단하게 바로 꺼줄 수도 있고(2), 단축키를 마음대로 지정할 수 있는 등(3), 그야말로 Services 메뉴 항목 청소에는 안성맞춤인 바로 그 ‘수세미’.

덧붙임 (2011-8-23): OS X 10.6, 10.7에서도 잘 작동하는 서비스 메뉴 청소 도구 발견 – Services Manager

요새 폭설 피해 기사들을 보면서, 별 도움은 안 되겠지만, 뜬구름 widget에도 기상 특보 상황을 표시해 주는 기능을 추가해 놓으면 알맞겠다는 생각에 기상청 홈페이지를 살펴보았다. 물론 기상 특보 상황은 대문에서 바로 살펴볼 수 있으니, 문제는 이놈을 XMLHttpRequest Object로 끌어오기만 하면 되는 샘.
생각보다 쉬우리라는 기분으로 기능을 추가하고 뜬구름을 실행시켜 보았으나…감감무소식이다.
결국, 이런저런 궁리 끝에 console.log를 살펴보니, 다음과 같은 자국이 찍혀 있다.

[526] http://www.kma.go.kr/index.jsp:Error - DOM Exception 3

DOM Exception 3? 뭐지? Document Object Model Exception 3???

문제의 원인은, 기상청 홈페이지의 html 소스를 보면 금방 알아차리게 된다.

맙소사. !DOCTYPE은 물론이고 <html> 시작 꼬리표까지 없단다. (그렇다면, 맨 밑의 </html> 꼬리표는 실수로 붙었단 말이냐?)
정부 사이트들이 웹 표준 나 몰라라 하는 상황은 이미 알고 있었지만, 이 정도일 줄이야…
이것은 사이트 제작자의 실수 이전에, 기본을 지킬 수도 없는 무지에서 나온 결과랄 수 밖에 설명할 도리가 없다.

앞니가 빠진 꼬리표 덕분에, html 문서도 일반 글자 문서(plain text)도 아닌 어처구니 없는 상황인지라 XMLHttpRequest로는 원하는 정보를 끌어올 방법이 없다. (물론, 다른 꼼수는 있겠지만, 힘 빠지는 것은 마찬가지.)

그나마 아쉬운 마음에 대문에 쓰여 있는 국민으로부터 사랑받는 열린 기상청이라는 문구 때문에라도, 소귀에 경 읽기 심경으로, 문의 게시판에 정정 요구를 해봤지만, Safari와 Firefox에서는 글도 올라가지 않는다. 참으로 징하다. 🙁

전자 정부 부르짖는 그들은 실로 대~충 그까짓 거 뚝딱 정부로세. 👿

또 다른 탄생을 준비하고 있는 대~충 그까짓 거 뚝딱 현장 방문하기 << 말이 디지털이지 그 속 내는 그까짓 거 대~충하는 섬세하지도 못한 아날로그이다.

아래에 소개될 방법은 MySQL 4.1.x에 적용될 수 있으며, 자세한 내용은 MySQL 설명서를 참고.

전체 서버의 기본 언어 인코딩을 UTF-8으로 설정

서버에 있는 my.ini(windows) 혹은 my.cnf(Unix)파일을 찾습니다. Unix일 경우, 보통 /etc/my.cnf에 있으며, 없다면 새로 만들어야 합니다. 기본 설정 파일은 MySQL 소스 코드와 함께 딸려오는 support-files 폴더 안에, 용도별로 여러 개의 설정 파일들이 있으며, 자신의 서버 환경에 맞는 설정 파일을 골라서 이것을 기준으로 수정해 주면 됩니다. Windows용 설정 파일은 보통 C:\Windows\my.ini에 있습니다.

설정 파일을 열고, [mysqld] 설정 부분에 character-set-server 변수 설정 내용을 다음과 같이 변경/추가합니다.

[mysqld]
character-set-server = utf8

저장하고 MySQL 서버를 재시동하면, 다음에 생성되는 데이터베이스들부터 적용됩니다.

주의할 것은, 여기에 default-collation 변수값을 설정해 줄 필요는 없으며, MySQL 서버가 character set에 적당한 값을 알아서 결정하게 됩니다.
참고 – MySQL 서버의 시스템 변수들

개별 데이터베이스의 기본 언어 인코딩 값을 UTF-8으로 설정

만약, 사용하고 있는 MySQL 애플리케이션들이 다른 언어 인코딩을 사용해서 전체 서버의 기본 언어 인코딩을 UTF-8으로 설정해 줄 수 없다면, 데이터베이스 생성 시 다음과 같은 명령으로 특정 데이타베이스의 기본 언어 인코딩을 설정해 줍니다:

CREATE DATABASE 데이타베이스_이름 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

ISP에서 제공한 지정 데이타베이스의 기본 인코딩 변경

전체 서버 설정 권한이 ISP에게 있을 때는, 지정된 데이터베이스의 테이블을 생성하기 전에 다음과 같은 명령을 줍니다:

ALTER DATABASE 데이타베이스_이름 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

이전 데이터베이스의 언어 인코딩을 UTF-8으로 변환

우선, 기존 데이터베이스를 따로 저장한 후에, 다음과 같이 내용을 추출해 냅니다:

mysqldump -uusername -ppassword --opt my_database > oldencoding.sql

추출해 낸 내용을 UTF-8으로 변환(MySQL의 기본 인코딩은 latin1):

iconv -f 기존_인코딩 -t UTF-8 oldencoding.sql > UTF8database.sql

변환한 내용을 기존 데이터베이스로 복구:

mysql -uusername -ppassword my_database < UTF8database.sql

참고 – MySQL가 지원하는 Character Sets와 Collations

덧붙임(2012.8.31): MySQL 5.5.3 이후 버전을 설치하였을 땐 UTF-8에 지정된 모든 심볼을 다 인식하는 utf8mb4 인코딩으로 설정해 주는 것이 더 바람직하겠다. – How to support full Unicode in MySQL databases