[24] URL の画面表示や印刷については、注意を要することがあります。

bidi

文脈

[16] URL を表示する

表示のために「壊された」URL

[40] Firefox の開発ツールのネットワーク欄の要求URLやHTTPヘッダー中の URL っぽい構文の文字列とみなされた部分は、勝手に…で省略されたり、 破壊的にパーセント復号されたりするようです。

[41] 開発者向け機能で >>40 みたいなことされるとすごい辛いんですが... 「生ヘッダー」を有効にすると元の値も見れるとは言え。

[42] …もパーセント復号もぱっとみで破壊的な変更が加わっていることがわからないのがまた。 右クリックからコピーしたら元の値ではなく表示上の値がコピーされてしまうのも酷い。

[43] Firefox って昔は開発者向け機能も頑張ってたイメージがあるのですけど、いつからこうなっちゃったんでしょうね。

URL scheme や // の省略

URLの省略

大文字URL

[233] 川を川が横断!?橋の上を水が流れる西川新川立体交差 | にいがたレポ, https://niigata-repo.com/life/post-2555/

[234] >>233 このWebサイトが使っている town というフォントはラテン文字小文字の符号位置になぜか大文字と同じような字形が入っています。

[235] そのために記事中の URL が全部大文字で表示されています。 文字列データもリンクも正しい URL なので、リンク先は正しいですし、 コピペしても問題はないのですが、 表示だけがおかしい。 印刷して渡されたらリンク先にたどり着けません。

[236] デザイナーが URL を使うことを考えないでフォントを選んで、 記事の著者が URL の表示がおかしいことに気づかず公開されている (または気づいても直せず放置している) といった感じでしょうか。

全角URL

折り返し

[27] URL は長いので行折り返しが必要になることが多いです。

[28] しかし自然言語の規則 ( 禁則処理 ) では適当な折り返し点が見つけられないことも多いです。

[31] URL の前後の区切子 <, > などがあれば、その内側では折り返し するべきではありません。

[29] 記号類の前後では折り返しが可能とするべきです: :, ;, /, ,, ?, #, =, @, _

[37] ~, $, |, + は含めても含めなくてもいいように思われます。

[30] / の連続の途中では折り返しするべきではありません。

[32] . の前で折り返しを可能とするべきですが、 . が行末に来るのは避けるべきです。

[33] - の前で折り返しを可能とするべきですが、 - が行末に来るのは避けるべきです。 hyphenation してはなりません。

[34] 折り返しの結果行頭に http: や https: が来るのは避けるべきです。 可能なら他の主要な URL scheme も避けるべきです。

[35] Internet Archive の URL のように途中に URL scheme 風の文字列が含まれる場合です。

[36] % の前で折り返しを可能とするべきですが、 % の後では折り返しするべきではありません。 可能なら % の後にASCII十六進数字が2つ続いた後で折り返しを可能としても構いません。

[38] ASCII英数字が長く続くときは、その途中で折り返し可能とするべきです。 可能なら他の条件より優先度を低くするといいかもしれません。 例えば6文字以上のときとするとわりかしうまくいく場合がありますが、 常にそうかはわかりません。 分断の結果2文字以上になる、のような条件も付けてもいいかもしれません。

[39] Xユーザーの齊藤明紀さん: 「Word文書をPDFエクスポートすると、長いURLがハイフネーションされてマイナスが勝手に追加される。PDFビューワでリンクをアクセスすると余分なマイナスが入ったURLにアクセスしてしまいエラー。 回避策はあるんだろうか?」 / X, , https://x.com/a_saitoh/status/1879169844861714633

欧文書体と URL

[19] 雑誌の参考文献欄を見てると、 (, ), / が欧文の普通の記号を使っていると英数字の上下に出ちゃうのがちょっと不格好な感じしますね。 / は区切りだからまあいいとしても(, ) はそこで途切れちゃうような違和感を与えちゃうのが考えもの。

[20] -, _ が印刷書体だと区別が付きにくかったりもしますね。 両方あればどちらかわかるけど単独で出現するとどちらか迷っちゃうような。 普通の文章だと_はまず出てこないから、-が下めに配置されてても困らないのでしょうけど、 URLだと困ります。

[23] URLは通常書体でなくて monospace 系フォントで印刷してるのもありますね。 それがいい。でも同じ雑誌の同じ号で記事ごとに monospace だったり本文と同じ serif だったりするのは、著者の配慮次第みたいなところあるんでしょうか。 編集・校正しっかりせい。

[26] 識別子の印刷書体はプログラマーが画面表示に使うようなフォントを参考に選ぶのがいいのでしょうね。 そうすればOと0の違いとか1とlの違いとかで迷うリスクも減らせそう。

[21] 参考文献リスト中の文末だからとURLの後に.を付け足しちゃうと、 URLに含まれるのか含まれないのかよくわからなくなっちゃうのでよくない。 でも URLで終わるときには.を付けないのにそれ以外は昔からの伝統通りに .を付けてる雑誌もあったりしてなんか落ち着かない。

[22] URLは<, > で括ればその後に.を付けても曖昧さは生じないのに。

[44] XユーザーのAoiMoe a.k.aしお兄Pさん: 「URL とかメアドは等幅フォントで表示した方がいいと思うんだよな。そうすれば rnicrosoft みたいなのには引っかかりにくくなる」 / X, , https://x.com/AoiMoe/status/1982778285781344374

[51] untitled - 20251119h01592full00010032.pdf, , https://www.kanpo.go.jp/20251119/20251119h01592/pdf/20251119h01592full00010032.pdf#page=32

[52] >>51 - だけ和文書体のものが使われているのでしょうか、周りの英字に比べて位置が高すぎて - であることがわかりにくい横線になってしまってます。 数字や英字でも大文字とは合っているので、 小文字とだけ合わないのでしょうか。変ですね。 和文とか欧文とかの問題ではなくて、 縦書き用に寝かせているせいで位置揃えが狂っているのでしょうか。

[53] >>51 _ は視認性には問題ないものの、ちょっと低すぎて美しくないですね。

印刷媒体における非ASCII文字の扱い

[17] 可搬性のため、印刷媒体では非ASCII文字を使うべきではありません。 非ASCII文字はパーセント符号化された状態とするべきです。

[18] 一般的な Webブラウザーではリンク先の URL をコピーすると自動的にパーセント符号化された状態になります。

[15] 書籍に印刷する URL をパーセント符号化するなという声がちらほら。

[237] 見にくいし入力しにくいという気持ちはわからないことはないのだけど、 一方でパーセント符号化していてくれたおかげで可搬性が保たれているというのも否定できないんだよなあ。

[238] この場合学術書であるということもあって、このURLを入力する人が日本語入力に堪能とも限らないわけだしねえ。 URL じゃないけどハングル表記の論文探すのに苦労したことある身としては、 母語でない人にとってはASCII文字だけで済むのは本当にありがたい。

[240] 今ならOCRで読めるだろって言われそうだけど、それをいうならパーセント符号化されてるのも OCR でより確実に読めるんだから変わんないよね。

[239] ASCII帝国主義かよって言われかねない案件だけど、 URL って基本機械が読む識別子だしねえ。 ASCII が基本なのは仕方ないよ。

[241] 書く方の気持ちになってみても、ブラウザーで URL をコピーしたら普通はパーセント符号化した状態で出てくるんだから、 著者か編集者が手動でパーセント復号するんか、そりゃおかしいだろ、って。

[243] それにどの文字を復号していいかって難しいぞ。記号類とか。 (とか_とか復号したら、半角と全角とかちゃんと印刷できる? 印刷時に区別つかなくならない? _ の半角と全角と __ と区別できる? - と ‐ と ― と ー と区別できる? 区別して印刷できたとして読者がちゃんと入力できる? ASCII だけでも 1 と l とか難しいのに、 非ASCII文字が入ってくると難易度爆上げやぞ。

[244] うまく復号したい文字、したくない文字を選べたとして、 したい文字だけ復号してあとはパーセント符号化を残す、 って操作、著者や編集者に正しくできる? そんなの編集者に求められる技術じゃないだろ?

[245] DTP オペレーターだって URL をろくに理解してないから、. の後にアキを入れたり、 URL の途中でハイフネーションしてたりすることがあるくらいなのに、 非ASCII文字まで入ってきてまともに組版できる人どんだけいるよ?

[242] URL の文字コードどうすんだってのは技術的には20年以上前に決着した話で (仕様上正式には10年ちょっとか? IRI のせいで実装より10年くらい遅れてるけど)、 それなのに未だにASCII表記が続いてるのはそれなりに意味があることだと知るべきだな。

[25] URL に濁音が入ってると、 NFC か NFD かみたいな問題になりかねないよね。 どちらも見た目は完全に一緒だから、読者がどちらか判断して入力するのは不可能だし、 著者や編集者がこの濁音はパーセント復号しても安全、とか判断するのも困難。 全部一律でパーセント符号化する以外に選択肢はないよ。

[50] 漢字も似たような字形のがいっぱいあるからね。日本人だから日本語は簡単に入力できるよね、っていわれてそれが成り立たないのが多様性ってやつ。

印刷媒体における URL 記述法としての QR コード

[45] 印刷媒体では URL に、空間的余裕があれば、 QRコードを添えるべきです。

[48] ただ現実には空間がないことがあって難しい。

[46] 印刷媒体では QRコードに必ず URL を添えるべきです。

[47] QRコードしか掲載しない事例が多数ありますが、 カメラや QRコード読み取り機能がない端末からアクセスが出来ず、 困ることがよくあります。

[49] PDF など印刷を想定した電子媒体では、 QRコードはそれが表す URL へのリンクに設定するべきです。

関連

URL自動リンク、文字のセキュリティー、英数字列の読み仮名

メモ

[2] RE: Concerns about new domain names, particularly non-Latin-scripts -- getting the tech community together (Shawn Steele著, ) https://lists.w3.org/Archives/Public/public-iri/2015Oct/0005.html

[4] Source/WebCore/platform/mac/WebCoreNSURLExtras.mm - external/Webkit - Git at Google () https://chromium.googlesource.com/external/Webkit/+/master/Source/WebCore/platform/mac/WebCoreNSURLExtras.mm

[5] gecko-dev/test_idn_blacklist.js at master · mozilla/gecko-dev () https://github.com/mozilla/gecko-dev/blob/master/netwerk/test/unit/test_idn_blacklist.js

[6] webkit/WebCoreNSURLExtras.mm at c9953af06bcf8707a0764a84a4a03a581dbe18a0 · WebKit/webkit () https://github.com/WebKit/webkit/blob/c9953af06bcf8707a0764a84a4a03a581dbe18a0/Source/WebCore/platform/mac/WebCoreNSURLExtras.mm

[7] Guidelines for URL Display, https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md

[3] IDN in Google Chrome - The Chromium Projects, https://www.chromium.org/developers/design-documents/idn-in-google-chrome

[8] IDN Display Algorithm - MozillaWiki, https://wiki.mozilla.org/IDN_Display_Algorithm

[9] Restructure URL rendering section and add additional guidance (estark37著, ) https://github.com/whatwg/url/commit/8809598ddfd1d935432c8a0cad53f13d70e24bc6

[10] Restructure URL rendering section and add additional guidance by estark37 · Pull Request #434 · whatwg/url () https://github.com/whatwg/url/pull/434