Loading…
Текст успешно скопирован!
Предварительная валидация
Онлайн HTML валидатор (HTML validator) является сервисом, который бесплатно анализирует html код web страниц на наличие ошибок. Валидатор HTML проводит верификацию согласно существующим стандартам. Большинство сайтов написаны с использованием языков разметки HTML5 или XHTML. Они должны содержать правильную разметку, которая обеспечит высокое качество веб-страниц, их быструю и полную индексацию. W3C валидатор HTML поможет вам найти отсутствующие или некорректные теги HTML в ваших документах. Валидация HTML является одним из основных факторов, влияющих на качество поисковой индексации в Яндекс и Google. W3C validator делает полный отчет по ошибкам в HTML коде. Он выполняет анализ сайта для оценки качества разметки в соответствии с действующими стандартами. Помогая вам проверить валидность кода HTML, выявить и исправить ошибки.
HTML Validator is a free online developer tool to validate HTML code against the W3C standards as known as HTML linter instantly. Supports partial HTML code validation.
You can either browse an HTML file, fetch HTML code from a URL, or paste HTML code manually, and then click the validate button. The results will be displayed accordingly when the process is done.
Basically, there are two types of result messages: warning
and error
Warning — A suggestion to fix your HTML code. For instance, an HTML attribute that can be omitted.
Error — An error in your HTML code that’s against the W3C standards. You’re encouraged to fix it.
Each message comes with a line number and excerpt code indicating where a warning or an error is located.
Optionally, you can partially validate HTML code by enabling the fragment
option so that the HTML code will be treated as part of an HTML document instead of a full one.
Как проверить CSS и HTML-код на валидность и зачем это нужно.
В статье:
-
Что такое валидность кода
-
Чем ошибки в HTML грозят сайту
-
Как проверить код на валидность
-
HTML и CSS валидаторы — онлайн-сервисы для проверки кода
Разберем, насколько критическими для работы сайта и его продвижения могут быть ошибки в HTML-коде, и зачем нужны общие стандарты верстки.
Что такое валидность кода
После разработки дизайна программисты верстают страницы сайта — приводят их к единой структуре в формате HTML. Задача верстальщика — сделать так, чтобы страницы отображались корректно у всех пользователей на любых устройствах и браузерах. Такая верстка называется кроссплатформенной и кроссбраузерной — это обязательное требование при разработке любых сайтов.
Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.
Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.
Разработчикам рекомендуется следовать критериям этих стандартов при верстке — это поможет избежать ошибок в коде, которые могут навредить сайту.
Чем ошибки в HTML грозят сайту
Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.
Какие проблемы могут возникнуть из-за ошибок в HTML-коде
- страницы загружаются медленно;
- сайт некорректно отображается на разных устройствах или в браузерах;
- посетители видят не весь контент;
- программист не замечает скрытую рекламу и вредоносный код.
Как валидность кода влияет на SEO
Валидность не является фактором ранжирования в Яндекс или Google, так что напрямую она не влияет на позиции сайта в выдаче поисковых систем. Но она влияет на мобилопригодность сайта и на то, как поисковые боты воспринимают разметку, а от этого косвенно могут пострадать позиции или трафик.
Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров
Представитель Google Джон Мюллер говорил о валидности кода:
«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?
Это не прямой фактор ранжирования. Если ваш сайт использует HTML с ошибками, это не значит, что мы удалим его из индекса — я думаю, что тогда у нас будут пустые результаты поиска.
Но есть несколько важных аспектов:— Если у сайта действительно битый HTML, тогда нам будет очень сложно его отсканировать и проиндексировать.
— Иногда действительно трудно подобрать структурированную разметку, если HTML полностью нарушен, поэтому используйте валидатор разметки.
— Другой аспект касается мобильных устройств и поддержки кроссбраузерности: если вы сломали HTML, то сайт иногда очень трудно рендерить на новых устройствах».
Итак, критические ошибки в HTML мешают
- сканированию сайта поисковыми ботами;
- определению структурированной разметки на странице;
- рендерингу на мобильных устройствах и кроссбраузерности.
Даже если вы уверены в своем коде, лучше его проверить — ошибки могут возникать из-за установки тем, сторонних плагинов и других элементов, и быть незаметными. Не все программисты ориентируются на стандарт W3C, так что среди готовых решений могут быть продукты с ошибками, особенно среди бесплатных.
Как проверить код на валидность
Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.
Что они проверяют:
- Синтаксис
Синтаксические ошибки: пропущенные символы, ошибки в написании тегов. - Вложенность тэгов
Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность.
- DTD (Document Type Definition)
Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.
Обычно сервисы делят результаты на ошибки и предупреждения. Ошибки — опечатки в коде, пропущенные или лишние символы, которые скорее всего создадут проблемы. Предупреждения — бессмысленная разметка, лишние символы, какие-то другие ошибки, которые скорее всего не навредят сайту, но идут вразрез с принятым стандартом.
Валидаторы не всегда правы — некоторые ошибки не мешают браузерам воспринимать код корректно, зато, к примеру, минификация сокращает длину кода, удаляя лишние пробелы, которые не влияют на его отображение.
Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов
Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.
Перед исправлением ошибок не забудьте сделать резервное копирование. Если вы исправите код, но что-то пойдет не так и он перестанет отображаться, как должен, вы сможете откатить все назад.
HTML и CSS валидаторы — онлайн-сервисы для проверки кода
Есть довольно много валидаторов, выберите тот, в котором вам удобнее работать. Мы рекомендуем использовать известные сервисы от создателей стандартов. Если пояснения на английском воспринимать сложно, можно использовать автоматический перевод страницы.
Валидатор от W3C
Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.
Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.
Валидатор CSS от W3C
Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.
Исправления ошибок и валидации HTML и CSS может быть недостаточно: всегда есть другие возможности испортить отображение сайта. Если что-то не работает, как надо, проведите полноценный аудит, чтобы найти ошибки.
С другой стороны, не зацикливайтесь на поиске недочетов в HTML — если код работает, а контент отображается корректно, лучше направить ресурсы на что-то другое — оптимизацию и ускорение загрузки, например.
Validates HTML files for compliance against the W3C standards and performs linting to assess code quality against best practices.
Find missing or unbalanced HTML tags in your documents, stray characters, duplicate IDs, missing or invalid attributes and other recommendations.
Supports HTML5, SVG 1.1, MathML 3.0, ITS 2.0, RDFa Lite 1.1. Implementation is based on Validator.Nu.
The Nu Html Checker (v.Nu)
The Nu Html Checker (v.Nu) helps you catch unintended mistakes in your HTML,
CSS, and SVG. It enables you to batch-check documents from the command
line and from other scripts/apps, and to deploy your own instance of the
checker as a service (like validator.w3.org/nu). Its source code is
available, as are instructions on how to build, test, and run the
code.
A Dockerfile (see Pulling the Docker image below) and npm,
pip, and brew packages are also available.
It is released upstream in these formats:
-
pre-compiled Linux, Windows, and macOS binaries that include an embedded
Java runtime -
vnu.jar
— a portable version you can use on any system that has Java 8 or
above installed -
vnu.war
— for deploying the checker service through a servlet container
such as Tomcat
Note: The vnu.jar and vnu.war files require you to have Java 8 or above
installed. The pre-compiled Linux, Windows, and macOS binaries don’t require you
to have any version of Java already installed at all.
You can get the latest release or run docker run -it --rm -p 8888:8888 ghcr.io/validator/validator:latest
, npm install vnu-jar
,
npm install --registry=https://npm.pkg.github.com @validator/vnu-jar
,
brew install vnu
, or pip install html5validator
and see the
Usage and Web-based checking sections below. Or automate your document
checking with a frontend such as:
-
Grunt plugin for HTML validation or Gulp plugin for HTML
validation or Maven plugin for HTML validation -
html5validator
pip
package (for integration in Travis CI, CircleCI,
CodeShip, Jekyll, Pelican, etc.) -
LMVTFY: Let Me Validate That For You (auto-check JSFiddle/JSBin, etc.,
links in GitHub issue comments)
Usage
Run the checker with one of the following invocations:
• vnu-runtime-image/bin/vnu OPTIONS FILES
(Linux or macOS)
• vnu-runtime-imagebinvnu.bat OPTIONS FILES
(Windows)
• java -jar ~/vnu.jar OPTIONS FILES
(any system with Java8+ installed)
…where FILES
are the documents to check, and OPTIONS
are zero or more of
the following options:
--errors-only --Werror --exit-zero-always --stdout --asciiquotes
--user-agent USER_AGENT --no-langdetect --no-stream --filterfile FILENAME
--filterpattern PATTERN --css --skip-non-css --also-check-css --svg
--skip-non-svg --also-check-svg --xml --html --skip-non-html
--format gnu|xml|json|text --help --verbose --version
The Options section below provides details on each option, and the rest of
this section provides some specific examples.
Note: Throughout these examples, replace ~/vnu.jar
with the actual path to
that jar file on your system, and replace vnu-runtime-image/bin/vnu
and
vnu-runtime-imagebinvnu.bat
with the actual path to the vnu
or vnu.bat
program on your system — or if you add the vnu-runtime-image/bin
or
vnu-runtime-imagebin
directory your system PATH
environment variable, you
can invoke the checker with just vnu
.
To check one or more documents from the command line:
vnu-runtime-image/bin/vnu FILE.html FILE2.html FILE3.html...
vnu-runtime-imagebinvnu.bat FILE.html FILE2.html FILE3.html...
java -jar ~/vnu.jar FILE.html FILE2.html FILE3.html...
Note: If you get a StackOverflowError
error when invoking the checker, try
adjusting the thread stack size by providing the -Xss
option to java:
java -Xss512k -jar ~/vnu.jar ...
vnu-runtime-image/bin/java -Xss512k
-m vnu/nu.validator.client.SimpleCommandLineValidator ...
To check all documents in a particular directory DIRECTORY_PATH
as HTML:
java -jar ~/vnu.jar DIRECTORY_PATH
vnu-runtime-image/bin/vnu DIRECTORY_PATH
vnu-runtime-imagebinvnu.bat DIRECTORY_PATH
More examples
Note: The examples in this section assume you have the
vnu-runtime-image/bin
or vnu-runtime-imagebin
directory in your system
PATH
environment variable. If you’re using the jar file instead, replace vnu
in the examples with java -jar ~/vnu.jar
.
To check all documents in a particular directory DIRECTORY_PATH
as HTML, but
skip any documents whose names don’t end with the extensions .html
, .htm
,
.xhtml
, or .xht
:
vnu --skip-non-html DIRECTORY_PATH
To check all documents in a particular directory as CSS:
To check all documents in a particular directory as CSS, but skip any documents
whose names don’t end with the extension .css
:
vnu --skip-non-css DIRECTORY_PATH
To check all documents in a particular directory, with documents whose names end
in the extension .css
being checked as CSS, and all other documents being
checked as HTML:
vnu --also-check-css DIRECTORY_PATH
To check all documents in a particular directory as SVG:
To check all documents in a particular directory as SVG, but skip any documents
whose names don’t end with the extension .svg
:
vnu --skip-non-svg DIRECTORY_PATH
To check all documents in a particular directory, with documents whose names end
in the extension .svg
being checked as SVG, and all other documents being
checked as HTML:
vnu --also-check-svg DIRECTORY_PATH
To check a Web document:
vnu _URL_
example: vnu http://example.com/foo
To check standard input:
vnu -
example:
echo '<!doctype html><title>...' | vnu -
echo '<!doctype html><title>...' | java -jar ~/vnu.jar -
Options
When used from the command line as described in this section, the checker
provides the following options:
—asciiquotes
Specifies whether ASCII quotation marks are substituted for Unicode smart
quotation marks in messages.
default: [unset; Unicode smart quotation marks are used in messages]
—errors-only
Specifies that only error-level messages and non-document-error messages are
reported (so that warnings and info messages are not reported).
default: [unset; all messages reported, including warnings & info messages]
—Werror
Makes the checker exit non-zero if any warnings are encountered (even if
there are no errors).
default: [unset; checker exits zero if only warnings are encountered]
—exit-zero-always
Makes the checker exit zero even if errors are reported for any documents.
default: [unset; checker exits 1 if errors are reported for any documents]
—stdout
Makes the checker report errors and warnings to stdout rather than stderr.
default: [unset; checker reports errors and warnings to stderr]
—filterfile FILENAME
Specifies a filename. Each line of the file contains either a regular
expression or starts with "#" to indicate the line is a comment. Any error
message or warning message that matches a regular expression in the file is
filtered out (dropped/suppressed).
default: [unset; checker does no message filtering]
—filterpattern REGEXP
Specifies a regular expression. Any error message or warning message that
matches the regular expression is filtered out (dropped/suppressed).
As with all other checker options, this option may only be specified once.
So to filter multiple error messages or warning messages, you must provide a
single regular expression that will match all the messages. The typical way
to do that for regular expressions is to OR multiple patterns together using
the "|" character.
default: [unset; checker does no message filtering]
—format format
Specifies the output format for reporting the results.
default: "gnu"
possible values: "gnu", "xml", "json", "text" [see information at URL below]
https://github.com/validator/validator/wiki/Service-%C2%BB-Common-params#out
—help
Shows detailed usage information.
—skip-non-css
Check documents as CSS but skip documents that don’t have *.css extensions.
default: [unset; all documents found are checked]
—css
Force all documents to be checked as CSS, regardless of extension.
default: [unset]
—skip-non-svg
Check documents as SVG but skip documents that don’t have *.svg extensions.
default: [unset; all documents found are checked]
—svg
Force all documents to be checked as SVG, regardless of extension.
default: [unset]
—skip-non-html
Skip documents that don’t have *.html, *.htm, *.xhtml, or *.xht extensions.
default: [unset; all documents found are checked, regardless of extension]
—html
Forces any *.xhtml or *.xht documents to be parsed using the HTML parser.
default: [unset; XML parser is used for *.xhtml and *.xht documents]
—xml
Forces any *.html documents to be parsed using the XML parser.
default: [unset; HTML parser is used for *.html documents]
—also-check-css
Check CSS documents (in addition to checking HTML documents).
default: [unset; no documents are checked as CSS]
—also-check-svg
Check SVG documents (in addition to checking HTML documents).
default: [unset; no documents are checked as SVG]
—user-agent USER_AGENT
Specifies the value of the User-Agent request header to send when checking
HTTPS/HTTP URLs.
default: "Validator.nu/LV"
—no-langdetect
Disables language detection, so that documents are not checked for missing
or mislabeled html[lang] attributes.
default: [unset; language detection & html[lang] checking are performed]
—no-stream
Forces all documents to be be parsed in buffered mode instead of streaming
mode (causes some parse errors to be treated as non-fatal document errors
instead of as fatal document errors).
default: [unset; non-streamable parse errors cause fatal document errors]
—verbose
Specifies "verbose" output. (Currently this just means that the names of
files being checked are written to stdout.)
default: [unset; output is not verbose]
—version
Shows the checker version number.
Web-based checking
The Nu Html Checker — along with being usable as a standalone command-line
client — can be run as an HTTP service, similar to
validator.w3.org/nu, for browser-based checking of HTML documents, CSS
stylesheets, and SVG images over the Web. To that end, the checker is released
as several separate packages:
-
Linux, Windows, and macOS binaries for deploying the checker as a simple
self-contained service on any system -
vnu.jar
for deploying the checker as a simple self-contained service on a
system with Java installed -
vnu.war
for deploying the checker to a servlet container such as Tomcat
All deployments expose a REST API that enables checking of HTML documents, CSS
stylesheets, and SVG images from other clients, not just web browsers. And the
Linux, Windows, and macOS binaries and vnu.jar
package also include a simple
HTTP client that enables you to either send documents to a locally-running
instance of the checker HTTP service — for fast command-line checking — or to
any remote instance of the checker HTTP service running anywhere on the Web.
The latest releases of the Linux, Windows, and macOS binaries and vnu.jar and
vnu.war packages are available from the validator
project at github. The
following are detailed instructions on using them.
Note: Throughout these instructions, replace ~/vnu.jar
with the actual
path to that jar file on your system, and replace vnu-runtime-image/bin/java
and vnu-runtime-imagebinjava.exe
with the actual path to the checker java
or java.exe
program on your system — or if you add the vnu-runtime-image/bin
or vnu-runtime-imagebin
directory your system PATH
environment variable,
you can invoke the checker with just java nu.validator.servlet.Main 8888
.
Standalone web server
To run the checker as a standalone service (using a built-in Jetty server), open
a new terminal window and invoke the checker like this:
java -cp ~/vnu.jar nu.validator.servlet.Main 8888
vnu-runtime-image/bin/java nu.validator.servlet.Main 8888
vnu-runtime-imagebinjava.exe nu.validator.servlet.Main 8888
Then open http://0.0.0.0:8888 in a browser. (To listen on a different
port, replace 8888
with the port number.)
Warning: Future checker releases will bind by default to the address
127.0.0.1
. Your checker deployment might become unreachable unless you use the
nu.validator.servlet.bind-address
system property to bind the checker to a
different address:
java -cp ~/vnu.jar
-Dnu.validator.servlet.bind-address=128.30.52.73
nu.validator.servlet.Main 8888
vnu-runtime-image/bin/java
-Dnu.validator.servlet.bind-address=128.30.52.73
nu.validator.servlet.Main 8888
vnu-runtime-imagebinjava.exe
-Dnu.validator.servlet.bind-address=128.30.52.73
nu.validator.servlet.Main 8888
When you open http://0.0.0.0:8888 (or whatever URL corresponds to the
nu.validator.servlet.bind-address
value you’re using), you’ll see a form
similar to validator.w3.org/nu that allows you to enter the URL of an HTML
document, CSS stylesheet, or SVG image, and have the results of checking that
resource displayed in the browser.
Note: If you get a StackOverflowError
error when using the checker, try
adjusting the thread stack size by providing the -Xss
option to java:
java -Xss512k -cp ~/vnu.jar nu.validator.servlet.Main 8888
vnu-runtime-image/bin/java -Xss512k -m vnu/nu.validator.servlet.Main 8888
Deployment to servlet container
To run the checker inside of an existing servlet container such as Apache Tomcat
you will need to deploy the vnu.war
file to that server following its
documentation. For example, on Apache Tomcat you could do this using the
Manager application or simply by copying the file to the webapps
directory (since that is the default appBase
setting). Typically you would see
a message similar to the following in the catalina.out
log file.
May 7, 2014 4:42:04 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive /var/lib/tomcat7/webapps/vnu.war
Assuming your servlet container is configured to receive HTTP requests sent to
localhost
on port 80
and the context root of this application is vnu
(often the default behavior is to use the WAR file’s filename as the context
root unless one is explicitly specified) you should be able to access the
application by connecting to http://localhost/vnu/.
Note: You may want to customize the /WEB-INF/web.xml
file inside the WAR
file (you can use any ZIP-handling program) to modify the servlet filter
configuration. For example, if you wanted to disable the inbound-size-limit
filter, you could comment out that filter like this:
<!--
<filter>
<filter-name>inbound-size-limit-filter</filter-name>
<filter-class>nu.validator.servlet.InboundSizeLimitFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>inbound-size-limit-filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
-->
HTTP client (for fast command-line checking)
The checker is packaged with an HTTP client you can use from the command line to
either send documents to a locally-running instance of the checker HTTP service
— for fast command-line checking — or to a remote instance anywhere on the Web.
To check documents locally using the packaged HTTP client, do this:
-
Start up the checker as a local HTTP service, as described in the
Standalone web server section. -
Open a new terminal window and invoke the HTTP client like this:
java -cp ~/vnu.jar nu.validator.client.HttpClient FILE.html...
vnu-runtime-image/bin/java nu.validator.client.HttpClient FILE.html...
To send documents to an instance of the checker on the Web, such as
html5.validator.nu/, use the nu.validator.client.host and
nu.validator.client.port options, like this:
java -cp ~/vnu.jar -Dnu.validator.client.port=80
-Dnu.validator.client.host=html5.validator.nu
nu.validator.client.HttpClient FILE.html...
…or like this:
vnu-runtime-image/bin/java -Dnu.validator.client.port=80
-Dnu.validator.client.host=html5.validator.nu
nu.validator.client.HttpClient FILE.html...
Other options are documented below.
HTTP client options
When using the packaged HTTP client for sending documents to an instance of the
checker HTTP service for checking, you can set Java system properties to control
configuration options for the checker behavior.
For example, you can suppress warning-level messages and only show error-level
ones by setting the value of the nu.validator.client.level
system property to
error
, like this:
java -Dnu.validator.client.level=error
-cp ~/vnu.jar nu.validator.client.HttpClient FILE.html...
…or like this:
vnu-runtime-image/bin/java -Dnu.validator.client.level=error
-cp ~/vnu.jar nu.validator.client.HttpClient FILE.html...
Most of the properties listed below map to the common input parameters for the
checker service, as documented at
github.com/validator/validator/wiki/Service-»-Common-params.
nu.validator.client.host
Specifies the hostname of the checker for the client to connect to.
default: "127.0.0.1"
nu.validator.client.port
Specifies the hostname of the checker for the client to connect to.
default: "8888"
example: java -Dnu.validator.client.port=8080 -jar ~/vnu.jar FILE.html
nu.validator.client.level
Specifies the severity level of messages to report; to suppress
warning-level messages, and only show error-level ones, set this property to
"error".
default: [unset]
possible values: "error"
example: java -Dnu.validator.client.level=error -jar ~/vnu.jar FILE.html
nu.validator.client.parser
Specifies which parser to use.
default: "html"; or, for *.xhtml input files, "xml"
possible values: [see information at URL below]
https://github.com/validator/validator/wiki/Service-%C2%BB-Common-params#parser
nu.validator.client.charset
Specifies the encoding of the input document.
default: [unset]
nu.validator.client.content-type
Specifies the content-type of the input document.
default: "text/html"; or, for *.xhtml files, "application/xhtml+xml"
nu.validator.client.out
Specifies the output format for messages.
default: "gnu"
possible values: [see information at URL below]
https://github.com/validator/validator/wiki/Service-%C2%BB-Common-params#out
nu.validator.client.asciiquotes
Specifies whether ASCII quotation marks are substituted for Unicode smart
quotation marks in messages.
default: "yes"
possible values: "yes" or "no"
HTTP servlet options
nu.validator.servlet.bind-address
Binds the validator service to the specified IP address.
default: 0.0.0.0 [causes the checker to listen on all interfaces]
possible values: The IP address of any network interface
example: -Dnu.validator.servlet.bind-address=127.0.0.1
nu.validator.servlet.connection-timeout
Specifies the connection timeout.
default: 5000
possible values: number of milliseconds
example: -Dnu.validator.servlet.connection-timeout=5000
nu.validator.servlet.socket-timeout
Specifies the socket timeout.
default: 5000
possible values: number of milliseconds
example: -Dnu.validator.servlet.socket-timeout=5000
Pulling the Docker image
You can pull the checker Docker image from
https://ghcr.io/validator/validator in the GitHub container registry.
To pull and run the latest version of the checker:
docker run -it --rm -p 8888:8888 ghcr.io/validator/validator:latest
To pull and run a specific tag/version of the checker from the container
registry — for example, the 17.11.1
version:
docker run -it --rm -p 8888:8888 ghcr.io/validator/validator:17.11.1
To bind the checker to a specific address (rather than have it listening on all
interfaces):
docker run -it --rm -p 128.30.52.73:8888:8888
ghcr.io/validator/validator:latest
To make the checker run with a connection timeout and socket timeout different
than the default 5 seconds, use the CONNECTION_TIMEOUT_SECONDS
and
SOCKET_TIMEOUT_SECONDS
environment variables:
docker run -it --rm
-e CONNECTION_TIMEOUT_SECONDS=15
-e SOCKET_TIMEOUT_SECONDS=15
-p 8888:8888
validator/validator
To make the checker run with particular Java system properties set, use the
JAVA_TOOL_OPTIONS
environment variable:
docker run -it --rm
-e JAVA_TOOL_OPTIONS=-Dnu.validator.client.asciiquotes=yes
-p 8888:8888
validator/validator
To define a service named vnu
for use with docker compose
, create a Compose
file named docker-compose.yml
(for example), with contents such as the
following:
version: '2' services:
vnu:
image: validator/validator ports:
- "8888:8888"
network_mode: "host" #so "localhost" refers to the host machine.
Build instructions
Follow the steps below to build, test, and run the checker such that you can
open http://0.0.0.0:8888/
in a Web browser to use the checker Web UI.
-
Make sure you have git, python, and JDK 8 or above installed.
-
Set the
JAVA_HOME
environment variable:export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 <— Ubuntu, etc.
export JAVA_HOME=$(/usr/libexec/java_home) <— MacOS
-
Create a working directory:
git clone https://github.com/validator/validator.git
-
Change into your working directory:
cd validator
-
Start the checker Python script:
python ./checker.py all
The first time you run the checker Python script, you’ll need to be online and
the build will need time to download several megabytes of dependencies.
The steps above will build, test, and run the checker such that you can open
http://0.0.0.0:8888/
in a Web browser to use the checker Web UI.
Warning: Future checker releases will bind by default to the address
127.0.0.1
. Your checker deployment might become unreachable unless you use the
--bind-address
option to bind the checker to a different address:
python ./checker.py --bind-address=128.30.52.73 all
Use python ./checker.py --help
to see command-line options for controlling the
behavior of the script, as well as build-target names you can call separately;
e.g.:
-
python ./checker.py build # to build only
-
python ./checker.py build test # to build and test
-
python ./checker.py run # to run only
-
python ./checker.py jar # to compile vnu.jar
-
python ./checker.py update-shallow &&
python ./checker.py dldeps &&
python ./checker.py jar # to compile vnu.jar faster