PC関係

PC関係

なんかやらせてみようと色々と

仕事で使う用事もあったし、先日のココログ→wordpress移行記事も少々手直ししたいし、ということで、copilot使うために再課金。

移行記事に需要があるとはあんま思わないけど。

で、ふと思い立ち、アナログゲームのメカニクスをリサーチさせてみたり、
自作の旧作カードゲームのルールとカードを読み込ませてみたり。

かなり深くルールとか理解してるとようなので、本気で恐い。

0
PC関係

秋葉原ちらっと眺めて帰りました

秋葉原HEYで数百円を1時間弱で溶かし、その後、オールドコンピューター系自主展示会?のマイコンインフィニットPRO68K見て、帰りました。

色々、すげーなー、という感想しかでないのがあちこちに。
まー見てもなにがなんだかわからない、て感じのも多かったんですが。

0
PC関係

横須賀で艦船とかいろいろ

する前に、先日投稿した「ココログからWordPressへのブログ移行手引きCopilot・ChatGPT・GeminiなどのAI活用版」に過去記事内の別記事へのリンクの修正について書き加え、再編集をcopilotにやらせました。

なもんで、出発が遅れて、結果10時過ぎに汐入駅到着。
カレー機関の行列に慄いて早々に諦め。
カレー一杯食べて、自衛隊のオータムフェスタを。

昼過ぎ、某氏と現地合流。
巡視船の行列に並んだものの時間的にギブアップしたり、艦これ看板を探したり。

その後、横須賀でちょっと飲んで、新橋でもうちょっと飲んで。

ということで、飲んだくれたのでとっとと寝ます。

0
PC関係

明日は軽く早起きして上京予定なのに

サイドバーの上部にくるくるぱたぱたするウィジェットを置きました。

今日はもう一個、
ココログからwordpressへの移植参考書類を別記事で(copilotに整理させて)投稿しました。
この記事、精査してないし、実際にこれだけでやれるとは思わないんですが、引っかかりそうなところは大体指摘できてるはずなんで、後はAIさんに一ヶ月くらい課金して頼りまくれば、(私が3か月苦労したよりは)ずっと楽になんとかなるんじゃないかと思います。

という訳で、今日でcopilotの課金切れるはず。
さよーならー。

0
PC関係

ココログからWordPressへのブログ移行手引きCopilot・ChatGPT・GeminiなどのAI活用版

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を使う

dry-run とは、実際にはファイルを書き換えず、何件が変更対象になるか、どのように変わる予定かだけを確認する試験実行です。

AIには、必ず次の条件を付けます。

  • 元ファイルを上書きしない
  • 最初はdry-runにする
  • 結果は別ファイルへ保存する
  • 変更予定件数を表示する
  • 変換前後の例を表示する
  • 未発見や複数候補を勝手に確定しない
  • 最初の10件だけで試せるようにする
  • エラー内容を記録する

第1部 旧ココログを保存し、サイトの構造を確認する

1. 自分のココログURLを確認する

本手引きでは、筆者が実際に移行した旧ブログを例にします。

移行時点のブログ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として調べます。

HTTPとHTTPSは別の文字列

次の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のどちらで残っていても見つけやすくなります。

URLを分解して考える

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を確認してください。

AIへの依頼例:旧サイトの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の種類と構造だけを報告してください。

2. MTバックアップを取得する

MTバックアップは、記事をまとめて保存したテキストファイルです。主に次の内容が入っています。

  • 記事タイトル
  • 記事本文
  • 投稿日時
  • カテゴリー
  • 本文中の画像HTML
  • 旧画像URL
  • 過去記事へのリンク

ただし、画像ファイルそのものは入っていません。

元ファイルは、例えば次の名前で保存します。

cocolog_mt_original.txt

直接編集しないでください。

MT内の記事は、例えば次のような形です。

TITLE: 記事タイトルDATE: 09/12/2016 23:31:33CATEGORY: 日記・コラム・つぶやきBODY:記事本文

3. HTTrackで旧ブログ全体を保存する

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└─ photos

4. MTバックアップとHTTrackは役割が違う

MTバックアップ  記事タイトル  投稿日時  記事本文  ココログ上の画像URL  過去記事へのリンク
HTTrack  月ごとの一覧HTML  個別記事HTML  パソコン内での画像参照先  実際に保存された画像ファイル

移行の中心作業は、この2種類の情報を結び付けることです。

MTの記事情報+HTTrackの保存情報+実際の画像ファイル↓WordPress移行用の対応表

5. 作業用フォルダーを作る

MigrationProject├─ backup_original│  ├─ mt│  └─ httrack├─ work│  ├─ mt│  └─ httrack├─ tables├─ scripts├─ output├─ logs└─ upload
  • backup_original:絶対に変更しない元データ
  • work:調査や変換に使うコピー
  • tables:記事・画像・URLの対応表
  • scripts:AIが作った処理用プログラム
  • output:変換後のMTファイル
  • logs:処理結果やエラーの記録
  • upload:WordPressへ送る画像

第2部 記事・画像・旧URLの対応表を作る

1. 対応表が移行の中心になる

主に次の3種類を作ります。

記事対応表MTの記事 → HTTrackの個別記事HTML
画像対応表旧画像URL → 保存画像 → WordPress配置先 → 新画像URL
旧記事URL対応表旧記事URL → 記事タイトル・投稿日 → 新記事URL

2. 記事対応表を作る

画像や旧記事リンクを正しく調べるには、MT内の記事がHTTrackのどの post-xxxx.html に対応するかを特定する必要があります。

照合は次の順で行います。

  1. タイトルと投稿日時が一致
  2. 投稿日時が一致
  3. タイトルと投稿日が一致
  4. 本文冒頭が一致
  5. 手動確認

例えば、MT側が次の場合、

TITLE: C71申し込みDATE: 08/19/2006 14:02:02

HTTrack側の月別ページで、

2006-08-19 14:02↓post-89ad.html

と分かれば、同じ記事として対応表へ記録します。

対応表で使う主な項目

  • 記事タイトル
  • MT側の投稿日時
  • HTTrack側の投稿日時
  • 月別 index.html の場所
  • 個別記事HTMLの場所
  • 本文冒頭
  • 何を根拠に一致と判断したか
  • 確実度
  • OK、要確認、未発見などの状態
  • メモ

AIが扱いやすいよう英語の列名を使う場合でも、読者は意味を理解できれば十分です。

3. 画像対応表を作る

画像対応表には次を記録します。

どの記事にあった画像か↓MTに書かれた表示画像URL↓MTに書かれたクリック先URL↓HTTrackの記事HTMLに書かれた参照先↓実際に保存された表示画像↓実際に保存された原画像↓WordPressでの配置先↓新しい画像URL

ここで重要なのが、img src と a href です。

  • img src:記事中に表示する画像のURL
  • a href:画像をクリックしたときの行き先

この2つは同じとは限りません。

画像対応表には少なくとも次を記録します。

  • 記事タイトル
  • 投稿日時
  • 個別記事HTML
  • 記事内で何枚目の画像か
  • MT側の img src
  • MT側の a href
  • HTTrack側の img src
  • HTTrack側の a href
  • パソコン上の表示画像
  • パソコン上の原画像
  • 画像形式A〜F
  • どの方法で特定したか
  • 確実度
  • WordPressでの配置先
  • 新URL
  • 状態
  • メモ

4. 画像を特定する順番

正しい画像を特定するときは、次の順番を使います。

1. 個別記事HTMLから直接取得2. 月別index.htmlから取得3. 元画像名で検索4. 投稿日時に近い画像を候補にする5. ファイルサイズと画像サイズを比較6. 実際に画像を開いて確認

HTMLから直接分かった結果と、更新日時から推定した結果を同じ扱いにしません。

HTTrackで原画像名が変わる例

個別記事HTMLに次の記述がある場合、

<a href="../../../.shared/image8e08.jpg?/photos/uncategorized/c71cut.jpg">

次の対応が分かります。

ココログ上の原画像名c71cut.jpg
HTTrackが保存した原画像.shared/image8e08.jpg

HTMLから見つからない場合だけ、更新日時、ファイルサイズ、画像の縦横サイズ、目視確認へ進みます。

AIへの依頼例:画像対応表を作る

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記事だけでテストできるようにする

5. 旧記事URL対応表を作る

記事本文中の旧リンクについて、次を記録します。

  • 旧URL
  • HTTPかHTTPSか
  • HTTrackの個別記事HTML
  • 記事タイトル
  • 投稿日
  • 投稿時刻
  • 本文冒頭
  • 判断方法
  • 確実度
  • 状態
  • メモ

HTTPとHTTPS以外が同じURLは、同じ記事の候補として扱います。ただし元URLは消さずに残します。


第3部 ココログの画像をWordPress向けの形へ変換する

1. この章の目的

この章の目的は、単に画像ファイルを新サーバーへコピーすることではありません。

ココログにあった多数の画像表示形式を、WordPressで扱いやすい標準的な形へそろえることです。

ココログの複数の画像表示形式↓表示画像と原画像を特定↓画像をWordPressへコピー↓新しい画像URLを決定↓MTバックアップの画像HTMLを書き換え↓WordPressで扱いやすい単純なHTMLへ統一

ココログでは、次のような記述が混在していました。

.shared/image.html?/window.open()class="mb"photos/uncategorizedblog/images_thumb

これらは削除する文字列の一覧ではありません。それぞれが、記事表示用画像、クリック先原画像、ココログ独自の画像表示機能などの役割を持っています。

2. WordPress側の基本形

ココログ側の複雑なHTMLを、基本的には次の形へそろえます。

<a href="新しい原画像URL">  <img src="新しい表示画像URL" alt=""></a>
  • <img src="...">:記事中に表示する画像
  • <a href="...">:画像をクリックしたときに開く原画像
  • alt:画像が表示できない場合などに使われる画像説明。元の値があれば残す

表示画像と原画像を同じファイルへ統一する場合は、href と src が同じURLになります。

3. 形式A 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側には存在しないため、そのまま残すと、画像は表示されてもクリック時にリンク切れになる可能性があります。

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>

変換内容

  1. .shared/image.html?/ を使うココログ独自のリンクを残さない
  2. onclick を削除する
  3. href を新しい原画像URLへ変更する
  4. src を新しい表示画像URLへ変更する
  5. class="mb" があれば削除する

4. 形式B 表示画像と原画像が別

ココログ側の例

<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>

原画像が非常に大きい場合は、ページ表示が重くなる可能性があるため、少数記事で確認します。

5. 形式C class="mb"

変換前

<a class="mb" href="旧URL">  <img src="旧画像URL" alt=""></a>

class="mb" はココログ側の画像表示機能に関係する指定であり、WordPressではそのまま使う必要がありません。

変換後

<a href="新しい原画像URL">  <img src="新しい表示画像URL" alt=""></a>

6. 形式D photos/uncategorized 直リンク

href と src が同じ画像を指している場合があります。

その場合は両方を新しい画像URLへ変更します。

<a href="新画像URL">  <img src="新画像URL" alt=""></a>

7. 形式E _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>

8. 形式F 画像だけを表示

変換前

<img src="旧画像URL" alt="">

変換後

<img src="新画像URL" alt="">

クリック先がないため、基本的には src の変更だけで対応できます。

9. 外部画像と file:/// 参照

ココログ以外のサイトを参照する画像は、外部画像として別に扱います。権利や利用条件を確認せず、自分のサーバーへ自動コピーしない方が安全です。

file:///C:/...

は、記事作成時のパソコン内ファイルを指していた可能性があります。旧パソコンやバックアップから元画像を探し、見つからなければ未発見として記録します。

10. WordPress用画像フォルダーを作る

例えば次の形で画像を集めます。

upload└─ 2016   └─ 09      └─ sample.jpg

サーバー側の配置先は次のようになります。

wp-content/uploads/2016/09/sample.jpg

同名ファイルは上書きしません。

sample.jpgsample-2.jpgsample-3.jpg

ファイル名を変更した場合は、画像対応表の配置先と新URLも更新します。

11. 画像をWordPressサーバーへアップロードする

画像は、記事を本番で読み込む前にアップロードします。

画像対応表を完成↓アップロード用画像を作成↓WordPressサーバーへ画像を配置↓新画像URLをブラウザーで確認↓MTバックアップの画像HTMLを書き換え

新URLを直接開き、画像が表示されることを確認します。

https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg

12. MTバックアップの画像HTMLを一括変換する

AIには次の処理を依頼します。

画像対応表を使い、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記事だけでテスト可能・文字コードを維持

第4部 記事内の過去記事リンクを新サイト用に直す

1. 記事内リンクも旧ココログを指している

記事本文には次のような過去記事リンクが残っています。

http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.html

画像だけ移行しても、これらを直さなければ過去記事リンクは旧サイトへ飛びます。

2. 実際に行った方法

実際の移行では次の方法を使いました。

WordPressへ記事を読み込む↓WordPressが実際に作った記事URLを取得↓旧URLと新URLの対応表を作成↓SQLを生成↓phpMyAdminで記事本文を一括更新↓Search Regexで旧リンクの残りを確認

SQLはデータベースへ処理を指示する命令文、phpMyAdminはブラウザーからデータベースを操作する管理画面です。この方法は実施済みですが、初心者には難易度が高い方法です。

3. AI活用版として考えられる方法

初心者向けには、WordPressのデータベースを直接変更せず、MTバックアップ側を先に直す方法を提案します。

MTバックアップから旧記事URLを抽出↓HTTrackでリンク先記事を特定↓記事タイトルと投稿日を取得↓新サイトの記事URLの付け方を決める↓旧URLと新URLの対応表を作る↓MTバックアップ内のリンクを書き換える↓WordPressへ少量テストで読み込む

ただし、この方法は全記事について実施済みではありません。少数記事でWordPressが想定どおりのURLを作ることを確認してください。

4. 同名記事に注意する

同じタイトルの記事が複数ある場合、タイトルだけでは新URLを決められません。

照合は次の順で行います。

タイトル+投稿日+投稿時刻タイトル+投稿日投稿日+本文冒頭表記ゆれを整えたタイトル手動確認

5. 旧URLと新URLの対応表を作る

oldurl_to_newurl.csv

という名前で、次を記録します。

  • 旧URL
  • HTTPかHTTPSか
  • 記事タイトル
  • 投稿日
  • 新URL
  • 判断方法
  • 確実度
  • OK、要確認、未発見などの状態
  • メモ

元の旧URLは消さずに残します。

6. MTバックアップ内の記事リンクを書き換える

OKと確認できたURLだけを変換します。

旧ココログ記事URL↓新WordPress記事URL

記事本文で昔のURLを説明しているだけの箇所まで変えないよう、<a href="..."> のリンク先を優先して処理します。

AIへの依頼例

旧URLと新URLの対応表を使い、MTバックアップの記事本文中にある旧ココログ記事リンクを新WordPress URLへ変換するPythonプログラムを書いてください。
条件:・元のMTバックアップは変更しない・結果は別ファイルへ保存・最初はdry-run・OKと確認済みのURLだけを変換・要確認、複数候補、未発見は変換しない・httpとhttpsの両方を確認・記事本文の説明用URLではなく、実際のリンク先を優先・変更した記事数とリンク数を記録・最初の10記事だけでテスト可能にする

第5部 画像と変換済み記事をWordPressへ移す

1. 読み込み前の完成状態

画像→ WordPressサーバーへ配置済み
新画像URL→ ブラウザーで表示確認済み
MT内の画像HTML→ WordPress向けの形へ変換済み
記事内の過去記事リンク→ 新URLへ変換済み、または未確定一覧へ分離済み

2. 旧ココログの記述を検索する

http://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com.sharedimage.htmlwindow.openclass="mb"photos/uncategorizedblog/imagesfile:///_thumb

一致した箇所をすべて自動削除するのではなく、画像HTMLやリンクとして残っているのか、説明文に書かれているだけなのかを確認します。

3. 少数記事でテストする

テストには次を含めます。

  • 画像なし
  • 通常画像
  • .shared/image.html?/ を使う記事
  • class="mb" を使う記事
  • _thumb を使う記事
  • 複数画像の記事
  • 外部画像の記事
  • 過去記事リンクがある記事
  • 同名タイトルの記事
10記事↓100記事または1か月分↓全記事

の順で進めます。

4. WordPressへ読み込む

変換済みMTバックアップを、MT形式に対応したWordPressの読み込み機能で取り込みます。

確認項目は次のとおりです。

  • タイトル
  • 投稿日時
  • カテゴリー
  • 本文
  • 画像表示
  • 画像クリック先
  • 過去記事へのリンク
  • 記事URL
  • 文字化け
  • 改行
  • スマートフォン表示

問題があればWordPress上で大量に手修正せず、対応表と変換処理へ戻ります。


第6部 移行結果を確認し、残った問題を直す

1. 記事の確認

  • 記事数が大きく欠けていないか
  • タイトルが正しいか
  • 投稿日時が正しいか
  • カテゴリーが正しいか
  • 本文が途中で切れていないか
  • 文字化けしていないか
  • 改行が崩れていないか
  • 重複記事がないか

2. 画像の確認

  • 画像が表示されるか
  • 縦横比が正しいか
  • 小さい画像だけになっていないか
  • クリックすると原画像が開くか
  • 別記事の画像になっていないか
  • img src と a href の両方が新URLか
  • .shared/image.html?/ が残っていないか
  • file:/// が残っていないか

3. 記事内リンクの確認

  • 新WordPress記事へ移動するか
  • 旧ココログへ戻らないか
  • HTTP形式の旧リンクが残っていないか
  • HTTPS形式の旧リンクが残っていないか
  • 同名の別記事へ間違って飛ばないか

4. 画像が見つからない場合

MTのimg srcとa hrefを確認↓個別記事HTMLを確認↓月別index.htmlを確認↓元画像名で検索↓.sharedフォルダーを確認↓更新日時を比較↓ファイルサイズと画像サイズを比較↓目視確認

見つからない場合は、無理に別画像を割り当てず未発見として残します。

5. 画像は表示されるがクリックすると壊れる場合

img src だけが新URLになり、a href が旧URLのまま残っている可能性があります。

6. 小さい画像しか表示されない場合

サムネイルを原画像として使っている可能性があります。画像対応表の表示画像と原画像を確認します。

7. 問題を見つけたら上流へ戻る

対応表を修正↓画像フォルダーを作り直す↓MTバックアップを変換し直す↓再検査↓再テスト

WordPress上だけを手修正すると、再読み込みしたときに同じ問題が復活します。


AIを使うときの用語メモ

  • MTバックアップ:ココログの記事をまとめたテキストファイル
  • HTTrack:WebサイトのHTMLや画像をパソコンへ保存するソフト
  • HTML:記事内で画像やリンクの表示方法を指定する記述
  • img src:記事に表示する画像の場所
  • a href:クリックしたときの行き先
  • CSV:Excelでも開ける、表形式のテキストファイル
  • スクリプト:繰り返し作業を自動処理する小さなプログラム
  • dry-run:実際には変更せず、変更予定だけを確認する試験実行
  • 正規表現:一定の規則に合う文字を検索する方法。複雑なものはAIに作らせる
  • SQL:WordPressのデータベースへ変更を指示する命令文
  • phpMyAdmin:ブラウザーからデータベースを操作する管理画面
  • パーマリンク:各記事の固定URL
  • スラッグ:記事URLの最後に付く記事名部分
  • サムネイル:記事表示用の小さい画像
  • 原画像:クリック先などに使う元の大きい画像

最終結論

ココログからWordPressへの移行は、単にMTバックアップを読み込む作業ではありません。

旧サイトを保存↓記事・画像・旧URLの対応表を作成↓表示画像と原画像を特定↓画像をWordPressへ配置↓ココログの複数の画像表示形式をWordPress向けHTMLへ統一↓過去記事リンクを新サイト用に変換↓少量テスト↓本番移行↓旧URL、画像、クリック先、記事内リンクを検査

画像移行の本質は、画像ファイルを集めることだけではありません。

ココログに混在していた複数の画像表示方式を理解し、表示画像と原画像を正しく特定し、img src と a href の両方をWordPress用の新URLへ直すことです。

そして、AIにすべてを勝手に判断させるのではなく、確定、要確認、複数候補、未発見を分けて記録することで、移行後の修正と再実行が可能になります。

0
PC関係

当初目標のウィジェットにしてねえな

昨日の帽子画像、メキシカンハット、て言うそうなんですよ。

昔々、MZ-2000のカタログ等に昨日の画像のような点群で描かれた3Dの帽子?画像が載っておりまして。
ただ、当時、プログラムで動いてたところは見た記憶がない。
なもんで、copilotに画像を見せて「こんなのを描画するスクリプト書いて」て言いました。

最終的に、copilotに作ってもらったのがこちら。
メキシカンハット くるくる比較・開始角選択版

ここにたどり着くまでに結構四苦八苦したけど、結構面白かった。

最初にでてきたのは、緑色の直線で頂点を四角形を結んだワイヤーフレームの3Dで
当時っぽいけど、元画像は点群なので違うだろう、と。

で、点群で描いてもらったんだけど、今度は山の稜線の向こう側にあるはずの点が見えるプログラムで。
元画像はどうにかして陰面処理してるようだ?どうやってる?
つーて、copilotがつくってくるスクリプトにダメ出しし続けて。
この頃は、copilotの陰面処理の提案が割とぽんすけで……

……というあたりはもう延々長いので、copilotにまとめさせました。
以下、暇な人向け。

MZ-2000の「帽子CG」をJavaScriptで再現するまで

昔見たMZ-2000のデモ画面には、帽子のような不思議な立体が描かれていた。その画像をブログ上で再現しようと始めた試みは、やがて当時の描画アルゴリズムを推理する作業へ発展していった。

1.発端は一枚のデモ画面

昔見た帽子状CGを探したところ、MZ-2000のデモ画像を発見。黒背景に緑色の立体を描くJavaScript版の制作を始めた。

2.初期案はワイヤーフレーム

正方形平面の格子点に高さを与え、隣接する点を線で結んだ。最初は一般的なワイヤーフレーム曲面として実装した。

3.帽子の断面形状を設計

中心からの距離で標高を決定。中央高原、浅い窪み、山麓の谷、外輪山、外周の谷を複数の関数で合成した。

4.真横から断面を確認

斜め視点だけでは形を判断しにくいため、真横視点を追加。正方形の対角線に沿った標高を見ながら、山谷の位置と幅を調整した。

5.ワイヤーフレームから点群へ

元画像は格子線よりも、高密度な点の集合に見えた。そこで線で結ぶ方式をやめ、計算した格子点を1ドットずつ表示する方式へ変更した。

6.点群にZバッファを導入

元画像では陰になる部分が見えないため、画素ごとの奥行きを記録。同じ画素に複数の点が重なった場合は、最も手前の点だけを残した。

7.「点では面を隠せない」と気付く

Zバッファが正しく働いても、1ドットが隠せるのは同じ画素の点だけだった。格子の隙間から、曲面の裏側にある点が見えてしまった。

8.セルを面として塗る案を提案

そこで私から、四つの格子点で囲まれたセルを面として塗りつぶせないかと提案。点単位から、ポリゴン的な面単位の処理へ発想を変えた。

9.奥から描き、手前の面で消去

格子セルを奥から手前へ処理し、投影したセル内部を黒く塗った後、四隅の格子点を緑色で打ち直す方式を実装した。

10.Canvas直接描画で消し残り

Canvasは斜めの線や多角形の縁をアンチエイリアス処理し、境界画素を半透明色として合成する。このため、黒い面を重ねても縁の緑が暗く残り、消し残りのように見えた。
さらに表示だけを拡大すると、Canvas内部の描画結果がCSSサイズへ引き伸ばされるため、半透明の境界画素やドットの濃淡が一層目立った。Canvasは内部寸法とCSS表示寸法が異なると拡大縮小される。

なお、image-rendering: pixelated や imageSmoothingEnabled = false は画像の拡大補間を抑える設定であり、Canvasのパス描画そのものにかかるアンチエイリアスを完全に無効化するものではない。

11.メモリ上で完成後に表示

Canvasへ直接描いて消す方式をやめ、ピクセル配列上で最終色を確定してから一括表示した。RGBA値を直接扱うことで、半透明の境界を作らず完全な黒と緑にできた。

12.元のBASICリストを発見

試行錯誤中、元のデモと思われるBASICリストの写真を発見。Copilotに解読させ、モデル形状、視点、座標計算、描画順を推定した。

13.元プログラムは浮動地平線法

Copilotの解析では、元の処理は浮動地平線法に近いとされた。画面各列の上下の可視境界を更新し、その内側へ入る後続の線を描かない方式だった。

浮動地平線法は英語で Floating Horizon Algorithm と呼ばれる一般的な隠線消去法で、二変数関数の曲面を線画として表示する用途に使われる。

14.セル消去方式と元祖方式を比較

同じ帽子形状と視点を使い、セルを黒く塗る面処理と、BASICリストを参考にした浮動地平線法をそれぞれHTMLで再現した。

15.元祖方式は固定視点向き

浮動地平線法は軽量だが、走査方向と視点の関係が重要だった。想定された固定視点では有効でも、自由に回転させると隠線判定が破綻しやすい。

16.三画面切替で回転デモを構想

MZ-2000の三つのグラフィックプレーンへ、方位角の異なる三枚を事前描画。表示ページの切替だけで回転して見せる案を考えた。

17.「くるくる」と「ぱたぱた」

三枚を「1→2→3→1」と循環させる回転版と、「1→2→3→2→1」と往復させる首振り版の二種類を構想した。

18.セル塗りつぶしは実機には重い?

セル方式では、各セルの座標変換、四角形内部の黒塗り、格子点の再描画が必要になる。ブラウザでは動いても、当時のZ80には重すぎた可能性がある。

19.実機らしさは浮動地平線法にある

浮動地平線法なら、画面各列の上端と下端だけを記録すればよい。全面を塗る必要がなく、セル方式より少ない計算量とメモリで隠線を除去できる。

形状再現から、描画技法の推理へ

この試みは、正方形格子を線で結ぶワイヤーフレームから始まった。

元画像との違いから点群描画へ移り、Zバッファによる奥行き判定も追加した。しかし、そこで「点では面の向こう側を隠せない」という根本的な問題に気付いた。

手前の格子点が1ドットなら、隠せるのも同じ画素にある1ドットだけである。格子点の間にある本来の地表面には面積がないため、その隙間から奥の点が見えてしまう。

そこで私から、格子点で囲まれたセルを面として塗りつぶす方式を提案した。これは、点単位の可視判定から、ポリゴン的な面処理への大きな転換だった。

ところが、Canvasへ直接黒い多角形を描いて消すと、境界の緑が暗く残った。原因は単純な「黒塗り不足」ではなく、斜めの輪郭に対してCanvasが自動的に行うアンチエイリアスと半透明合成だった。

そこで、描画途中のCanvasへ黒や緑を重ねるのではなく、メモリ上のピクセル配列で最終的な色を確定し、完成画像だけを一括表示する方式へ変更した。これにより、消し残りや不均一な明るさを解消できた。

そして最大の転機となったのが、元のBASICリストらしき写真の発見である。Copilotによる解析から、元プログラムは浮動地平線法に近い処理を使っていた可能性が高まった。

こうしてテーマは、単に「帽子らしい形を作る」ことから、1980年代の8ビット機が、限られた計算能力で立体をどう表現したのかを推理することへ変わっていった。

4
PC関係

プログラムは書けないけど、仕組み考えるのは結構楽しい

ここ数日、「課金切れるまでにcopilotになんか作らせて、このブログのサイドバーのとこに置いてみよう」と思い、あーだこーだやっておりました。

で、昔のMZ-2000のデモで見たことのある帽子の3D画像、あれを再現したいな、と思い立ち。

調べてみるも、webで見つかったのはカタログのぼやけた写真だけ(この時点では)。
で、copilotに丸投げで「こんな感じの3D物体を点群で画像表示するhtml+Javascriptを作ってちょうだい」つーたら色々作ってくれまして。

今、こんな感じになりました。

もー大体、気は済みました。

0
PC関係

一応の目的は達成したし

ブログの移植、という目的は達成したし、copilotさん目当てにMicrosoft365Premiumを課金し続けるのは違うだろう、ということで10/09で課金切れしてそのまま、ということにしました。

残り期間でもうちょっとなんか作れないかなー、と思い、ちまちまやってます。
元画像の資料どっかに無いかしら?

0
PC関係

ココログからのブログ移転を追試してたんだけど

どうも「最初にココログから画像とかhtmlをクロールするのに失敗してたんじゃないか?」という気がしてきました。

いや、ほとんどいないとは思うんだけど、ココログからwordpressへのブログ移植を志す人が今後いる場合に備えて、ここ3か月の四苦八苦をまとめてみようと思いましてね?

んで、手順をもう一度確認、と思って、

1.記事本体はMT形式でココログから全件出力(ただしこれはテキストソースのみ)
2.HTTRACKで画像をクロール

と、ここまでやった時点で、最初のクロール結果と随分違うことになって。

……これ、ちゃんとクロールできてれば、ここ3か月の四苦八苦の半分くらいは無くなっていたのでは?

という気がしてきてるところ。

まあ実際には、その四苦八苦の結果、最短手順に至れてるのだと思うのですが。

……だったらいいなあ。本当にorz

0
PC関係

他にするべきことがきっといっぱいある

copilotさんに自動ブロック崩し作らせて時間溶かしました。

我ながら何やってるんだろうなあ。

0
PC関係

かなり無駄足も踏んだけど

今日も大体一日copilotさんとやりとりして、ブログ移行、大体終了。

あとは移行案内の記事こっちで作って……、あー、でも、移転先が背景とか模様とか全然設定してなくて真っ白なのはどうにかしたほうがいい?

それはそれとして、まー、移行作業も結構面白かった。
ちょっとした頭脳パズルでしたな。

あと、copilotさん、長時間使ってると疲れてくるのか、生成していないcsvファイルを要求してきたり(説明によると内部で生成していた、とのこと)、ああ、sqlに出すクエリとかpowershellで動かすコマンドの提示にエラーが多くなってくるのがまたなんとも。

人間的?

0
PC関係

買い切り版office買ってるから二重投資になるので嫌なんだけど

blogの移転作業をやってたんだけど、copilotがまた「1 日のチャットの上限に達しました。より上限の高いプランに変更してチャットを続けるか、明日もう一度お試しください。」つーたので今日はここまで。

今から他のAIに持ち込むのも面倒だしなあ。
ひと月分だけ課金OKなら、課金するのも手か?

0
PC関係

課金するなら他のAIのほうがまだリーズナブルかなあ

ぐーたらしたり、用事を片付けたり。

blog移転作業もちょこっと。
……もう作業内容大分忘れちゃったなあ。

ココログ側の日記も移転作業開始時点より増えてるから、その分もバックアップしないといかんし。

作業開始したころは、copilotはなんぼでも話に付き合ってくれてたんだけど、最近は、

「1 日のチャットの上限に達しました。より上限の高いプランに変更してチャットを続けるか、明日もう一度お試しください。」

とか言って相談に乗ってくれないことが多いし。

0
PC関係

単純作業ぽいところは眠くなっていけませんな

ちまちまとブログの移転作業をcopilot先生と。

画像のチェックと移転先指定がようやく半分くらい。
これが終わったら、copilot先生にhtmlの書き換えスクリプトやらを片付けてもらい……

今月中はぎりぎりかなー。

0
PC関係

明日も仕事だし艦これのメンテだし

今日もAIさんと偽装jpgファイルと記事中画像のマッチング&リネーム処理について相談。

今日のcopilotさんはなんか頭悪かった。
まだ問題解決までは行ってない。

というかこれ、無理めりマッチング率高めのスクリプトを吐き出させようとする努力よりも、ぼちぼち手で対応付けていったほうが早い時期のような気がしてきました。

……寝よ寝よ。

0
PC関係

て書いてからそのまま椅子寝してた。現在08:00

今日も今日とてココログからの引っ越し作業。

記事のほうにはサムネイル画像のファイル名が残っているけれど、画像本体はimage-???.htmlてなってる偽装jpgなので、
これを500個くらいあるimage-???.htmlとどうやってマッチングさせるか?という作業。

幸い、image-???.htmlにはタイムスタンプが残っていて、記事投稿前後に生成(偽装)された画像だとわかる。
であれば、記事の投稿日時(これは記事htmlの中に書かれている)と近いimage-???.htmlがあれば、
そのサムネイル画像のファイル名をひっぱってimage-???.htmlにあてはめてやれば良い。
記事中に画像が1個しかなければ1対1対応なので、そのまま名前を変えてやれば良い、と。

ただ、同じ記事に複数画像あると、順番通りに生成したかわからないので(記事作成中にアップロードだけして記事中では使わなかった画像も保管されていることがわかったので)、そこは手作業で対応させなければならない。

ただまあ、記事と候補画像をまとめてくれれば、目視確認でなんとかなるんじゃないか?
てことで、記事の投稿日時と近い時間に生成された偽装jpgをまとめて、htmlで表示するスクリプトをcopilotさんに作ってもらいました。

もらいましたが、ココログの仕様なのか、同じ記事のバックアップファイるが作成されてて、それを除外しておかないとマッチング作業がやりにくい。

ということで、記事のバックアップファイル(記事のファイルネームがXXXX.htmlだとするとXXXX-1.html、XXXX-2.htmlのようになっていた。
これを選択して避けるスクリプトをcopilotさんに……書いて動かしたら、なかなか期待通りにならず、えらく時間かかりました。

なんだよう正規表現て!
\なんてどうやって入力するんだよう!

という訳で、本題ではない作業で今日はおしまい。おやすみなさい!

あーえー、X/twitterは今日もダメでした。

0
PC関係

相談するにもそれなりに知識とか理解は必要だとは思うけど

こちらのココログ、画像の格納方式が二パターンあるようでして。

普通のはjpgなりpngなりのファイルがそのまま格納されてて、このパターンだとそこらのブログバックアップツールでバックアップできます。

問題なのは、、

<a href="https://buran.tea-nifty.com/.shared/image.html?/photos/uncategorized/YYYY/MM/DD/1805_aaa.jpg" class="mb"><img alt="1805_aaa" title="1805_aaa" src="https://buran.tea-nifty.com/blog/images/YYYY/MM/DD/1805_aaa.jpg" width="300" height="450" border="0" /></a>
</p>

みたいに書かれてるのがあって、https://buran.tea-nifty.com/.shared/の中にimage-1.html、image-2.htmlという具合に番号が割り振られてるファイルが転がっております。
これが実は拡張子変えただけのjpgファイルで。

サムネイルをクリックすると、そのjpgが表示される仕組みなんですが、こちらのパターンはそこらのブログバックアップツールだと拾えなくて(小さいサムネイルだけ取れてた)、往生してたんですが、copilotに相談したところ、python使ってクロールするスクリプト書くから使えよ、とか言い出しまして。

やりました。

結果。全部バックアップ取れたぽいです。
06/25から相談しつつこの作業やってたんで、休み休みですが、おおよそ一週間でどうにかなりました。

SHARP X-1のHu-BASIC以来コンピュータ言語なんて触ったことの無い人間になにさせやがるんだ。
自分じゃ一行も書いてないけど。

続きも、ブログ記事ソースとファイルネームとの対応もスクリプトとか書いてくれるそうなので、なんとかなる見込みが。

今日はもう寝ます。

2
PC関係

WordPressよくわからない(今日はそこまで作業できてません)

blogの移転作業を延々と。

ココログの仕様が時期によって変わってるんで、画像の扱いがまちまちで往生しまくり。
仕事さぼりつつ8時間くらいcopilot等に相談しながらあれこれやったものの、結局、500個超の画像ファイルを手作業でリンクしなきゃいけないことが判明しまして(copilotは微妙に違う見解)。

というか放置してても、ココログにある画像を取りに行って取れちゃってるので、niftyのメールアドレスを維持してる限りココログも維持される(サービス終了までは)んで今の所は困らない。てことで諦めました。

とりあえずblogの見た目とか作業環境のほうをまとめて、とっとと移行できるようにしたい。

X/twitterは見込みなし。

あ、目は大分良くなりました。明日明後日に病院行って、okをもぎ取りたいところ。

0
PC関係

課金しなくてもまーまー使えるし

ここ一週間くらい、主に使ってるデスクトップPCのWiFiがぶちぶち切れるので、原因追及。

結果、Copilotに相談した際にちょこっと出てたWiFi6をルーター側でオフにする、という方法で解決。
調べものもこんな感じだと未来感ありますなあ。

勿論、平気で嘘をつくこともあるのは飲みこむものとして。

X/twitterも目も改善の兆しはなし。



0
PC関係

twitter名義で送られてきた文面なんかもあって

色々やって、「Xの自動化システムは違反に該当しないと判断したため、アカウントの機能制限が解除されました。」てメールが届いたものの、制限が解除されてない状態。

フォームで再申請しようとすると、「元のケースはすでにキュー内にあります。元のケースに関して弊社からの返答をお待ちください。」とか言われて送信できない。
んで、届いたメールのほうに返信はできたので、そちらに「制限解除したつーてるけど、まだ制限されたままだよ、どうにかして!」てメールを送ったところまで。

copilotは3-7日くらいかかるんじゃないか?つーてるけどどうなることやら。

0
PC関係

Dynabook VZ72/BでAESペンを使う話(後編)

……で、単6電池をAmazonでポチり、電池を交換してみたんですがそれでもダメで。

「あれ、これペン先の芯の所がダメになってるんじゃ?」と思いついたのが昨日のこと。
……いや、実際にはだいぶ前からその可能性はあると思ってたんですが、そう思いたくなかったというか。

とりあえず、「芯の刺さり具合がダメな可能性」を考慮して、芯を抜いて刺しなおしてみようと。

芯飛ばしてなくしました。

長さ1.2cm×太さ0.1cm程度の黒いプラスティックですからねえ……。
見つからない見つからない。

それでも「確か予備の芯が
Dynabook VZ72/Bには添付されてたはず」だったのを覚えておりましたのであまり焦らず、マニュアル類を放り込んでた場所をひっくり返しまして。

……見つかったのは上記の芯より若干太い芯と若干細い芯で。
……もっと昔に使ってたHPのtx2505のペン芯と、dynaPad NZ72/TG のペン芯でした。

あとついでにdynaPad NZ72/TGの予備ペンも。

「ダメかー」と思い、Dynabook VZ72/Bのアクティブ静電ペンPADPN004の替え芯とか互換品が無いかを探しておりましたところ、「WACOM AES」に対応しているペンであれば使える可能性がある旨の記載があるページを発見。

dynaPad NZ72/TGのペンを見ると「AES stylus with 2 side switch」との記載が。

試してみました。

使えました。

ClipPaintExでも筆圧は感知してるぽいです。
傾きは感知してないようなのでこれもPADPN004同様にAESの1.0なんだと思います(同メーカーのより古い機種なんで当然か)。

自分の使い道としては傾き感知は無くてもあんま困らないので、十分だと思います。

難を言うなら、VZ72/B自体が大分時間経ってて、バッテリが死にかけてる&CPU性能が今となっては少々物足りないことですが、まあ。

0
PC関係

おわらねー

よーやく新PCの梱包を開けて、セットアップ始めました。

とりあえず、仕事とか作業でも使うんで、Adobe Creative Cloudを……、て思ったら、何故かインストールできなくて。

しばらくあーだこーだといじってたんですが、結局、インストールできなかったのは、「Windows Updateが実行されておらず、最新のWindowsの状態じゃ無かったから」ぽいです。
そのあたり一通り設定して、ようやくダウンロードが出来ました。

が、まあ、もうこんな時間ですので、セットアップの続きはまた明日(行以降)。



0
PC関係

予算は一応確保したので

今のPCやっぱり調子悪いし、blenderとか使うにはもうちょっと性能あってもいいし、などと考え、消費税上がる前に買ってしまおうかな、と。

問題は今の PC のデータで、適当に放り込んでたせいで、同じファイルの時期違いのやつとかがぐちゃぐちゃと。

ちまちまHDDの整理中なんだけど、このペースだと消費税増税前には絶対終わりそうにない。

なるべく今のハードディスクをそのまま新PCにぶら下げるような真似はしたくないんだけどなー。


0
PC関係

Excelで表作り直すしか無いのだろうけれど、利用頻度低いので手間かけたくもないし

職場のPCが不調で、新しいのを調達したのは良いのですが、Lotus1-2-3がインストールできなくて往生しました。

年に一度くらい使う古い1-2-3のワークシートがExcelだとうまく動かないんですよ。
ある日から別のある日までの年数、月数、日数を算出するDATEINFO関数は他の計算式でできるようになったんですが、Vlookup関数の動作が違うのが解決できてなくて。

従来のPCはダウングレード版のWindows7だった時にLotus1-2-3をインストールしてて、その後Windows10に上書きインストールした結果、そのまま1-2-3も動いてたんですが、新しいPCは最初からWindows10なもんでインストール出来ず。

なもんで私物PCでとりあえずどうにかしたんですが、今後はどうしたものかと。

VMware Workstation PlayerにWindows7環境作ってそっちにインストールするか、とも思ったのですが、営利目的だと無料てわけにはいかないみたいだし。

2
PC関係

2リットルペットボトル×15本と考えると無理ぽいのがわかるでしょうか

職場で使ってたA3のインクジェット複合機を、A4のカラーレーザー複合機に変えてみました。

最近A4ばっかりだしA3は職場の他のプリンタあるし、お値段5万円くらいで両面自動印刷対応だし、出来が悪く無ければ自宅用に同じの買おう、とかいろいろ思ってたんですよ。

んで、職場経費で買い換えて実物見た結果、自宅導入は断念しました。
いや、性能的には文句無かったんですが、これ、本体重量が29kgあるって言うんですよ。A4機なのに。
今まで使ってたA3インクジェット複合機が16.5kgなんでおおよそ2倍。

結局、一人だと机に乗っけられなかったんで、階段を担いで登らないといけない自宅導入は無理だなあ、と。

……多少筋トレしても無理だろうなー。

2
PC関係

大きめのプラワッシャかなにかでネジ留めできるかもしれませんが

諸々のファイルを4TBのHDDに一応コピーできたようなので、旧データHDDをケースから外して、新HDD(4TB)に換装。

……と思ったら、3.5インチベイのレールにドライブ(の入ったスロット)を固定しているピンがうまく外れない。
レール側にゴムワッシャみたいなので支えられたピンがあって、このピンをドライブのねじ穴に射し込んでドライブを固定する方式なのですが、このPCの購入当初は「防振にもなっているし、ねじ回し不用で、よくできた構造だなあ」とか思ってたんですよ。

んでも長年の使用でゴムが劣化してて、ちょっと力入れて外したらゴムワッシャがちぎれちゃって。

Kimg0280

(左側がちぎれたゴムワッシャ&ピン。右側の2本だけが一応ちぎれてないゴムワッシャ&ピン)

結局、ケース内にあったベイ3本分レールから寄せ集めて、新HDDを固定するゴムワッシャ&ピン4本を用意しました。
ケースの輸入代理店サイトとか見ても、このゴムワッシャ&ピンとかドライブ固定用レールとか、オプションで売ってませんでしたし。

という訳で、今後、このPCでドライブ交換する時は往生するだろうなあ、と。

その時は買い換えかねえ……まだ使えると思うんだけどなあ……。

0
PC関係

原因はよくわからないけれど

USB3.0のメモリカードリーダーとSamsungのmicroSDXCを買ったので、手持ちのmicroSDXCカードとかの速度をちょっと比べてみよう、と思い立ったのですが……。

なんか2枚ばかりmicroSDXCカードを認識しない……。

Androidタブに入れてたのが悪いのか、Nintendo Switchに入れてたのが悪いのか?それともカメラ?

microSDのスロットがあるWindowsタブレットで読み込ませた所、「セキュリティで保護された記憶域デバイス」とか表示されて、中身も見えるけど、他の機器だと認識しない。

てな訳で、とりあえずWindowsタブレットのフォーマットでexFATにしてみたところ、一枚はちゃんとメモリカードリーダーでも認識。
もう一枚は、フォーマットが終わらないとりあえず明日朝までこのまま放置して、それから確認かな、と。

という訳で、書き込み速度は判定できず。
そのうち再挑戦します。

0
PC関係

再起動&再起動

なんか、PCが再起動を繰り返すので、調べてみたらKB4056894の不具合にひっかかったぽくて。

AMDチップじゃないんで、DiXiM Digital TV Plusのほうでしょうか。

随分昔からTV録画機側がDLNAに対応してないやつにしちゃってたし、テレビ放送で観たいものもあんまり無いんで、アンインストールしちゃえば問題無くなるんですが、当時代金支払って買ったはずのソフトウェアなんでそれもなんか悔しい。


2
PC関係

まともに修理すると高いしなあ

こないだ取り替えて余ったメインPCで使ってた240GのSSDを、ThinkpadX201sに換装してみました。

電源投入>>起動は速くなったんだけど、メーカー製ユーティリティの動作が重々しいのはあんま変わらない印象。
暇見て、個別にアンインストールしてみよう。

問題は、このX201s、バッテリがへたってる&バッテリ固定爪が折れてる、んで使うのやめたんですが(そのため、キーボード付きのwindowsタブレットを買った)、どう使おうか?

重量的には(ACアダプタ除けば)似たようなものなんで、旅先に持ち歩いて、カメラのデータバックアップ先に使えないか、とも思うんですが、それにしてはSSDがちと容量不足だし。
ポータブルHDD持ち歩くんじゃタブレットでも一緒だしなあ。

Expresscard用の大容量SSDとかどっかに転がってないかしら。

カメラのデータバックアップ機にするなら、SSHD買ってきて換装するのが一番だとは思うんですけどね。

0
PC関係

特に速くなったとかいう気はしませんが

PCのSSD(Crucial m4 256GB)が残り容量わずかだったので、同社のCT500MX200SSD1(500GB)を先日通販で購入。
今日届いたので換装作業してました。

SSDを新旧2台ともSATA接続して、付属(ダウンロード用シリアル添付)のクローンソフトで、旧SSDから新SSDへ10分少々でコピー完了(パーティションサイズも同時に変更できた)、付け替えて、換装作業終了。

かなりあっさりと終わったんで、ちょっと拍子抜け。

当初、新SSDをUSB接続しようとして、手持ちのSATA~USB接続ケーブルを使おうとしたら、SATAの電源コネクタが割れてて、使えなかったのは少々悔しかったのですが。

0
PC関係

このまま朝まで放置の予定

件の廃棄PC、128GBでは常用するのに辛いので、通販でSEAGATEの2TBのSSHD、ST2000DX001を10,346円(税込) で購入しまして。

起動ドライブ以外にHDDを積めれば、そのまま128GBのSSDでも運用できたとは思うんですが、メーカー製の一体型PCだったんで、HDDを追加できる空きベイも無いし、SATAコネクタも足りないし。
ただ、SSDに慣れてるとHDDの速度はちょっとしんどいので、間をとって、起動はSSD程じゃないけどそこそこ速くなるというSSHDにしてみました。

んで、今日届いてたので、早速組み込んでみました。

今の所、リカバリまでは順調に。
今現在、WindowsUpdateをかけてるとこですが、この辺りはこないだSSDでやったときも同じくらい時間かかってたので、速いとか遅いとかはまだわかりませんなー。

2
PC関係

Pavilion x2 10の問題点

先月、上司の持ち歩き用に買ったPavilion x2 10なんですが、問題があることがわかりました。

ノートPCでよくある仕様で、ファンクションキーに音声ボリュームとか液晶の明るさ調整とかの機能キーが割り振られているのですが、これが「Fnキーを押した時」じゃなくて、「Fnキーが押されていない時」に機能キーになっている。
つまり、普段はファンクションキーになってない、てことがわかりました。

日本語入力してるとF5~F10あたりは頻繁に使うので、「その都度Fnキーを押して」とかやってられません。

HPの他機種にはBIOSで「普段はファンクションキーとして動作する」設定ができる機種もあるのですが、この機種のBIOSにその設定項目はありませんでした。

あちこちいじって、英語のフォーラムとかまで見たんですが、結局解決はせず。
(回答者がキーボードドライバを削除して、再インストしなさい、とか書いてて、解決してない)

HPにBIOSのアップデート要望でも出すとして、当面はBluetoothキーボードでも使うようにするしか無いですかねえ。

そうすると持ち歩きのうまみが大分なくなっちゃうんですが。

3
PC関係

他メーカーも連鎖撤退すると恐いし

太陽誘電が光メディア撤退だそうで。

言われれば、最近録画用以外は買ってない。
昔はデータ引き渡しの時にちょこちょこ焼いてたのに、今はメール添付とかGoogle Cloud経由で渡してるから、全然使わなくなったもんなあ。

フロッピーの時も後でちょこちょこ必要になって困ったし、少し買い溜めしとくべきでしょうか。

1
PC関係

H027を試して見ました。使用量>充電量なのか?

こないだ秋葉原で税込み\2101で買ってきた、各社Windowsタブレット用、本体充電機能付きUSBハブ「H027」を手持ちのAcer W4-820で試してみました。

結果、USBハブとしては使えたものの、使用中本体への充電+USBハブ利用はできませんでした。

普通に本体使用中に電源に接続しておくと、「○○%が使用可能です(電源に接続:充電しています)」て表示がでていたのですが、H027を挟むと、「残り:○○%」てバッテリを使ってる旨の表示に切り替わりました。

H027を挟むと、シャットダウンした状態で給電しても、電源SW横の充電ランプも赤点灯しなくなりましたし。

まあ、電圧の低いACアダプタに繋いだ時は、充電されていても充電ランプは赤点灯してくれなかったんで、繋いでいれば微妙に給電してくれている可能性はあるんですが。

0
PC関係

ケーブル無くてもマウスって言うのは、なんかもやもやしませんか?

探してみたら、ホイールの可動部分を無くしたマウスてのもあったようで。

更に探してみたら、無線(非BT)だけど、箱汚れ品が980円送料込みで売ってたので、とりあえず注文してみました。

まあ、投げ売りされてた商品なんで、過剰な期待はしないで待ってみます。
当たりだった時のうれしさが倍増しますし。

0
PC関係

詳しい人求む

結局、旧PCのHDDに置き忘れてたファイルは、FileSeekerてフリーウェアを使って、拡張子で検索してコピーすることに。

てか、Windows7のフォルダ右上にあるファイル検索窓だと、あるはずのファイルが何故か検索に引っかからないんですが、どなたか詳しいことプリーズ!

まあ、今回は上述のFileSeekerでどうにかなったんで、どうしても必要、てわけじゃないんですが、なんか気味が悪くて。
つーか、後でコピーしたファイル自体が検索窓でひっかからなくても困るし。

2
PC関係

艦これのデイリーはあらかた片付けたけど

出張先まで(仕事では使わない予定の)ThinkpadX201sを持ってきた挙げ句、電源ケーブルを忘れてきて、残り33分とか言われているこの状況。

つーか、このバッテリ放置しすぎたのか、残り64%で36分とか言うてやがりますし。
前に言った、バッテリ固定部品が壊れただけじゃなくて、液晶部分とキーボード側のコネクタもはがれたか何かしたのか、フィルム部が露出してるし。

真剣に修理するか、なんか適当なの買うか、検討しないとなあ。

0
PC関係

おーぱっけらまーどーぱっけらまーどー

ThinkpadX201のバッテリを固定してる部品が壊れてました。

こないだ、珍しくLサイズバッテリなんぞつけて移動してたら、出っ張りがどっかにひっかかったんじゃないかと。

困ったことに、バッテリがきっちり固定されてくれないんで、修理に出すべきかと思うのですが、料金表見ると、ちょっと躊躇するお値段で。

テープかなんかで固定するかなあ……。

0
PC関係

M4

先日から作業環境をwin7機に切り替えたんですが、なんか時々引っかかるような?

起動ドライブがSSDなんで、プチフリーズかとも思ったのですが、OSインストール前に対応済みファームに書き換えたような記憶があるし?

書き換えたのは別の不具合対応ファームだったかもしれないんで、もうちょい調べてみるべきでしょうか。

まあ、致命的じゃなきゃ、しばらくは放置ですが。

0