てがろぐ - Fumy Otegaru Memo Logger -
2025年6月5日(木) 12:45:39〔17時間前〕 更新
■No.5183, No.5182, No.5181, No.5180, No.5179, No.5178, No.5177［7件］ （ 7 件 ）
■フリースペース： 編集
ここは、CGIの設定画面から自由に文章を入力して掲載できるスペースです。スキンを編集しなくてもCGI上から手軽に内容を変更できます(HTML使用可)。
動作サンプルです。◆他のスキン：標準スキン, 昔のツイッターっぽいスキン(ピンク版), 付箋型スキン, シンプル日記スキン, ジャーナル(日誌)スキン, ブログタイプスキン, チャットタイプスキン, 黒板スキン 《てがろぐCGIの配布ページに戻る》
動作サンプルです。◆他のスキン：標準スキン, 昔のツイッターっぽいスキン(ピンク版), 付箋型スキン, シンプル日記スキン, ジャーナル(日誌)スキン, ブログタイプスキン, チャットタイプスキン, 黒板スキン 《てがろぐCGIの配布ページに戻る》
■日付検索：
■全文検索：
〔49文字〕 編集
〔252文字〕 編集
2025/05/20 (Tue)
01:49:19
No.5181
by
あどみ
〔17日前〕
検索して探したのですがなかなか見つからなかったので、こちらにて失礼します。経過時間(相対時間)表記機能について質問です。[[DATE:《A》]] を使ってn秒前やm分前という表示を24時間以内の時だけ表示させ、24時間を過ぎたら非表示にしたいのですが、この場合はどこを設定すればできますか？
経過時間の表記変更は設定の項目でできる事は分かったのですが、一定時間後に非表示にするなどの方法が探してもなかなか見つからなくこちらで質問させて頂きました。
お忙しいところ恐れ入りますが何卒よろしくお願い致します。
経過時間の表記変更は設定の項目でできる事は分かったのですが、一定時間後に非表示にするなどの方法が探してもなかなか見つからなくこちらで質問させて頂きました。
お忙しいところ恐れ入りますが何卒よろしくお願い致します。
〔335文字〕 編集
2025/05/18 (Sun)
11:13:55
No.5180
by
あどみ
〔18日前〕
5174/5176です。要望、ご検討いただきありがとうございます。
また、余談とのことでしたが、具体的な対応策を詳細にご教示いただき、ありがとうございました。何度も読み返させていただきました。
少し前に、同じく手作業で1000件ほど、SNSの投稿データをてがろぐに移動させたことがあったものですから、300件くらいなら…と、感覚が麻痺してしまっていたような状態でした。
でも、やはり何かしら効率化は【できる】し、恐らく自分の勉強のために、【やるべき】でもあるのだなと猛省いたしました。ご想像のとおり、プログラミング言語やAIとは縁遠い人生でしたので、これを機にもう少し、勉強してみようと思います。
この度は色々とお時間を割いていただき、誠にありがとうございました。
また、余談とのことでしたが、具体的な対応策を詳細にご教示いただき、ありがとうございました。何度も読み返させていただきました。
少し前に、同じく手作業で1000件ほど、SNSの投稿データをてがろぐに移動させたことがあったものですから、300件くらいなら…と、感覚が麻痺してしまっていたような状態でした。
でも、やはり何かしら効率化は【できる】し、恐らく自分の勉強のために、【やるべき】でもあるのだなと猛省いたしました。ご想像のとおり、プログラミング言語やAIとは縁遠い人生でしたので、これを機にもう少し、勉強してみようと思います。
この度は色々とお時間を割いていただき、誠にありがとうございました。
2025/05/18 (Sun)
10:37:37
No.5179
by
にしし
〔18日前〕
朝食はサンドイッチ。🥪🥪🥪
🥪Re:5178◆おっしゃるとおり、30MBというのは「サーバへのアップロード時の連続通信を切る閾値」でしかなく「扱えるサイズの上限」というわけではありません。なので、FTP等の別手段でUPした場合は、30MBを超えていても（てがろぐ側が扱う上では）問題はありません。その画像を [PICT:～]で表示させても問題ありませんし、画像管理画面に出しても問題はありません。
仕様上の上限があるのは、●CGI側の処理がサーバに負荷を掛けすぎていると解釈されないようにするため、●誤って巨大なファイルをUPしてしまわないため、●未知の不具合で莫大なファイルがUPされてしまうようなケースがあった場合の被害を軽減するため、などが理由ですが、その閾値を30MBに設定しているのは「まあ、それくらいを超えるファイルをUPする需要はないだろう」という予想からでしかありません。(^_^;) よほどそれでは不足するようなら見直しも考えます。（プログラムの起動時点で上限を固定しておく必要があるので、設定画面等でユーザが自由に変更できるようには作れないので。）
🥪Re:5178◆おっしゃるとおり、30MBというのは「サーバへのアップロード時の連続通信を切る閾値」でしかなく「扱えるサイズの上限」というわけではありません。なので、FTP等の別手段でUPした場合は、30MBを超えていても（てがろぐ側が扱う上では）問題はありません。その画像を [PICT:～]で表示させても問題ありませんし、画像管理画面に出しても問題はありません。
仕様上の上限があるのは、●CGI側の処理がサーバに負荷を掛けすぎていると解釈されないようにするため、●誤って巨大なファイルをUPしてしまわないため、●未知の不具合で莫大なファイルがUPされてしまうようなケースがあった場合の被害を軽減するため、などが理由ですが、その閾値を30MBに設定しているのは「まあ、それくらいを超えるファイルをUPする需要はないだろう」という予想からでしかありません。(^_^;) よほどそれでは不足するようなら見直しも考えます。（プログラムの起動時点で上限を固定しておく必要があるので、設定画面等でユーザが自由に変更できるようには作れないので。）
2025/05/17 (Sat)
23:04:29
No.5178
by
さくら
〔19日前〕
平素より大変お世話になっております。
素敵なツールの開発に継続的な改良、本当にありがとうございます。
自分好みにカスタマイズ可能でマイペースにつぶやき・メモを残せる理想のミニブログとして愛用させていただいています。
当方、てがろぐにてイラストを投稿することがありますが、投稿に失敗することが度々ありました。
そこでユーザー側で設定可能な画像の容量上限とは別にCGI側にて設定されている「強制的にHTTP接続を切る仕様上のデータサイズの上限」は30MBとの記載を見つけ、投稿に失敗したすべての画像がこのサイズを超過していたためおそらくこの仕様に引っかかったものと思います。
質問ですが、例えばFTPでサイズ上限を超過するメディアファイルをアップロードの上でてがろぐの投稿から [PICT:メディアファイルのパス]とした場合てがろぐの動作に支障はありませんでしょうか？
記載を読む限り30MBはサーバーとの通信を切る上限サイズでてがろぐで扱えるデータサイズの上限ではないと読み取れますが、CGIの仕様には疎いため念の為質問をさせて頂きました。(それ以前に上限に収まるように事前に調整すべきとは思います…)
#質問
素敵なツールの開発に継続的な改良、本当にありがとうございます。
自分好みにカスタマイズ可能でマイペースにつぶやき・メモを残せる理想のミニブログとして愛用させていただいています。
当方、てがろぐにてイラストを投稿することがありますが、投稿に失敗することが度々ありました。
そこでユーザー側で設定可能な画像の容量上限とは別にCGI側にて設定されている「強制的にHTTP接続を切る仕様上のデータサイズの上限」は30MBとの記載を見つけ、投稿に失敗したすべての画像がこのサイズを超過していたためおそらくこの仕様に引っかかったものと思います。
質問ですが、例えばFTPでサイズ上限を超過するメディアファイルをアップロードの上でてがろぐの投稿から [PICT:メディアファイルのパス]とした場合てがろぐの動作に支障はありませんでしょうか？
記載を読む限り30MBはサーバーとの通信を切る上限サイズでてがろぐで扱えるデータサイズの上限ではないと読み取れますが、CGIの仕様には疎いため念の為質問をさせて頂きました。(それ以前に上限に収まるように事前に調整すべきとは思います…)
#質問
2025/05/17 (Sat)
13:51:12
No.5177
by
にしし
〔19日前〕
昼食のパスタでおなかいっぱい。ぐっふぅ。_(┐｢ε:)_
🍝Re:5176◆詳細な背景情報をありがとうございます。よく分かりました。日付欄の常時表示ができるような設定も、ToDoリストには含めておきます。
300件もの移行作業を手動でとは頑張りましたね。^^;
以下は、今後や同様のことをしようとされている方々に向けた余談のようなものです。参考までに記します。
エクスポート機能がなかったとのことですが、エクスポート機能がなくても表示ページのHTMLをローカルにファイルとして保存することは可能ですから、私なら以下のような「データ変換のための使い捨てプログラム」をChatAIに作ってもらって実行します。
上記のプロンプトを使ってChatGPTに生成してもらった結果が https://chatgpt.com/share/6828044f-0eec-800b-bdcc-9269... です。
元ページの構造に応じて指示は変える必要がありますから、このまま使えるわけではありませんけども。（元データとして書いた内容がテキトーなので動作確認はしていませんが（しようがありませんから）。生成されたcleanHtmlBody関数の中で若干無駄なことをしている気もしますが、まあ概ね問題なさそうな気がします。^^; 元データがHTMLの文法に正確には従っていない場合は「DOMDocumentを使わずに、正規表現で抽出して下さい」的な指示を加える必要はあるかもしれませんけども。）
こういう感じで、『元HTMLソースから情報を抽出して、てがろぐのデータ形式に変換する』プログラムを用意すれば、自力で1つ1つ移行するよりも楽に済みます。（生成されたデータを、既存の tegalog.xml にペーストするだけで済みます。※もちろん、うまくいかなかった場合に備えて元の tegalog.xml ファイルはバックアップ保存しておいて下さい。）
ここでは、元データがローカルにHTMLファイルとして存在していることを前提にしています。
この手のプログラムに「ネット上から情報を取ってくる処理」自体を含めてはいけません。試行錯誤する過程で毎回ネットから情報を取ってきてしまうと、サーバに無駄な負荷がかかるからです（時間もかかりますし）。
データさえローカルに保存してあればいくらでも試行錯誤できますから、「ネットからデータを取ってくる処理」と「取ってきたデータを加工する処理」は分ける方が望ましいでしょう。
「ネットからデータを取ってくる処理」は、数が少なければ自力で（ブラウザで当該ページを表示させて [Ctrl]＋[S] を押すとかで）保存しても良いでしょうし、それ用の使い捨てプログラムを別途用意しても良いでしょう。
（※ただし、そのようなプログラムを他人のサイトに対して実行すると、凄まじく迷惑なスクレイピングプログラムになりますので、自分に100％の使用権があるサーバに対してだけ実行して下さい。共用サーバの場合は「1件のURLにアクセスするたびに、数秒間の待機時間を設ける」的な緩和措置を含める方が望ましいです。）
プログラミング言語にはここではPHPを使いましたが、もちろん（ローカルで実行できる言語なら）何でも都合の良いものを指定すれば良いです。
自身が読んで理解できない言語だと実行するのは安全とは限りませんし細かな調整が利きませんから、理解できる言語が望ましいですね。
「プログラミング言語は何もわからん……」という場合にはまあ使えませんが。^^;（なので、これは何かしらプログラミング言語が分かる人向けの話です。）
「AIにプログラムを生成してもらうのではなく、AIに直接データを整形してもらえば……？」という意見もあるかもしれませんが、作業量が多いとAIは割と手を抜くので、数百件ものデータを処理させると（本当に正確に移行したのかどうか）確認するのが面倒なので、「整形のためのプログラム」を生成するに留める方が確実だと思っています。少なくとも今のところは。^^;
AIそのものをローカルで実行できるようになれば、何もかもをAIに任せる選択も採りやすくなるかもしれませんけどもね。（いくらでも試行錯誤できる点で。）
畳む
🍝Re:5176◆詳細な背景情報をありがとうございます。よく分かりました。日付欄の常時表示ができるような設定も、ToDoリストには含めておきます。
300件もの移行作業を手動でとは頑張りましたね。^^;
以下は、今後や同様のことをしようとされている方々に向けた余談のようなものです。参考までに記します。
エクスポート機能がなかったとのことですが、エクスポート機能がなくても表示ページのHTMLをローカルにファイルとして保存することは可能ですから、私なら以下のような「データ変換のための使い捨てプログラム」をChatAIに作ってもらって実行します。
ローカルにある複数のHTMLファイルから情報を抽出して、別のブログツールに結合するためのデータを作るプログラムをPHPで書こうとしています。どのようなソースコードを書けば良いか教えて下さい。
以下の手順での処理が必要です。
1. サブディレクトリ OldBlog にあるすべてのHTMLファイルから以下の情報を抽出する。
(a) ページタイトル ： title要素の中身を取得。
(b) 投稿日時 ： <span class="postdate">～</span>の中身を取得。
(c) 本文 ： <div class="post">～</div>の中身を取得。
2. 投稿日時を整形する。
元データの投稿日時は「 2025年5月17日(土) 12時18分 」のような日本語形式で書かれています。これを YYYY/MM/DD hh:mm:ss 形式に整形します。西暦は必ず4桁で、それ以外はすべて必ず2桁にする必要があります。
3. 本文を整形する。
本文として取得した内容にHTMLタグが含まれている場合は、改行以外のHTMLタグをすべて削除します。
また、改行タグはすべて <br /> に統一します。
改行コードもすべて削除して、データが1行になるようにします。
4. 移行先ブログツール用のデータを生成する
手順1～3で用意したデータを1件ずつ、以下のような1行のデータに変換します。
<log><date>日付</date><id>連番</id><user>admin</user><cat></cat><flag></flag><comment>本文</comment></log>
「日付」部分には、2で作成した YYYY/MM/DD hh:mm:ss 形式の日付を入れます。
「連番」部分には、半角数値で 10001 から始まる番号を入れます。
「本文」部分には、3で整形した文字列を入れます。
それ以外の文字列は上記のまま使います。畳む
上記のプロンプトを使ってChatGPTに生成してもらった結果が https://chatgpt.com/share/6828044f-0eec-800b-bdcc-9269... です。
元ページの構造に応じて指示は変える必要がありますから、このまま使えるわけではありませんけども。（元データとして書いた内容がテキトーなので動作確認はしていませんが（しようがありませんから）。生成されたcleanHtmlBody関数の中で若干無駄なことをしている気もしますが、まあ概ね問題なさそうな気がします。^^; 元データがHTMLの文法に正確には従っていない場合は「DOMDocumentを使わずに、正規表現で抽出して下さい」的な指示を加える必要はあるかもしれませんけども。）
こういう感じで、『元HTMLソースから情報を抽出して、てがろぐのデータ形式に変換する』プログラムを用意すれば、自力で1つ1つ移行するよりも楽に済みます。（生成されたデータを、既存の tegalog.xml にペーストするだけで済みます。※もちろん、うまくいかなかった場合に備えて元の tegalog.xml ファイルはバックアップ保存しておいて下さい。）
ここでは、元データがローカルにHTMLファイルとして存在していることを前提にしています。
この手のプログラムに「ネット上から情報を取ってくる処理」自体を含めてはいけません。試行錯誤する過程で毎回ネットから情報を取ってきてしまうと、サーバに無駄な負荷がかかるからです（時間もかかりますし）。
データさえローカルに保存してあればいくらでも試行錯誤できますから、「ネットからデータを取ってくる処理」と「取ってきたデータを加工する処理」は分ける方が望ましいでしょう。
「ネットからデータを取ってくる処理」は、数が少なければ自力で（ブラウザで当該ページを表示させて [Ctrl]＋[S] を押すとかで）保存しても良いでしょうし、それ用の使い捨てプログラムを別途用意しても良いでしょう。
（※ただし、そのようなプログラムを他人のサイトに対して実行すると、凄まじく迷惑なスクレイピングプログラムになりますので、自分に100％の使用権があるサーバに対してだけ実行して下さい。共用サーバの場合は「1件のURLにアクセスするたびに、数秒間の待機時間を設ける」的な緩和措置を含める方が望ましいです。）
プログラミング言語にはここではPHPを使いましたが、もちろん（ローカルで実行できる言語なら）何でも都合の良いものを指定すれば良いです。
自身が読んで理解できない言語だと実行するのは安全とは限りませんし細かな調整が利きませんから、理解できる言語が望ましいですね。
「プログラミング言語は何もわからん……」という場合にはまあ使えませんが。^^;（なので、これは何かしらプログラミング言語が分かる人向けの話です。）
「AIにプログラムを生成してもらうのではなく、AIに直接データを整形してもらえば……？」という意見もあるかもしれませんが、作業量が多いとAIは割と手を抜くので、数百件ものデータを処理させると（本当に正確に移行したのかどうか）確認するのが面倒なので、「整形のためのプログラム」を生成するに留める方が確実だと思っています。少なくとも今のところは。^^;
AIそのものをローカルで実行できるようになれば、何もかもをAIに任せる選択も採りやすくなるかもしれませんけどもね。（いくらでも試行錯誤できる点で。）
畳む
