You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
iOSアプリにはアプリ毎にカスタムURLスキームが設定でき、カスタムURLスキームを設定すると他のアプリからそのURLスキーム経由で、アプリを起動する事ができます。 カスタムURLスキームを利用する (1) | calmscape: //ソフトウェア開発部 「iPhoneアプリをカスタムURLスキームで呼ぶ」をも少し詳しく 単純に起動するだけではなくて、URLという用に自由にクエリなどを付けられるので、他のアプリから文字列を受け取って処理することもできます。 単独のアプリで特に他のアプリと連携するわけでもないという場合も多いですが、 そういう場合にもとりあえずカスタムURLスキームを設定しておくといい場合もあります。 他のアプリから、アプリを起動する事ができる これは、自分がそういう用途で使ってなくてもユーザーがそういう使い方をしたい時などにカスタムURLスキームが無いけないため 、本当に
URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority(). URI.js offers simple, yet powerful ways of working with query string, has a number of URI-normalization functions and converts relative/absolute paths. While URI.js p
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
2011年02月14日 URL #!的な話題の関連記事まとめ #!関連のエントリーが調べにくいので目にとまったらここに追記していく。 TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場 NewTwitterとかFacebookのAjaxなURL(#!)を変換する奴を書いた - 金利0無利息キャッシング – キャッシングできます - subtech Tim Bray: 「URLに#!入れるな」 - karasuyamatenguの日記 urlに#!とか入れるなという話と、ひとつのURL≒ひとつのコンテンツという原則の話 さらなる「#!」URL批判 - karasuyamatenguの日記 HOKYPOKY.BLOG » 「#!」を含むURLについて YappoLogs: #!なんか糞だ ツイート Prev E
このブログはlifehackerを含むgawkerメディア系サイトの#!URLへの移行を批判している。 http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/ 以下、isolaniとテングの見解をごっちゃ混ぜに紹介する。 lifehacker他のgawkerメディアサイトが数日前に長時間におよびアクセス不能になった。(厳密に言うとページ内のコンテンツアクセス不能になった) #!URLベースのサイトはJavaScriptにエラーがあるとコンテンツが一切ロードせずのっぺらぼう状態になってしまうようだ。 #!について 「#!」は何で呼ぶの？ shebangと綴られる。 Hash=# Bang=!の略 発音すると「シバン」といったところか。(ちなみにUnixの#!とは無関係) 以下「#URL」は： サイト内のロケーション情
前置き IEでのa要素の各属性について - 文殊堂の続き。 IE 6,7 で相対URL -> 絶対 URL の変換 - #生存戦略 、それは - subtechを参考にして、 cloneNodeハックとlink.hrefによるURLの絶対URL化を組み合わせてみました。 http://jsdo.it/monjudoh/o2Mk http://jsdo.it/monjudoh/9aHd link.hrefによるURLの絶対URL化はIE6,7では使えないので割愛。 検証 IE6 なぜかhostnameがiframeではなく外側のものになってしまっている。 少なくとも短いURLについてはouterHTMLハックを使った場合に各属性の値をちゃんと取れていたので、 そっちを使ったほうが良さそう。 a要素の各属性(cloneNodeハック) ---url.length:11 href:[htt
色々あってa要素でURLをパースするというコードを書いていて色々はまったのでまとめます。 IE6-8でのa.hrefの上限 IE6,7:4096bytes IE8:4121bytes でした。 なお、Firefox,Google Chrome,Safariは1MBとか普通に扱えます。 使わないけど。 http://jsdo.it/monjudoh/8Fm6/read 各属性の取得状況 a.hrefにURLを代入して各属性がどうなるか調べてみました。 URLの長さが短い⇔上限超え outerHTMLハックを使わない⇔使う a.hrefにURLを代入後、別の要素のinnerHTMLにa.outerHTMLを代入し、そのfirstChild(a要素)の各属性を見ること の二軸を変えて調べてみました。 http://jsdo.it/monjudoh/sc82 IE6 a.hrefへの代入で更新され
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
I hate the DOM! The API sucks! Don’t you agree? Regardless, we should definitely take advantage of what we’ve been given. So, if something is built into the DOM it would be silly not to use it, right? Well, that’s what I believe and that’s why I think it’s okay to parse URLs via this API instead of trying to accomplish it in a language-agnostic manner (using a tonne of expensive string operations)
ユーザーエージェントおよびサーバの実装に依存します。スキーム、ホスト名を含めて、255 バイト以下は安全です。メジャーなブラウザとサーバに限定すれば、2000 バイト程度までは使えるでしょう。 SGML では 1024 文字 HTML のスーパーセットである SGML では、LITLEN=1024 文字とされています。 RFC2070 | URL の長さの制限って | HTML 4のSGML宣言 HTML 4.01 では 65536 文字 HTML 4.01 では LITLEN=65536 文字です。 HTTP では未定義、255 バイト以下を推奨 RFC2616 (HTTP/1.1) には、URL の長さに関する規定はありません。ただし、 Note: Servers ought to be cautious about depending on URI lengths above
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
<script src="..."> という感じでjsファイルを読み込んで、src部分が http://example.com/lab/test.js であるとき、 http://example.com/lab/ を自分自身で取り出す方法を模索する。 自分自身のsrcを調べる方法は とてもシンプルに自分自身が属する script 要素を取得 - IT戦記 http://d.hatena.ne.jp/amachang/20061201/1164986067 で大体いいと思います。 もしくは var n=document.getElementsByTagName("script"); n[n.length-1].src; // 自分自身のurl 相対パスの場合とか調べてないけど、今回の主題はディレクトリを取り出すとこなので後回し。 Twitterでどういう方法があるのだろうと投
Web において使われる URI（URL）には様々な情報が埋め込まれるが、その埋め込みの際にはエスケープ（パーセントエンコード）が行われる。埋め込まれた情報は取り出されるときにアンエスケープ（パーセントデコード）される。 たとえば、四則演算を行う電卓の Web アプリケーションを考える。この電卓は HTML の form でユーザに式の入力を求め、式が入力されてサーバに送られたらその結果を表示する。ここで、式は "http://calc.example.org?q=式" というような URI にブラウザがアクセスすることによって、サーバに送られるものとする。この形式は HTML の form で用いられる application/x-www-form-urlencoded という形式であり、HTML の規格で定義される。この場合、"1+1" という式を URI に埋め込むには "+" とい
http://d.hatena.ne.jp/m-bird/20100402/1270190863 とか http://anond.hatelabo.jp/20100403084111 とか ずいぶん適当なこと書いてあるなと思ったので調べた。 見ているページのURLが送られるかという話 ツールバーは使ってないのでChromeについてだけ軽く検証したので書いておく。検証したバージョンはGoogle Chrome 5.0.366.2 devでモニタに使ったのはFiddler。 見ているページのURLを自動で送信する機能はChrome自体には無い。アドレスバーにURLを貼りつければ検索語句の補完機能が動いて送られることがある。 ただしhttpsの場合はホスト名まで、httpの場合はクエリストリング(URLの?以降)は含まれない。 フォームの自動入力を有効にしたらなんかXMLが送られるけど、これは見
（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP
2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
