フレンドリーURLの安全な文字[終了]


168

記事を掲載するウェブサイトを作成する必要がありますが、わかりやすいURLを作成したいと思います。たとえば、

タイトル:記事テスト

になるはずですhttp://www.example.com/articles/article_test

もちろん、?やなどのタイトルから一部の文字を削除する必要#がありますが、どの文字を削除するかわかりません。

安全に保管できるキャラクターを教えてもらえますか?


同様の質問がここにありました。ぜひチェックしてみてください。役に立つ答えもいくつか見つかるはずです(かなりたくさんありました)。
ルーク

回答:


210

RFC 3986のセクション2.3を引用するには:

「URIで許可されているが予約された目的がない文字は、予約されていません。大文字と小文字、10進数、ハイフン、ピリオド、アンダースコア、およびチルダが含まれます。」

ALPHA  DIGIT  "-" / "." / "_" / "~"

RFC 3986に記載されている句読点は、以前のRFC 2396よりも少ないことに注意してください。


@スキップヘッド、「文字」にはçやなどのラテン語でエンコードされた文字が含まれõますか?
Mohamad

6
@Mohamad:いいえ、ASCIIのみですが、UTF-8サポートは改善されています。
ディートリッヒエップ2011年

@Dietrich Epp、ありがとう。次のように、URLが装飾とSEOの目的であるかどうかは問題ではないと思います:www.mysite.com/[postId]/post
Mohamad

1
@Mohamad:フードの最後の部分はに変更されpost-title-with-%C3%A7-and-%C3%B5ますが、ユーザーのロケーションバーにはとして表示されpost-title-with-ç-and-õます。
ディートリッヒエップ2011年

7
読者はポルトガル語なので、ポルトガル語の文字を使用してください。
ディートリッヒエップ2011年

107

注意が必要な文字セットは2つあります:reservedunsafeです。

予約文字は次のとおりです。

  • アンパサンド( "&")
  • ドル( "$")
  • プラス記号( "+")
  • コンマ ("、")
  • スラッシュ( "/")
  • コロン( ":")
  • セミコロン( ";")
  • 等しい( "=")
  • 疑問符( "?")
  • 「アット」マーク( "@")
  • ポンド( "#")。

安全でないと一般的に見なされている文字は次のとおりです。

  • スペース (" ")
  • より小さいおよびより大きい( "<>")
  • 開き括弧と閉じ括弧( "[]")
  • 中括弧( "{}")を開閉します
  • パイプ( "|")
  • バックスラッシュ( "\")
  • キャレット( "^")
  • パーセント( "%")

私は1つ以上を忘れた可能性があります。長い目で見れば、サーバーとシステムで許可されていない文字に遅れを取らないようにするよりも、許可された文字の「ホワイトリスト」を使用して文字列をエンコードする方が良いでしょう。


#特定のページのブックマークに使用される予約文字であり、一致する名前属性またはID属性(sans #-symbol)を持つ1つのHTML要素を持つことによって作成されます。
TheLonelyGhost 2014

ありがとう-答えを更新しました。
Gary.Ray 2014

疑問符が予約済みと安全でないの両方としてここに表示されます-予約済みだと思いますが、私は間違っている可能性があります
ジョナサンバジル

6
他の人は、チルド~が安全でないことに異議を唱えているようです。よろしいですか?
Drs

3
英語以外の言語を扱う場合、ホワイトリストはあまり良くありません。UnicodeのOKコードポイントが多すぎます。したがって、安全でないものをブラックリストに登録することは、正規表現で実装するのが最も簡単です。
Patanjali 2015年

41

特定の文字(ブラックリスト)を削除するのではなく、一部の文字(ホワイトリスト)のみを保持するのが最善です。

技術的には、適切にエンコードする限り、任意の文字を許可できます。ただし、質問の精神で答えるには、次の文字のみを許可する必要があります。

  1. 小文字(大文字を小文字に変換)
  2. 0〜9の数字
  3. ダッシュ-またはアンダースコア_
  4. チルド〜

他のすべてのものは潜在的に特別な意味を持っています。たとえば、+を使用できると思うかもしれませんが、スペースで置き換えることができます。&も、特にいくつかの書き換えルールを使用している場合は危険です。

他のコメントと同様に、詳細については規格と仕様を確認してください。


15
今日発見したピリオドは、URLセーフなBase64エンコーダーに使用する文字の選択としては不適切です。これは、エンコードされたデータが2つの連続したドット( "..")を生成するというまれなケースがあるためです。親ディレクトリを参照すること。
ポール、2011年

5
@pohl:コードでURLがファイルパスとして使用されている場合、またはWebサーバーがリクエストをスクリプトに転送する前に実際にURLをファイルにマップしようとした場合にのみ問題になります(残念ながら非常に一般的です)。
アンドレ・キャノン

4
実際には、私たちの場合、ファイルパスとして使用しても問題ありません。Unixでは、ファイル名に複数の、さらには連続したドットを含めることができるためです。私たちにとっては、バグ(おそらく単純な正規表現)を持つSite Scopeと呼ばれる監視ツールで問題が発生し、偽の誤ったダウンタイムが報告されていました。私たちにとっては、古いバージョンのサイトスコープに行き詰まっており、管理チームはアップグレードの支払いを拒否し、1つの非常に重要なクライアントがサイトスコープ(同等ではない)を契約に書いています。確かに、ほとんどの人は私の立場に立たされません。
pohl、

8
誰かが余計なことをせずにリストを投稿したことを神に感謝します。ドット(。)について-@pohlが言ったように、使用しないでください!IISの別の奇妙なケースを次に示します(これが他のWebサーバーで発生するかどうかはわかりません)。URLの末尾にある場合は、404エラーが発生する可能性があります([/ pagename]を検索しようとします) 。ページ)
nikib3ro

34

常に安全

これらは安全であり(理論上/仕様上)、基本的にドメイン名を除いてどこでもです。
リストされていないものをパーセントエンコードすれば、準備は完了です。

    A-Z a-z 0-9 - . _ ~ ( ) ' ! * : @ , ;

時には安全

特定のURLコンポーネント内で使用する場合にのみ安全です。注意して使用してください。

    Paths:     + & =
    Queries:   ? /
    Fragments: ? / # + & =
    

安全ではない

URI仕様(RFC 3986)によると、他のすべての文字はパーセントエンコードする必要があります。これも:

    <space> <control-characters> <extended-ascii> <unicode>
    % < > [ ] { } | \ ^
    

最大の互換性が問題になる場合は、文字セットをAZ az 0-9-_に制限してください。
(ファイル名拡張子のピリオドのみ)。

コンテキストを維持する

仕様ごとに有効であっても、URLはコンテキストによっては「安全でない」場合があります。無効なファイル名文字を含むfile:/// URL、または区切り文字として使用されていない場合の「?」、「=」、および「&」を含むクエリコンポーネントなど。これらのケースの正しい処理は、通常はスクリプト次第であり、回避できますが、これは覚えておくべきことです。


2番目のクレーム(「ときどき安全」)の情報源を教えてください。特に、=クエリに対して安全ではないと言うのは間違っていると思います。たとえば、FIQLは等号を受け入れ、「URIフレンドリー」であり、「クエリコンポーネントでの使用を目的として最適化されている」と説明します。私の解釈では、RFC 3986では "="、 "&"、 "+"などをクエリで明示的に許可しています。
DanielM

@DanielM "?"、 "="、 "&"は仕様ごとのクエリで有効ですが、実際にはクエリ内の名前と値のペアの解析に広く使用されています。そのため、名前/値自体の一部として安全ではない可能性があります。これが「安全でない」かどうかは、意見の問題かもしれません。
Beejor

要求に応じていくつかの情報源。(1)RFC 3986、Sec 3.4:「[...]クエリコンポーネントは、 'key = value'ペア[...]の形式で識別情報を運ぶためによく使用されます(2)WhatWG URL仕様、Sec。6.2: "URLSearchParamsオブジェクトの構築と文字列化はかなり簡単です:[...] params.toString() // "key=730d67""(3)PHP Manual、http-build-query: "Generate URL-encoded query string。[...]上記の例は出力します:0=foo&1=bar[...]"(4)J.スター、生鮮プレス:" Webページを作成するとき、パラメーター化されたクエリ文字列を必要とするリンクを追加する必要があることがよくあります。 "
Beejor

@Beejor:私はURLを作成しています&「-」と「;」を使用しています 建設中。Webアプリではなく、モバイルアプリです。Web開発者ではないため、上記の2つの文字をPathプロパティで使用しても安全ですか?docs.microsoft.com/en-us/dotnet/api/...
karsnen

1
@karsnenこれらは有効なURL文字です。ローカルファイルシステムのパスを参照するために使用される場合でも、一部のシステムではファイル名に特定の文字を使用できないことに注意してください。たとえば、「file:/// path / to / my:file.ext」はMacでは無効です。
Beejor

17

見てみるとRFC3986 -統一資源識別子(URI):一般的な構文、周りのあなたの質問の公転パス URIのコンポーネント。

    foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

セクション3.3を引用すると、URIの有効な文字segmentのタイプはpchar次のとおりです。

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

内訳は次のとおりです。

ALPHA / DIGIT / "-" / "." / "_" / "~"

pct-encoded

"!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

":" / "@"

言い換えれば:あなたはから任意の(非制御- )文字を使用することができASCIIテーブル除く外 /?#[]

この理解は、RFC1738-Uniform Resource Locators(URL)によって裏付けられています


2
これは理論的に正しい答えの良い例であり、私たちが実際に住んでいる現実の世界に適用すると問題が発生します。ほとんどの場合、これらのキャラクターのほとんどは問題を引き起こしません。しかし、現実の世界には、プロキシ、ルーター、ゲートウェイ、リレーなどのものが存在します。これらはすべて、理論的な標準を無視した方法でURLを検査および対話することが「好き」です。これらの落とし穴を回避するために、英数字、ダッシュ、アンダースコア、およびピリオドを除くすべてをエスケープすることにかなり制限されています。
deltamind106

1
@ deltamind106例やリファレンスを提供して、RFCに従って安全ではない文字を実際に明らかにすることはできますか?私の回答では、標準に裏打ちされた事実に固執することを好みます。私が無視したかもしれない事実を特定できる場合は、私の回答を更新させていただきます。
Philzen

2
@ deltamind106開発者に指示しないで、製品が標準に準拠するようにすることをお勧めします。私はあなたの警告は価値があると考えていますが、必要に応じてベンダーに非準拠を報告するという私たちの役割を果たすべきです。
Lo-Tan

@Philzen:私はURLを作成しています&「-」と「;」を使用しています 建設中。Webアプリではなく、モバイルアプリです。Web開発者ではないため、上記の2つの文字をPathプロパティで使用しても安全ですか?docs.microsoft.com/en-us/dotnet/api/...
karsnen

1
もちろんはい@karsnen -;安全である、それは私の答えとRFCが明記ものです。
フィルゼン

12

予約なし= ALPHA / DIGIT / "-" / "。" / "_" / "〜"


3
「ALPHA」は「DIGIT」を意味しないのですか?ALPHAは「英数字」の略で、英数字は大文字、小文字、数字を意味すると思います。
Luc

11
実際、アルファは英数字を意味するものではありません。英数字は2つの異なるものであり、英数字はそれらの組み合わせです。彼はそのように彼の答えを書くことができた:ALPHANUMERIC / "-" / "。" / "_" / "〜"
MacroMan

1
RFC 3986の「予約なし」のABNF表記は、それらを個別にリストしています。
パタンジャリ2015年

11

あなたが説明する文脈から、あなたが実際に作ろうとしているのは「SEOスラッグ」と呼ばれるものだと思います。それらのための最も一般的な既知の慣行は:

  1. 小文字に変換
  2. azおよび0-9以外の文字のシーケンス全体を1つのハイフン(-)に変換します(アンダースコアではありません)
  3. URLから「ストップワード」を削除します。広範なリストのGoogleの「ストップワード」

したがって、例として、「!@%$ *を使用してコミックスの誓いを表現する」というタイトルの記事は、「usage-represent-swearing-comics」のスラッグになります。


これらの「ストップワード」をURLから削除するのは本当に良い方法ですか?このため、検索エンジンはWebサイトにペナルティを課しますか?
パウロ

通常、検索エンジンは、URLの一部のみを認識し、後の部分の重要性を低減すると考えられているため、ストップワードを削除することで、URLに埋め込むキーワードの数を最大化できます。実際のランキングの。
混乱

1
@chaosこれを考慮に入れる場合は、StopWordを削除することをお勧めしますか:seobythesea.com/2008/08/google-stopword-patentまた、ストップワードの優れたリストを推奨できますか?これは私がこれまでに見つけた最高のリストです-link-assistant.com/seo-stop-words.html
nikib3ro

@ kape123それは私には非常に良いリストのようには見えません。「c」と「d」はプログラミング言語であり、他の多くの単語も重要に見えます。私はおそらく基本的なものを取り除くだけでしょう:a、and、is、on、of、または、with、with。
mpen 2016


6

SEOの観点からは、ハイフンはアンダースコアよりも優先されます。小文字に変換し、すべてのアポストロフィを削除してから、英数字以外のすべての文字列を1つのハイフンに置き換えます。最初と最後の余分なハイフンを削除します。


3

同様の問題がありました。かなりのURLが必要で、URLには文字、数字、および_のみを許可する必要があるという結論に達しました。それで結構です、それから私はいくつかの素晴らしい正規表現を書いて、それがすべてのUTF8文字が.NETの文字ではなく、ねじ込まれていることを認識していることに気付きました。これは、.NET正規表現エンジンの既知の問題のようです。だから私はこの解決策を得ました:

private static string GetTitleForUrlDisplay(string title)
{
    if (!string.IsNullOrEmpty(title))
    {
        return Regex.Replace(Regex.Replace(title, @"[^A-Za-z0-9_-]", new MatchEvaluator(CharacterTester)).Replace(' ', '-').TrimStart('-').TrimEnd('-'), "[-]+", "-").ToLower();
    }
    return string.Empty;
}


/// <summary>
/// All characters that do not match the patter, will get to this method, i.e. useful for unicode chars, because
/// .NET impl of regext do not handle unicode chars. So we use char.IsLetterOrDigit() which works nicely and we 
/// return what we approve and return - for everything else.
/// </summary>
/// <param name="m"></param>
/// <returns></returns>
private static string CharacterTester(Match m)
{
    string x = m.ToString();
    if (x.Length > 0 && char.IsLetterOrDigit(x[0]))
    {
        return x.ToLower();
    }
    else
    {
        return "-";
    }
}

3
.NET正規表現は、実際には非常によくユニコードをサポートしています。すべての文字に対して、\ p {L}などのUnicode文字クラスを使用する必要があります。msdn.microsoft.com/en-us/library/20bw873z.aspx#CategoryOrBlockを
TheCycoONE 2013年

1

ajax / phpを介して値をURLに返し、そのURLを再度ページで読み取ったときに、URLを安全なURLにエンコードすると非常に便利です。

特殊文字&のURLエンコーダーを備えたPHP出力

//PHP returning the sucess info of ajax request
echo "".str_replace('&','%26',$_POST['name'])." category was changed";

//javascript sending the value to url
window.location.href='time.php?return=updated&val='+msg;

//javascript/php executing the function printing the value of the url,
//now with the text normally lost in space because of the reserved & character.

setTimeout("infoApp('updated','<?php echo $_GET['val'];?>');",360);

私の小さなコードの抽出が誰かに役立つことを誰かが願っています!:)


0

あなたは「URLエンコーディング」のようなものを探していると思います-Webで使用するために「安全」になるようにURLをエンコードします。

以下がそのリファレンスです。特殊文字が不要な場合は、URLエンコードが必要な文字を削除してください。

http://www.w3schools.com/TAGS/ref_urlencode.asp


-4

3〜50文字。小文字、数字、特殊文字を含めることができます-ドット(。)、ダッシュ(-)、アンダースコア(_)、および速度(@)。


4
そのための参照はありますか?
ダカブ2016
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.