実装戦略

[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 の一部とみなします。 2016-08-22T14:36:26.700Z

[13] はてなブックマークのブックマークコメントでは、 URL の後に「>」 があると、「>」まで URL の一部とみなします。 2017-01-19T10:27:49.100Z

[14] 掲示板の自動リンクで、 #! のような ! が URL の一部と見なされず、その直前までが URL とみなされることがあります。

[15] W3C のメーリングリストのアーカイブ: Re: Breaking the `opener` relationship. (Mike West著, 2017-04-28 17:10:13 +09:00) 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!" (2017-12-23 13:27:17 +09:00) https://twitter.com/mino90h/status/873210646183026689

[20] ! で終わる URL を Twitter は ! の直前まで URL と認識。

[21] GitHub は href="https://example.com/">Example Web Page</a> の「https:」から「Example」 までを1つの URL とみなします。 2018-01-14T00:27:17.600Z

[42] LimeChat は 《http://example.jp/abc-def/》 の最後の括弧まで URL と認識してしまいます。 2020-02-17T01:19:15.400Z

[51] [tz] Some time zone history (2), 2020-11-30T15:48:50.000Z, 2020-12-03T03:03:42.245Z 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, 2022-07-16T01:23:09.000Z https://kawa.at.webry.info/200610/article_1.html

        location.href = 'http://www.kawa.net/xp/index-j.html';

ブログソフトウェアの自動リンクによるものか。

[89] PyCon JPの技術に対する不正の告発、並びに技術者と大衆に対しての警鐘 #Python - Qiita, 2024-09-23T11:01:09.000Z https://qiita.com/python_bokume2/items/7aa80b73010919007581

[90] >>89 URL 直後の全角閉じ括弧を誤解している事案。こういうの平成の頃はたまに見たけど最近見ないよね。 こういう壊れた実装って未だにあるんだー

[93] it-talks(いっとく)/@DSi, 2024-10-08T13:16:50.000Z https://pulpdust.org/i/?topic=%40DSi&sort=ASC

[94] >>93

http://ugomemo.hatena.ne.jp/1351D79031C5FE68@DSi/movie/C5FE68_0A6EF461FE09B_002

のような URL の @ の前までが URL と誤認している。

非ASCII文字

[27] かつては URL には非ASCII文字は認められていなかったので、 日本語などの非ASCII文字主体の文章では URL とその周りの区切りは比較的明確でした。

[28] ところが URL で非ASCII文字一般が認められるようになってから、 URL の直後に文章が続いているものと URL に非ASCII文字が含まれるものの区別が難しくなりました。

[31] 素片識別子に非ASCII文字を含む語が書かれている場合や、 パスに見出し語が入る Wikipedia の URL の場合のように、 非ASCII文字が含まれる URL が書かれることは少なくないため、 何らかの対応は必須といえます。

リンク回避

[22] 自動リンク機能のある掲示板などの利用者は、 自動リンクを敢えて回避することを好む場合があります。

[23] そのため http: の h を省略した ttp: のような URL が用いられることもあります。

[24] しかしそうした自動リンクを回避した URL を敢えて自動リンクしリンクをたどる利用者の便を図る実装もあります。

URL scheme の省略

[32] ドメイン名のみを書いたり、 ドメイン名から始まる不完全な URL を書いたりして省略して HTTP(S) URL を表すこともあります。 自動リンクの実装の中には、そうした不完全なものも抽出しようと試みるものがあります。

ドメイン名のみの自動リンク

[59] ドメイン名のみで構成される文字列が自動リンクされることがあります。

[60] そのような実装の多くは http:// を補います。

[61] 実はそれほど役に立つ場面は多くなく、最近はあまり実装されていない印象があります。

[62] ドメイン名は HTTP(S) URL 以外にも色々な用途がありますが、 HTTP 以外の URL と解釈するものは見たことがありません。 HTTP の場合以上に自動リンク化したい需要がないということなのでしょう。

[63] IDN 対応すると、句読点を含んだほとんどどんな文字列もドメイン名扱いしてしまうことになります。 既知の TLD で終わるかどうかで制限すれば幾分ましになりますが、 近年 TLD はどんどん追加されていますから、追随すればするほど悪化します。 しかし IDN もそれほど使わていないのが現状で、 わざわざ対応して使い勝手を落とす必要性は疑問です。

URL 以外の自動リンク

[39] メールアドレスや電話番号が自動リンクされることがしばしばあります。

[66] メールアドレスは平成時代中頃まではよく自動リンクの対象になっていました。 その後は (私的、娯楽的領域における) インターネットメールの衰退のためか、 対象とされなくなってきている印象があります。 ただし MUA では依然として対象になっています。

[67] 電話番号はスマートフォンの普及 (= 自動リンクされた媒体を閲覧する端末と電話機の統合) により自動リンクの対象に含まれがちになってきている印象があります。 ただし自動リンクされるような媒体で電話番号の自動リンクを使って利用者が電話したり、アドレス帳に登録したり、 といった需要があるのかは、疑問もあります。

[65] Webブラウザーが自動リンク機能を実装し、 a 要素がなくてもリンク表示することがあります。 x-ms-format-detection も参照。

[68] メールアドレスは mailto:, 電話番号は tel: が暗示されているとみなすことで、URL の自動リンクの特殊形として扱うことができます。

[64] その他にアプリケーション依存の識別子などの自動抽出・リンク化が実装されていることがあります。

[103] インターネットメールやネットニュースのメッセージの表示ではメッセージ識別子が自動リンクされることがあります。

[69] Wiki は元々 WikiName と呼ばれる独特の名前文字列構文に一致するものをリンク先ページ名とみなして自動リンクするシステムでした。

[70] Wiki の中には、伝統的な WikiName 構文でなくとも、 データベース中のページ名に一致する任意の文字列を検出し自動リンクするものもありました。 商用サービスでははてなダイアリーの実装例が有名で、 はてなキーワードの登録キーワードに一致すると (特別な構文を使わなくても) 自動的に当該キーワードへのリンクとなりました。

[71] 近年では多くのWebサービスやSNSがハッシュタグを実装しています。 ハッシュタグは # から始まる文字列を分類キーワードとみなすもので、 文中にその形式の文字列があれば自動リンクされます。

[73] ハッシュタグ中に使える文字は、採用サービスによって少しずつ違います。 統一的な規定はありません。 識別子文字

[74] 昔の Twitter はASCII文字しか使えませんでした。 日本のものでも昔から使われ続けているハッシュタグはASCII英数字だけだったりします。

[75] しかし多くの人に普及したサービスではやはりASCII文字のみという制限は非現実的であり (文化的多様性を否定する差別的取り扱いでもあり)、 現在では多くのサービスが非ASCII文字を認めています。

[76] ところが記号類の扱いはサービスによって違っています。 サービスによっては通常表記に必要な文字まで記号とみなすためか、 ハッシュタグで使えないことがあります。

[77] たとえば YouTube は仮名の長音記号ーの異体字として使われる〜 ( 長音記号 ) をハッシュタグに認めていません。 普通に使えると誤解して使ってみたら使えなかったという日本人の利用者が困っている現実があります。 2024-05-10T13:12:50.900Z

[40] smart tag も参照。

[85] LINE では金額がリンク化されます。 >>84, >>86 日本語で日本円、タイ語でタイバーツがリンク化されると説明があり、 他の言語には説明がありません。 言語ごとに挙動が変わるのか、説明が違うだけで挙動は共通なのか、 実は国など他の設定によって挙動が変わるのか、不明です。

[102] 動画サービスの説明欄やコメント欄では HH:MM:SS のような形式の文字列が媒体タイムライン上の時刻の表記として認識され、 指定時刻へのシークのボタンとして機能することがよくあります。

対応する URL scheme

[10] 任意の URL を自動リンク化すると、 : さえ入っていればほとんどどんな文章でも一部が URL ということになってしまいます。

[35] 一般的な実装は特定の URL scheme のみに対応しています。 HTTP(S) URL のみに対応する最低限のものから、 それ以外の色々な URL に対応するものまであります。

[11] javascript: など、危険な動作を誘引する URL scheme もあります。無邪気な実装はセキュリティーホールとなりかねません。

区切り文字

[25] 古い URL の RFC では、自然言語文に URL を混ぜる場合は区切りとして < と > で括るのが好ましいという記述がありました。 URL そのため URL の前後に < と > を書くことをよしとする人もいます。 しかしこの慣習は一般には普及しませんでしたし、 Web 技術に詳しい人の中でもそこまで有名ではありません。 (が無視するのは惜しいほどには普及しています。)

[26] < と > は通常の URL には含まれないものですから、 自動リンクの実装は特に考慮しなくてもこの区切り文字を意図通りに解釈すると期待されます。 しかし文字参照の扱いが杜撰な自動リンクの実装に誤解釈されることもあるようです (例えば >>13)。

[88] 関連: URLの表示

自動リンク機能付きマーク付け言語

[33] Wiki構文などテキスト系のマーク付け言語は、 自動リンク機能を言語の一部として組み込んでいることがよくあります。

[34] はてな記法は URL の自動リンクの他に、 はてなキーワードのキーワード自動リンクなどもあります。

[83] Markdown の実装の多くはURLの自動リンクも行います。

[17] GitHub Flavored Markdown Spec (2017-05-15 12:05:46 +09:00) https://github.github.com/gfm/#autolinks-extension-

[80] マーク付け言語系の自動リンクには、それ独特の難しさがあります。 マーク付け言語の構文を構成する記号類は URL とみなしてはいけません。 しかし URL の中にそのような記号が含まれることもあります。 マーク付け言語のエスケープ構文を使わせるのが筋ですが、 書きやすさを犠牲にしてしまいます。

[81] 問題を避けるには、マーク付け言語を慎重に設計する、なんなればマーク付け言語の設計に自動リンクを組み込む必要があります。 そうなるとマーク付け言語の構造の検知と URL の検出は同時に行う必要があります。 構文解析が済んでから自動リンクへという処理の分離ができなくなります。

[82] 例えば pre 要素相当の構造の中では自動リンク機能を停止したい、 のように自動リンクの制御とマーク付け言語の機能の連動の要件も出てくると、 実装方針はますます制約されることになります。

文脈

[37] 次のような分野で使われています。

テストデータ

[47] 自動リンクテストデータ。 HTCT 形式のテストセット中に、 入力例とそのURL自動リンク検出例、 HTML 変換例が記述されています。

その他実装例

[45] Perl による実装。

関連

[49] リンク展開

歴史

[95] Proposed Draft UTS #58: Unicode Linkification, 2024-10-22T01:51:57.000Z https://www.unicode.org/L2/L2024/24217-uts58-working-draft.html

メモ

[91] interactive hypermedia, 2003-08-04T15:50:21.000Z, 2024-09-29T09:28:21.361Z https://lists.w3.org/Archives/Public/www-talk/1992NovDec/0124.html

[92] >>91 最後の段落、やや明確ではないけど、 URL を自動リンクするということかな。 自動リンク仕様の最古の言及かも。自動リンクしていたサーバー用ソフトウェアはこれ以前からあったのかもしれないけど。

[50] Tcl Improvement Proposals: TIP 3: TIP Format, 2020-11-17T01:10:32.000Z https://core.tcl-lang.org/tips/doc/trunk/tip/3.md

[52] RFC 1842 - ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages, 2021-01-31T11:17:23.000Z, 2021-03-20T10:01:29.688Z 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, 2024-04-19T17:17:04.000Z, 2024-04-25T04:12:14.741Z https://www.unicode.org/L2/L2024/24122-url-linkification.pdf

[55] UASG 010 Quick Guide to Linkification EN - Universal Acceptance Steering Group (UASG), 2024-04-24T23:51:14.000Z, 2024-04-25T04:12:59.902Z https://uasg.tech/download/uasg-010-quick-guide-to-linkification-en/

[56] >>55 例文自体の自動リンク化が推奨と無関係の滅茶苦茶な状態のままで草。てきとーに編集してるんかいw

[87] 電子メール本文中の日本語ドメイン名URLをクリックできるようにするには - 日本語.jp (2006-11-29 16:15:15 +09:00 版) http://nihongojp.jp/support/mail_guide/ (名無しさん 2006-12-29 07:19:52 +00:00)

[97] JVN#43561812: スマートフォンアプリ「+メッセージ(プラスメッセージ)」における Unicode 制御文字の扱いに関する脆弱性 (2022-12-21T03:00:00.000Z, 2024-11-07T07:14:35.551Z) https://jvn.jp/jp/JVN43561812/

[98] JVN#43561812: スマートフォンアプリ「+メッセージ(プラスメッセージ)」における Unicode 制御文字の扱いに関する脆弱性 (2022-12-21T03:00:00.000Z, 2024-11-07T07:14:35.551Z) https://jvn.jp/jp/JVN43561812/

[99] +メッセージの挙動はクライアントによると推測されますが、 ある携帯電話のクライアントの場合は、 foo.test/abc や foo.test のような URL scheme がないものも URL として自動リンクします。

[100] 非ASCII文字も認識されることがあるらしく、 foo.test… だと…までドメイン名の一部とみなします。 2024-11-15T03:47:23.800Z

[101] Chatwork の自動リンクは URL の後に > があると > まで URL の一部と誤認します。 2024-12-02T05:28:28.800Z