🔒 String Escape/Unescape

🎯
⚙️
📝
{{ inputText.length }} characters
ℹ️
{{ formatInfo.name }}: {{ formatInfo.description }}
Pattern: {{ formatInfo.pattern }}
Example: {{ formatInfo.example }}
⚡
📤
{{ outputText.length }} characters
📊
Length: {{ analysis.length }} characters
Needs Escaping for: {{ analysis.needs_escaping.join(',') }}
Detected Escapes: {{ analysis.detected_escapes.join(',') }}
Recommendations:
• {{ rec }}
🔍
Original:
{{ inputText }}
{{ operation ==='escape' ?'Escaped' :'Unescaped' }}:
{{ outputText }}
Length changed: {{ inputText.length }} → {{ outputText.length }} ({{ outputText.length > inputText.length ?'+' :'' }}{{ outputText.length - inputText.length }})
💡
SQL: SELECT * FROM users WHERE name ='escaped_value'
Shell: echo"escaped_value"
PHP: $var ='escaped_value';
⚠️ {{ error }}

ℹ️ About String Escape/Unescape

String escaping rewrites quotes, backslashes, separators, control characters, and other syntax-sensitive bytes so the same text can be pasted into a specific parser context without changing the surrounding SQL, CSV, shell, regex, PHP, LDAP, XML, or C-style syntax. It is useful for quick checks, test fixtures, migration scripts, log samples, configuration snippets, and examples where you need to see the exact escaped form before putting text into code or a command line.

Each format has different rules. SQL string literal quoting is commonly done by doubling a single quote, as documented in the PostgreSQL lexical syntax reference, while CSV uses doubled quotes inside quoted fields as described by RFC 4180. Shell escaping follows quoting behavior such as the Bash quoting rules, LDAP filter escaping comes from RFC 4515, and XML attribute escaping follows the XML attribute-value grammar. JavaScript and JSON strings have their own grammars in the ECMAScript string literal rules and RFC 8259.

Supported escape targets:

  • SQL: doubles single quotes for SQL string literals, such as O'Reilly to O''Reilly.
  • CSV: quotes fields that contain commas, quotes, carriage returns, or line feeds, such as Hello, "World" to "Hello, ""World""".
  • Shell/Bash: prefixes shell metacharacters and whitespace with backslashes, such as echo $HOME to echo \$HOME.
  • Regular expression: escapes regex metacharacters so user text is matched literally, such as file[1].txt to file\[1\]\.txt.
  • PHP: escapes backslashes and single quotes for PHP single-quoted strings; see the PHP string documentation for language details.
  • LDAP filter: encodes *, parentheses, backslash, and NUL as RFC 4515 hex escapes.
  • XML attribute: converts &, quotes, apostrophes, and angle brackets to XML-safe entity references.
  • C/C++ string: turns tabs, line breaks, quotes, backslashes, and control characters into C-style escape sequences.

Security and correctness notes:

  • Escaping is context-specific: a string escaped for SQL is not safe for a shell command, JSON document, HTML attribute, or regex pattern.
  • For real database writes, prefer parameterized queries. OWASP SQL injection guidance treats escaping as secondary protection, not the main defense.
  • For shell execution, prefer APIs that pass an argument vector instead of building one command string from untrusted input.
  • For JSON and JavaScript source, use a JSON serializer or language-specific string literal encoder when you need a complete syntactically valid value.
  • Unescape mode reverses common escape sequences, but it cannot always infer the original parser state, quote style, database mode, or shell dialect.

Common workflows: preparing CSV cells for import, building a literal regex search from user text, checking how an LDAP filter value will be encoded, writing XML attribute examples, producing PHP or C fixture strings, and comparing escaped output against JavaScript or JSON requirements before moving to a dedicated serializer.

API Usage Example:

POST /api/tools/encoding-decoding/string-escape
Content-Type: application/json

{
    "text": "O'Reilly's book",
    "operation": "escape",
    "format": "sql"
}
Ready