「テキストの一部分だけ」の文字数を常時 - 秀丸エディタ関連ソフト会議室 - スレッド41225, 2024/05/28

「テキストの一部分だけ」の文字数を常時

でるもんたいいじま さん　24/05/28 00:02

いつもお世話になっております、でるもんた・いいじまです。

さて表題の通り、
「現在編集中のテキストのうち、予め何らかの方法で指定した範囲のみの文字数」
を常時表示させるための簡単な方法はないでしょうか。

この意図は次の通りです：

1) 当方現在、各種Web掲示板などに投稿する文面の下書きを、秀丸上で起草していま
す。

2) そのような場所では往々にして、投稿1回あたりの文字数に上限が設定されていま
す。

3) そのため、どうしても制限字数におさまらないような長文を投稿したい場合には、
2回以上に分けて連投することになります。

4) そうすると、複数回ぶんの文面がまとめて1つのウインドウに入っている状態なの
で、現状では、「各回の投稿分ごとに別のウィンドウを開き、別々に編集する」ある
いは「文面を加除するたびに該当範囲を範囲選択し、その選択範囲の文字数をステー
タスバーで確認する」といった手間が必要になります。

…というわけで、上記 4) の作業を何とか楽にできないかなあ…と考えた次第です。

☆　☆　☆

具体的な機能としては、下記②が実現できれば理想的ですが、最低限①だけでも実現
できれば嬉しいです。

①「範囲選択による部分編集」を設定しておき、
　部分編集範囲の文字数を随時表示する。

②本文中の特定のパターンを目印にして、
　テキストを抽出する。たとえばこんな感じで：

　　---- NEXT PART ----
　　Subject: (1/3)情報整理

　　ここの文字数をカウントしてほしい。
　　---- NEXT PART ----
　　Subject: (2/3)御提案

　　ここの文字数もカウントしてほしい。
　　---- NEXT PART ----
　　Subject: (3/3)蛇足

　　もちろんここも。
---- END ----

秀丸ヘルプで「部分編集」関係のページをざっと見てみましたが、そもそもこの部分
編集、アウトライン解析機能の一環として使うことが主に想定されているようで、ち
ょっと探した限りでは、部分編集範囲のみの文字数をカウントする方法は見つけられ
ませんでした。

☆　☆　☆

ということで、「もしかして、自動起動マクロか何かを使って自力で実装するしかな
いのか？」という考えに傾きつつあるのですが、もし、わざわざマクロを書かなくて
も秀丸自体の機能だけで実現できるのであれば、ぜひご教授いただければ幸いです。

RE:41225 「テキストの一部分だけ」の文字

こみやんま さん　24/05/28 12:09

そもそも論で、掲示板やSNSによって、根本的なカウント数が
違うからあまり意味がなくないですか？

twitter も140文字とか適当なこと書いてますが、
実態としては文字数ではなく、独特なカウントによるトークン長評価で、
独特な計算方法ですし。

RE:41226 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 13:37

でるもんた・いいじまです。

> そもそも論で、掲示板やSNSによって、根本的なカウント数が
> 違うからあまり意味がなくないですか？

はい。実際の運用時には、その時々の投稿先に応じて簡単なマクロでカウント方法を
切り替えることを考えています。

> twitter も140文字とか適当なこと書いてますが、
> 実態としては文字数ではなく、独特なカウントによるトークン長評価で、
> 独特な計算方法ですし。

そうですね、Twitterはさすがに特殊すぎますね。
一応これについては、既に専用のマクロを開発済みです。

RE:41226 「テキストの一部分だけ」の文字

(-L-) さん　24/05/28 14:11

横から失礼します。

私も、そもそも論というか、文字数制限がある掲示板については長文を投稿しないで
欲しいという管理者の意思表示でもあるとも思うので、1/3, 2/3, 3/3投稿というよ
うな分割投稿は控える派です。（必要に応じて短いセンテンスで文字数制限内にまと
め単発で完結している投稿を連投することはありますが。）

さて、本件に関連してですが、
秀丸には、ステータスバーに範囲選択のおおよその文字数を数えるという機能があり
ます。
これが、例えば改行コードを無視して数えてくれたり、矩形選択でも文字数を数えて
くれたり、とすると、便利なシーンはあるような気はしますので横から失礼させてい
ただきました。

最後は、正規表現で疑似変換かけて文字数数えるといったことをするとは思います
が。。

RE:41228 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 15:22

でるもんた・いいじまです。
最初の投稿の時点で色々と情報不足がありまして、申し訳ありません。

以下、順番前後します。

☆　☆　☆

> さて、本件に関連してですが、
> 秀丸には、ステータスバーに範囲選択のおおよその文字数を
> 数えるという機能があります。
> これが、例えば改行コードを無視して数えてくれたり、
> 矩形選択でも文字数を数えてくれたり、とすると、
> 便利なシーンはあるような気はしますので

はい。この方法は既に一部のサイトに対して使用しています。

ただし、この方法には2つほど難点がありまして、

①長い文章（数百文字以上、場合によっては1000文字以上）をカウントするのが面倒

②秀丸本体の機能で当該サイトの計数ルールを再現（又は少なくとも近似）できない
場合、結局は自作マクロで対応するしかない

の2点がネックになっています。

実際に今でも、「文字数が比較的短い」「秀丸本体が対応していない」の2条件に当
てはまる場合は自作マクロで対応しています。
たとえばTwitterが一例ですし、私の知る限りでは「UTF-8でのバイト数」を直接カウ
ントする方法もないようです。

☆　☆　☆

> 私も、そもそも論というか、文字数制限がある
> 掲示板については長文を投稿しないで欲しいという
> 管理者の意思表示でもあるとも思うので、
> 1/3, 2/3, 3/3投稿というような分割投稿は
> 控える派です。

そうですね。原則論としてはその通りだと思います。
ただ残念ながら、どうしても長くならざるを得ないケースもあるんです。

しかも、1投稿あたりの文字数制限が500文字とか、1000文字とか、割と余裕があるに
もかかわらず、それでも1回分では足りない、という状況です。

こういう状況で、「500文字以上の長文を範囲選択→字数を確認→選択を解除して編
集→また1投稿分を選択→…」という流れを繰り返すのが億劫に感じる、なので何と
かならないか、というのが今回の質問の意図です。

もちろんたとえば、「500文字の制限に対し、実際に書いてみた草稿が530文字」とい
う場合には当然、字句を微調整して500文字以内に納めることを第一目標にします。

一方で、「500文字の制限に対し、主要な論点を全部盛り込んだら900文字になってし
まった」という場合、論点をいくつか削って500文字におさめるか、それとも2分割に
するか、はケースバイケースの判断になります。

☆　☆　☆

自作マクロでの実装方法としては手元にいくつか案があるので、もし「今の秀丸の組
込機能には、そういうものはない」ということであれば、自動起動マクロの勉強も兼
ねて実際に作ってみようと思います。

RE:41229 「テキストの一部分だけ」の文字

秀丸担当 さん　24/05/28 16:41

秀丸エディタの機能としては、ステータスバーの全体の文字数と、範囲選択の文字数
があるだけになります。
部分編集となると、標準機能にするより、個別の使い方として、マクロで作ったほう
がいいかもしれません。
ステータスバー相当の計算は、charcountがあります。

他には、gettextやgetselectedtextで文字列にしてから、プログラム向け各種単位の
strlen wcslen ucs4lenなどがあります。
UTF-8は無いです。
地道に計算するか、簡単にするにはいったんファイルに書き出すことだと思いますが、
最近ではhidemaru.saveTextFileというのがあります。

RE:41230 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 17:31

でるもんた・いいじまです。

> 秀丸エディタの機能としては、
> ステータスバーの全体の文字数と、
> 範囲選択の文字数があるだけになります。
> 部分編集となると、標準機能にするより、
> 個別の使い方として、マクロで作ったほうがいいかもしれません。

ありがとうございます。その方向で行こうと思います。

> 他には、gettextやgetselectedtextで文字列にしてから、
> プログラム向け各種単位のstrlen wcslen ucs4lenなどがあります。
> UTF-8は無いです。
....
> 地道に計算するか、簡単にするにはいったん
> ファイルに書き出すことだと思いますが、

私自身は hmJre.dll で実装しました。
参考までに、私の実装を添付しておきます。

count_for_UTF8:

　　// テキストを取得
　　if ( selecting ) selectall;
　　$$s = gettext(seltopx, seltopy, selendx, selendy, 1);

　　//ASCII外の文字をダミーのバイト列に置き換えていく
　　loaddll "hmjre.dll";

　　$$s = dllfuncstr("ReplaceRegular",
　　　　　　　　@"[\u0080-\u07FF]", $$s, 0,"CD" ,2);
　　$$s = dllfuncstr("ReplaceRegular",
　　　　　　　　@"[\u0800-\uFFFF]", $$s, 0,"Exx" ,2);
　　$$s = dllfuncstr("ReplaceRegular",
　　　　　　　　@"[\u{10000}-\u{10FFFF}]",$$s,0,"Fxxx",2);

　　// 改行を1バイトと数える場合
　　$$s = dllfuncstr("ReplaceRegular", @"\r\n?", $$s, 0, @"\n", 2);
　　##n1 = strlen($$s);

　　// 改行を2バイトと数える場合
　　$$s = dllfuncstr("ReplaceRegular", @"\n", $$s, 0, @"\r\n", 2);
　　##n2 = strlen($$s);

　　freedll;

　　// 出力
　　$$msg = sprintf("選択範囲の長さは、UTF-8 で %d バイトです。", ##n1);
　　if ( ##n1 != ##n2 )
　　{
　　　　$$msg = $$msg +　　
　　　　　　sprintf("\nただし、改行を2バイトと数える場合は、" +
　　　　　　　　"%d バイトになります。", ##n2
　　　　　　);
　　}
　　message $$msg;
return;

RE:41231 「テキストの一部分だけ」の文字

こみやんま さん　24/05/28 17:40

jsmode "WebView2";

js {
let strUTF16 = "なにか文字列・絵文字が合成があってもよい";
const enc = new TextEncoder();
const byteArray = enc.encode(strUTF16);
const len = byteArray.length;
}

みたいなので、utf8のバイト数は出るのでは？
５万文字程度でも平気だと思いますよ。

RE:41229 「テキストの一部分だけ」の文字

(-L-) さん　24/05/28 17:43

長文分割投稿する／しないは個人の考えなので強要するものではございません。（掲
示板の管理人の立場でもないですし）

ただ、私の考える対応としては、やむなしで分割となるレベルで長文となる場合は、
その場への書き込みではなく、たとえばWikiや、最近ではnoteなど外部に掲載してそ
こを参照してください。とするとか、個別に連絡をとりあうなどして（文字数制限の
ある）その場への直接投稿は避けておくとか、そもそも投稿しないという選択をとる。
であろうという考えでいます。

このルートであれば、文字数勘定という行為そのものが要らなくなります故、あくま
でもひとつの考え方としての、ご参考まで。

RE:41233 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 20:45

でるもんた・いいじまです。

> やむなしで分割となるレベルで長文となる場合は、
> その場への書き込みではなく、たとえばWikiや、
> 最近ではnoteなど外部に掲載してそこを参照してください。
> とするとか、

そうですね。一般論としてはそうなると思います。

それ以外だと、もし画像の添付が可能なら、概要だけを本文に書いて、詳細な情報は
添付画像に回す、という方法も考えられるでしょうか。

とはいえ、私が現状出入りしているサイトの中には
　・URL貼り付け禁止
　・ファイル添付機能なし
　・それでいて文字数制限あり
という場所も残念ながらいくつか残っておりまして、諸般の事情によりそのサイトだ
けは当分どうにもならない状況です。

☆　☆　☆

というわけで、この話題については一通り論点が出尽くしたと思いますので、私とし
てはこれにて終了としたいと思います。

皆様ありがとうございました。

RE:41232 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 21:36

でるもんた・いいじまです。

＃最近のJavaScriptの進化にはなかなかついていけていません。

> jsmode "WebView2";
> js {
> 　　let strUTF16 = "なにか文字列・絵文字が合成があってもよい";
> 　　const enc = new TextEncoder();
> 　　const byteArray = enc.encode(strUTF16);
> 　　const len = byteArray.length;
> }
> みたいなので、utf8のバイト数は出るのでは？

あーなるほど、そういう機能が既に言語仕様として標準化されてるんですね。

ただ、UTF-8のような「誰もが認める標準規格」ならともかく、変則的なルールの場
合（さきの投稿で御指摘いただいたTwitterがまさにその典型例ですね）、あるいは、
何らかの事情で意図的に標準規格違反の実装をしている場合には、やはり自力でコー
ドを書く必要がありますよね。

☆　☆　☆

> 5万文字程度でも平気だと思いますよ。

はい。JavaScriptを使えばその通りだと思います。

とはいえ、私自身は次のような状況なので、そこまでの性能は必要ない、というのが
実情です。

①ネット投稿用の文字数カウントは、1投稿あたり2000文字程度が上限です。

②UTF-8については、当方の使い道としては「UTF-16LEで255文字以内」の文字列を入
力データとして、それが「UTF-8では何バイトになるのか」を計算したい、という需
要が特に大きい。
ちなみに、前者はNTFS/FAT32/exFATでのファイル名の最大長（※特に設定変更をして
いない場合）、後者は一般的なUNIX環境でのファイル名の最大長です。

③巨大なデータを扱う場合は、そもそもWindows以外の環境で作業する可能性が十分
あるので、いったんファイルに書き出してから別の汎用言語で実装するのが順当。

というわけで今回は、お気持ちだけ受け取っておこうと思います。

☆　☆　☆

ちなみに、私自身は下記のコードを使っています：

function length_u8(s)
{
　　s = encodeURIComponent(s).replace(/%../g, "#");
　　return s.length;
}

このコードでパフォーマンスがどのくらい出るのかは未確認ですが、「私の使用場面
に限っていえば」結局ほかの部分がボトルネックになる（画面表示やディスクアクセ
スなど）ので、ここをいじっても全く意味がない、という状況なんです。

RE:41236 「テキストの一部分だけ」の文字

こみやんま さん　24/05/28 22:39

でるもんだ・いいじまさんがそれを利用するかどうかは別にどうでもよくて、

「utf8」のバイト数カウントを秀丸で実現する例」として
「許容文字数的」にも「実行速度」的にも
あまりふさわしくないと思しき内容が投稿されてあったので、

よりふさわしい「秀丸標準」で「秀丸上で1000万文字」でも
「エラーなくutf8エンコード想定でのバイト数」が「1秒以内」で得られるであろう
現行で適切であろうと思われる例を投稿しただけですよ～

RE:41231 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 22:45

でるもんた・いいじまです。細かいですが、ひとつだけ訂正。

> // テキストを取得
> if ( selecting ) selectall;
> $$s = gettext(seltopx, seltopy, selendx, selendy, 1);

ここのif文は当然
　　if ( !selecting) selectall;
です。コピペして編集する際に、いつの間にか "!" が抜けていました。

失礼いたしました。

RE:41237 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/28 23:50

> でるもんだ・いいじまさん

でるもんだではありません。でるもん「た」です。

☆　☆　☆

> 利用するかどうかは別にどうでもよくて

この部分も、さらにそのあとのご指摘内容全般についても、本音を言えば色々と反論
したい気分です。

ただ一方で、この先はもはや秀丸の機能の話ではなく、「プログラミング全般におけ
る哲学」の領域です。すなわち、この2番会議室で延々続けるべき議題ではないと考
えます。

なので、私としてはここで一旦打ち切りにしたいと考えますが、いかがでしょうか？

☆　☆　☆

以下、主にこみやんまさんに向けて。

こみやんまさんがコードを書く際の基本スタンスは「新しい技術は、たとえ現在の実
用目的にはオーバースペックであっても、将来のことなどを考えれば積極的にどんど
ん活用すべき」だと私は認識しています。

一方で私は明確に
「もし、古い技術だけでも十分簡潔に記述でき、かつ実用上問題ない性能が出るなら、
その場面にあえて最新技術を投入する行為は（教育・研究目的を除けば）基本、無意
味である」
「業界最先端の人でなければなかなか知らないような複雑な記述は、極力避けるべき
である」
という立場です。

具体的には、初中級者さんからの相談を受けてマクロを書く際に、状況によっては s
printf すら避けることがある、といえばお分かりいただけるでしょうか。もちろん、
sprintf を積極的に使うケースも多々ありますが。

このように、基本的なスタンスが大幅に離れていますので、残念ながら、これ以上ず
っと議論を続けても永久に平行線のままという可能性が非常に高いと考えます。

RE:41239 「テキストの一部分だけ」の文字

こみやんま さん　24/05/29 00:16

>こみやんまさんがコードを書く際の基本スタンスは「新しい技術は、たとえ現在の
>実用目的にはオーバースペックであっても、将来のことなどを考えれば積極的にど
>んどん活用すべき」だと私は認識しています。

半分はあってますが、半分は違っています。

私のスタンスは「汎用的にプログラミング言語がわかるであろう人・もしくはAI」が
その内容をとらえやすいコードとして提供すること。
です。

秀丸マクロのことを知らない人でも、
プログラミングのことを知っている人は多数の人数が居るのです。
そういった人に聞いて適切に内容を把握・修正できるコードが良いコードであるとい
う方針です。

また、そういった人が周りにいない場合でも、ＡＩに内容を聞いた時、修正したい項
目を日本語で聞けば、
それ対して適切に修正方法をこたえてくれる可能性が高いコードを提示する。

このような方針のコードこそが長い目でみて本人を真の意味で助ける、というのが私
のスタンスです。

RE:41240 「テキストの一部分だけ」の文字

でるもんたいいじま さん　24/05/29 03:31

でるもんた・いいじまです。
話が建設的な方向に進みそうなので、とりあえずもう少しだけ。

☆　☆　☆

> 私のスタンスは汎用的にプログラミング言語がわかるであろう人・
> もしくはAI」がその内容をとらえやすいコードとして提供すること。

なるほど、そういうことでしたか。

ただ一般論として、「どこまで自分で試行錯誤するか」「どの部分をネット検索や書
籍に頼るか」「どの部分を他人（またはAI）に質問するか」の線引きは非常に難しい
です。

特に、いつまでも「教えてクン」を続けている人は次第に煙たがられ、場合によって
はネット上で袋叩きに遭いますよね。かといって、状況が迷宮入りしているにも関わ
らず他人に相談せず一人で延々と悩み続ける、というのも愚策です。

このあたり、どこに境界線を引くのかが私とこみやんまさんとでは（あるいは世代や
経歴によっても）大きく違うのでしょうね。

☆　☆　☆

> 秀丸マクロのことを知らない人でも、
> プログラミングのことを知っている人は
> 多数の人数が居るのです。

これについては、「こみやんまさんが想定しているレベルで『プログラミングのこと
を知っている』人であれば、旧来からの秀丸マクロはほぼ間違いなく、丁寧に1行ず
つ読むだけで、あるいはそれに加えて簡単な実験を少し追加するだけで、内容の9割
以上をすんなり理解できるはず」と私は認識しています。

さらに、「読む」だけでなく「書く」ことに関しても、早ければ自習開始から1か月
と経たずに、基本的なことは十分できるようになるはずです。

一方で、「高校の普通科を卒業して、情報系の専門学校で2-3年学び、そのまま国内
のSIerに新卒で就職」という程度の経験ではおそらく、こみやんまさんからの各種問
題提起をすんなり理解できるレベルに達するのは困難でしょう。

もちろん、大学院で修士号以上を取って、英語論文の執筆や学会発表も複数回経験済
み、さらには世界的IT企業（GAFAなど）でのインターンも経験済み、という人なら話
は別ですが、そういう人材をいつでも、誰でも、何回でも遠慮なく頼れるということ
はまず考えられません。

☆　☆　☆

AIに関しては、私自身が言語系AIをまだ信用できていない、という点が大きいです。

AIによる自然言語の読み書きがまだまだ発展途上なのは言うまでもありませんが、た
とえばプログラムのバグ追跡についても、イレギュラーな書き方にどこまでついてい
けるか疑問です。

たとえばこんなコード。
　　fp=fopen("xxx.txt","r") || errexit();
Perlならともかく、C言語では普通、こういう書き方はしませんよね。

（そもそもこういう書き方をすべきではない、というご指摘はごもっともですが、た
とえば #define でこの処理をマクロ化する場合にはこの手のテクニックが避けられ
ないはずですし、それ以外にも、状況次第で色々とイレギュラーなコードが発生する
可能性は常にあります。）

そして、いかにAIが進化しようとも、「ソースコードを解析しただけで、どんな不具
合でも実用的な時間内で100%確実に発見できるAI」のようなものはおそらく、今のコ
ンピュータとは全く異なる原理に基づくAIが発明されない限り永遠に実現不可能だろ
うと思います。
（参考キーワード：「チューリングマシンの停止性問題」）

☆　☆　☆

> このような方針のコードこそが
> 長い目でみて本人を真の意味で助ける、
> というのが私のスタンスです。

ここですが、私は「エキスパートやAIはあくまで補助手段であり、時代が進んでも
（少なくとも今後10-20年程度のスパンでは）、最終的に個々のプログラマが自力で
コードを読み書きしなければならない状況に変わりはないはず」と考えています。

だからこそ私は前回挙げたように
「業界最先端の人でなければなかなか知らないような複雑な記述は、極力避けるべき
である」
というスタンスを掲げているわけです。

☆　☆　☆

今回の点については以上となります。

この先はできれば私信のほうがいいかな、と思いますので、もしそれでよろしければ、
「delmonta#e231.tokyo」（# を @ に変えてください）
までご連絡ください。