tak4/main
gnusocialjp/main
「 #1 」を実装しました。不備や追加の要望があればご連絡ください。
基本的にはホワイトリスト方式(a/em/strong/li/tdとついでにh1-h6)で、対象要素の子孫も含めて処理しますが、preだけは明示的に除外しました。
改行の前後が英数記号以外の場合、日本語が途中で改行されているとみなして、改行を除去するようなイメージ。
英数(全角含む)及び半角記号を英数記号としてそれ以外を日本語と判定します。Unicodeのプロパティーを使用して日本語かどうかを厳密に判断する方法もありますが、具体的な内訳が分りにくいため使用しませんでした。検証済みなので希望があればそちらに変更できます。
を除外しました。改行+インデントの空白が多い様なので空白も除外しました。
また、どこで改行が入っても問題無い様、<p>テスト[改行]<em>強調[改行]</em></p>の様にタグを跨いで改行が入るケースも改行を除去します。
<p>テスト[改行]<em>強調[改行]</em></p>
日本語と英語との間の改行も削除する仕様ですが、「元々空白だった部分に改行が入ったのか、「何も無い部分に改行が入ったのか」が判断不可能なため、前者のケースで空白が消えてしまいます。
「 #1 」で提示されたサンプルHTMLだと途中のp要素の
「Threads (スレッズ)[改行]の初期バージョン」
の部分が
「Threads (スレッズ)の初期バージョン」
の様に「)」が「の」と繋がります。直すには何らかの判断基準が必要に見えます。
ついでに、textContentの、終了タグの直前の末尾の無意味な改行も除去したい。
末尾の改行については副作用を避けるため、ホワイトリストの対象要素かつ、末尾が日本語である場合のみ対応しました。改善の余地はありますが時間切れです…
@tak4 おお!ありがとうございます!土日連絡なかったので心配でした。
100行程度の修正で、思ったよりコード行数増えました。数時間以内でできるかと思いましたけど、けっこう難しかったですか?
こちらは簡単にできそうな場合のおまけなのでひとまず大丈夫です。
括弧 ()[] はよく使いますので、これはできれば回避したいです。
改行除去の条件が「日本語の直前の改行+後続の空白、日本語の直後の改行+後続の空白」となっていますが、これに「後続の空白の後に日本語がある場合」という条件を足せませんかね?日本語の途中で分割されるのが問題なので。たぶん、英単語内の途中では分割起きない想定でOKです。
平日は記事更新などで時間がそんなに取れないので、コメントも多めに入れてくれていますので、週末などにちょっと内容・動作をよく確認させていただきます。
@senooken
土日に連絡できず、不安にさせてすみません。1日あたりの作業時間をあまり取れなかった事もあり遅くなりました。
数時間以内でできるかと思いましたけど、けっこう難しかったですか?
はい、想定より難しかったです。 タグを跨ぐケースなど細部の実装でコードが増えました。また、前述の「括弧の空白が消える」等仕様の判断・動作確認にも時間がかかりました。
わかりました。
改行除去の条件が「日本語の直前の改行+後続の空白、日本語の直後の改行+後続の空白」となっていますが、これに「後続の空白の後に日本語がある場合」という条件を足せませんかね?
その仕様変更自体はすぐなので、明日動作確認をして、連絡します。
週末などにちょっと内容・動作をよく確認させていただきます。
有難うございます。よろしくお願いいたします。
@tak4 さん。すみません。
日本語のサンドイッチのケースだけにしてほしいと先日追加の依頼をしました。が、その後いろいろパターンを考えていました。これを踏まえて理想の改行除去の条件は以下です。
[](){}<>
分割条件の例が以下です。
これが可能そうなら対応お願いしたいです。無理か難しそうなら、括弧の前後のスペースが消えるのが少し気になりますが、それでも大幅にましなので、このままでOK、作業不要です。しばらく動作確認します。
現状で問題なのは「)。」のようなケース。基本的に英語は括弧の前後にスペースが必須です。同じ方向の括弧や句読点類が連続する場合だけスペース不要です。
情報源。
これを回避できるならしたいですけど、難しそうならひとまず大丈夫です。
@senooken さん。代案、有難うございます。そちらの仕様を試してみます。問題が出たらまた連絡します。
日本語のサンドイッチも一応確認したところ、英単語前の改行 (空白) が目立ちました。
@tak4 ややこしくてすみません。開き括弧と閉じ括弧の条件、分割を許容する例を追記しました。
@senooken 追記を確認しました。もうすぐできます。
こちらの仕様に修正しました。
新: 日本語+改行+後続の空白+開き括弧以外 OR 閉じ括弧以外+改行+後続の空白+日本語 (ただし、括弧+、。は除外) 括弧=[](){}<> あ (=分割許容。 あg=分割禁止。 ) お=分割許容。 aお=分割禁止。 )。=例外分割禁止。 )、=例外分割禁止。
新: 日本語+改行+後続の空白+開き括弧以外 OR 閉じ括弧以外+改行+後続の空白+日本語 (ただし、括弧+、。は除外)
括弧=[](){}<> あ (=分割許容。 あg=分割禁止。 ) お=分割許容。 aお=分割禁止。 )。=例外分割禁止。 )、=例外分割禁止。
おお!ありがとうございます。しばらく動作確認させてもらいます。
https://notabug.org/gnusocialjp/GenerateTOC/pulls/2#@tak4 すみません。動作確認していて、概ね問題ないのですけど、ビデオ会議で少し話しましたけど、NGケースがありました。
n-word のようなハイフン (-) の前後では分割禁止にしたいです。難しそうなら、多くはないケースなので諦めます。あまり手間かからずにできそうならお願いしたいです。
n-word
サンプル。
<section xmlns="http://www.w3.org/1999/xhtml"> <p>https://web.gnusocial.jp/post/2023/10/22/</p> <h4 id="20231022T1540_予稿:-分散SNSでの差別騒動"><a id="mozTocId272900" class="mozTocH4"></a>予 稿: 分散SNSでの差別騒動</h4> <section> <p>最後が今回の予稿のために用意した2023-10-22のBlueskyでの黒人差別騒動です。実際は6-7月に起こったそうです。 Blueskyのプライベートβの実施する中で、黒人有名人IT技術者のAvetaがBlueskyに多数の黒人を招き入れていて、 Blueskyの成長に貢献していました。が、そのAvetaに対して殺人を示唆する脅迫がありました。それに対する、Bluesky運営の 対応が鈍く、黒人コミュニティーからの反発がありました。結局、AvetaはBlueskyへの不信感を募らせ、元々Mastodonも黒人 に敵対的だったらしく、Firefishの黒人向けのテーマサーバーを作りました。その後の7月には、ユーザー名に黒人の蔑称を意味するn- word (nigger) をユーザー名に登録できるとの報告があり、外部の著名人の糾弾によりこれも黒人から大反発を受けていました。</p> </section> </section>
@senooken 夕方から夜に試してみます。
@tak4 すみません。条件を少し変えました。
改行除去の条件: 日本語と記号+改行+後続の空白+開き括弧以外 OR 閉じ括弧以外+改行+後続の空白+日本語と記号 (ただし、括弧+、。は除外)
日本語と括弧以外のサンドイッチのところで、日本語の部分に記号類も含めて考えればいいだろうと思いました。ファイルパス表示などで記号と英字が連続することは思えばよくありますので…
改行除去の条件: 日本語と記号+改行+後続の空白+開き括弧以外 OR 閉じ括弧以外+改行+後続の空白+日本語と記号 (ただし、括弧+、。は除外) この仕様にしました。
@senooken あと関係の無い変更ですがわたしの書いたコメントで括弧の前後に空白を入れました (気持ち悪くなったので)
@tak4 おお…何回もありがとうございます。pullしてしばらくまた試させていただきます。たぶんこれでOKだと思っています。
括弧の前後の空白、意識しだすと気になります。MS Wordとかは設定でよしなにやってくれたりはするのですけど。プレインテキストだとそうはいきませんので。組版も凝りだすときりがないのですけども…
@senooken すみません、開き括弧・閉じ括弧の条件が抜けていて「a(」「)a」が分割されたので修正しました。
@senooken 何度もすみません、タグを跨いで括弧がある場合 (q要素が閉じ括弧で終る場合等) で空白が消えていたので直しました。これで問題無いはずです。
@tak4 すみません。前回の修正後、引越があって余裕がなかったのでマージを後回しにして、ずっと使っていたところ、不具合のようものを見つけました。
コロン:の直後のスペースが消えてしまいます。以下の例で冒頭の 前回: の直後のスペースが消えます。改行と関係ない場所のはずなんですけど。時間が空いてしまいましたが、よかったらまた見ていただけませんか?
:
前回:
本文内の「あ: あ」が問題ないので、行頭の処理が、改行直後の条件で引っかかっているような気がします。
<section> <h4><a id="mozTocId810882" class="mozTocH4" />役務: にほんブログ村 | 手軽にアクセスが集まる有名ブログランキングサイト</h4> <section> <h5><a id="mozTocId559609" class="mozTocH5" />概要</h5> <p>前回: <a href="https://web.gnusocial.jp/post/2023/11/27/9429/">役務: YouTubeの広告動画の即時終了ブラウザー拡張Ad Speedup | GNU social JP Web</a>。</p> <p>「<a href="https://web.gnusocial.jp/post/2023/11/09/9303/">役務: Misskey愛好家運営の新しい分散SNSのブログサイトfedimagazine.tokyo | GNU social JP Web</a>」でfedimagazine.tokyoを紹介しました。「あ: あ」その際に、にほんブログ村 (<a href="https://blogmura.com/">人 気ブログランキングとブログ検索 にほんブログ村</a>) というサービスに登録 (<a href="https://blogmura.com/profiles/11178461">fedimagazine.tokyo - にほんブログ村</a>) されていて、このサービスを私は初めて知りました。</p> <p>調べたところ、登録するだけでサイトへのアクセスが簡単に見込めるサービスで興味を持ったので登録・紹介します。</p> <figure class="example"> <figcaption>情報源</figcaption> <ul> <li><a href="https://ja.wikipedia.org/wiki/%E3%81%AB%E3%81%BB%E3%82%93%E3%83%96%E3%83%AD%E3%82%B0%E6%9D%91">に ほんブログ村 - Wikipedia</a></li> <li><a href="https://blogmura.com/about">にほんブログ村とは? - にほんブログ村</a></li> <li><a href="https://hidesunblog.com/blog-ranking-sites/">2023年ブ ログランキング!おすすめブログランキングサイト比較【一般人向け】</a></li> <li><a href="https://hidesunblog.com/nihon-blogmura/">【初心者必見!】にほ んブログ村の登録とランキング参加方法</a></li> </ul> </figure> </section> </section>
@senooken 確認して修正します。
@senooken 修正しました。タグの境目で改行後の処理が発生していました。
また「にほんブログ村 | 手軽に」の部分の「|」の後の改行 + 空白が消えて「にほんブログ村 |手軽に」となっていたため、「|」の前後の空白を保つ様にしました。(他にもでてきそうですね……)
<h4><a id="mozTocId810882" class="mozTocH4" />役務: にほんブログ村 | 手軽にアクセスが集まる有名ブログランキングサイト</h4>
@tak4 早速ありがとうございます。ひとまず今回の現象が解決したことを確認できました。これでしばらく使わせてもらいます。
「|」の前後の空白を保つ様にしました。(他にもでてきそうですね……)
これは | くらいですかね。次回登場したら、今回の修正内容を参考に、こちらで追加を試みてみます。
|
後、今後のための指摘です。正規表現リテラルにすると、正規表現部分に変数を使えないので、置換部分は、Regexpオブジェクトを使って、正規表現部分を変数で流用したほうが作りとしてはきれいでしたね。書き捨てみたいな感じなので、別に対応しなくていいです。
正規表現リテラルにすると、正規表現部分に変数を使えないので、置換部分は、Regexpオブジェクトを使って、正規表現部分を変数で流用したほうが作りとしてはきれいでしたね。
有難うございます。
その方法だと管理しやすいですが、「\」「"」などの特殊文字のエスケープが複雑になるので正規表現リテラルを好んで使用しました、が、RegExpコンストラクターに渡す正規表現文字列を きちんと確認してデバッグすればいいだけの話ですね。今後機会があればその様にします。
今後機会があればその様にします。 GenerateTOCを直すというより「正規表現に変数を埋め込みたくなった時」ですね。
@tak4 該当正規表現リテラルは、複数回使っていてDRY原則に反していたので、変数にしたほうがよいと助言しました。たぶんDRY原則をあなたはわかっていません。
DRY (Don't Repeat Yourself) 原則がプログラミングでも作業効率化で非常に重要です。達人の秘訣・本質です。同じこと、失敗を何回も繰り返してはいけません。複雑で時間がかかることならなおさらです。
正規表現に限りません。日頃からDRY原則を意識するときっとレベルアップします。私が「1回やればおしまいだから」というのもこれです。
@senooken わかりました。たしかにDRY原則の意識が足りませんでした。同じことを繰り返さない様にします。
@senooken 「変数にする」の解釈に入れ違いがあったかもしれないので補足します。
(1) は問答無用でそうするべきでした。失礼しました。
わたしがエスケープ云々と書いたのは (2) の意味で捉えたからです。どちらにしてもDRY原則を守るべきですが。
@tak4 ありがとうございました。その後あまり余裕がなくてマージが遅れました。OKです。以前口頭で話のあった通り、4か月分のGold会員で報酬を贈呈 (2024-12-31期限に延長) しました。
「 #1 」を実装しました。不備や追加の要望があればご連絡ください。
仕様
ホワイトリスト
基本的にはホワイトリスト方式(a/em/strong/li/tdとついでにh1-h6)で、対象要素の子孫も含めて処理しますが、preだけは明示的に除外しました。
日本語の判定
英数(全角含む)及び半角記号を英数記号としてそれ以外を日本語と判定します。Unicodeのプロパティーを使用して日本語かどうかを厳密に判断する方法もありますが、具体的な内訳が分りにくいため使用しませんでした。検証済みなので希望があればそちらに変更できます。
改行除去
を除外しました。改行+インデントの空白が多い様なので空白も除外しました。
また、どこで改行が入っても問題無い様、
<p>テスト[改行]<em>強調[改行]</em></p>
の様にタグを跨いで改行が入るケースも改行を除去します。制約
日本語と英語との間の改行も削除する仕様ですが、「元々空白だった部分に改行が入ったのか、「何も無い部分に改行が入ったのか」が判断不可能なため、前者のケースで空白が消えてしまいます。
「 #1 」で提示されたサンプルHTMLだと途中のp要素の
「Threads (スレッズ)[改行]の初期バージョン」
の部分が
「Threads (スレッズ)の初期バージョン」
の様に「)」が「の」と繋がります。直すには何らかの判断基準が必要に見えます。
末尾の改行については副作用を避けるため、ホワイトリストの対象要素かつ、末尾が日本語である場合のみ対応しました。改善の余地はありますが時間切れです…
@tak4 おお!ありがとうございます!土日連絡なかったので心配でした。
100行程度の修正で、思ったよりコード行数増えました。数時間以内でできるかと思いましたけど、けっこう難しかったですか?
こちらは簡単にできそうな場合のおまけなのでひとまず大丈夫です。
括弧 ()[] はよく使いますので、これはできれば回避したいです。
改行除去の条件が「日本語の直前の改行+後続の空白、日本語の直後の改行+後続の空白」となっていますが、これに「後続の空白の後に日本語がある場合」という条件を足せませんかね?日本語の途中で分割されるのが問題なので。たぶん、英単語内の途中では分割起きない想定でOKです。
平日は記事更新などで時間がそんなに取れないので、コメントも多めに入れてくれていますので、週末などにちょっと内容・動作をよく確認させていただきます。
@senooken
土日に連絡できず、不安にさせてすみません。1日あたりの作業時間をあまり取れなかった事もあり遅くなりました。
はい、想定より難しかったです。 タグを跨ぐケースなど細部の実装でコードが増えました。また、前述の「括弧の空白が消える」等仕様の判断・動作確認にも時間がかかりました。
わかりました。
その仕様変更自体はすぐなので、明日動作確認をして、連絡します。
有難うございます。よろしくお願いいたします。
@tak4 さん。すみません。
日本語のサンドイッチのケースだけにしてほしいと先日追加の依頼をしました。が、その後いろいろパターンを考えていました。これを踏まえて理想の改行除去の条件は以下です。
[](){}<>
分割条件の例が以下です。
これが可能そうなら対応お願いしたいです。無理か難しそうなら、括弧の前後のスペースが消えるのが少し気になりますが、それでも大幅にましなので、このままでOK、作業不要です。しばらく動作確認します。
現状で問題なのは「)。」のようなケース。基本的に英語は括弧の前後にスペースが必須です。同じ方向の括弧や句読点類が連続する場合だけスペース不要です。
情報源。
これを回避できるならしたいですけど、難しそうならひとまず大丈夫です。
@senooken さん。代案、有難うございます。そちらの仕様を試してみます。問題が出たらまた連絡します。
日本語のサンドイッチも一応確認したところ、英単語前の改行 (空白) が目立ちました。
@tak4 ややこしくてすみません。開き括弧と閉じ括弧の条件、分割を許容する例を追記しました。
@senooken 追記を確認しました。もうすぐできます。
こちらの仕様に修正しました。
おお!ありがとうございます。しばらく動作確認させてもらいます。
https://notabug.org/gnusocialjp/GenerateTOC/pulls/2#@tak4 すみません。動作確認していて、概ね問題ないのですけど、ビデオ会議で少し話しましたけど、NGケースがありました。
n-word
のようなハイフン (-) の前後では分割禁止にしたいです。難しそうなら、多くはないケースなので諦めます。あまり手間かからずにできそうならお願いしたいです。[](){}<>
分割条件の例が以下です。
サンプル。
@senooken 夕方から夜に試してみます。
@tak4 すみません。条件を少し変えました。
改行除去の条件: 日本語と記号+改行+後続の空白+開き括弧以外 OR 閉じ括弧以外+改行+後続の空白+日本語と記号 (ただし、括弧+、。は除外)
日本語と括弧以外のサンドイッチのところで、日本語の部分に記号類も含めて考えればいいだろうと思いました。ファイルパス表示などで記号と英字が連続することは思えばよくありますので…
@senooken
@senooken あと関係の無い変更ですがわたしの書いたコメントで括弧の前後に空白を入れました (気持ち悪くなったので)
@tak4 おお…何回もありがとうございます。pullしてしばらくまた試させていただきます。たぶんこれでOKだと思っています。
括弧の前後の空白、意識しだすと気になります。MS Wordとかは設定でよしなにやってくれたりはするのですけど。プレインテキストだとそうはいきませんので。組版も凝りだすときりがないのですけども…
@senooken すみません、開き括弧・閉じ括弧の条件が抜けていて「a(」「)a」が分割されたので修正しました。
@senooken 何度もすみません、タグを跨いで括弧がある場合 (q要素が閉じ括弧で終る場合等) で空白が消えていたので直しました。これで問題無いはずです。
@tak4 すみません。前回の修正後、引越があって余裕がなかったのでマージを後回しにして、ずっと使っていたところ、不具合のようものを見つけました。
コロン
:
の直後のスペースが消えてしまいます。以下の例で冒頭の前回:
の直後のスペースが消えます。改行と関係ない場所のはずなんですけど。時間が空いてしまいましたが、よかったらまた見ていただけませんか?本文内の「あ: あ」が問題ないので、行頭の処理が、改行直後の条件で引っかかっているような気がします。
@senooken 確認して修正します。
@senooken 修正しました。タグの境目で改行後の処理が発生していました。
また「にほんブログ村 | 手軽に」の部分の「|」の後の改行 + 空白が消えて「にほんブログ村 |手軽に」となっていたため、「|」の前後の空白を保つ様にしました。(他にもでてきそうですね……)
@tak4 早速ありがとうございます。ひとまず今回の現象が解決したことを確認できました。これでしばらく使わせてもらいます。
これは
|
くらいですかね。次回登場したら、今回の修正内容を参考に、こちらで追加を試みてみます。後、今後のための指摘です。正規表現リテラルにすると、正規表現部分に変数を使えないので、置換部分は、Regexpオブジェクトを使って、正規表現部分を変数で流用したほうが作りとしてはきれいでしたね。書き捨てみたいな感じなので、別に対応しなくていいです。
@senooken
有難うございます。
その方法だと管理しやすいですが、「\」「"」などの特殊文字のエスケープが複雑になるので正規表現リテラルを好んで使用しました、が、RegExpコンストラクターに渡す正規表現文字列を きちんと確認してデバッグすればいいだけの話ですね。今後機会があればその様にします。
@tak4 該当正規表現リテラルは、複数回使っていてDRY原則に反していたので、変数にしたほうがよいと助言しました。たぶんDRY原則をあなたはわかっていません。
DRY (Don't Repeat Yourself) 原則がプログラミングでも作業効率化で非常に重要です。達人の秘訣・本質です。同じこと、失敗を何回も繰り返してはいけません。複雑で時間がかかることならなおさらです。
正規表現に限りません。日頃からDRY原則を意識するときっとレベルアップします。私が「1回やればおしまいだから」というのもこれです。
@senooken わかりました。たしかにDRY原則の意識が足りませんでした。同じことを繰り返さない様にします。
@senooken 「変数にする」の解釈に入れ違いがあったかもしれないので補足します。
(1) は問答無用でそうするべきでした。失礼しました。
わたしがエスケープ云々と書いたのは (2) の意味で捉えたからです。どちらにしてもDRY原則を守るべきですが。
@tak4 ありがとうございました。その後あまり余裕がなくてマージが遅れました。OKです。以前口頭で話のあった通り、4か月分のGold会員で報酬を贈呈 (2024-12-31期限に延長) しました。