그러면 무한 반복에 빠지지요. ^^;

이렇게 했기 때문에 blog/뭐시기 로 들어오는 건 모두 preserveURL.php 이 받는데, 이 파일 안에서 다시 blog/$1/index.php 로 날리면 또 다시 preserveURL.php?redirect=뭐시기/index.php 가 받아서

/blog/notice/index.php/index.php/ ...

이런 식으로 계속 붙습니다. 그래서

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

이거 위에

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

를 넣어서 실제 파일이나 디렉토리가 없는 완전 가상 주소로 접근하면 preserveURL.php 가 받고, 실제 파일이나 디렉토리가 있는 주소(owner, entry, trackback, notice, tag 등등)는 원래 있던 /blog/$1/index.php 가 받도록 했는데 제가 .htaccess 미숙한 탓인지 언제나

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

이 놈이 받더군요. ^^; 딱 봐도 아닐 듯한

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

아래에

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

이걸 넣으면 예상대로

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

이 놈이 다 받아버리고. ^^; 그것 참...

그래서 혹시나 하는 작은 마음으로 preserveURL.php 에서 slogan 검사를 한 뒤 있으면 그 글로 이동시켜주고, 없으면(tag, notice, owner 같은 주소) 해당 위치에 있는 index.php 파일을(blog/$1/index.php) 통채로 include 해봤습니다. 즉, preserveURL.php 파일이 주소를 거의 다 받아다 역할을 갈라주는 Wordpress 2.x과 비슷하게 한 것인데요. 작동은 전반에 걸쳐 잘 작동하지만 owner 는 로그인이 안되더군요. ^^;

덧쓰기 : 아~ wp2tt ... 예전에 얼핏 본 기억이 나는군요. 진작 찾아냈더라면 10시간 절약 했을텐데! ^^;

덧쓰기 2 :

Wordpress 1.5 는 실제로 이렇게 처리 했었습니다. ^^ 모든 글에 대해서 그렇게 한 건 아니고요. page 라고 하는 고정글(태터나 텍스트큐브에선 notice 에 해당하는)은 모두 저렇게 일일이 Rewriterule 을 더했습니다. 그래서 .htaccess 를 갱신하는 event가 발생할 때마다 제가 따로 더해 쓰는 RewriteRule 을 함께 더하는 확장기능을 만들어 썼었지요. (쪽 더하거나 뺄 때마다 .htaccess 내용이 바뀌니까^^)

전 아쉽지만 급한대로(??) 일단 제가 validateSlogan 함수를 고쳐서 쓰려고 Textcube.Data.Post.php 를 열었더니...

        /*@static@*/
        function validateSlogan($slogan) {
                return preg_match('/^[^!-,.\/:-@[-`{-~\s]+$/', $slogan);
        }

캬오. 역시나 제가 무서워하는 정규표현식이네요. ^^

다음 판에 _ 를 허용 하신다면 다음 판까지 얌전히 관련 패치 기다리겠습니다.

정말 몰라서 여쭙는 건데요. 도메인은 대소문자 구분이 없고 _ (underbar)를 허용하지 않는 등 몇 가지 필수 규칙이 있지만, 도메인 이후 부분(path)에도 그런 규칙이 있나요?

경로(path) 부분은 도메인 이름 짓는 규칙과는 다르게 적용되고 있고, 경로에 _ 문자를 쓰는 곳도 많던데요. 이런 부분들은 권장 규칙이 있는지 모르겠지만(이 부분이 제가 여쭙는 부분), 대체로 서비스 정책 차원에서 결정하고 쓰는 듯 해서요. 주소 경로에 _ 를 쓰는 곳이야 많으니 제껴두고, 전자우편 주소에 _ 를 쓰는 것도 서비스 업체마다 다른 걸 보면 서비스 정책으로 결정하는 듯 해서요. 예를 들면, gmail은 _ 문자를 허용하지 않지만 daum 은 계정 이름을 _ 문자로 시작해도 됩니다. 실제로 제 daum id 는 _-_hi-_-b 입니다. MS passport(hotmail 등)는 _ 문자를 쓸 순 있지만 계정 이름 맨 처음엔 쓸 수 없고요.

그렇다면

이 말씀은 그러한 국제 표준이나 규칙이 있다고 쳐도 강제나 필수 요소는 아니고 권장 요소인 듯 한데, 꼭 따라야 하는 이유가 있을만한 요소인지 궁금합니다. (전자우편 주소 규칙과 URL 규칙은 서로 다른 부분이긴 하지만, _ 를 쓰고 안쓰고는 서비스나 도구 정책 차원에서 이뤄지는 것이 아닌가를 말하기 위한 예입니다. ^^; )

제가 원하는 것은 낱장주소에 “안녕하세요 한날입니다”를 썼을 때 이걸 “안녕하세요_한날입니다” 로 바꿔주는 걸 원하는 것이 아니라, 제가(이용자가) 직접 “안녕하세요_한날입니다” 라고 입력했을 때 지금처럼 “안녕하세요한날입니다”로 바꾸지 않고 “안녕하세요_한날입니다”로 유지해주는 것입니다. 즉, 공백 등을 강제로 _ 로 바꾸는 걸 원하는 것이 아니라 _ 문자도 쓸 수 있는 정책입니다.

주소 규칙상 _ 를 허용 “하지” 않는 것인지 “되지” 않는 것인지, 그리고 그 이유를 알고 싶습니다. ^^;