XML 검사기
적격 형식 검사와 스키마 검증. 아무것도 업로드하지 않습니다.
모든 처리는 이 탭 안에서 이루어집니다. 붙여넣은 내용은 업로드되거나 기록되거나 전송되지 않습니다. 네트워크 패널을 열어 확인하세요.
위에 문서를 붙여넣으면 입력하는 동안 검사합니다. 모든 문제를 줄, 열, 그리고 대신 무엇을 써야 하는지와 함께 보고하며, 첫 오류에서 멈추지 않고 한 번에 전부 보여 줍니다. 아무것도 업로드하지 않습니다. 파서도, 스키마 엔진도, 편집기도 전부 이 탭 안에서 돌아갑니다. 브라우저의 네트워크 패널을 열어 두고 작업해 보면 아무 요청도 오가지 않는 것을 직접 확인할 수 있습니다.
마지막 문장은 홍보 문구가 아닙니다. 이 검색어에서 상위에 노출되는 도구 여러 개는 검사를 위해 여러분의 문서를 서버로 보냅니다. 그중 하나는 데이터가 자사 서버에 저장되고 보관될 수 있음을 이해했다는 체크박스를 요구합니다. 베어러 토큰이 담긴 SOAP 엔벨로프나 접속 문자열이 든 설정 파일을 디버깅하는 중이라면 그것은 실제 문제이며, 이 사이트가 존재하는 이유이기도 합니다.
이 검사기는 XML이 정의하는 두 가지 검사를 모두 수행하되 서로 구분해서 다룹니다. 둘은 서로 다른 질문에 답하는데도, 거의 모든 무료 도구가 이 둘을 뒤섞기 때문입니다.
적격 형식과 유효성은 다른 검사입니다
문서가 적격 형식이라는 것은 구문이 올바르다는 뜻입니다. 태그가 닫혀 있고 제대로 중첩되어 있으며, 루트 요소가 정확히 하나이고, 특수 문자가 이스케이프되어 있으며, 속성 값이 따옴표로 묶여 있다는 것입니다. 여기에는 문서 자체 말고는 아무것도 필요하지 않으므로 입력하는 동안 자동으로 실행됩니다.
문서가 유효하다는 것은 적격 형식이면서 스키마에도 들어맞는다는 뜻입니다. 있어야 할 요소가 올바른 순서로, 올바른 타입으로 존재한다는 것이죠. 여기에는 XSD나 DTD라는 두 번째 파일이 필요하므로, 여러분이 의도적으로 실행하는 별도의 동작으로 두었습니다.
이 구분이 중요한 이유는, 사람들이 두 가지 중 어느 쪽을 뜻하든 "유효한 XML"이라고 말하기 때문입니다. 어떤 시스템이 문서를 유효하지 않다며 거부했다면, 십중팔구 스키마 검사를 실행한 것이고, 적격 형식 검사기의 녹색 표시는 그 실패의 이유를 알려 주지 못합니다. 이곳의 결과 패널은 어떤 검사를 실행했는지 항상 명시합니다.
- 적격 형식이지만 유효하지 않은 예: <from>도 요구하는 스키마에 대한 <note><to>Alice</to></note>. 구문은 완벽하지만 내용이 틀렸습니다.
- 유효하지만 적격 형식이 아닌 예: 불가능합니다. 유효성은 적격 형식을 포함하며, 그래서 구문이 깨끗해지기 전에는 스키마 검사가 실행을 거부합니다.
오류 메시지가 실제로 알려 주는 것
이 분야에서 부족한 것은 기능이 아니라 오류 메시지입니다. 브라우저 파서는 첫 문제에서 멈추고, 그것도 파서를 만든 사람의 언어로 설명합니다. 이스케이프되지 않은 앰퍼샌드를 파이어폭스는 "EntityRef: expecting ';'"라고 보고합니다. libxml2는 같은 것을 "xmlParseEntityRef: no name"이라고 부릅니다. 어느 쪽도 앰퍼샌드나 이스케이프, 혹은 거의 틀림없이 원인이었을 URL 쿼리 문자열을 언급하지 않습니다.
여기의 모든 진단은 여러분이 쓸 법한 말로 문제를 지목하고, 정확한 위치를 알려 주며, 해결 방법을 제안합니다. 줄:열 표시를 누르면 커서가 그 자리로 이동합니다. 충분히 자주 발생하는 오류에는 원인을 설명하는 문서로 가는 링크가 붙고, 다른 파서 여섯 개가 내놓는 같은 뜻의 메시지도 함께 실려 있습니다. 다음에 빌드가 다른 표현으로 알려 와도 같은 문제임을 알아볼 수 있도록요.
큰 문서, 그리고 악의적인 문서
구문 분석은 Web Worker에서 실행되므로 큰 문서를 훑는 동안에도 화면은 계속 반응합니다. 100 KB 파일은 약 20밀리초, 1 MB는 약 110밀리초, 10 MB는 1초 조금 넘게 걸립니다. 20 MB를 넘으면 도구가 처리를 거절합니다. 모든 것이 이 탭의 메모리에 올라가고, 그보다 큰 문서는 브라우저를 느리게 만드는 정도가 아니라 아예 멈추게 하기 때문입니다.
XML에는 JSON에 없는 서비스 거부 공격 형태가 있고, 여기서는 그것을 가정하지 않고 실제로 제한합니다. 지수적으로 팽창하는 중첩 엔티티를 선언한 문서, 이른바 "billion laughs"는 약 2밀리초 만에 거부됩니다. 한 글자도 확장하기 전에 선언만 보고 팽창 비용을 계산하기 때문입니다. 큰 엔티티를 수천 번 참조하는 2차 변종도 같은 예산에 걸립니다. 중첩 깊이에는 상한이 있고, 엔티티 순환은 따라가지 않고 감지하며, 외부 엔티티는 보고만 할 뿐 절대 가져오지 않습니다.
실제로 이곳에 붙여 넣는 문서들
검사기는 범용 도구이지만, 실제로 들어오는 문서의 종류는 고르게 퍼져 있지 않습니다. 몇 가지 유형이 대부분을 차지하고, 각각 고유한 방식으로 깨집니다.
이런 경우 대부분에서 검사와 정렬은 같은 작업입니다. 파일이 읽히지 않는 이유는 축약된 채로 도착했거나 서로 다른 도구 세 개를 거치며 들여쓰기가 뒤섞였기 때문이고, 제대로 배치하기 전까지 잘못된 부분은 보이지 않습니다. 위의 정렬 버튼은 다른 사이트를 거치지 않고 그 자리에서 다시 정렬하며, XML 포매터는 들여쓰기 너비와 주석 처리 방식까지 고를 수 있는 완전한 버전입니다.
- XML 사이트맵. 사이트맵 검사기는 문법만이 아니라 sitemaps.org 프로토콜 자체를 확인합니다. URL 50,000개와 50 MB 상한, lastmod가 실제로 요구하는 W3C Datetime 형식, 그리고 모든 URL이 사이트맵과 같은 호스트에 있어야 한다는 규칙입니다. 구글용 사이트맵은 완벽하게 정형식이면서도 거부될 수 있고, 거의 언제나 이 셋 중 하나입니다.
- SEPA를 비롯한 ISO 20022 지급 메시지. pain.008 자동이체 지시서나 camt.053 거래내역서는 공개된 XSD와 대조해야 의미가 있으므로, 스키마를 옆에 붙여 넣고 XSD 검사기로 보내십시오. 아무것도 업로드하지 않는다는 약속이 추상이 아니게 되는 영역이 바로 여기입니다. 시험용 파일에도 실제 IBAN과 채권자 식별자가 들어 있습니다.
- 게임 서버 설정. DayZ와 Arma, 그리고 같은 엔진으로 만든 서버는 시작할 때 types.xml, cfgspawnabletypes.xml, events.xml을 읽는데, 닫히지 않은 <type> 요소 하나만으로 서버가 멈추고 그 메시지는 파일 이름도 줄 번호도 알려 주지 않습니다. 여기에 붙여 넣으면 둘 다 나오고, 깨진 지점의 중첩 깊이까지 함께 나옵니다.
- SOAP 엔벌로프와 거기서 돌아오는 응답. 베어러 토큰이나 연결 문자열을 담고 있을 가능성이 가장 높은 문서이며, SOAP 포매터가 별도 페이지로 있는 이유가 그것입니다.
- RSS와 Atom 피드. 흔한 실패는 제목 안의 URL에 이스케이프되지 않은 앰퍼샌드가 들어간 경우이고, 피드 리더는 그저 피드가 깨졌다고만 알려 줍니다.
Notepad++에서 검사하는 데 익숙하다면
Notepad++ 자체에는 XML 지원이 없습니다. XML Tools 플러그인이 그것을 더해 주는데, 이 플러그인은 libxml2에 대한 바인딩이며 이는 이 사이트가 WebAssembly로 컴파일해 쓰는 바로 그 엔진입니다. 따라서 검사 자체의 결과는 서로 일치합니다. 다른 것은 그 주변의 모든 것입니다.
플러그인은 문서 위가 아니라 대화 상자에 실패를 표시하므로, 줄 번호를 읽은 다음 직접 찾아가야 합니다. Notepad++가 그렇듯 Windows 전용이고, 플러그인 빌드가 편집기의 아키텍처와 맞아야 합니다. 새로 설치했는데 메뉴가 회색인 흔한 원인이 이것입니다. 스키마 검사도 있지만 XSD가 문서 자체의 선언을 통해 닿을 수 있어야 하고, 더 큰 파일에서 잘라 온 조각에는 그런 선언이 거의 없습니다.
어느 쪽이 다른 쪽을 대체하지는 않으며, 정직한 구분 기준은 그 문서가 지금 어디에 있느냐입니다. 디스크의 파일이고, 이미 편집기를 열어 두었고, 네트워크가 없다면 플러그인이 더 빠른 길입니다. 지원 티켓이나 클립보드, 브라우저 탭에서 왔다면, 대화 상자마다 하나씩이 아니라 한 번에 모든 오류를 보고 싶다면, 또는 Windows가 아니라면, 페이지를 여는 편이 플러그인을 설치하는 것보다 빠릅니다. 스키마도 마찬가지여서, 여기 두 번째 창에 XSD를 붙여 넣는 데에는 문서 안의 선언이 전혀 필요하지 않습니다.
코드로 같은 일 하기
XML을 가장 많이 다루는 언어들에서의 같은 검사입니다. 모두 안전한 형태로 적어 두었습니다. 이 라이브러리들 중 몇몇은 기본 설정에서 외부 엔티티를 스스럼없이 해석하는데, 그것이 바로 XXE 취약점입니다. 아래의 플래그들은 형식적인 코드가 아니라 핵심입니다.
// DOMParser does not throw on malformed input. It returns a document
// containing a <parsererror> element instead, which is why so much code
// silently accepts broken XML.
function parseXml(source) {
const doc = new DOMParser().parseFromString(source, 'application/xml');
const error = doc.querySelector('parsererror');
if (error) {
throw new Error(error.textContent.trim());
}
return doc;
}
// Browsers do not resolve external entities, so XXE is not reachable here.
// Internal entity expansion is, so cap the input size before parsing.# The standard library is not safe against entity-expansion attacks.
# defusedxml is the maintained answer and is a drop-in replacement.
from defusedxml.ElementTree import fromstring, ParseError
try:
root = fromstring(source)
except ParseError as e:
# e.position is a (line, column) tuple, 1-based line, 0-based column
line, column = e.position
raise SystemExit(f"XML error at line {line}, column {column + 1}: {e}")
# With lxml, disable resolution explicitly:
# parser = etree.XMLParser(resolve_entities=False, no_network=True,
# huge_tree=False, load_dtd=False)
# root = etree.fromstring(source.encode(), parser)import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// FEATURE_SECURE_PROCESSING caps entity expansion. The three
// disallow-doctype settings close XXE. None of this is the default.
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
var builder = factory.newDocumentBuilder();
try {
var document = builder.parse(new java.io.ByteArrayInputStream(bytes));
} catch (org.xml.sax.SAXParseException e) {
System.err.printf("XML error at line %d, column %d: %s%n",
e.getLineNumber(), e.getColumnNumber(), e.getMessage());
}using System.Xml;
var settings = new XmlReaderSettings
{
// Null resolver means external DTDs and entities are never fetched.
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
MaxCharactersFromEntities = 1024 * 1024,
MaxCharactersInDocument = 20L * 1024 * 1024,
};
try
{
using var reader = XmlReader.Create(new StringReader(source), settings);
var document = new XmlDocument { XmlResolver = null };
document.Load(reader);
}
catch (XmlException e)
{
Console.Error.WriteLine(
$"XML error at line {e.LineNumber}, column {e.LinePosition}: {e.Message}");
}<?php
// libxml_disable_entity_loader was deprecated in PHP 8.0 because external
// entity loading became off by default. On PHP 7 you still need it.
libxml_use_internal_errors(true);
$doc = new DOMDocument();
$loaded = $doc->loadXML($source, LIBXML_NONET | LIBXML_NOENT & ~LIBXML_NOENT);
if (!$loaded) {
foreach (libxml_get_errors() as $error) {
fprintf(
STDERR,
"XML error at line %d, column %d: %s\n",
$error->line,
$error->column,
trim($error->message)
);
}
libxml_clear_errors();
exit(1);
}# xmllint is part of libxml2 and is almost certainly already installed.
# --nonet stops it fetching a DTD referenced by the document.
xmllint --noout --nonet document.xml
# Validate against a schema:
xmllint --noout --nonet --schema schema.xsd document.xml
xmllint --noout --nonet --valid document.xml # against its own DTD
# Exit status is 0 when valid. Note that xmllint's exit code does not
# always reflect namespace errors, so check the output too.예제마다 무언가를 끄고 있습니다. 우연이 아닙니다. 위험한 쪽 동작이 기본값인 것이 Java, 8.0 이전의 PHP, 그리고 Python 표준 라이브러리이며, 실제 운영 환경의 XML 파싱은 대부분 그 기본값 위에서 돌아갑니다.
자주 묻는 질문
제 XML이 어딘가로 업로드되나요?
아닙니다. 파서와 포맷터, 스키마 엔진은 모두 이 탭에서 실행되는 JavaScript와 WebAssembly입니다. 무언가를 보낼 서버 쪽 구성요소 자체가 없습니다.
믿어 달라고 부탁하지 않겠습니다. 브라우저 개발자 도구를 열고 네트워크 탭으로 옮긴 다음, 문서를 붙여넣고 검사해 보세요. 페이지 자체의 자원이 한 번 로드된 뒤로는 아무 일도 일어나지 않는 것이 보입니다. 이 사이트에는 편집기에 접근하는 분석 도구도, 서드파티 스크립트도, 오류 보고 서비스도 없습니다.
적격 형식과 유효성의 차이는 무엇인가요?
적격 형식은 구문이 올바르다는 뜻입니다. 태그가 닫혀 있고, 중첩이 올바르며, 루트 요소가 하나이고, 특수 문자가 이스케이프되어 있고, 속성 값이 따옴표로 묶여 있다는 것이죠. 유효하다는 것은 적격 형식이면서 스키마, 즉 어떤 요소가 어디에 허용되는지 기술한 별도 파일에도 부합한다는 뜻입니다.
문서는 유효하지 않아도 적격 형식일 수 있습니다. 적격 형식이 아니면서 유효할 수는 없습니다. 시스템이 XML이 "유효하지 않다"고 말할 때는 보통 스키마 검사를 실행한 것이므로, 구문 검사기만으로는 그 실패를 설명할 수 없습니다.
XSD로 검증할 수 있나요?
가능합니다. 그리고 서버 없이 그렇게 하는 것은 드문 일입니다. 브라우저에는 스키마 검사기가 내장되어 있지 않아서, 무료 도구들은 스키마 검증을 아예 건너뛰거나 파일을 업로드합니다. 이 사이트는 WebAssembly로 컴파일한 libxml2를 실행해 XSD 1.0과 DTD 검증을 전부 브라우저 안에서 수행합니다.
엔진은 압축 기준 약 480 KB이므로 페이지를 열 때가 아니라 실제로 스키마 검사를 요청했을 때만 내려받습니다. 다만 libxml2는 XSD 1.0만 구현합니다. xs:assert 같은 XSD 1.1 기능을 쓰는 스키마는 컴파일되지 않으며, 이 도구는 알 수 없는 구조 오류 대신 그 사실을 분명히 알려 줍니다.
다른 검사기는 하나만 알려 주는데 여기서는 왜 여러 오류가 나오나요?
오류 하나가 전부인 경우는 드물고, 첫 문제에서 멈추는 파서는 큰 문서를 한 번에 하나씩 고치게 만들기 때문입니다.
이 스캐너는 실패 후에 복구해 계속 진행하므로, 한 번의 검사로 4행의 따옴표 없는 속성, 12행의 그대로 쓰인 앰퍼샌드, 끝부분의 닫히지 않은 태그를 모두 찾아냅니다. 다만 주의할 점이 있습니다. 닫히지 않은 태그처럼 앞쪽에서 생긴 실수는 그 뒤의 모든 것을 잘못된 것처럼 보이게 만들 수 있습니다. 목록을 아래에서부터 훑기보다, 앞의 몇 개를 고치고 다시 검사하세요.
얼마나 큰 파일까지 처리하나요?
20 MB까지입니다. 10 MB 문서는 1초 조금 넘게 걸려 검사되고, 구문 분석은 Web Worker에서 돌기 때문에 그동안 페이지가 멈추지 않습니다.
이 한계는 충돌을 겪고 나서 정한 것이 아니라 의도적으로 둔 것입니다. 모든 것이 이 탭의 메모리에 올라가는데, 대략 20 MB를 넘으면 파스 트리가 수백 MB를 차지할 수 있습니다. 정말 큰 파일이라면 자신의 컴퓨터에서 스트리밍 파서를 쓰는 것이 맞습니다. xmllint, 파이썬의 iterparse, SAX 파서 모두 트리 전체를 만들지 않습니다.
네임스페이스를 제대로 처리하나요?
네. 접두사는 유효 범위 안의 선언에 따라 해석되며, 바인딩되지 않은 접두사를 쓰면 추가해야 할 선언과 함께 오류로 보고합니다. 더 큰 문서에서 일부만 복사해 오고 xmlns 선언은 원래 루트 요소에 남겨 두었을 때 자주 생기는 문제입니다.
편집기는 접두사를 지역 이름보다 흐리게 표시하기도 합니다. 덕분에 soap:Body는 "받침대가 붙은 Body"처럼 읽힙니다. 사소한 차이지만, 깊이 중첩된 SOAP 엔벨로프를 눈으로 훑기가 훨씬 수월해집니다.
자격 증명이 들어 있는 문서를 붙여넣어도 안전한가요?
문서를 업로드하는 어떤 도구보다 안전합니다. 아무것도 전송되지 않기 때문입니다. 문서는 탭을 벗어나지 않고, 기록되지 않으며, 어떤 오류 보고에도 포함되지 않습니다.
한 가지는 분명히 말해 둘 필요가 있습니다. 새로고침해도 작업이 사라지지 않도록, 입력한 내용은 이 브라우저의 localStorage에 저장됩니다. 이것은 여러분의 컴퓨터 안에만 있고 전송되지 않지만, 지우기 전까지는 문서가 남아 있다는 뜻이기도 합니다. 지우기 버튼을 누르면 즉시 삭제되고, 300 KB가 넘는 문서는 애초에 저장되지 않습니다.
이것으로 XML 사이트맵을 검사할 수 있나요?
가능하지만 사이트맵이라면 전용 사이트맵 검사기 페이지가 더 낫습니다. 이 페이지가 확인하는 것은 문서가 정형식 XML인지 여부이고, 그것은 필요조건일 뿐 충분조건이 아닙니다. 구글이 거부하는 사이트맵은 대개 정형식이며 대신 프로토콜 규칙을 어기고 있습니다.
전용 페이지는 규칙 자체를 검사합니다. URL 50,000개와 비압축 50 MB 한도, sitemaps.org 네임스페이스, 프레임워크가 내보낸 값이 아니라 W3C Datetime 형식의 lastmod, 그리고 모든 URL이 사이트맵 파일과 같은 호스트에 있어야 한다는 요건입니다. 구글이 무시한다고 공개적으로 밝힌 요소도 표시해 주므로, 아무 효과 없는 값을 계속 조정하지 않아도 됩니다.
SEPA나 pain.008, camt.053 같은 ISO 20022 파일도 처리하나요?
처리합니다. ISO 20022 메시지는 큰 스키마를 뒤에 둔 평범한 XML이므로, 메시지는 XSD 검사기에 넣고 해당하는 pain.008 또는 camt.053 스키마를 두 번째 창에 붙여 넣으십시오. 검사는 브라우저 안에서 그 스키마에 대해 실행되며, 만들 계정도 없고 전체 20 MB 제한 외의 상한도 없습니다.
문서가 어디로 가느냐가 가장 중요한 경우가 바로 이것입니다. 시험용에 불과한 지급 파일에도 실제 IBAN과 채권자 식별자, 위임 참조번호가 들어 있으며, ISO 20022 파일을 받아 주는 무료 검사기 중 여럿은 그것을 먼저 서버로 올립니다. 여기서는 아무것도 전송되지 않고, 작업하는 동안 네트워크 탭에서 직접 확인할 수 있습니다. 알아 둘 한계가 하나 있습니다. 엔진이 구현한 것은 XSD 1.0이며, 공개된 ISO 20022 스키마가 그 판으로 작성되어 있습니다.
DayZ의 types.xml 같은 서버 파일에도 쓸 수 있나요?
쓸 수 있고, 잘 맞는 편입니다. DayZ의 경제 파일인 types.xml, cfgspawnabletypes.xml, events.xml, cfgeventspawns.xml은 모두 평범한 XML이고, 그중 하나라도 깨져 있으면 서버가 시작을 거부합니다. 그때 출력되는 메시지는 대개 파일도 위치도 알려 주지 않는데, 꺾쇠 하나 빠진 일이 저녁 한나절이 되는 이유가 그것입니다.
파일을 여기에 붙여 넣으면 모든 문법 오류가 줄과 열과 함께 한 번에 보고되므로, 여러 차례에 걸쳐 손으로 고친 파일도 재시작을 반복하지 않고 한 번에 정리할 수 있습니다. 밝혀 둘 점이 두 가지 있습니다. 이 파일들에는 공개된 XSD가 없으므로 여기서 확인하는 것은 XML이 정형식인지이지 속성 값이 게임이 받아들이는 값인지가 아닙니다. 또한 nominal이나 lifetime 값이 XML로는 올바르지만 루트 경제 설정으로는 틀린 경우, 여기서는 통과하고 게임 안에서는 여전히 잘못 동작합니다.
Notepad++의 XML 검사기와 비교하면 어떤가요?
엔진은 같습니다. Notepad++ 자체는 XML을 지원하지 않고 XML Tools 플러그인이 그것을 제공하는데, 그 토대가 libxml2이고 이 사이트가 WebAssembly로 실행하는 것도 같은 것입니다. 따라서 문서가 정형식인지에 대한 두 판단은 일치합니다.
차이는 실무적인 데 있습니다. 플러그인은 Windows 전용이고 빌드가 편집기의 아키텍처와 맞아야 하며, 새로 설치했는데 메뉴가 회색인 경우가 잦은 이유가 그것입니다. 오류를 문서 위가 아니라 대화 상자에 표시하고, 스키마 검사는 XSD가 파일 안에 선언되어 있기를 기대하지만 복사해 온 조각에는 그런 선언이 거의 없습니다. 이 페이지는 선언 없이 두 번째 창에 붙여 넣은 XSD를 받고, 모든 문법 오류를 한 번에 보고하며, 브라우저만 있으면 어디서든 동작합니다. 파일이 이미 Notepad++에 열려 있고 오프라인이라면 플러그인을 쓰십시오. 그 경우는 플러그인이 낫습니다.
이 XML 검사기는 무료인가요? 가입해야 하나요?
무료이며 계정도, 이메일 요구도, 하루 사용량 제한도, 스키마 검사를 붙잡아 두는 유료 요금제도 없습니다. 이 사이트에서 잠겨 있는 기능은 없습니다.
이는 들리는 것만큼 어려운 약속이 아닙니다. 비용 구조가 다르기 때문입니다. 서버에서 도는 검사기는 여러분이 검사하는 문서마다 CPU 비용을 냅니다. 그래서 그런 도구들은 사용량을 세고, 파일 크기에 상한을 두고, 가입을 요구합니다. 여기서는 해석이 여러분의 기기에서 일어나므로 10 MB 파일도 사이트에는 비용이 들지 않고, 몇 건을 검사했는지 셀 이유가 없습니다.
아무것도 설치하지 않고 온라인에서 XML을 검사할 수 있나요?
이 페이지가 바로 그것입니다. Windows, macOS, Linux, Android, iOS 어디서든 최신 브라우저면 동작하고, 설치할 것도 확장 프로그램도 계정도 없습니다.
한 가지 구분해 둘 만한 점이 있습니다. 여기서 '온라인'이라는 말이 두 가지 일을 하고 있기 때문입니다. 대부분의 온라인 검사기는 두 뜻 모두에서 온라인입니다. 페이지가 웹에 있고, 여러분의 문서도 검사를 위해 그쪽 서버로 전송됩니다. 이것은 첫 번째 뜻에서만 온라인입니다. 페이지는 네트워크로 한 번 전달되고, 그 뒤로는 파서와 스키마 엔진과 편집기가 모두 탭 안에서 로컬로 동작합니다. 한 번 열어 두면 네트워크를 끊어도 계속 쓸 수 있습니다.
이것은 XML 검사기이자 포매터인가요, 아니면 도구가 둘 필요한가요?
둘 다 여기 있습니다. 위쪽 줄의 정렬 버튼은 편집기에 있는 내용을 그 자리에서 다시 정렬합니다. 읽을 수 없는 것을 붙여 넣고, 보기 좋게 펼친 다음, 오류를 찾는 평소의 순서가 사이트를 옮겨 다니지 않고 끝납니다.
XML 포매터는 정렬 자체가 목적이고 다른 일로 가는 중간 단계가 아닐 때를 위한 완전한 버전입니다. 공백 두 칸, 네 칸, 탭 중에서 들여쓰기를 고르고, 주석을 어떻게 할지 정하고, 반대 방향으로 축약까지 할 수 있습니다. 그 페이지에서도 검사는 함께 돌아갑니다. 문서가 정형식이어야 애초에 다시 정렬할 수 있기 때문입니다.
검사뿐 아니라 XML을 보기 좋게 정리(beautify)할 수도 있나요?
가능합니다. 정리, 보기 좋은 출력, 정렬은 모두 같은 작업입니다. 중첩이 눈에 보이도록 들여쓰기를 다시 하는 것이고, 대개 그것이 잘못된 곳을 찾을 수 있게 해 줍니다.
알아 둘 만한 점이 하나 있습니다. 대부분의 정리 도구가 이 부분을 틀리기 때문입니다. 두 요소 사이의 공백은 의미가 없어 바꾸어도 안전하지만, 텍스트도 함께 담고 있는 요소 안쪽의 공백은 데이터이며, 들여쓰기를 다시 하면 문서의 뜻이 바뀝니다. <p>Hello <b>there</b></p>를 들여쓴 세 줄로 쪼개는 도구는 표현이 아니라 내용을 바꿔 버린 것입니다. 이 도구는 혼합 내용을 발견한 그대로 두며, 그래서 정리된 문서에서도 일부는 한 줄로 남습니다.
가장 좋은 XML 검사기는 무엇인가요?
문서가 이미 어디에 있고 무엇을 확인해야 하느냐에 따라 다르며, 정직한 답에는 이것이 답이 아닌 경우도 들어갑니다.
붙여 넣을 수 있는 문서라면 브라우저 도구가 가장 짧은 길이고, 비교할 만한 것은 세 가지입니다. 스키마 검사를 하기는 하는지, 그러려고 파일을 업로드하는지, 그리고 알려 주는 오류를 가지고 실제로 움직일 수 있는지입니다. 이미 프로젝트에서 열려 있는 파일이라면 편집기가 더 가깝습니다. VS Code에 Red Hat의 XML 확장을 넣거나 IntelliJ를 쓰면 입력하는 동안 스키마 검사가 돌아갑니다. 메모리에 담기 어려울 만큼 큰 파일이거나 빌드의 한 단계라면 xmllint가 맞는 도구이고 대부분의 장비에 이미 설치되어 있습니다. CI 파이프라인이라면 그 자리에 맞는 것은 파이프라인이 작성된 언어의 검사기입니다.
이 사이트가 겨냥한 것은 그 중간입니다. 서버 없는 스키마 검사, 첫 번째 하나가 아니라 모든 문법 오류를 한 번에, 그리고 파서를 만든 사람이 아니라 읽는 사람을 향해 쓰인 메시지입니다.