仕様と根拠

変換の手順

RFC 3986 の 5.2.2 の手順で、参照にスキームがあればそのまま絶対のアドレスとして扱い、ホストがあれば基準のスキームだけを使い、パスが空なら基準のパスを使い、/ で始まるパスはそのまま、それ以外は基準の最後の / までに結合します(5.2.3)。クエリとフラグメントは参照のものを使い、パスが空でクエリもなければ基準のクエリを引き継ぎます。

ドットセグメントの除去

./ と ../ は 5.2.4 の手順で取り除きます。階層を上がる ../ が根(/)より上に出る場合は、5.4.2 の例のとおり根で止まります。g. や ..g のように、ドットが名前の一部になっているものは取り除きません。

情報・警告・エラー

参照にスキームがあって基準を使わないもの、根より上へ上がろうとした ../ があるものは情報として示します。空白を含む行、スキームとして正しくない文字を含む行、基準が絶対のアドレスでない場合はエラーで、変換しません。

根拠にした仕様・資料

指摘の段階

• エラー: 仕様に反していて、正しく読めない・処理できない入力です。
• 警告: 読めるものの、仕様の推奨に反する・矛盾する・意図と違う結果になりやすい入力です。
• 情報: 誤りではありませんが、知っておくとよい扱い(読み飛ばした部分や解釈)です。

入力の扱い(送信しない仕組み)

処理はすべてお使いのブラウザの中で行います。処理の本体はこのサイトから配信する小さなスクリプト(/app.js)で、外部のサービスやライブラリを読み込みません。ページはブラウザに通信を禁止させる設定(Content-Security-Policy の connect-src)つきで配信しており、入力した内容がサーバーや第三者へ送られることはありません。ファイルを選んだ場合も、端末の中で読み込むだけです。

このツールでできないこと(制約)

• RFC 3986 5.2 の厳格な手順による変換です。ブラウザの URL の解析(WHATWG URL)とは、バックスラッシュの扱いや http:g のような書き方などで結果が異なる場合があります。
• HTML の base 要素や複数の基準のアドレスは扱いません。基準は 1 つだけ入力します。
• 変換したアドレスが実際に存在するかは確認しません。アドレスへの接続は行いません。
• %エンコードや大文字小文字の整理(正規化)はしません。入力の書き方をそのまま残して結合します。