デコード URL

  1. いつもお世話になっています。Ver.3.3.6 です。
    URL に日本語を含むと、URL に適さない文字としてアンダーラインが外れます。
    実際には、日本語を含む URL を Chrome で使っても動作します。
    （例）https://ja.wikipedia.org/wiki/メモ帳
    このほうがコンパクトで、可読性も高まります。
    Mery でも日本語部分までアンダーラインがつながると助かります。

     |  TN24  |  返信

  2. いちユーザーですが、共感の気持ちが溢れたのでコメントしにきました。

    日本語URL、ダブルクリックで扱えると確かに嬉しいですよね。私もよく遭遇します。

    ただ、日本語文書との組み合わせを考えると厳しいんだろうなぁと想像してます。
    「まずはhttps://www.google.co.jp/にアクセスしてください」という文章だと、URLの区切りがどこか分からないですしね😅

    文字をURLエンコードするマクロを用意して、Mery上でリンクとして認識できるように簡単に変換してもいいかもですが、折角の日本語URLが分かりづらい見た目になってしまうのが悩ましいところです。

     |  yuko  |  返信

  3. ご愛用いただきありがとうございます。

    そうなんですよね。日本語を含む URL の認識については以前からご要望がありまして、実装したいなーと思ってはいるのですが、技術的に難しく開発に時間がかかりそうなので優先度は低めに設定していました。

    【参考】https://www.haijin-boys.com/wiki/よくある質問#日本語を含む_URL_を認識したい

    ↑ 絶対無理…。という気持ちがにじみ出ている Tips ですが、うーん、今の技術力でも難しそうな気が…。

    とりあえずご意見は心にとどめておき、開発のヒントになりそうな情報は積極的に調査してみたいと思います。

     |  Kuro  |  返信
  4. yuko さんの投稿 (2022年11月4日) への返信

    レスを書いている間にタイミングが重なってしまったようで…。

    > 「まずはhttps://www.google.co.jp/にアクセスしてください」という文章だと、URLの区切りがどこか分からないですしね😅

    そうなんですよね。日本語を含む URL の場合、山かっこ < > でくくるとか特殊な入力方法が必要だったりしますし、自動できちんと認識させることはほぼ不可能ではないかと思っています。

    中途半端な実装ならしないほうが良いというのが Mery 的な志向ですが、簡単に実装できて割とそれっぽく動くのなら [オプション] で実装しても良いかなぁとも思います。

    [オプション] で同意の上なら、日本語を含む URL が全部つながっちゃっても、仕方ないよねーってなるかなぁと😅

    ホント、難しいですこの問題。

     |  Kuro  |  返信
  5. Kuro さんの投稿 (2022年11月4日) への返信

    検討ありがとうございます。オプションで同意に一票です。
    自分の使い方では、URL の後ろに続けて文章を書くことはないので、
    改行または EOF を区切りというのはどうでしょうか。

     |  TN24  |  返信
  6. Kuro さんの投稿 (2022年11月4日) への返信

    たしかに、搭載するなれオプション化は必至でしょうね。まだまだURLに日本語が使われるって比較的マイナーなケースでしょうし…

    いっそサクラエディタのように、URL認識パターンを自分で追加定義できる機能とかもありかもしれません。そうしたらカスタムURLスキームでブラウザ以外のアプリ呼び出しもできたりして…!? なんてちょっと夢が広がりますｗ

     |  yuko  |  返信
  7. Kuro さんの投稿 (2022年11月4日) への返信

    どこまでがURLなのかは本人がわかっているという前提の上で、
    http:// https:// から始まる選択した文字列をアドレスと扱う形を取りコンテキストメニューに
    「ブラウザで移動する」といった辺りの項目を追加しユーザー側に任せる方が確実で
    それならマクロで充分かつオプションもわざわざ用意せずにいけるという気もするのですが・・・

     |  ZZT  |  返信

  8. みなさんご意見ありがとうございます。

    > 改行または EOF を区切りというのはどうでしょうか。

    そうですね、改行と EOF は URL の区切りとしては必須条件だと思います。

    きちんと実装するなら、それに加えて、かぎかっこ (「」) や点 (、) や、まる (。) など、日本語の区切りとして使われそうな文字を精査して、それらを区切りとして認識させる必要がありそうです。

    > いっそサクラエディタのように、URL認識パターンを自分で追加定義できる機能とかもありかもしれません。

    正規表現キーワードとして登録した強調文字列を URL として認識できるみたいですね。

    自由度は高いと思いますが、それだと正規表現を知らないと手も足も出ない感じなので Mery 的にはもうちょっと簡単なほうが良いかもです😅

    > それならマクロで充分かつオプションもわざわざ用意せずにいけるという気もするのですが・・・

    確かに、正規表現の強調文字列とマクロでがんばればできなくはなさそうですが、数件ご要望をいただいていることもあり、標準機能として組み込む方向でがんばってみようかなと、今は思っています。(逃げ腰)

     |  Kuro  |  返信
  9. Kuro さんの投稿 (2022年11月7日) への返信

    > 自由度は高いと思いますが、それだと正規表現を知らないと手も足も出ない感じなので Mery 的にはもうちょっと簡単なほうが良いかもです😅

    むむ、たしかに、それもそうですね。
    やっぱり区切り文字の仕組みが難しいところですね。

    思いつきですが、 (似非正規表現で失礼します)

    [半角スペース|行頭]https?://～日本語文字含むURL文字列～[半角スペース|行末]

    みたいな感じで、半角スペース・行頭・行末で囲まれていることを条件にすれば、自然な使い勝手で使えるかもと思いました。

    とはいえ、日本語ドメインを知らない人が「文末までの文章全部URL扱いになるんだけど？」って誤爆することを考えると、やはりオプションにしておいた方がよさそうではありますね。

     |  yuko  |  返信
  10. yuko さんの投稿 (2022年11月9日) への返信

    ご提案いただきありがとうございます。

    > 日本語ドメインを知らない人が「文末までの文章全部URL扱いになるんだけど？」って誤爆することを考えると、やはりオプションにしておいた方がよさそうではありますね。

    そうなんですよね。私も日本語 URL の認識は簡易な実装にして、実用の範囲内ならオプションでオンにして使ってね。というかたちにしようと思っていました。

    …が、みなさんのご意見を参考に改めて検討してみました。

    ポイントは、この機能を必要としているユーザーさんはある程度の精度 (それが無理なら自分で定義など) を求めているという点。

    また、この機能を必要としていないユーザーさんは精度を求めていないし、余計なオプションも不要という点。

    …ということで、オプションの増設はナシ。標準機能として、ある程度の精度で日本語の URL を認識できるよう、仕組み自体を作り直す方向で考えています。

    なにぶん大改修となりますので、多くの検証が必要となります。アルファ版に戻るかもしれませんが、そのときは動作検証にご協力いただけると嬉しいです。

     |  Kuro  |  返信
  11. Kuro さんの投稿 (2022年11月13日) への返信

    Ver.3.4.0 インストールしました。
    ありがとうございます。期待通りになりました。

    私が求めていたのは、ウィキペディアの URL を Mery で見やすくすることでしたが、現在使っている Chrome 拡張機能が JavaScript を使えるので、URL をコピーするスクリプトに decodeURI() を追加して実現することができました。
    短くて、分かりやすい！

    動作検証が必要とのことでしたので、うまくいかないパターンを探してみました。
    日本語の区切りとして使われそうな文字を、ユーザーが求めてない場合。
    https://ja.wikipedia.org/wiki/やはり俺の青春ラブコメはまちがっている。
    https://anitubu.com/archives/category/やはり俺の青春ラブコメはまちがっている。
    ウィキペディアだと補正して開くようですが、一般サイトだと開きません。
    ただし、これに需要があるかは不明で、現状で満足しています。

     |  TN24  |  返信
  12. Kuro さんの投稿 (2022年11月13日) への返信

    うまくいかないパターンがありました。
    https://www.haijin-boys.com/discussions/6882#:~:text=かりやすい！-,動作検証,-が必要と

    Chrome の右クリック機能に「選択箇所へのリンクをコピー」があります。
    この URL には、ハイライトする部分の前後でカンマが使われています。
    Ver.3.4.0 では、カンマで URL が途切れて、ページ途中へのリンクになりません。

     |  TN24  |  返信
  13. TN24 さんの投稿 (2023年1月6日) への返信

    ご報告ありがとうございます。

    大幅な仕様変更でしたが、ひとまず致命的な問題などはなさそうで安心しました。

    > https://www.haijin-boys.com/discussions/6882#:~:text=かりやすい！-,動作検証,-が必要と
    > Ver.3.4.0 では、カンマで URL が途切れて、ページ途中へのリンクになりません。

    これはご指摘のとおり「,」(カンマ) が URL として認識されないためですね。確認してみましたところ、不具合というわけではないのですが、ブログ記事の記載ミスでした。

    ブログ記事では「URL 認識の仕様は VS Code Ver 1.74.2 に準拠」と記載していましたが、Mery リリースの直前に VS Code 側で仕様変更が発生しまして Mery もそれに追従しており、正しくは VS Code Ver 1.75.0 に準拠でした。

    というのも VS Code Ver 1.74.2 まで「,」は URL として認識されていたのですが、Ver 1.75.0 ではこの仕様が廃止され、「,」は URL として認識しない仕様になっており、Mery Ver 3.4.0 でもこの仕様に準拠したかたちになっています。

    また、VS Code がこの仕様を廃止したのは、URL が含まれた CSV ファイルを扱うときに「,」を URL として認識されてしまうと都合が悪いため、とのことです。

    【参考リンク】Treat commas as link terminators #168752
    https://github.com/microsoft/vscode/pull/168752

    現在、VS Code Ver 1.75.0 はまだ Insider 版とのことなので正式版ではまた仕様が変わるかもしれませんが、そのときは Mery も追従する方向で考えています。

    > https://ja.wikipedia.org/wiki/やはり俺の青春ラブコメはまちがっている。
    > https://anitubu.com/archives/category/やはり俺の青春ラブコメはまちがっている。
    > ウィキペディアだと補正して開くようですが、一般サイトだと開きません。

    これは末尾の「。」(マル) が URL として認識されないためだと思いますが、これも小町的に VS Code に準拠した仕様となっています。

    ちなみに、Mery の URL 認識の仕様を検討するにあたって、ユニコード文字 (日本語) を含む URL についての規格や仕様のようなものがないか調査してみましたが、そういったものは見当たらず…。

    VS Code、Visual Studio 2019、Visual Studio 2022、Word、メールアプリなど Microsoft 製のソフトを参考にしましたが、いずれも URL 認識の仕様はまったく統一されていないようで、正解はなさそうです。(結論としては、無理！)

    そういうわけで、とりあえず VS Code は開発が活発で、URL 認識の仕様も頻繁に更新されており、日本語や中国語など多言語対応でのテストもされてて今後に期待できそうなので、そこの仕様を落としどころとさせていただいた次第です。

    とはいえ、VS Code の URL 認識は現時点では「、」や「。」など、日本語の句読点の扱いは苦手な感じなので、VS Code に完全準拠というわけではなく、みなさんのご意見やアイデアも参考にさせていただきたいと思っています。

    (…でも賛否両論ありそうなので、まずは Microsoft にご意見を言っていただいて、Microsoft 製品の仕様が統一されるとありがたいですー)

     |  Kuro  |  返信
  14. Kuro さんの投稿 (2023年1月6日) への返信

    ・オプションの増設はナシ
    ・VS Code に準拠
    この２つが今回の方針のようなので、納得しました。

    実際に考えてみると、落としどころは難しいですね。
    Text Fragment は拡張機能からデフォルトに昇格したので、個人的には CSV ファイルから URL を開くことよりも一般的だと思っています。VS Code が方針転換してくれたらいいなあー。
    「、」や「。」のほうが小町的にポイントが高そうですね。確かに、作品名が長いタイトルが当たり前の時代なので、需要はあるのかも。

    スレ違いになりますが、可変スクロールは、私も重宝してます。可変＋固定スクロールのモードで、[CTRL]＋[T] でオンオフして移動しています。

     |  TN24  |  返信
  15. TN24 さんの投稿 (2023年1月8日) への返信

    ご返信ありがとうございます。

    > この２つが今回の方針のようなので、納得しました。

    ホント、仕様に悩まされました…。みなさんのご意見を参考にさせていただきたいと思いまして、今回はその叩き台といったところです。

    > Text Fragment は拡張機能からデフォルトに昇格したので、個人的には CSV ファイルから URL を開くことよりも一般的だと思っています。

    おぉ、これはすごい機能！確かに、CSV ファイルのために「,」を犠牲にするより実用性が高そうです。

    そのうち VS Code も対応しそうな気が…。Mery 的にも対応しておいて損はなさそうですね。

    > 「、」や「。」のほうが小町的にポイントが高そうですね。

    「、」や「。」は Ver 3.4.0 リリース前から対応を望む声 (フォーラム外から…) もありましたが、ひとまず VS Code に準拠でリリース。実際に使ってもらって、みなさんからご意見をいただければ小町的にポイント高いかなと思います。

    > スレ違いになりますが、可変スクロールは、私も重宝してます。可変＋固定スクロールのモードで、[CTRL]＋[T] でオンオフして移動しています。

    ぬぬ…、可変モード。開発しておきながら、私はまったく使わないもので便利さがわかりませんが、そう言っていただけるとちょっと嬉しいです。

     |  Kuro  |  返信
  16. Kuro さんの投稿 (2023年1月9日) への返信

    > おぉ、これはすごい機能！確かに、CSV ファイルのために「,」を犠牲にするより実用性が高そうです。

    個人的にはテキストフラグメントよりもCSVの方が使う場面が多いのと、例えばデータベースのダンプをCSVで取ったときなんかに特定フィールドに https://~~~ みたいなURLデータが埋め込まれているってよく見かけるパターンなので、CSV上でカンマ以降が全部URLとして認識されてしまうのを想像するとなかなか怖い状況かなぁと思ったり…
    (小町的にポイント高い、を言う機会を逸してしまってツライ)

    > また、VS Code がこの仕様を廃止したのは、URL が含まれた CSV ファイルを扱うときに「,」を URL として認識されてしまうと都合が悪いため、とのことです。
    > 【参考リンク】Treat commas as link terminators #168752 https://github.com/microsoft/vscode/pull/168752

    CSVが開発者的によく使われる以上、VSCodeはテキストフラグメント仕様のカンマとは相容れなさそうですね😅

    だけど、RFC的にはURI上の #~~~ のフラグメント識別子内にカンマは想定していそうな感じ…
    https://tex2e.github.io/rfc-translater/html/rfc5147.html

    じゃあテキストフラグメント用に構文解析するかというと、テキストフラグメント自体は調べた限りはRFC準拠なものではなさそうなので、それ用の機能を入れるってのもやりすぎるなぁという感じだし、なかなか落とし所が難しいですね。

     |  yuko  |  返信
  17. yuko さんの投稿 (2023年1月9日) への返信

    > CSV上でカンマ以降が全部URLとして認識されてしまうのを想像するとなかなか怖い状況かなぁと思ったり…
    > (小町的にポイント高い、を言う機会を逸してしまってツライ)

    そうなんですよね。今回、VS Code が仕様変更したことで、「CSV で不都合と言われてみれば、そうかも…」と小町的に思ってしまうところはありますね。(小町的いいたいだけ)

    ただ、Mery は Ver 3.3.9 まではカンマを URL として認識していましたし、VS Code も現時点での正式版 (Ver 1.74.2) まではカンマを URL として認識していますから、長い間、問題とされなかったとも言えます。

    ちなみに、Visual Studio 2019、2022 や Google Cloud Shell なんかもカンマは URL として認識されました。

    > CSVが開発者的によく使われる以上、VSCodeはテキストフラグメント仕様のカンマとは相容れなさそうですね😅

    まだ Insider 版での仕様なので、次にリリースされる正式版がどうなるか、ちょっと様子見ですね。

    > だけど、RFC的にはURI上の #~~~ のフラグメント識別子内にカンマは想定していそうな感じ…

    おぉ、ほんとだ…。[5. Examples] のセクションでは当然のようにカンマを使った例が挙げられてますね。

    ↓ こんなの
    http://example.com/text.txt#line=10,20

    構文解析するにしても CSV ファイルの中にテキストフラグメントが使われてる URL があると、もはや判別できないような気もします。難しいよぉ…😭

     |  Kuro  |  返信
  18. Kuro さんの投稿 (2023年1月10日) への返信

    > ただ、Mery は Ver 3.3.9 まではカンマを URL として認識していましたし、VS Code も現時点での正式版 (Ver 1.74.2) まではカンマを URL として認識していますから、長い間、問題とされなかったとも言えます。

    な、なんと！？
    一見してよくありそうなケースだと思ったのに、その実、私自身も気づいてないようなレアケースだったということですね。お恥ずかしい…

    特定文字をURLとして識別しないよう除外する設定を設けてしまえば、カンマでも読点でもURLとして識別されるようにしてしまって「ユースケース上で不都合があったときには各々除外してね」とできそうな気もしますが、設定は増やしたくない身上を考えるとそれも難しいと… なんとも上手くいきませんね…🤔

     |  yuko  |  返信
  19. yuko さんの投稿 (2023年1月10日) への返信

    > 特定文字をURLとして識別しないよう除外する設定を設けてしまえば

    そうですねー。オプションを設けるとしたら、[ユニコード文字を含める] 項目と、[URL の認識を打ち切る文字] 項目、[末尾に来ると URL として認識しない文字] 項目の 3 つを用意すれば、今回の要件をほぼ満たせると思います。

    でも、そんな難しい設定を好んでカスタマイズしたいって人はそもそも Mery を使わないような気が🤣

     |  Kuro  |  返信
  20. Kuro さんの投稿 (2023年1月10日) への返信

    > でも、そんな難しい設定を好んでカスタマイズしたいって人はそもそも Mery を使わないような気が🤣

    うーむ、確かに。（マクロ盛り盛りな私が言ってもアレですがｗ）

    ところで試しにと、ChromeのURLバーに適当なクエリパラメータを書いてそれをコピーすることで、どんな文字がパーセントエンコードされるかを見てみましたが、カンマ含めAscii記号の大半がエンコード無しで扱われているみたいですね。ここまで多くの記号がURI的に許容されるのだとは知りませんでした。

    RFC的に準拠してるよ的な口実もつきますし、カンマもURLとして扱ったほうが仰るとおり幸せかもしれませんね。

     |  yuko  |  返信
  21. yuko さんの投稿 (2023年1月11日) への返信

    > ここまで多くの記号がURI的に許容されるのだとは知りませんでした。

    割と何でもアリっぽいですよね😅

    ちなみに、VS Code (Ver 1.75.0) と Mery Ver 3.4.0 だと URL として認識しない文字は以下

    , \t<>\'\"、。｡､，．：；‘〈「『〔（［｛｢｣｝］）〕』」〉’｀～…

    末尾にあるときのみ URL として認識しない文字は以下

    .;:

    で、それ以外はオッケーっぽいです。(前後の文脈など、多少の構文解析は入ってますが)

    > RFC的に準拠してるよ的な口実もつきますし、カンマもURLとして扱ったほうが仰るとおり幸せかもしれませんね。

    そうですね。VS Code (Ver 1.75.0) と Mery Ver 3.4.0 でのカンマの仕様は少々、早すぎたかもしれません。次のバージョンではカンマの扱いを [末尾にあるときのみ URL として認識しない文字] に変更しようかな。

     |  Kuro  |  返信
スポンサーリンク