日記・コラム・つぶやき 早起きしたんでぼちぼち活動限界。
明日は横須賀行ってカレーと艦船をみてくるつもりなので、とっとと寝ます。
U-NEXTで新作アニメみてたらおススメにR.O.Dがでてきたからつーて全話観ようとはしません。
なおOVA版。
あ、あと「ガールズ＆パンツァー最終章第5話」を観てきました。
0
PC関係 サイドバーの上部にくるくるぱたぱたするウィジェットを置きました。
今日はもう一個、ココログからwordpressへの移植参考書類を別記事で（copilotに整理させて）投稿しました。
この記事、精査してないし、実際にこれだけでやれるとは思わないんですが、引っかかりそうなところは大体指摘できてるはずなんで、後はAIさんに一ヶ月くらい課金して頼りまくれば、（私が3か月苦労したよりは）ずっと楽になんとかなるんじゃないかと思います。
という訳で、今日でcopilotの課金切れるはず。
さよーならー。
0
PC関係 26/10/14改稿
この手引きは、ココログで長期間運営してきたブログをWordPressへ移し、できる限り元の記事、画像、投稿日、カテゴリー、記事同士のリンクを残したい人のための実務手引きです。
HTML、Python、SQLなどに詳しくない人でも進められるよう、専門用語は必要な場面で使い、その直後に意味を説明します。専門用語を覚えることが目的ではありません。AIへ何を調べさせ、何を作らせ、どこを人間が確認するかを理解することが目的です。
今回の実測例では、MTバックアップに含まれる7,048記事を調査し、829件の画像参照と12種類のHTML構造を確認しました。実際の変換ルールとしては、おおむね6系統の画像表示方式に整理できました。
この手引きでは、移行作業を次の6部に分けます。
第1部 旧ココログを保存し、サイトの構造を確認する第2部 記事・画像・旧URLの対応表を作る第3部 ココログの画像をWordPress向けの形へ変換する第4部 記事内の過去記事リンクを新サイト用に直す第5部 画像と変換済み記事をWordPressへ移す第6部 移行結果を確認し、残った問題を直す本手引きには、実際に行った方法だけでなく、保存データから確認した内容、保存結果をもとにした推定、AI活用版として提案する未検証の方法も含まれます。未検証の方法は、そのことが分かるように記載します。
移行作業では、次のような多数のファイルを扱います。
ココログから取得したMTバックアップHTTrackで保存した旧サイト記事の対応表画像の対応表旧URLと新URLの対応表AIに作成してもらった処理用プログラム処理結果の記録書き換え後のMTバックアップWordPressへ送る画像一括処理の設定を一つ間違えるだけで、多数の記事を書き換えてしまう可能性があります。
必ず次の順番で作業します。
元データを保存↓作業用コピーを作成↓コピーだけを調査・変換↓変換結果は別ファイルへ保存AIが作った処理用プログラムも、最初から正しく動くとは限りません。
1記事↓10記事↓1か月分↓全期間の順で試します。
dry-run とは、実際にはファイルを書き換えず、何件が変更対象になるか、どのように変わる予定かだけを確認する試験実行です。
AIには、必ず次の条件を付けます。
本手引きでは、筆者が実際に移行した旧ブログを例にします。
移行時点のブログURLは次のとおりです。
https://buran.tea-nifty.com/blog/サイトの一番上のURLは次のとおりです。
https://buran.tea-nifty.com/ただし、長年の記事データにはHTTP時代のURLも残っていました。
http://buran.tea-nifty.com/blog/http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttp://buran.tea-nifty.com/blog/images/sample.jpgそのため、この手引きではHTTPとHTTPSの両方を旧ココログURLとして調べます。
次の2つは、人間には同じ記事に見えても、文字列としては別URLです。
http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlサイト側の設定によっては、HTTPからHTTPSへ自動転送され、同じ記事や画像が開く場合があります。しかし、検索や一括置換では別の文字列として扱われます。
したがって、旧URLを探すときは次の3種類を確認します。
http://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com最後にサイト名だけでも検索すれば、HTTPとHTTPSのどちらで残っていても見つけやすくなります。
https://buran.tea-nifty.com/blog/2006/08/post-89ad.htmlは、次のように分けて考えます。
https:// HTTPかHTTPSかを示す部分
buran.tea-nifty.com サイトを表す部分
blog/ ブログ部分の名前
2006/08/ 記事の年月
post-89ad.html 個別記事のファイル名すべてのココログが ○○○.tea-nifty.com/blog/ という形とは限りません。tea に相当する部分や、blog に相当する部分が異なる例もあるため、自分のブログの実URLを確認してください。
ココログからWordPressへの移行を行います。
まずMTバックアップとHTTrack保存データを調査し、旧ココログサイトのURL構造を確認してください。
筆者の例:https://buran.tea-nifty.com/https://buran.tea-nifty.com/blog/
ただし過去記事には、http://buran.tea-nifty.com/http://buran.tea-nifty.com/blog/も残っている可能性があります。
http:// と https:// の両方を調べてください。URL先頭のhttp/https以外が同じものは、同じ記事または画像の候補として記録してください。
buran、tea-nifty.com、blogに相当する部分は、他のココログでは違う可能性があるため固定しないでください。
この段階では何も書き換えず、見つかったURLの種類と構造だけを報告してください。MTバックアップは、記事をまとめて保存したテキストファイルです。主に次の内容が入っています。
ただし、画像ファイルそのものは入っていません。
元ファイルは、例えば次の名前で保存します。
cocolog_mt_original.txt直接編集しないでください。
MT内の記事は、例えば次のような形です。
TITLE: 記事タイトルDATE: 09/12/2016 23:31:33CATEGORY: 日記・コラム・つぶやきBODY:記事本文HTTrackは、WebサイトをHTMLや画像を含めてパソコンへ保存するソフトです。
ブログが次のURLでも、
https://buran.tea-nifty.com/blog/可能ならサイトの一番上から保存します。
https://buran.tea-nifty.com/画像や共有ファイルが /blog/ の外側にある場合があるためです。
保存結果は、例えば次のようになります。
buran.tea-nifty.com├─ .shared├─ blog│ ├─ 2006│ │ └─ 08│ │ ├─ index.html│ │ └─ post-89ad.html│ └─ images└─ photosMTバックアップ 記事タイトル 投稿日時 記事本文 ココログ上の画像URL 過去記事へのリンク
HTTrack 月ごとの一覧HTML 個別記事HTML パソコン内での画像参照先 実際に保存された画像ファイル移行の中心作業は、この2種類の情報を結び付けることです。
MTの記事情報＋HTTrackの保存情報＋実際の画像ファイル↓WordPress移行用の対応表MigrationProject├─ backup_original│ ├─ mt│ └─ httrack├─ work│ ├─ mt│ └─ httrack├─ tables├─ scripts├─ output├─ logs└─ uploadbackup_original：絶対に変更しない元データwork：調査や変換に使うコピーtables：記事・画像・URLの対応表scripts：AIが作った処理用プログラムoutput：変換後のMTファイルlogs：処理結果やエラーの記録upload：WordPressへ送る画像主に次の3種類を作ります。
記事対応表MTの記事 → HTTrackの個別記事HTML
画像対応表旧画像URL → 保存画像 → WordPress配置先 → 新画像URL
旧記事URL対応表旧記事URL → 記事タイトル・投稿日 → 新記事URL画像や旧記事リンクを正しく調べるには、MT内の記事がHTTrackのどの post-xxxx.html に対応するかを特定する必要があります。
照合は次の順で行います。
例えば、MT側が次の場合、
TITLE: Ｃ７１申し込みDATE: 08/19/2006 14:02:02HTTrack側の月別ページで、
2006-08-19 14:02↓post-89ad.htmlと分かれば、同じ記事として対応表へ記録します。
index.html の場所AIが扱いやすいよう英語の列名を使う場合でも、読者は意味を理解できれば十分です。
画像対応表には次を記録します。
どの記事にあった画像か↓MTに書かれた表示画像URL↓MTに書かれたクリック先URL↓HTTrackの記事HTMLに書かれた参照先↓実際に保存された表示画像↓実際に保存された原画像↓WordPressでの配置先↓新しい画像URLここで重要なのが、img src と a href です。
img src：記事中に表示する画像のURLa href：画像をクリックしたときの行き先この2つは同じとは限りません。
画像対応表には少なくとも次を記録します。
img srca hrefimg srca href正しい画像を特定するときは、次の順番を使います。
1. 個別記事HTMLから直接取得2. 月別index.htmlから取得3. 元画像名で検索4. 投稿日時に近い画像を候補にする5. ファイルサイズと画像サイズを比較6. 実際に画像を開いて確認HTMLから直接分かった結果と、更新日時から推定した結果を同じ扱いにしません。
個別記事HTMLに次の記述がある場合、
<a href="../../../.shared/image8e08.jpg?/photos/uncategorized/c71cut.jpg">次の対応が分かります。
ココログ上の原画像名c71cut.jpg
HTTrackが保存した原画像.shared/image8e08.jpgHTMLから見つからない場合だけ、更新日時、ファイルサイズ、画像の縦横サイズ、目視確認へ進みます。
MT形式バックアップ、HTTrackの月別index.html、個別記事HTML、画像フォルダーを解析するPythonプログラムを書いてください。
目的:MTバックアップ中の画像参照と、HTTrackで保存された画像を対応付けること。
重要:・img srcは記事に表示する画像・a hrefはクリック先・表示画像と原画像が別の場合がある・.shared/imageXXXX.jpgへ名前が変わっている場合がある
照合順:1. 個別記事HTML内の参照2. 月別index.html内の参照3. 画像ファイル名一致4. 投稿日時と更新日時が近い候補5. 手動確認候補
対象:・.shared/image.html?/ を使う形式・window.openを使う形式・photos/uncategorizedとblog/imagesが別の形式・class="mb"を使う形式・_thumbを使う形式・imgタグだけの形式・外部画像・file:/// で始まる壊れた参照
条件:・元データは変更しない・未発見は別一覧にする・複数候補は自動確定しない・推定結果を確定結果と同じ扱いにしない・最初の10記事だけでテストできるようにする記事本文中の旧リンクについて、次を記録します。
HTTPとHTTPS以外が同じURLは、同じ記事の候補として扱います。ただし元URLは消さずに残します。
この章の目的は、単に画像ファイルを新サーバーへコピーすることではありません。
ココログにあった多数の画像表示形式を、WordPressで扱いやすい標準的な形へそろえることです。
ココログの複数の画像表示形式↓表示画像と原画像を特定↓画像をWordPressへコピー↓新しい画像URLを決定↓MTバックアップの画像HTMLを書き換え↓WordPressで扱いやすい単純なHTMLへ統一ココログでは、次のような記述が混在していました。
.shared/image.html?/window.open()class="mb"photos/uncategorizedblog/images_thumbこれらは削除する文字列の一覧ではありません。それぞれが、記事表示用画像、クリック先原画像、ココログ独自の画像表示機能などの役割を持っています。
ココログ側の複雑なHTMLを、基本的には次の形へそろえます。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a><img src="...">：記事中に表示する画像<a href="...">：画像をクリックしたときに開く原画像alt：画像が表示できない場合などに使われる画像説明。元の値があれば残す表示画像と原画像を同じファイルへ統一する場合は、href と src が同じURLになります。
window.open と .shared/image.html?/<a href="http://buran.tea-nifty.com/.shared/image.html?/photos/uncategorized/sample.jpg" onclick="window.open(this.href); return false"> <img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt=""></a>ここでは、
img src が記事中の表示画像href がココログ独自の画像表示ページonclick が別画面を開くための処理です。
.shared/image.html?/ はWordPress側には存在しないため、そのまま残すと、画像は表示されてもクリック時にリンク切れになる可能性があります。
<a href="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg"> <img src="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg" alt=""></a>.shared/image.html?/ を使うココログ独自のリンクを残さないonclick を削除するhref を新しい原画像URLへ変更するsrc を新しい表示画像URLへ変更するclass="mb" があれば削除する<a href="http://buran.tea-nifty.com/photos/uncategorized/sample.jpg"> <img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt=""></a>この形式では、img src と a href の両方を修正します。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a><a href="新しい原画像URL"> <img src="新しい原画像URL" alt=""></a>原画像が非常に大きい場合は、ページ表示が重くなる可能性があるため、少数記事で確認します。
class="mb"<a class="mb" href="旧URL"> <img src="旧画像URL" alt=""></a>class="mb" はココログ側の画像表示機能に関係する指定であり、WordPressではそのまま使う必要がありません。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a>photos/uncategorized 直リンクhref と src が同じ画像を指している場合があります。
その場合は両方を新しい画像URLへ変更します。
<a href="新画像URL"> <img src="新画像URL" alt=""></a>_thumb 方式<a href="sample.jpg"> <img src="sample_thumb.jpg" alt=""></a>sample_thumb.jpg：記事表示用の小さい画像sample.jpg：クリック先の原画像この形式では2つの実ファイルを区別します。
<a href="新URL/sample.jpg"> <img src="新URL/sample_thumb.jpg" alt=""></a><a href="新URL/sample.jpg"> <img src="新URL/sample.jpg" alt=""></a><img src="旧画像URL" alt=""><img src="新画像URL" alt="">クリック先がないため、基本的には src の変更だけで対応できます。
file:/// 参照ココログ以外のサイトを参照する画像は、外部画像として別に扱います。権利や利用条件を確認せず、自分のサーバーへ自動コピーしない方が安全です。
file:///C:/...は、記事作成時のパソコン内ファイルを指していた可能性があります。旧パソコンやバックアップから元画像を探し、見つからなければ未発見として記録します。
例えば次の形で画像を集めます。
upload└─ 2016 └─ 09 └─ sample.jpgサーバー側の配置先は次のようになります。
wp-content/uploads/2016/09/sample.jpg同名ファイルは上書きしません。
sample.jpgsample-2.jpgsample-3.jpgファイル名を変更した場合は、画像対応表の配置先と新URLも更新します。
画像は、記事を本番で読み込む前にアップロードします。
画像対応表を完成↓アップロード用画像を作成↓WordPressサーバーへ画像を配置↓新画像URLをブラウザーで確認↓MTバックアップの画像HTMLを書き換え新URLを直接開き、画像が表示されることを確認します。
https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpgAIには次の処理を依頼します。
画像対応表を使い、MT形式バックアップ内の画像HTMLをWordPress向けの単純なHTMLへ変換するPythonプログラムを書いてください。
変換ルール:1. 記事表示用画像URLを対応する新URLへ変更2. クリック先URLを対応する新しい原画像URLへ変更3. .shared/image.html?/ を使う旧リンクを残さない4. onclick属性を削除5. class="mb"を削除6. border、hspace、vspaceなど古い表示指定を削除7. 元のalt属性があれば維持8. altがなければalt=""を付ける9. _thumbは対応表の指定に従って維持または原画像へ統一10. 外部画像は自動変換しない11. 未発見や複数候補は自動変換しない12. 可能ならHTML解析ライブラリを使い、タグの順番や改行の違いにも対応する
安全条件:・元のMTファイルは変更しない・変換結果は別ファイルへ保存・最初はdry-run・変換前後の例を出力・変換数、未変換数、エラー数を記録・最初の10記事だけでテスト可能・文字コードを維持記事本文には次のような過去記事リンクが残っています。
http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.html画像だけ移行しても、これらを直さなければ過去記事リンクは旧サイトへ飛びます。
実際の移行では次の方法を使いました。
WordPressへ記事を読み込む↓WordPressが実際に作った記事URLを取得↓旧URLと新URLの対応表を作成↓SQLを生成↓phpMyAdminで記事本文を一括更新↓Search Regexで旧リンクの残りを確認SQLはデータベースへ処理を指示する命令文、phpMyAdminはブラウザーからデータベースを操作する管理画面です。この方法は実施済みですが、初心者には難易度が高い方法です。
初心者向けには、WordPressのデータベースを直接変更せず、MTバックアップ側を先に直す方法を提案します。
MTバックアップから旧記事URLを抽出↓HTTrackでリンク先記事を特定↓記事タイトルと投稿日を取得↓新サイトの記事URLの付け方を決める↓旧URLと新URLの対応表を作る↓MTバックアップ内のリンクを書き換える↓WordPressへ少量テストで読み込むただし、この方法は全記事について実施済みではありません。少数記事でWordPressが想定どおりのURLを作ることを確認してください。
同じタイトルの記事が複数ある場合、タイトルだけでは新URLを決められません。
照合は次の順で行います。
タイトル＋投稿日＋投稿時刻タイトル＋投稿日投稿日＋本文冒頭表記ゆれを整えたタイトル手動確認oldurl_to_newurl.csvという名前で、次を記録します。
元の旧URLは消さずに残します。
OKと確認できたURLだけを変換します。
旧ココログ記事URL↓新WordPress記事URL記事本文で昔のURLを説明しているだけの箇所まで変えないよう、<a href="..."> のリンク先を優先して処理します。
旧URLと新URLの対応表を使い、MTバックアップの記事本文中にある旧ココログ記事リンクを新WordPress URLへ変換するPythonプログラムを書いてください。
条件:・元のMTバックアップは変更しない・結果は別ファイルへ保存・最初はdry-run・OKと確認済みのURLだけを変換・要確認、複数候補、未発見は変換しない・httpとhttpsの両方を確認・記事本文の説明用URLではなく、実際のリンク先を優先・変更した記事数とリンク数を記録・最初の10記事だけでテスト可能にする画像→ WordPressサーバーへ配置済み
新画像URL→ ブラウザーで表示確認済み
MT内の画像HTML→ WordPress向けの形へ変換済み
記事内の過去記事リンク→ 新URLへ変換済み、または未確定一覧へ分離済みhttp://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com.sharedimage.htmlwindow.openclass="mb"photos/uncategorizedblog/imagesfile:///_thumb一致した箇所をすべて自動削除するのではなく、画像HTMLやリンクとして残っているのか、説明文に書かれているだけなのかを確認します。
テストには次を含めます。
.shared/image.html?/ を使う記事class="mb" を使う記事_thumb を使う記事10記事↓100記事または1か月分↓全記事の順で進めます。
変換済みMTバックアップを、MT形式に対応したWordPressの読み込み機能で取り込みます。
確認項目は次のとおりです。
問題があればWordPress上で大量に手修正せず、対応表と変換処理へ戻ります。
img src と a href の両方が新URLか.shared/image.html?/ が残っていないかfile:/// が残っていないかMTのimg srcとa hrefを確認↓個別記事HTMLを確認↓月別index.htmlを確認↓元画像名で検索↓.sharedフォルダーを確認↓更新日時を比較↓ファイルサイズと画像サイズを比較↓目視確認見つからない場合は、無理に別画像を割り当てず未発見として残します。
img src だけが新URLになり、a href が旧URLのまま残っている可能性があります。
サムネイルを原画像として使っている可能性があります。画像対応表の表示画像と原画像を確認します。
対応表を修正↓画像フォルダーを作り直す↓MTバックアップを変換し直す↓再検査↓再テストWordPress上だけを手修正すると、再読み込みしたときに同じ問題が復活します。
ココログからWordPressへの移行は、単にMTバックアップを読み込む作業ではありません。
旧サイトを保存↓記事・画像・旧URLの対応表を作成↓表示画像と原画像を特定↓画像をWordPressへ配置↓ココログの複数の画像表示形式をWordPress向けHTMLへ統一↓過去記事リンクを新サイト用に変換↓少量テスト↓本番移行↓旧URL、画像、クリック先、記事内リンクを検査画像移行の本質は、画像ファイルを集めることだけではありません。
ココログに混在していた複数の画像表示方式を理解し、表示画像と原画像を正しく特定し、img src と a href の両方をWordPress用の新URLへ直すことです。
そして、AIにすべてを勝手に判断させるのではなく、確定、要確認、複数候補、未発見を分けて記録することで、移行後の修正と再実行が可能になります。
0