[8] 色々なソフトウェアで平文や利用者の入力文、 あるいは HTMLメールの地の文などから、 URL らしき部分を自動的に検出し、これをリンクとして表示する自動リンク機能が備わっています。
[9] 中には URL の、あるいは HTTP(S) URL など一部の URL の構文を機械的に正規表現に変換しただけのような雑な実装もありますが、 実用上十分良好な利用者体験を提供するためには、 細かな調整が必要となります。
[57] URL の他に、メールアドレス、電話番号、アプリケーション依存の構造 (ハッシュタグなど) でも同様の仕組みが使われることがよくあります。
[58] 本項では特に断らない限り URL の自動リンクを扱いますが、 それ以外の自動リンクにも触れます。
[78] URL の構文を正規表現のようなものに置き換えて一致させてリンクを作ればいいだけではないのだろうか、 と安易に考えがちですが、それだけでは実用的なものになりません。 簡単そうに見えて、これは思っている以上に複雑な問題なのです。
[79] 明文化された手順や有名な実装だけでもいくつもありますが、 それぞれ違った方針で違った特徴を持ったものになっています。 それぞれに欠点もあります。
[2] 「This is great: https://example.com/great.html. Thanks!」 の最後の「.」は URL の一部ではなく英文の一部と解釈する必要があります。
[3] とすると「See www.example.com.」も www.example.com. を表すのではなさそうです。
[4] 「See https://example.com/great.html, please.」 の「,」は URL の一部ではなく英文の一部と解釈する必要があります。
[5] 「https://example.com/pageU+3000です」は、
U+3000 の前までを URL と解釈する必要があります。
[7] 「... (https://test.test/foo)、...」
で GitHub は ) のあともずっと URL の一部とみなします。
[13] はてなブックマークのブックマークコメントでは、 URL の後に「>」 があると、「>」まで URL の一部とみなします。
[14] 掲示板の自動リンクで、 #! のような ! が URL
の一部と見なされず、その直前までが URL とみなされることがあります。
[15] W3C のメーリングリストのアーカイブ: Re: Breaking the `opener` relationship. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0078.html は、なぜか
`WindowProxy`'s `GetOwnProperty` uses https://html.spec.whatwg.org/#isplatformobjectsameorigin-(-o-): I'd just stick with that as a determinant of the properties listed in https://html.spec.whatwg.org/#crossoriginproperties-(-o-).
を
`WindowProxy`'s `GetOwnProperty` uses https://html.spec.whatwg.org/#isplatformobjectsameorigin-(-o-): I'd just stick with that as a determinant of the properties listed in https://html.spec.whatwg.org/#crossoriginproperties-(-o-).
と解釈します。
[19] みのさんのツイート: "https://t.co/927QpBK32e!" () https://twitter.com/mino90h/status/873210646183026689
[20] ! で終わる URL を Twitter は ! の直前まで URL と認識。
[21] GitHub は
href="https://example.com/">Example Web Page</a>
の「https:」から「Example」
までを1つの URL とみなします。
「http://www.<em>mozilla</em>.org/」みたいに複数のテキストノードに分割されたURIも認識できる。
某新聞社のサイトのように「http://piro.sakura.ne.jp/」ってな全角文字で書かれたURIも認識できる。
2chでよくある「ttp://」で始まるURIも認識できる。ていうか最初はこれが目的だったんだよね……
[42]
LimeChat は
《http://example.jp/abc-def/》
の最後の括弧まで
URL
と認識してしまいます。
[51] [tz] Some time zone history (2), , https://mm.icann.org/pipermail/tz/2020-November/029514.html
https://parliament.gov.gy/documents/acts/10923-act_no._27_of_1975_-_interpretation_and_general_clauses_(amendment)_act_1975.pdf
「)」の直前の「t」までで URL が終わると誤認してしまっています。
[53] [JavaScript] PCのタイムゾーン・時差情報の活用: Kawanet Blog II, https://kawa.at.webry.info/200610/article_1.html
location.href = 'http://www.kawa.net/xp/index-j.html'; リンク
[27] かつては URL には非ASCII文字は認められていなかったので、 日本語などの非ASCII文字主体の文章では URL とその周りの区切りは比較的明確でした。
[28] ところが URL で非ASCII文字一般が認められるようになってから、 URL の直後に文章が続いているものと URL に非ASCII文字が含まれるものの区別が難しくなりました。
[31] 素片識別子に非ASCII文字を含む語が書かれている場合や、 パスに見出し語が入る Wikipedia の URL の場合のように、 非ASCII文字が含まれる URL が書かれることは少なくないため、 何らかの対応は必須といえます。
[22] 自動リンク機能のある掲示板などの利用者は、 自動リンクを敢えて回避することを好む場合があります。
[23] そのため http: の h を省略した ttp:
のような URL が用いられることもあります。
ttp: 参照。[24] しかしそうした自動リンクを回避した URL を敢えて自動リンクしリンクをたどる利用者の便を図る実装もあります。
[32] ドメイン名のみを書いたり、 ドメイン名から始まる不完全な URL を書いたりして省略して HTTP(S) URL を表すこともあります。 自動リンクの実装の中には、そうした不完全なものも抽出しようと試みるものがあります。
[59] ドメイン名のみで構成される文字列が自動リンクされることがあります。
[60]
そのような実装の多くは http:// を補います。
[61] 実はそれほど役に立つ場面は多くなく、最近はあまり実装されていない印象があります。
[62] ドメイン名は HTTP(S) URL 以外にも色々な用途がありますが、 HTTP 以外の URL と解釈するものは見たことがありません。 HTTP の場合以上に自動リンク化したい需要がないということなのでしょう。
[63] IDN 対応すると、句読点を含んだほとんどどんな文字列もドメイン名扱いしてしまうことになります。 既知の TLD で終わるかどうかで制限すれば幾分ましになりますが、 近年 TLD はどんどん追加されていますから、追随すればするほど悪化します。 しかし IDN もそれほど使わていないのが現状で、 わざわざ対応して使い勝手を落とす必要性は疑問です。
[39] メールアドレスや電話番号が自動リンクされることがしばしばあります。
[66] メールアドレスは平成時代中頃まではよく自動リンクの対象になっていました。 その後は (私的、娯楽的領域における) インターネットメールの衰退のためか、 対象とされなくなってきている印象があります。 ただし MUA では依然として対象になっています。
[67] 電話番号はスマートフォンの普及 (= 自動リンクされた媒体を閲覧する端末と電話機の統合) により自動リンクの対象に含まれがちになってきている印象があります。 ただし自動リンクされるような媒体で電話番号の自動リンクを使って利用者が電話したり、アドレス帳に登録したり、 といった需要があるのかは、疑問もあります。
[65]
Webブラウザーが自動リンク機能を実装し、 a 要素がなくてもリンク表示することがあります。
x-ms-format-detection も参照。
[68]
メールアドレスは mailto:, 電話番号は tel:
が暗示されているとみなすことで、URL の自動リンクの特殊形として扱うことができます。
[64] その他にアプリケーション依存の識別子などの自動抽出・リンク化が実装されていることがあります。
[69] Wiki は元々 WikiName と呼ばれる独特の名前文字列構文に一致するものをリンク先ページ名とみなして自動リンクするシステムでした。
[70] Wiki の中には、伝統的な WikiName 構文でなくとも、 データベース中のページ名に一致する任意の文字列を検出し自動リンクするものもありました。 商用サービスでははてなダイアリーの実装例が有名で、 はてなキーワードの登録キーワードに一致すると (特別な構文を使わなくても) 自動的に当該キーワードへのリンクとなりました。
[71]
近年では多くのWebサービスやSNSがハッシュタグを実装しています。
ハッシュタグは # から始まる文字列を分類キーワードとみなすもので、
文中にその形式の文字列があれば自動リンクされます。
[73] ハッシュタグ中に使える文字は、採用サービスによって少しずつ違います。 統一的な規定はありません。
[74] 昔の Twitter はASCII文字しか使えませんでした。 日本のものでも昔から使われ続けているハッシュタグはASCII英数字だけだったりします。
[75] しかし多くの人に普及したサービスではやはりASCII文字のみという制限は非現実的であり (文化的多様性を否定する差別的取り扱いでもあり)、 現在では多くのサービスが非ASCII文字を認めています。
[76] ところが記号類の扱いはサービスによって違っています。 サービスによっては通常表記に必要な文字まで記号とみなすためか、 ハッシュタグで使えないことがあります。
[77]
たとえば YouTube は仮名の長音記号ーの異体字として使われる〜
(
[10] 任意の URL を自動リンク化すると、 : さえ入っていればほとんどどんな文章でも一部が
URL ということになってしまいます。
[35] 一般的な実装は特定の URL scheme のみに対応しています。 HTTP(S) URL のみに対応する最低限のものから、 それ以外の色々な URL に対応するものまであります。
[11] javascript: など、危険な動作を誘引する URL scheme
もあります。無邪気な実装はセキュリティーホールとなりかねません。
[25] 古い URL の RFC では、自然言語文に URL を混ぜる場合は区切りとして
< と > で括るのが好ましいという記述がありました。
そのため URL の前後に < と > を書くことをよしとする人もいます。
しかしこの慣習は一般には普及しませんでしたし、
Web 技術に詳しい人の中でもそこまで有名ではありません。
(が無視するのは惜しいほどには普及しています。)
[26] < と > は通常の URL には含まれないものですから、
自動リンクの実装は特に考慮しなくてもこの区切り文字を意図通りに解釈すると期待されます。
しかし文字参照の扱いが杜撰な自動リンクの実装に誤解釈されることもあるようです
(例えば >>13)。
Angle brackets are strongly recommended around URIs [STD66], e.g., http://example.com/
[33] Wiki構文などテキスト系のマーク付け言語は、 自動リンク機能を言語の一部として組み込んでいることがよくあります。
[34] はてな記法は URL の自動リンクの他に、 はてなキーワードのキーワード自動リンクなどもあります。
[83] Markdown の実装の多くはURLの自動リンクも行います。
[17] GitHub Flavored Markdown Spec () https://github.github.com/gfm/#autolinks-extension-
[80] マーク付け言語系の自動リンクには、それ独特の難しさがあります。 マーク付け言語の構文を構成する記号類は URL とみなしてはいけません。 しかし URL の中にそのような記号が含まれることもあります。 マーク付け言語のエスケープ構文を使わせるのが筋ですが、 書きやすさを犠牲にしてしまいます。
[81] 問題を避けるには、マーク付け言語を慎重に設計する、なんなればマーク付け言語の設計に自動リンクを組み込む必要があります。 そうなるとマーク付け言語の構造の検知と URL の検出は同時に行う必要があります。 構文解析が済んでから自動リンクへという処理の分離ができなくなります。
[82]
例えば pre 要素相当の構造の中では自動リンク機能を停止したい、
のように自動リンクの制御とマーク付け言語の機能の連動の要件も出てくると、
実装方針はますます制約されることになります。
[37] 次のような分野で使われています。
[47] 自動リンクテストデータ。 HTCT 形式のテストセット中に、 入力例とそのURL自動リンク検出例、 HTML 変換例が記述されています。
はてなアンテナで、複数のページを一括で登録する機能を追加しました。OPMLファイルやHTML、またテキストファイルに対応しています。(テキストファイルからはURLと判別できる文字列を抽出します。)
[50] Tcl Improvement Proposals: TIP 3: TIP Format, https://core.tcl-lang.org/tips/doc/trunk/tip/3.md
[52] RFC 1842 - ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages, , https://tools.ietf.org/html/rfc1842#section-10
原文
at Beijing, China: ftp://info.bta.net.cn:/pub/software/;
at Shanghai, China: ftp://info.bta.net.cn:/pub/software/;
at Taiwan: ftp://nctuccca.edu.tw/pub/Chinese/ifcss/;
or ftp://ftp.edu.tw:/Chinese/ifcss/software/;
At Singapore: ftp://ftp.technet.sg:/pub/chinese/;
at California, U.S.A.: ftp://cnd.org/pub/software/.これが自動リンクされた結果の解釈:
at Beijing, China: ftp://info.bta.net.cn:/pub/software/; at Shanghai, China: ftp://info.bta.net.cn:/pub/software/; at Taiwan: ftp://nctuccca.edu.tw/pub/Chinese/ifcss/; or ftp://ftp.edu.tw:/Chinese/ifcss/software/; At Singapore: ftp://ftp.technet.sg:/pub/chinese/; at California, U.S.A.: ftp://cnd.org/pub/software/.
なぜこんな切り方になるのか理解し難い。規則性が見えそうで見えない。
[54] Linkification of URLs - 24122-url-linkification.pdf, , https://www.unicode.org/L2/L2024/24122-url-linkification.pdf
[55] UASG 010 Quick Guide to Linkification EN - Universal Acceptance Steering Group (UASG), , https://uasg.tech/download/uasg-010-quick-guide-to-linkification-en/