概要
URL デコードとエンコードをご紹介します。これはその名の通りのシンプルなオンラインツールで、URL エンコードからのデコードも、URL へのエンコードも、素早く簡単に行えます。面倒なくデータを URL エンコードしたり、人間が読みやすい形式にデコードしたりできます。
URLエンコーディング（「パーセントエンコーディング」とも呼ばれる）は、Uniform Resource Identifier（URI）内の情報をエンコードするための仕組みです。URLエンコーディングと呼ばれますが、実際にはUniform Resource Identifier（URI）の主要セット全体、つまりUniform Resource Locator（URL）やUniform Resource Name（URN）でも一般的に使用されます。そのため、HTTPリクエストでHTMLフォームデータを送信する際によく使われる「application/x-www-form-urlencoded」メディアタイプのデータ準備にも使用されます。
高度なオプション
- 文字セット：当ウェブサイトはUTF-8文字セットを使用しているため、入力データもその形式で送信されます。エンコード前に別の文字セットに変換したい場合はこのオプションを変更してください。テキストデータの場合、エンコーディング方式には文字セットが含まれないため、デコード時に適切なセットを指定する必要があります。ファイルの場合はデフォルトでバイナリオプションとなり、変換は行われません。プレーンテキスト以外のすべてのデータにこのオプションが必要です。
- 改行セパレーター： Unix と Windows では改行コードが異なるため、エンコード前に選択したオプションに従ってデータ内の改行コードが統一されます。ファイルセクションでは、ファイル自体にすでに適切なセパレーターが含まれているため、この設定はほとんど関係ありませんが、「各行を個別にエンコード」や「行をチャンクに分割」機能で使用するセパレーターを指定できます。
- 各行を個別にエンコード：改行文字もパーセントエンコードされます。改行で区切られた複数の独立したデータエントリをエンコードする場合に使用します。（*）
- 行を76文字ごとのチャンクに分割：エンコードされたデータは空白なしの連続テキストになります。複数行に分割したい場合はこのオプションを選択してください。文字数制限はMIME（RFC 2045）仕様で定義されており、エンコードされた行は最大76文字までです。（*）
- ライブモード：このオプションを有効にすると、入力されたデータはブラウザ内蔵のJavaScript関数で即座にエンコードされ、サーバーには情報が送信されません。現在、このモードはUTF-8文字セットのみ対応しています。
（*）これらのオプションは同時に有効にできません。結果として得られる出力が多くのアプリケーションで無効になるためです。
安全性とセキュリティ
サーバーとの通信はすべて安全なSSL暗号化接続（https）で行われます。アップロードされたファイルは処理後すぐにサーバーから削除され、生成されたダウンロード可能ファイルは最初のダウンロード試行後、または15分間操作がない場合（短い方）に削除されます。提出されたデータやアップロードされたファイルの内容を保持または検査することはありません。詳細は下記のプライバシーポリシーをご参照ください。
完全に無料
このツールは無料で使用できます。今後、このような簡単な作業のためにソフトウェアをダウンロードする必要はありません。
URLエンコーディングの詳細
URI文字の種類
URIで使用できる文字は、予約文字か非予約文字（またはパーセントエンコーディングの一部としてのパーセント文字）のいずれかです。予約文字は、場合によって特別な意味を持つ文字です。例えば、スラッシュ（/）はURL（またはより一般的にはURI）の異なる部分を区切るために使用されます。非予約文字には特別な意味はありません。パーセントエンコーディングを使用すると、予約文字は特別な文字列で表現されます。予約文字と非予約文字のセットおよび特定の予約文字が特別な意味を持つ状況は、URIおよびURIスキームを規定する仕様の改訂ごとに若干変更されています。
| RFC 3986 セクション 2.2 予約文字（2005年1月） | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
* |
' |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
| RFC 3986 セクション 2.3 非予約文字（2005年1月） | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z |
a |
b |
c |
d |
e |
f |
g |
h |
i |
j |
k |
l |
m |
n |
o |
p |
q |
r |
s |
t |
u |
v |
w |
x |
y |
z |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
- |
_ |
. |
~ |
||||||||||||
URI内のその他の文字はすべてパーセントエンコードする必要があります。
予約文字のパーセントエンコード
予約文字セットの文字（「予約文字」）が特定の文脈で特別な意味（「予約目的」）を持ち、URIスキームでその文字を別の目的で使用する必要がある場合、その文字はパーセントエンコードされなければなりません。予約文字のパーセントエンコードとは、文字を対応するASCIIのバイト値に変換し、その値を16進数2桁で表現することを意味します。数字の前にパーセント記号（「%」）を付けて、URI内で予約文字の代わりに使用します。（非ASCII文字の場合、通常はUTF-8のバイト列に変換され、各バイト値が上記のように表現されます。）
例えば、予約文字「/」がURIの「path」コンポーネントで使用される場合、パスセグメント間の区切りとして特別な意味を持ちます。特定のURIスキームで「/」がパスセグメント内に必要な場合、「/」の代わりに「%2F」（または「%2f」）の3文字を使用する必要があります。
| パーセントエンコード後の予約文字 | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
] |
%21 |
%23 |
%24 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D |
特定の文脈で予約目的を持たない予約文字もパーセントエンコードされることがありますが、他の文字と意味的に異なるわけではありません。
例えば、URIの「query」コンポーネント（「?」の後の部分）では、「/」は依然として予約文字と見なされますが、通常は予約目的を持ちません（特定のURIスキームで別途指定がある場合を除く）。予約目的を持たない場合、その文字をパーセントエンコードする必要はありません。
予約文字がパーセントエンコードされているかどうかだけで異なるURIは、通常、同じリソースを指すものとしては扱われません。ただし、対象の予約文字が予約目的を持たない場合はこの限りではありません。この判断は、各URIスキームによって定められた予約文字のルールに依存します。
非予約文字のパーセントエンコード
非予約文字セットの文字は、パーセントエンコードする必要はありません。
非予約文字がパーセントエンコードされているかどうかだけで異なるURIは、定義上は同等ですが、実際のURIプロセッサでは常に同等として扱われるわけではありません。例えば、URI利用者は「%41」を「A」（「%41」は「A」のパーセントエンコード）と区別したり、「%7E」を「~」と区別したりすべきではありませんが、一部は区別します。最大限の相互運用性を確保するため、URI生成者は非予約文字をパーセントエンコードすることを避けるべきです。
パーセント文字のパーセントエンコード
パーセント文字（「%」）はパーセントエンコードされたオクテットの指示子として使用されるため、そのオクテットをURI内のデータとして使用する場合は「%25」としてパーセントエンコードする必要があります。
任意のデータのパーセントエンコード
ほとんどのURIスキームでは、IPアドレスやファイルシステムパスなどの任意データをURIの構成要素として表現します。URIスキームの仕様は、URI文字とその文字で表される可能性のあるすべてのデータ値との明示的な対応を提供するべきですが、多くの場合そうなっていません。
バイナリデータ
RFC 1738（1994年）の公開以来、URI内でバイナリデータを表現するスキームでは、データを8ビットバイトに分割し、各バイトを前述の方法でパーセントエンコードすることが規定されています。例えば、バイト値0F（16進数）は「%0F」と表現され、バイト値41（16進数）は「A」または「%41」と表現されます。英数字やその他の非予約文字はエンコードせずに使用する方が、URLが短くなるため通常は推奨されます。
文字データ
バイナリデータのパーセントエンコード手順は、時に不適切に、または十分に明示されないまま、文字ベースのデータにも適用されることがありました。WWW初期の頃、ASCII文字のデータを扱い、対応するASCIIバイトを基にパーセントエンコード列を決定する場合、この慣習は比較的無害でした。多くの人が文字とバイトは1対1で対応し、互換性があると考えていました。しかし、ASCII範囲外の文字を表現する必要が急速に増加し、URIスキームやプロトコルは文字データをURIに組み込むための標準ルールを提供できないことが多くなりました。その結果、Webアプリケーションは複数バイト、状態依存、非ASCII互換のエンコーディングをパーセントエンコードの基礎として使用するようになり、あいまいさやURIの解釈の困難さが生じました。
例えば、RFC 1738および2396に基づく多くのURIスキームやプロトコルは、データ文字をURIで非予約文字やパーセントエンコードバイトとして表現する前に、未指定の文字エンコーディングに従ってバイトに変換することを前提としています。スキームが使用したエンコーディングを示す手掛かりをURIに提供できない場合や、エンコーディングが予約文字および非予約文字のパーセントエンコードに使用されるASCIIと競合する場合、URIは正しく解釈できません。一部のスキームはエンコーディングを考慮せず、データ文字を直接URI文字にマップすると提案するだけであり、非予約・予約文字セットに含まれないデータ文字をユーザーがパーセントエンコードするかどうかを判断する必要があります。
| パーセントエンコード後の一般的な文字（ASCIIまたはUTF-8ベース） | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 改行 | スペース | " |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
| |
} |
~ |
%0A または %0D または %0D%0A |
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
任意の文字データは、パーセントエンコードされ、非URI用途（パスワードの難読化プログラムや、その他システム固有の変換プロトコルなど）で使用されることもあります。
