ホームページ > 記事 > ウェブフロントエンド > URL 検証または: 心配するのをやめてユーザーを愛する方法を学んだ方法
すべての Web 開発者には、何らかの入力検証を行う必要がある時期が来ます。フォームは、ユーザーが電子メール フィールドで Yahoo Mail への愛を詩的に語ることができるブログ投稿ではありません。最終的には、単語数の制限、特定の文字のチェック、およびユーザーがジャンク POST リクエストを送信しないようにする簡単な検証技術が必要になります。
しかし、URL を検証する必要がある場合はどうすればよいでしょうか?さらに、問題にもう 1 つのレイヤーを追加します。URL のホスト名のみが必要で、パスやプロトコルは必要なく、「dubya dubya dubya dot」 (www.) と .com.
だけが必要な場合はどうなるでしょうか。URL が URL であるかどうかを知ることから始めましょう。リンクには、セカンド レベル ドメインとトップ レベル ドメイン、それぞれ walmart.com の walmart と .com、およびスキーム (https://) が必要です。これらの部分がなければ、リンクは何にもリンクせず、テキスト行と何ら変わりません。
しかし、URL の部分がわかったので、フォークインまたは開発パスに到達します。検証では、フィールドでのユーザーを制限する必要がありますか、それともデータがサーバーに送信されるときにユーザー入力をサニタイズする必要がありますか?
どちらのオプションにも長所と短所があります:
送信前の検証
ユーザーが無効な URL を送信できないように制限すると、必要な正確な入力構造をユーザーに送信させることで、追加の作業を行わずにサーバー側でデータを簡単に取得できるようになります。この場合、input 要素の pattern 属性と正規表現を組み合わせることで、古き良きフィールド検証が可能になります。
このアプローチの例を次に示します:
<input type="text" pattern="https?://.*"
ただし、ユーザーが制限されるという欠点もあります。ユーザーは入力に特定の部分を含める必要があり、.com だけが必要な場合は、長い正規表現パターンは過剰になる可能性があります。
送信後の検証
一方、ユーザーがデータを送信した後にデータをサニタイズすることを選択した場合、ユーザーは何でも入力でき、データをどう扱うかはサーバーに決定されます。 Javascript の URL コンストラクターは検証を行い、入力が無効な場合は TypeError を返します。また、オリジンやホスト名などの URL の特定の部分を抽出することもできます。
このアプローチの例を次に示します:
export const formatWebsiteAfterDomain = (website: string): string => { if (!website.trim().length) { return ''; } const regEx = /:\/\//; const websiteTrimmed = website.trim(); const hasProtocol = regEx.exec(websiteTrimmed); const updatedWebsite = hasProtocol ? websiteTrimmed : `https://${websiteTrimmed}`; try { const url = new URL(updatedWebsite); return hasProtocol ? url.origin : url.origin.replace('https://', ''); } catch (_err) { return websiteTrimmed; } };
ただし、ユーザーに非常に自由な入力を与えるため、サーバーがデータを処理する際にはある程度の妥協が必要になります。ユーザーが無効な URL を入力した場合、それをどうしますか? TypeError 応答を使用してユーザーに通知しますか、それともユーザーが送信した内容をサーバーが消費できるようにするだけですか?さらに、URL コンストラクターはスキーム (https:// または http://) が存在するかどうかをチェックすることによって入力を検証しますが、これは使用するには検証が不十分すぎる可能性があります。
最終的に、取られる道は問題の特定のエッジケースによって異なります。両方のソリューションを組み合わせたものが最も包括的で多用途である場合もあれば、どちらかの選択肢だけで十分な場合もあります。ユーザーは任意の入力を行うことができ、ユーザーにどの程度の自由を与えるかによってソリューションが決まります。 ただし、依然として普遍的なのは、ユーザーが何でも入力できるということは、常にユーザーと開発者に何らかの妥協を強いることになります (多くの場合、開発者は特定の入力パターンを取得し、ユーザーはアプリケーションを使用できるようになります)。
しかし、ユーザー入力の特殊性は永遠であるため、ユーザーがフォームの URL フィールドに画像を貼り付けようとしたときに Web アプリが壊れないようにするためのソリューションを必死に押し出す開発者が常に存在します。
以上がURL 検証または: 心配するのをやめてユーザーを愛する方法を学んだ方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。