本文へスキップ

文字列エスケープ

String Escaper

JSON・JavaScript・SQL・シェル・CSV・正規表現の規則に合わせて文字列をエスケープし、元にも戻します。

文字列リテラルの中に貼り付けられるよう、テキストをエスケープし、また元に戻します。JSON、JavaScript、Python、Java、C#、SQL、シェルのコマンド、CSVのフィールド、正規表現と、対象ごとに規則が違います。その違いこそが、インジェクションのバグが住んでいる場所です。

🔒 ブラウザの中だけで動きますescapestringjsonshell
ルール
向き

RFC 8259: `\" \\ \/ \b \f \n \r \t`、残りは `\uXXXX`。`\'` も `\x` も `\0` もありません。

テキスト

エスケープされた値

入力

0文字

出力

0文字

使い方

  1. 対象の言語を選びます

    選択欄の下に、その対象が実際に何をエスケープするのかが書いてあります。JSONはJavaScriptより厳しく、テンプレートリテラルは気にすべき文字が2つ増えます。シングルクォートのシェルとダブルクォートのシェルは、そもそも別の問題です。

  2. 元のテキストを貼り付けます

    改行、クォート、非ASCIIはすべて処理します。出てくるのはリテラルの*内側*です。囲むクォートは自分で付けてください。

  3. 「元に戻しても同じ」を確認します

    出力の下の項目が、結果をエスケープ解除して入力と比べます。いいえと出たら、この対象ではエスケープに損失があるということで、貼り付ける文字列は元の文字列ではありません。

よくある質問

エスケープすればSQLは安全になりますか

なりません。リテラルをエスケープすることと、プレースホルダを使ったクエリは別のものです。このツールは、データベースのクォートのモードも、文字セットも、その値がクォートを区切りとしない場所へ行くのかどうかも知りません。バインド変数を使ってください。これはクエリを読むためのもので、本番のクエリを組み立てるための道具ではありません。

SQLのモードがバックスラッシュを使わないのはなぜですか

標準のSQLにバックスラッシュのエスケープが無いからです。クォートは2回書きます。バックスラッシュのエスケープはMySQLの拡張で、それがあると決めてかかったコードからインジェクションの事故がかなり出ています。MySQLの挙動が必要なら、それは意識して選ぶことです。

`\uXXXX`の対象は何をしますか

非ASCIIの文字をすべて`\uXXXX`のエスケープに変えます。サロゲートペアも含みます。役に立つのはむしろ逆方向です。ASCIIしか通らないパイプラインが壊したpropertiesファイルやログの行を戻すと、日本語が戻ってきます。

シングルクォートのシェルなら、どんな文字列でも本当に安全ですか

文字列そのものについてはそうです。POSIXのシングルクォートの中では何も意味を持たず、クォート自体は`'\''`と書きます。守ってくれないのは、呼び出す先のプログラムが引数を解釈することと、POSIXではないシェルです。これはクォートの規則であって、サンドボックスではありません。

ここから渡せます

次の一手

このツールが出したものをそのまま受け取れる道具です。