JSONからクエリ文字列へ
このコンバータは、お使いのブラウザ内でJSONオブジェクトをURLクエリ文字列としてエンコードします。ネストされたオブジェクトはa[b]=cのブラケット形式を使用し、配列はキーを繰り返し、値はRFC 3986に従ってパーセントエンコードされ（スペースは%20）、nullは空値を持つキーになります。データはアップロードされません。
JSONからクエリ文字列へとは
GETリクエストパラメータとして送信されたことのあるJSONオブジェクトはすべて、単一行のkey=valueペアにフラット化されており、その過程では選択肢が存在しました：ネストの表現方法、配列の繰り返し方、nullの扱い方。このコンバータはこれらの選択肢を明示的かつ従来的に処理します――オブジェクトはa[b]=cのようにネストし、配列はキーを繰り返し、結果は1つのパーセントエンコードされた行になり、?の後に貼り付ける準備が整います。
これらの規約はここで発明されたものではありません。ブラケット形式はPHPのhttp_build_queryとRuby on Railsが20年以上出力してきた形式であり、すべての主要なクエリ文字列パーサーはそれを構造に戻して読み取ります。エンコードはRFC 3986に従います：予約されていない文字はそのまま読み取り可能で、スペースは%20になり、リテラルのプラスは%2Bになり、フォームモードと厳密なパーサーの両方で生き残ります。
このサイトの他の場所と同様に、作業はページを開いたタブ内で行われます：JSONはページ内のコードで解析・エンコードされ、ネットワークを越えることはありません。Content-Security-Policyは送信接続を明確に禁止しているため、変換中にDevToolsのネットワークパネルが空のままになることが、主張されるのではなく実証されるプライバシー保証そのものです。
このページが生成する文字列は、サイト上の姉妹コンバータが正確にJSONにデコードし直す解釈できるため、URLを送信する前の健全性チェックとしてラウンドトリップは有効です。
オブジェクト全体を構成するのではなく、単一の値をエスケープするだけの場合は、スタンドアロンのURLエンコーダ・デコーダが同じRFC 3986ルールで1つの文字列を処理します。
エンコードの実際の動作
コンバータは、解析されたオブジェクトをキーの順に走査し、各要素に対して1つのペアを出力し、&で結合します。各値はエンコード前に文字列化されます――数値はそのままの数字、ブール値はtrueまたはfalse、nullは空値――その後UTF-8としてパーセントエンコードされます。構造のルールは次のとおりです：
- オブジェクト：ネストされたオブジェクトはキーのパスをブラケットで拡張します。{"user": {"name": "Ada"}}はuser[name]=Adaになり、より深いレベルは別のブラケットグループを追加します：user[address][city]=London。
- 配列：スカラーの配列は要素ごとにキーを繰り返します――tag=navy&tag=math――これはRackとNodeのqsパーサーが配列に戻して読み取る形式です。
- null：空値を持つキー（token=）になり、キーをURLに保持しつつドロップしません。
- 空のオブジェクトと配列：そのキーに対して何も出力しません、書くべきペアがないため；キーの不在はプレビューに表示されるため、それは驚きではなく意図された動作です。
パーセントエンコード、RFC 3986スタイル
RFC 3986は予約されていない文字セット――A–Z, a–z, 0–9, ハイフン、ドット、アンダースコア、チルド――をそのままにしておき、それ以外のすべてをUTF-8としてバイト単位でパーセントエンコードすることを要求します。スペースは+ではなく%20です。プラスをスペースの代わりに使うのはapplication/x-www-form-urlencodedの古いフォーム規約であり、実際のバグを引き起こします：厳密なRFC 3986リーダーは裸の+をリテラルのプラス記号としてデコードします。スペースに%20、プラスに%2Bを出力することで、出力はフォームモードと厳密なリーダーの両方にとって同じ意味になります。
意図された例外：キーの角括弧はリテラルに出力されます、なぜならa[b]=c規約が実際に使われている形式だからです――PHPとRailsもそれをエスケープしません。角括弧はコンテンツではなく構造です。値は厳密にエンコードされ、このサイトの逆デコーダーはリテラルと%5B/%5Dでエスケープされた角括弧の両方を受け入れます。
出力の見た目
以下の実行例は、サンプル読み込みボタンが生成する正確なペアです：ネストされたユーザーオブジェクト、繰り返されるタグキー、nullトークンを持つ検索パラメータ。キーの順序はJSONドキュメントに従うため、再解析された文字列を再エンコードしても安定しています――同じオブジェクトは常に同じURLを生成し、これはリンクの比較、キャッシュ、またはそれらに対するテスト書き込みにおいて重要です。
このコンバータが変換せずに拒否するケース
これらの規約では誠実にエンコードできない形状が2つあり、どちらも創造的な推測ではなく名前付きエラーで拒否されます：
- トップレベルの配列――クエリ文字列にはキーのないスロットがありません。配列をキーの下のオブジェクトでラップし、繰り返し規約が残りを処理します。
- オブジェクトの配列――tag[name]=a&tag[name]=bは2つのレコードを1つのキーパスに collapse させ、tag[0][name]のようなインデックスを生成すると、要求していない構造を追加してしまいます。コンバータは拒否し、問題のキーを特定します。
よくある質問
JSONをクエリ文字列に変換すると、データがどこかにアップロードされますか？
いいえ。JSONは完全にこのブラウザタブ内で解析・エンコードされます；ページにはアップロードエンドポイントがなく、そのContent-Security-Policyは他への接続を禁止しているため、データの持ち出しは構造上不可能です。約束されているだけではありません。30秒で確認できます：DevToolsを開き、ネットワークパネルに切り替え、変換し、リクエストが発生しないのを確認してください。
なぜスペースは%20でエンコードされ、+ではありませんか？
プラスをスペースの代わりに使うのはapplication/x-www-form-urlencoded規約であり、RFC 3986――URI文法自体――は%20を要求し、リテラルの+をプラス記号として扱います。%20と%2Bでエンコードすることで、フォームモードと厳密なパーサーの両方が値を同一にデコードすることが明確になります。ブラウザはどちらでも寛容ですが、リスクは署名付きURLやキャッシュ層にある厳密なリーダーにあり、そここそ曖昧さが高くつく場所です。
なぜネストにa[b]=c表記を使うのですか？
それは事実上の標準的なブラケット表記で、PHPのhttp_build_queryとRuby on Railsが20年以上出力し、qs（Node）やRack（Ruby）のようなライブラリがネストされた構造に戻して解析しています。代替案は存在します――ドット、コロン、繰り返される深いキー――しかしいずれもリーダーのサポートはほど遠く、相互運用形式は最も広いオーディエンスを最適化すべきです。
配列はどのようにエンコードされ、なぜtag[]表記はありませんか？
スカラーの配列はキーを繰り返します：tag=navy&tag=math。RackやNodeのqsのようなサーバーはパース時に繰り返されたキーを配列に収集するため、ラウンドトリップはクリーンです。例外はPHPで、配列を構築するにはtag[]が必要です――この表記はこのコンバータは決して出力しません、なぜなら角括弧はここではオブジェクトのネストに予約されているからです。PHPが宛先の場合は、変換後にキーに空の角括弧を追加してください。
null、ブール値、数値はどうなりますか？
nullは空値を持つキー――token=――になり、キーをURLに保持します。ブール値はリテラルのtrueまたはfalseになり、数値はロケールのフォーマットや桁区切りなしのプレーンな10進数になります。空文字列も空値になります；クエリ文字列はそれをnullと区別できず、逆デコーダーは意図的に空値をnullとして読み取ります。
どの文字がエンコードされずに残りますか？
正確にはRFC 3986の予約されていないセット：A–Z, a–z, 0–9, ハイフン、ドット、アンダースコア、チルド。それ以外のすべて――スペース、アンパサンド、スラッシュ、アクセント付き文字、絵文字――はUTF-8としてバイト単位でパーセントエンコードされます。キーの角括弧は唯一の可視的な例外で、ネスト規約そのものであるためリテラルに出力されます；値は決してその扱いを受けません。