問題タブ [friendly-url]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
regex - Stack Overflow はどのようにして SEO に適した URL を生成しますか?
タイトルを取得する適切な完全な正規表現またはその他のプロセスは次のとおりです。
Stack Overflow のようにタイトルを URL の一部に変更するにはどうすればよいですか?
そしてそれを
Stack Overflow の SEO に適した URL で使用されている
私が使用している開発環境はRuby on Railsですが、他にプラットフォーム固有のソリューション (.NET、PHP、Djangoなど) があれば、それも見てみたいです。
私 (または別の読者) は、別のプラットフォームで同じ問題に直面することになると確信しています。
私はカスタムルートを使用しています。主に、すべての特殊文字が削除され、すべて小文字になり、すべての空白が置き換えられるように文字列を変更する方法を知りたいです。
c# - C# でフレンドリー URL を生成するにはどうすればよいですか?
C# でフレンドリー URL を生成するにはどうすればよいですか? 現在、スペースをアンダースコアに置き換えるだけですが、Stack Overflow のような URL を生成するにはどうすればよいですか?
たとえば、どのように変換できますか:
C# でフレンドリー URL を生成するにはどうすればよいですか?
の中へ
How-do-i-generate-a-friendly-url-in-C
asp.net - ASP.NET のフレンドリ URL
Python フレームワークは常に、リクエストのデータを洗練された方法で伝える URL を処理する方法を提供します。たとえばhttp://somewhere.overtherainbow.com/userid/123424/のように
終了パス/userid/123424/に注目してほしい
ASP.NET でこれを行うにはどうすればよいでしょうか。
url - URL の末尾に「スラッグ」を追加する Web サイトがあるのはなぜですか?
このサイトを含む多くの Web サイトでは、どうやらスラッグと呼ばれるもの(説明的ですが、私が知る限り役に立たないテキスト) を URL の末尾に追加しています。
たとえば、この質問に対してサイトが提供する URL は次のとおりです。
https://stackoverflow.com/questions/47427/why-do-some-websites-add-slugs-to-the-end-of-urls
ただし、次の URL も同様に機能します。
https://stackoverflow.com/questions/47427/
このテキストのポイントは、何らかの方法で URL をよりユーザー フレンドリーにすることだけですか、それとも他に何か利点がありますか?
.net - ASP.NETUrlの書き換えとページリンクの構築
そのため、この投稿では、ASP.NETアプリケーションで実際にURL書き換えを実装して、「わかりやすいURL」を取得する方法について説明しました。これは完璧に機能し、ユーザーを特定のページに送るのに最適ですが、参照されているツールの1つを使用して、コード内に「フレンドリー」なURLを作成するための優れたソリューションを知っている人はいますか?
たとえば、書き換えルールが存在する場合にasp.netコントロール内のリンクを〜/ mypage.aspx?product = 12としてリストすると、2つの異なる方法でコンテンツにリンクするため問題になります。
私はDotNetNukeとFriendlyUrlの使用に精通しており、リライターからフレンドリUrlコードを取得する「NavigateUrl」メソッドがありますが、UrlRewriting.netまたは他のソリューションでこれを行う方法の例は見つかりません。そこの。
理想的には、このようなものを手に入れたいです。
編集:私は一般的な解決策を探しています。私のサイトのすべてのページに実装する必要があるものではなく、反対方向のルールに一致する可能性のあるものを探しています。
url - フレンドリーな URL スキーム?
先週セットアップしたスクレイパー サービスに欠けていた多くの機能の 1 つは、きれいな URL です。現在、ユーザー パラメーターは?u=を使用してスクリプトに渡されています。しかし、私はそれをやり直すことを考えていたので、利用可能なオプションについてフィードバックを得たいと思っています. 現在、ユーザーに情報を提供する 2 つのページ、update と chart があります。ここで私が思いついた2つの可能性があります。「1234」はユーザーID番号です。技術的な理由により、残念ながらユーザー名は使用できません:
- http://<tld>/update/1234
- http://<tld>/chart/1234
また
- http://<tld>/1234/update
- http://<tld>/1234/chart
オプション #1 は、概念的には、ユーザー ID を使用して update を呼び出すことです。オプション #2 は、ユーザー ID を操作する動詞を提供しています。
一貫性の観点から、どちらがより理にかなっていますか?
言及されている別のオプションは
- http://<tld>/user/1234/update
- http://<tld>/user/1234/chart
これにより、特定のユーザーに関係のないページ用のスペースが提供されます。すなわち
- http://< tld >/stats
ruby-on-rails - /similar-to-:product のような URL を Ruby on Rails でサポートしていますか?
私は自分のウェブサイトの URL /similar-to-:product (product が動的な場合) を作成するために routes.rb を使用しようとしています。問題は、routes.rb が /:product-similar のような URL を容易にサポートするが、:product の前に区切り記号を付ける必要があるため、前者をサポートしないことです (「/」は区切り記号ですが、「-」はそうではありません)。セパレーターのリストは、ActionController::Routing::SEPARATORS にあります。
:product にはハイフンも含まれる可能性があるため、区切り記号として「-」を追加できません。このような URL をサポートする最善の方法は何ですか?
私が成功した方法の 1 つは、routes.rb を使用せず、URL 解析ロジックをコントローラー自体に配置することですが、これは最もクリーンな方法ではありません。
php - mod_rewrite RewriteRule を使用して、.php 拡張子を必要としないようにすべてのクエリを書き換えます。
次のようなすべてのクエリが欲しい
のように書き換えられる
言い換えれば、.php 拡張子を任意で普遍的にするだけです。
svn - VisualSVN サーバーの URL の簡素化
svnserve
現在、NT サービスとしてインスタンスを実行しています。これは機能しますが、管理が不必要に面倒なので、もっと単純な VisualSVN サーバーに移りたいと思います。(ボーナスの副次的な利点には、Windows 統合認証と、HTTP/WebDAV のおかげで最新リビジョンのブラウジングが含まれます。)
とはいえ、現在のサーバーは次のような URL を提供しています。
むしろ懐かしい。
VSVNS を介して設定された新しいもの:
ああ。1 つには、/svn
ビットはまったく不要です。VSVNS は独自の HTTP サーバーを実行するため (そのため、結局のところ、特別なポート上にあり8443
ます)、もちろんすべてが に関連していsvn
ます。さらに、レポジトリは 1 つしかありません (それ以上のレポジトリは必要ありません)。そのため、 のレポジトリ名/Repos
もsvnserve
そこにあるべきではありません。
- を削除するように VisualSVN サーバーを構成することは可能
/svn
ですか? (そもそもなんでそこにあるの?) - リポジトリが 1 つしかない場合、リポジトリ名を URL の一部にしないように指定できますか?
ruby-on-rails - Railsサイトに適しているのはどれですか? /{login} または /user/{login}
どちらが優れているか (ユーザーにとって、寿命のために、パフォーマンスのために、何のためにも):
http://{site}/{login} 例: http://wildobs.com/adam_jack
また
http://{site}/user/{login}
前者の長所:
- ユーザーはより特別な気分になります。
- URL が短くなります。
前者の短所:
- キーワードに一致するログインを持つユーザーを持つことはできず、キーワードは時間の経過とともに増加する可能性があります。
すべてのユーザー定義 URL はこれに基づいているため、これを正しく行う (または間違って固執する) ことが重要であることは明らかです。それを変更することは、サイトの自殺のように思えます。
短所 (特に時間の経過とともに) が長所を上回っていますか?