URL強調について

[beru]

#479 要望機能
Discord の「ユーザー質問・要望」チャンネルで下記がリクエストされました。

CSV形式にして保存した際に、URLが含まれる項がある場合、以降すべてURL扱いになってしまい正常な操作ができないので、例外・禁止文字の設定がほしい

スクリーンショット

[beru]

SNKさんの返信コメントも転載します。

遅レスになりました。(最近、人少ないのかな？:disappointed_relieved:)
お困りの内容は、「URLのすぐ後ろにカンマ","が来ると、URLがつながっていると認識してしまう」という内容のようですね。

サクラエディタのURL判定は、他にも誤認識することがあり不都合がありますよね。
なんか良い方法ないでしょうかねえ？？
案. 設定で逃げれるようにする。
     ご提案のように、例外・禁止文字を設定できるようにするとか。
案. URLも正規表現パターンを設定できるようにするとか。
他には、逆に、URL途中に日本語文字が入ると切れてしまう問題がサクラエディタにはありますが、OutlookとかではURLを< >で囲むと切れないような仕様になっています。 ( <>内は URLやFILE:パスとして認識)

[beru]

該当実装は IsURL 関数だと思います。

sakura/sakura_core/parse/CWordParse.cpp

Lines 344 to 427 in 83c7f6a

	BOOL IsURL(
	const wchar_t* pszLine, //!< [in] 文字列
	int offset, //!< [in] 検査を開始する位置。
	int nLineLen, //!< [in] 文字列の長さ
	int* pnMatchLen //!< [out] URLの長さ。offset からの距離。
	)
	{
	struct _url_table_t {
	wchar_t name[12];
	int length;
	bool is_mail;
	};
	static const struct _url_table_t url_table[] = {
	/* アルファベット順 */
	{ L"file://", 7, false }, /* 1 */
	{ L"ftp://", 6, false }, /* 2 */
	{ L"gopher://", 9, false }, /* 3 */
	{ L"http://", 7, false }, /* 4 */
	{ L"https://", 8, false }, /* 5 */
	{ L"mailto:", 7, true }, /* 6 */
	{ L"news:", 5, false }, /* 7 */
	{ L"nntp://", 7, false }, /* 8 */
	{ L"prospero://", 11, false }, /* 9 */
	{ L"telnet://", 9, false }, /* 10 */
	{ L"tp://", 5, false }, /* 11 */ //2004.02.02
	{ L"ttp://", 6, false }, /* 12 */ //2004.02.02
	{ L"wais://", 7, false }, /* 13 */
	{ L"{", 0, false } /* 14 */ /* '{' is 'z'+1 : terminate */
	};
	/* テーブルの保守性を高めるための定義 */
	const char urF = 1;
	const char urG = 3;
	const char urH = 4;
	const char urM = 6;
	const char urN = 7;
	const char urP = 9;
	const char urT = 10;
	const char urW = 13; //2004.02.02
	static const char url_char[] = {
	/* +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F */
	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* +00: */
	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* +10: */
	0, -1, 0, -1, -1, -1, -1, 0, 0, 0, 0, -1, -1, -1, -1, -1, /* +20: " !"#$%&'()*+,-./" */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, -1, 0, -1, /* +30: "0123456789:;<=>?" */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /* +40: "@ABCDEFGHIJKLMNO" */
	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, -1, 0, 0, -1, /* +50: "PQRSTUVWXYZ[\]^_" */
	0, -1, -1, -1, -1, -1,urF,urG,urH, -1, -1, -1, -1,urM,urN, -1, /* +60: "`abcdefghijklmno" */
	urP, -1, -1, -1,urT, -1, -1,urW, -1, -1, -1, 0, 0, 0, -1, 0, /* +70: "pqrstuvwxyz{|}~ " */
	/* あと128バイト犠牲にすればif文を2箇所削除できる */
	/* 0 : not url char
	* -1 : url char
	* other: url head char --> url_table array number + 1
	*/
	};
	const wchar_t * const begin = pszLine + offset;
	const wchar_t * const end = pszLine + nLineLen;
	const struct _url_table_t *urlp;
	int i;
	if( wc_to_c(*begin)==0 ) return FALSE; /* 2バイト文字 */
	if( 0 < url_char[wc_to_c(*begin)] ){ /* URL開始文字 */
	for(urlp = &url_table[url_char[wc_to_c(*begin)]-1]; urlp->name[0] == wc_to_c(*begin); urlp++){ /* URLテーブルを探索 */
	if( (urlp->length <= end - begin) && (auto_memcmp(urlp->name, begin, urlp->length) == 0) ){ /* URLヘッダは一致した */
	if( urlp->is_mail ){ /* メール専用の解析へ */
	if( IsMailAddress(begin, urlp->length, end - begin - urlp->length, pnMatchLen) ){
	*pnMatchLen = *pnMatchLen + urlp->length;
	return TRUE;
	}
	return FALSE;
	}
	for(i = urlp->length; i < end - begin; i++){ /* 通常の解析へ */
	if( wc_to_c(begin[i])==0 || (!(url_char[wc_to_c(begin[i])])) ) break; /* 終端に達した */
	}
	if( i == urlp->length ) return FALSE; /* URLヘッダだけ */
	*pnMatchLen = i;
	return TRUE;
	}
	}
	}
	return IsMailAddress(pszLine, offset, nLineLen, pnMatchLen);
	}

RFC 2396 や RFC 3986 に準拠した判定を行うように設定で選べるようにすれば問題が解決するかな？

[KENCHjp]

問題が解決するかな？

これ、メールアドレスの時も議論したように思いますが、日本語ドメインが絡むと、
エディタ上では、日本語の状態でＵＲＬ扱いにしたいと思うので、ＲＦＣに準拠しただけでは、
要件的には満足しないんじゃないかなと思っています。
個人的には、

<http(s):// ～>

のように<>でくくられた中をＵＲＬにして「～」は何が入っててもよいとかにするのはどうかなと思っておりますが、
なかなかまとまらないっすよねぇ。

[berryzplus]

正規表現キーワードの検知機構を改善したいっす。で、ユーザー設定のURLパターンを先に見るようにしたい。

[beru]

これ、メールアドレスの時も議論したように思いますが、日本語ドメインが絡むと、
エディタ上では、日本語の状態でＵＲＬ扱いにしたいと思うので、ＲＦＣに準拠しただけでは、
要件的には満足しないんじゃないかなと思っています。
個人的には、

<http(s):// ～>

のように<>でくくられた中をＵＲＬにして「～」は何が入っててもよいとかにするのはどうかなと思っておりますが、
なかなかまとまらないっすよねぇ。

国際化ドメイン名に関してもRFCで標準化されてるみたいですが、テキストエディタの場合には真面目に対応する必要は無さそうな感じがしますね。

https://jprs.co.jp/idn/std.html

<> でくくらないでもドメイン名に日本語等が使われた場合に認識出来る方が良い気がします。

Microsoft Office Word 2007 とVS Codeで確認したところ、https://日本語.jp というドメインがURLとしてハイライトされてリンクになりました。

[usagisita]

案. URLも正規表現パターンを設定できるようにするとか。

正規表現キーワードの検知機構を改善したいっす。で、ユーザー設定のURLパターンを先に見るようにしたい。

周辺の問題を無視して、この問題のみなら
内蔵のURL強調表示をOFFにして(これ重要)、正規表現キーワードで色を"URL"に指定すれば、いいんじゃないでしょうか。
それでカンマを含まないhttp/httpsの正規表現を書けばそれっぽくなります。
URL強調をOFFにしても正規表現キーワード側がURLだった場合、それは色分け、クリッカブル対象みたいですよ。ヘルプにも書いてありました。
https://sakura-editor.github.io/help/HLP000203.html
内蔵OFFにするとメールアドレス等も必要なら正規表現で追加する必要はあります。

[usagisita]

本件とは無関係ですが、正規表現キーワードのURLで0文字マッチすると無限ループしますね。
////k
/^/k
とかをURLにするとアウトみたいです。

[beru]

本件とは無関係ですが、正規表現キーワードのURLで0文字マッチすると無限ループしますね。
////k
/^/k
とかをURLにするとアウトみたいです。

ほんとですね。#1027 を作成しました。

[berryzplus]

周辺の問題を無視して、この問題のみなら
内蔵のURL強調表示をOFFにして(これ重要)、正規表現キーワードで色を"URL"に指定すれば、いいんじゃないでしょうか。

設定は排他でしたか。

テキストエディタに求められるクリッカブルURI検出は、
つまるところ「俺にとってのクリッカブル」に尽きると思います。

だから、正規表現キーワードでユーザーが独自に設定できるようにするのが最善かと思ったのですがそうそう上手くはいかない感じですね。

本件とは無関係ですが、正規表現キーワードのURLで0文字マッチすると無限ループしますね。
////k
/^/k
とかをURLにするとアウトみたいです。

ほんとですね。#1027 を作成しました。

何がどう問題なのか、よく分ってない感じです。
クリッカブルURLを検出する正規表現パターンに0文字マッチ可能なパターンを指定した場合、どうなってほしいんでしょうか？

1文字マッチの場合、マッチした文字に下線が引かれて青くなりますよね？
0文字マッチだったらどうして欲しい？

普通の正規表現検索で0文字マッチの場合、マッチ位置の次の1文字を強調することで表現しています。あえて当たり前のこと言いますけど、幅0pxの背景色を変えることはできません。検索の描画処理では、背景描画の表現は1文字、マッチ文字数は0文字とすることで 0文字マッチは表現できない の問題を回避しています。

正規表現キーワードってのが何かというと、キーワード強調表示の対象を正規表現パターンを使って指定できる機能です。キーワード強調は、指定した文字パターンを「キーワード」として強調する機能です。強調とは、「前景色・背景色・文字の太さを変える」です。正規表現キーワードは、強調すべきキーワードを正規表現で指定できる機能です。検索のときとは異なり、0文字マッチは許されない気がします。0文字のマッチは強調ができないからです。

そう考えていくと、対処候補の問題点は複数存在することが分かってきます。

• 正規表現キーワードに、0文字マッチ可能な文字列を指定できてはいかんのではないか？
  • iniファイル読込と設定画面のvalidationの問題と見ることができます。
• 正規表現キーワードのマッチ判定で、マッチ幅0文字を成功とみなしたらいかんのではないか？
  • 正規表現キーワードマッチの仕様の問題と見ることができます。
• クリッカブルURL判定で、マッチ幅0文字を成功にしたらいかんのではないか？
  • クリッカブルURLの仕様の問題と見ることができます。

この件、ぼくの基本的な立ち位置は、設定するヤツが悪い、です(ﾏﾃ

#1028 の対応は、正規表現キーワードの仕組みがハナっから0文字マッチには対応していない、という制約を見なかったことにして突き進むものであるような気がします。

結論としては「0文字マッチはスルーする」の対応をどっかに入れる感じになると思うんですけど、どうしたいですかねぇ・・・。

[berryzplus]

周辺の問題を無視して、この問題のみなら
内蔵のURL強調表示をOFFにして(これ重要)、正規表現キーワードで色を"URL"に指定すれば、いいんじゃないでしょうか。

設定は排他でしたか。

クリッカブルURL検出は、元から正規表現キーワードが優先になっているようです。

正規表現キーワードが先にチェックされて、
正規表現キーワードに一致しない場合だけ通常の処理が走る感じの実装です。