Hex и dataUri

Валидация строк, содержащих шестнадцатеричные данные, часто используется при работе с идентификаторами, криптографическими значениями, цветами и бинарными представлениями. В Joi для этого предусмотрен специализированный метод hex, который обеспечивает проверку строки на соответствие шестнадцатеричному формату.

Метод hex применяется к базовому типу строки и ограничивает допустимые символы диапазоном 0-9, a-f, A-F. Любые другие символы автоматически приводят к ошибке валидации. Это позволяет гарантировать, что данные строго соответствуют hex-формату без дополнительных проверок.

Типичная структура использования:

import Joi from 'joi';

const schema = Joi.object({
  hash: Joi.string().hex()
});

Такой вариант проверяет только допустимость символов, но не ограничивает длину строки. В реальных сценариях hex-значения почти всегда имеют фиксированный размер, например 32 символа для MD5 или 64 символа для SHA-256. Для этого применяется комбинирование hex с ограничениями длины.

const schema = Joi.object({
  md5: Joi.string().hex().length(32),
  sha256: Joi.string().hex().length(64)
});

Ограничение длины является важным элементом защиты от некорректных или частично обрезанных данных. Joi выполняет проверку последовательно: сначала проверяется набор символов, затем длина строки.

В некоторых случаях требуется контроль не только длины, но и структуры hex-данных, например при работе с бинарными буферами, представленными в текстовом виде. В таких ситуациях полезно использовать дополнительные ограничения, такие как регулярные выражения, однако hex остаётся более читаемым и декларативным способом выражения намерения.

const colorSchema = Joi.object({
  color: Joi.string().hex().length(6)
});

Такой подход часто применяется для проверки цветов в формате RRGGBB, где строка не содержит символа `

Работа с data URI представляет собой отдельный класс задач, связанных с передачей бинарных данных в текстовом формате. Data URI используется для встраивания изображений, файлов и других ресурсов непосредственно в строку. Формат описывается стандартом RFC 2397 и имеет вид:

data:[<mediatype>][;base64],<data>

В Joi для проверки таких строк используется метод dataUri, который обеспечивает базовую валидацию структуры.

const schema = Joi.object({
  file: Joi.string().dataUri()
});

Данный валидатор проверяет, что строка начинается с префикса data: и соответствует общей структуре data URI. Это включает наличие MIME-типа (необязательно), указание кодировки base64 при необходимости и наличие самой полезной нагрузки после запятой.

Валидация data URI особенно важна в системах, где пользователь может загружать файлы в виде строк, например изображения аватаров или вложения в API-запросах. Без проверки структура может быть нарушена, что приведёт к ошибкам декодирования или потенциальным уязвимостям.

Пример более прикладного использования:

const imageSchema = Joi.object({
  avatar: Joi.string().dataUri()
});

При необходимости можно комбинировать dataUri с другими ограничениями строки, например проверкой максимального размера, чтобы ограничить объём передаваемых данных:

const schema = Joi.object({
  avatar: Joi.string().dataUri().max(50_000)
});

Такое ограничение не анализирует содержимое data URI, но предотвращает чрезмерно большие строки, которые могут негативно повлиять на производительность или привести к злоупотреблениям.

Внутренняя логика проверки data URI в Joi ориентирована на структурную целостность строки. Основное внимание уделяется корректности схемы и наличию разделителей. При этом содержимое после base64-заголовка не декодируется и не анализируется на соответствие MIME-типу, если не используются дополнительные пользовательские проверки.

Hex и dataUri часто применяются в разных слоях одной системы. Hex-значения характерны для идентификаторов и хэшей, dataUri — для передачи медиа-контента. Их совместное использование встречается в API, где идентификаторы связываются с встроенными ресурсами.

Пример комбинированной схемы:

const schema = Joi.object({
  id: Joi.string().hex().length(24),
  preview: Joi.string().dataUri()
});

Такое разделение позволяет чётко отделять структурные идентификаторы от бинарных данных, представленных в строковом виде.

При проектировании схем важно учитывать, что hex проверяет исключительно допустимые символы, не накладывая семантических ограничений на значение строки. Это означает, что строка может быть валидной с точки зрения формата, но не соответствовать ожидаемой бизнес-логике, если не заданы дополнительные правила.

Аналогично dataUri гарантирует корректность синтаксиса, но не проверяет содержимое на предмет безопасности, типа файла или корректности декодирования в конкретном контексте приложения. Валидация на уровне Joi решает задачу структурной проверки, оставляя семантическую обработку прикладному коду.

При работе с hex-значениями в некоторых системах дополнительно учитывается регистр символов. Joi по умолчанию допускает как верхний, так и нижний регистр, что соответствует стандартной практике представления шестнадцатеричных данных.

Использование строгих ограничений длины вместе с hex часто заменяет необходимость сложных регулярных выражений, делая схемы более читаемыми и поддерживаемыми.

const tokenSchema = Joi.object({
  accessToken: Joi.string().hex().length(40),
  refreshToken: Joi.string().hex().length(64)
});

Такой подход особенно распространён в системах аутентификации, где токены имеют фиксированную длину и кодируются в hex для удобства передачи.

Data URI валидация также часто используется в сценариях клиент-серверного взаимодействия, где изображения или файлы передаются без отдельного загрузочного механизма. В таких случаях Joi обеспечивает первичную фильтрацию входных данных до их дальнейшей обработки.

const uploadSchema = Joi.object({
  filename: Joi.string().min(1).max(255),
  content: Joi.string().dataUri()
});

Такое разделение позволяет отделить метаданные файла от его содержимого и упростить последующую обработку.

Hex и dataUri остаются базовыми, но важными инструментами в наборе строковой валидации Joi, обеспечивая контроль над распространёнными форматами представления данных в современных веб-приложениях.

Оглавление