XPath 테스터

문서를 붙여 넣고 식을 입력하면 무엇이 선택되는지 보입니다. 평가는 브라우저 자체의 XPath 엔진이 하므로, 여기서 얻는 결과가 여러분의 코드에서 document.evaluate가 내놓을 결과입니다. 일치한 노드가 직렬화된 형태로 하나씩 나열되거나, string()·count()·starts-with() 같은 함수가 노드 집합 대신 돌려주는 문자열·숫자·불리언이 나옵니다.

엔진은 XPath 1.0이고, 이것이 가장 먼저 알아야 할 점입니다. 모든 브라우저가 1.0만 싣고 그 이상은 싣지 않으므로, 사람들이 손을 뻗는 2.0과 3.1 함수는 아예 없습니다. matches(), lower-case(), ends-with(), tokenize()는 빈 결과를 돌려주는 것이 아니라 문법 오류로 거부됩니다. 1.0에서 대응하는 것은 contains(), translate(), substring() 계열, 그리고 접미사 검사를 위한 substring(s, string-length(s) - n) 관용구입니다. 여기서 거부된 식은 lxml과 libxml2 기반 도구에서도 같은 이유로 거부됩니다.

실제 문서가 첫 시도를 무너뜨리는 곳은 대개 네임스페이스입니다. XPath 1.0에는 기본 네임스페이스라는 개념이 없습니다. 문서가 <feed xmlns="http://www.w3.org/2005/Atom">으로 열린다면 //entry는 아무것도 맞히지 못합니다. 식에 쓴 접두어 없는 이름은 “네임스페이스 없음”을 뜻하는데 문서의 모든 요소는 Atom 네임스페이스에 있기 때문입니다. 빠져나갈 길은 둘이고 이 도구는 둘 다 지원합니다. 네임스페이스 칸에 접두어를 묶고 //a:entry라고 쓰거나, //*[local-name()='entry']로 문제 자체를 비켜 가는 것입니다. 기본 네임스페이스를 선언한 문서에서 질의가 빈 결과를 내면 이 도구가 그 사실을 알려 주므로 추측하지 않아도 됩니다.

해석 방식도 같은 이유로 반대 방향에서 중요합니다. XML 해석은 엄격해서 닫히지 않은 태그 하나로도 해석 오류가 납니다. 이 도구는 그것을 보고합니다. 브라우저는 그래도 부분 문서를 돌려주고 XPath는 살아남은 조각을 대상으로 실행되어, 그럴듯해 보이지만 사실이 아닌 답을 내기 때문입니다. HTML 해석은 관용적이어서 마크업을 대신 고쳐 줍니다. 실제 페이지를 긁어 올 때 원하는 동작입니다. 다만 그곳에서는 요소 이름이 대문자로 돌아옵니다. HTML 요소에 대해 DOM이 보고하는 값이 그것이기 때문입니다.

모든 처리는 로컬에서 이루어지며 문서는 업로드되지 않습니다.