壊れたURLをここに貼り付けて、「URLを修復！」をクリックしてください壊れたURLを入力

URL修復ツールとは？

メール、Word文書、Slackメッセージ、Confluenceページからリンクをコピーしたら、周りに丸い引用符（"ではなく"）が付いていたり、ハイフンの代わりにエンダッシュ（–）が入っていたり、先頭のhttps://がなかったり、誰かがEnterを押した拍子に紛れ込んだ改行でURLが二つに割れていたりします。ここに貼り付ければ、動くURLが返ってきます。URL修復ツールはコピー＆ペーストが残す構文上の傷を、WHATWG URL標準とRFC 3986のルールに従って整えます。

この修復ツールは、正規表現だと延々と特殊ケースとして扱わなければならない種類の問題を処理します。スマートクォート、スマートダッシュ、パス内に紛れ込んだ二重スラッシュ、混在または二重のパーセントエンコーディング（明らかに二重エンコードのときは%2520を%20に戻します）、エンコードされていないスペース、誰かが間違ったタイミングでEnterを押したせいでURL内に紛れ込んだCR/LF/タブ文字などです。ホスト名を勝手にでっち上げたり、クエリパラメータを変えたり、なかったパスセグメントを足したりはしません。出力はブラウザのURL APIのルールで検証されるので、向こう側でちゃんとパースされることが分かります。国際化ホスト名（Unicode、IDN）はRFC 3987に従って保持されます。

あなたのURLは修復処理を実行するためにバックエンドに送られ、すぐに戻ってきます。入力はログに残しません。URLにはセッショントークンや顧客IDなど、ログファイルに残したくないものが含まれていることが多いからです。URLに本当の秘密情報（署名付きS3リンク、ワンタイム認証トークンなど）が含まれている場合は、ここを含めどこかに貼り付けた後でローテーションしてください。

URL修復ツールの使い方

3ステップ。それぞれがこのページのボタンに対応していて、隠れた手順はありません。

壊れたURLを貼り付けるか、サンプルを読み込む

左側のエディタに壊れたURLを入れます。サンプルURLをクリックすると、丸い引用符、エンダッシュ、スキーム欠落、エンコードされていないスペースなど、わざと壊した例が読み込まれます。実際にメールから貼り付けると出てくるような壊れ方です。壊れたURLの例：

"shop.example.com/orders/ORD–1001?customer=Ava Chen"

Wordから来た丸い引用符がURLを囲み、パスセグメント内にエンダッシュ、スキームなし、クエリ値内にそのままのスペース。短い1行に4つの問題が同居しています。

「URLを修復！」をクリック

緑色のURLを修復！ボタンを押します。修復ツールは囲っている引用符を取り除き、エンダッシュをハイフンに置き換え、先頭にhttps://を付け、スペースをパーセントエンコードしてRFC 3986に準拠させます。

修復したURLをコピー

右側のパネルに整ったURLが表示されます。確認してコピーし、ブラウザ、fetch()呼び出し、READMEや失敗していたテストに貼り付けてください。URLを各構成要素に分解して見たい場合は、続けてURLパーサーに通してみてください。

実際にこれを使う場面

メールやWordから貼り付けたリンク

OutlookやWordはストレートな引用符を勝手に丸い引用符に、ハイフンをエンダッシュに変えます。メッセージ上では問題なさそうに見えるURLが、ターミナルに貼り付けた瞬間に壊れます。修復ツールはその「賢い」自動補正を巻き戻して、リンクをまた使える状態に戻します。

ロガーが引用符でくるんだURL

JSON形式のアプリケーションログは、URLを"https://api.example.com/v1/orders?id=ORD-1001"のように出力したがります。さっとcurlしようとつかむと、囲みの引用符まで一緒に付いてきます。修復ツールがそれを外してくれるので、シェルが「閉じていない引用符」と文句を言う理由を考えなくて済みます。

SlackやJiraがURLの途中に放り込む改行

Slack、Jira、Confluenceの長いURLは折り返されて、コピーすると\nが紛れ込みがちです。パスは正しそうに見えるのにfetch()がパースエラーで弾く——そんな状況です。修復ツールが改行をならしてくれるので、URLは再び一続きの文字列に戻ります。

二重エンコードされたクエリ文字列

URLが二つのシステムを経由してそれぞれパーセントエンコードされると、%20が入るべき場所に%2520が入ってしまいます。修復ツールは明らかな二重エンコードを1層に戻すので、リダイレクトチェーンやWebhookペイロードのデバッグ時に役立ちます。

よくある質問

URLは保存されたり、私から見えないどこかに送られたりしますか？

URLは修復処理を実行するためにバックエンドに送られ、すぐに戻ってきます。入力そのものはログに残しません——URLにはセッショントークンやパス・クエリ内のPIIが含まれることが多いからです。修復が起きたことは記録しますが、何が修復されたかは記録しません。URLに本物の秘密情報（署名付きリンク、認証トークンなど）が含まれている場合は、ここを含むサードパーティのツールに貼り付けた時点で漏えい扱いにし、ローテーションしてください。

実際にどんな種類のURLエラーを直せますか？

日常的なものは一通り。スキーム欠落（既定でhttps://）、URLを囲む丸い／スマートな引用符、ハイフンが入るべき位置のエンダッシュやエムダッシュ、パス内の不要な//、二重パーセントエンコード（明らかな場合%2520 → %20）、クエリ値中のエンコードされていないスペース、ワープロソフトがURL内に落とすタブ／CR／LF文字、Markdownリンク由来の<https://example.com>のような囲み山かっこ、などです。

パスやクエリ、フラグメントの値を変えてしまいませんか？

いいえ。修復ツールは意図的に保守的です。ホスト名を勝手にでっち上げない、欠けたTLDを推測しない、パスセグメントを増減しない、クエリパラメータを増減しない、パラメータの順序を変えない、フラグメントを落とさない——構文的に間違っている文字だけに触れます。customer=Ava Chenが入ればcustomer=Ava%20Chenとして出ていきます。値は同じで、RFC 3986に従って正しくエンコードされているだけです。

国際化ドメイン名（Unicode）に対応していますか？

はい。ホストやパスのUnicode文字は国際化リソース識別子（IRI形式）として保持されます。アプリ側でホストにpunycode（ASCII）形式が必要な場合は、整えたURLを各言語のURLライブラリに通してください。Nodeのurlモジュール、Pythonのidnaパッケージ、ブラウザ組み込みのURLコンストラクタなどが両方の形式を返してくれます。

本当に長いURLはどうなりますか？

入力には64KBの上限があります（およそ64,000文字）。現実のURLはほぼ常に2,000文字未満です。それより大きい場合、たいていは何かが二重エンコードされて巨大な塊になっているか、本来POSTボディに入れるべきバイナリペイロードがクエリ文字列に乗っているかです。修復ツールは入力が大きすぎる旨を伝えます。先に削るか組み直してください。

修復されたURLではなくエラーが返ってきました。どうすればいい？

入力によっては手の施しようがない場合があります。たとえばホストがすっかり欠けているURLや、構造が崩れすぎてモデルが何を意図していたか判別できないURLなどです。その場合はURLを目視し、明らかな部分（ホストとスキームが定番容疑者です）を手で直して再実行してください。結果をURLバリデータに流して、URLパーサーが具体的に何に文句を言っているかを確認してもよいでしょう。

他にも役立つかもしれないURLツール

URLを修復するのはひとつの工程です。きれいにパースできるようになったら、これらのツールが残りの仕事を引き受けます：