URLをブラウザ内で変換する
日本語・Space・記号をURLで扱える形式へEncodeし、%E6%97%A5のような文字列をDecodeできます。URL全体・URL構成要素・フォーム形式を選んで確認できます。
URL Encoder / Decoderを開く結論：UTF-8でEncodeし、元の日本語とRound Trip比較する
日本語TextをURL構成要素としてEncodeし、生成結果を1回Decodeして同じTextへ戻るか確認します。%25E6のように%25が残る場合は二重Encodeの可能性があります。
元DataがShift_JISなどUTF-8以外なら、decodeURIComponentだけでは正しい日本語へ戻らない場合があります。元Byteと送信側のEncodingを確認します。
元の文字列を残し、URL全体・Path・Query Value・Fragmentのどこを変換するか決めてから実行してください。
日本語の文字化けを段階別に確認する
JavaScriptのencodeURIComponentはUnicode StringをUTF-8表現に対応するEscape Sequenceへします。Decode側もUTF-8として有効なSequenceである必要があります。
現ツールはUTF-8を前提にします。任意のLegacy Encodingを選ぶ機能はなく、欠損したByte列や誤変換済みTextを自動修復しません。
| 確認対象 | 見る内容 | 対応 |
|---|---|---|
| 元Text | 日本語・Emoji | UTF-8を確認 |
| 入力 | %E6か%25E6か | Decode回数を判断 |
| 範囲 | URL全体／Value | 形式を選択 |
| 結果 | Round Trip一致 | Code Pointも確認 |
URL Encoder / Decoderで確認する手順
- URL構成要素・Encodeを選びます。
- 東京都杉並区やEmojiを入力します。
- 結果を入れ替えてDecodeします。
- 元Textと一文字ずつ一致することを確認します。
文字数とUTF-8 Byte数が異なることも画面の統計で確認できます。
変換できない・結果が違う場合の切り分け
ãのようなMojibakeはUTF-8 Byteを別Encodingとして読んだ可能性があります。%が残るだけならDecode不足や二重Encodeを確認します。
途中でURL全体をdecodeURIComponentした、ProxyとApplicationで重複Decodeした、入力が途中で切れた場合も結果が変わります。
- 元EncodingがUTF-8か
- %25を一度だけDecodeしたか
- 不完全なUTF-8 Sequenceがないか
- Server側で追加Decodeしていないか
現行のURL Encoder / Decoderで確認できる範囲
DevelopToolsは入力文字列をブラウザ内で処理します。URL構成要素はencodeURIComponent・decodeURIComponent相当、URL全体はencodeURI・decodeURI相当、フォーム形式はapplication/x-www-form-urlencodedのSpaceと+の規則で変換します。RFC 3986準拠Option、1回または最大5回のDecode、多重Encode検出、不正な%XXの位置表示、URL構造・Query Parameter解析、Copy、入れ替え、全消去、文字数・UTF-8 Byte数・変換箇所・Size変化の表示に対応しています。
| 機能 | 現行ツールの動作 |
|---|---|
| URL構成要素 | Query Valueや検索語を変換し、&・=・?などもDataとしてPercent Encode |
| URL全体 | Scheme・Host・Path・Query・Fragmentの区切りを維持して日本語やSpaceを変換 |
| フォーム形式 | Encode時はSpaceを+にし、Decode時は+をSpaceとして扱う |
| Error処理 | 不完全な%XX、無効なUTF-8 Sequence、孤立Surrogateを画面内Messageで案内 |
| 解析 | URL APIでProtocol、Host、Path、Query、Fragment、重複・空値を含むParameterを表示 |
URL Encodingを暗号化やSecret保護と混同しない
URL Encodingは暗号化ではありません。%XXはByteをURLで扱える形へ表す可逆的なEncodingで、Decodeすれば元へ戻せます。Token、Email、User ID、Internal Host、JWT、Session IdentifierをEncodeしても秘密にはなりません。
URLはBrowser History、Server Log、Referer、Analytics、画面共有へ残る可能性があります。SecretをQueryへ入れる設計そのものを見直し、実例にはSAMPLE_TOKENやexample.comなどのDummy値だけを使います。現行ツールは入力・結果を変換API、History、LocalStorageへ保存しません。
URLを共有する前に、User Information、Token、Password、顧客名、内部Hostを含んでいないか確認してください。
仕様とWeb APIは一次資料で確認する
一般的なURI SyntaxとReserved Character、Percent-EncodingはRFC 3986、現在のBrowser URL処理とapplication/x-www-form-urlencodedはWHATWG URL Standard、JavaScript APIの挙動はECMAScriptとMDNを基準にします。
具体例：東京都杉並区をUTF-8で往復変換する
日本語7文字が複数の%XXへ展開されることを確認します。
Encode結果を1回Decodeすると元の住所へ戻り、文字数・Byte数の差も確認できます。
- 元Textを控える
- URL構成要素でEncodeする
- 結果を1回Decodeする
- 元Textと比較する
住所・氏名など実データではなく架空のSampleを使ってください。
よくある質問
- URLエンコードすれば機密情報を安全に送れますか？
- いいえ。Percent-Encodingは暗号化ではなく元へ戻せます。TokenやPasswordをURLへ入れるとHistoryやLog等へ残る可能性があります。
- 入力したURLはサーバーへ送信されますか？
- URLの変換と解析は利用中のブラウザ内で行われます。入力内容や結果を変換API、History、LocalStorageへ保存する処理はありません。