Как пользоваться
- Вставьте текст в поле Текст и выберите Экранировать или Снять экранирование в поле Действие.
- Выберите вид строки в поле Формат, например Строка JSON или Строковый литерал SQL.
- Для формата с кавычками оставьте отметку Добавить кавычки, чтобы получить текст с кавычками, или снимите её, чтобы получить только содержимое.
- Прочитайте Результат и таблицу Экранированные символы, если вы экранировали текст.
Что означает экранирование
Строка в программе, файле или запросе может напрямую содержать лишь некоторые символы. Экранирование заменяет остальные символы, а также те, что завершили бы строку, на последовательность, которую формат читает обратно как тот же символ. У каждого формата свои последовательности, поэтому один символ можно записать несколькими способами, а снятие экранирования читает эти последовательности обратно в символы.
- JSON и JavaScript используют обратную косую черту, поэтому перевод строки записывается как \n.
- HTML и XML используют амперсанд, имя и точку с запятой, поэтому амперсанд записывается как &.
- CSV и SQL удваивают символ, который завершает поле или строку, поэтому одинарная кавычка в SQL записывается двумя одинарными кавычками.
Правила каждого формата
- Строка JSON: RFC 8259, раздел 7. Кавычка, обратная косая черта и управляющие символы экранируются, а экранирование \u с четырьмя шестнадцатеричными цифрами читается.
- Строка JavaScript: строковые литералы ECMA-262. В строке в двойных кавычках нужно экранировать только двойную кавычку, а старые восьмеричные экранирования не допускаются.
- Значение атрибута HTML: пять символов & < > " ' записываются ссылками. Имя, которое эта страница не знает, например é, остаётся как есть.
- Текст XML: те же пять символов, апостроф записывается как '. В XML 1.0 нет способа записать управляющий символ, поэтому такие символы отклоняются.
- Поле CSV: RFC 4180. Поле с запятой, кавычкой или переводом строки заключается в двойные кавычки, а каждая кавычка внутри него удваивается.
- Строковый литерал SQL: руководство PostgreSQL. Одинарная кавычка удваивается. Обратная косая черта в стандартном SQL не имеет особого значения.
- Регулярное выражение: обратная косая черта ставится перед каждым символом синтаксиса, как их перечисляет ECMA-262. При снятии экранирования сохраняются экранирования вроде \d, потому что это классы символов.
- Строка C# или Java: экранирования, которые читают оба языка. Перевод строки записывается как \n, а другие управляющие символы экранированием \u.
- Текст оболочки в одинарных кавычках: POSIX. Внутри одинарных кавычек ничто не имеет особого значения, поэтому кавычка записывается как '\'' (закрыть кавычку, экранировать её и открыть снова).
Ошибки, которые легко допустить
- Двойное экранирование удваивает обратные косые черты, поэтому результат показывает \\n там, где первое экранирование дало \n.
- Строка JSON, помещённая в файл JavaScript, по-прежнему требует собственных экранирований в этом файле, а строка SQL внутри приложения может требовать экранирований языка.
- Половину эмодзи нельзя записать ни в одном из этих форматов, поэтому страница её отклоняет. Введите символ заново.
Пример: строка JSON с кавычками, переводом строки и обратной косой чертой
Текст «Он сказал "привет" & ушёл.», перевод строки и затем «Путь: C:\temp» содержат две кавычки, один перевод строки и одну обратную косую черту. Экранированный как строка JSON с кавычками, он становится "Он сказал \"привет\" & ушёл.\nПуть: C:\\temp". Таблица считает символы, которые записаны иначе.
| Символ | Записан как | Количество |
|---|---|---|
| " | \" | 2 |
| U+000A | \n | 1 |
| \ | \\ | 1 |
Частые вопросы
Текст отправляется на сервер?
Нет. Экранирование и снятие экранирования выполняются в вашем браузере, поэтому текст, который содержит пароль или токен, остаётся на вашем устройстве.
Почему при снятии экранирования в JSON отклоняется \x41?
В JSON нет экранирования \x. Есть \u и четыре шестнадцатеричные цифры, поэтому буква A записывается как \u0041. Строка JavaScript допускает \x41, поэтому два формата перечислены отдельно.
Почему одинарные кавычки в строке JavaScript не трогаются?
Строке в двойных кавычках нужно экранировать только двойные кавычки. Если включена опция кавычек, результат заключается в двойные кавычки, поэтому одинарная кавычка там — обычный символ.
Почему в SQL не экранируется обратная косая черта?
Стандартный SQL не считает обратную косую черту особой внутри строковой константы. Некоторые базы данных, например MySQL по умолчанию, считают, поэтому проверьте правила своей базы, прежде чем писать обратную косую черту в строке SQL.
Что меняет опция «Добавить кавычки»?
Когда она включена, экранированный текст заключается в кавычки формата, например в двойные кавычки для JSON или в одинарные для SQL. Выключите её, чтобы получить только содержимое, например чтобы вставить его в строку, которая уже заключена в кавычки.
Почему результат CSV в кавычках, если в тексте нет кавычек?
RFC 4180 требует заключать поле в кавычки, если в нём есть запятая, кавычка или перевод строки. Простое поле записывается как есть, без кавычек.
Почему управляющий символ отклоняется для XML?
XML 1.0 не допускает символы вроде U+0001 вообще, даже в виде ссылки, поэтому страница не может их записать. Сначала удалите их из текста.
Источники
- RFC 8259: формат обмена данными JSON, раздел 7 (IETF, на английском)
- ECMA-262: спецификация языка ECMAScript, строковые литералы и синтаксис регулярных выражений (на английском)
- XML 1.0 (пятое издание), раздел 4.6, предопределённые сущности (W3C, на английском)
- RFC 4180: общий формат и тип MIME для файлов CSV (IETF, на английском)
- Руководство PostgreSQL: строковые константы (на английском)
- POSIX Shell and Utilities, раздел 2.2.2, одинарные кавычки (The Open Group, на английском)
- Спецификация языка Java, глава 3: литералы и escape-последовательности (Oracle, на английском)
- Спецификация языка C#, лексическая структура (Microsoft, на английском)
- Руководство MySQL: строковые литералы и символ экранирования обратной косой чертой (на английском)
Цифры и текст в последний раз проверены вторник, 10 ноября 2026 г..