2014年5月31日土曜日

Windows Live メールからMac Mail.appへのマイグレーション

移行アシスタントをなんとか使えるようにしてメールとかをmacに移行したにも関わらず、結局文字化けして使い物になりませんでした。

だめだめですね、移行アシスタント。

てなわけで、Windows Live メールからMail.appへのマイグレーションだいさくせ~ん!の開始です。

まずWebで調べるとThunderbirdを中継するのが鉄板な方法らしいです。

(1)WindowsのThunderbirdに「ImportExportTools」アドオンをインストール
(2)Windows Live メールでeml形式ファイルにエクスポート
(3)WindowsのThunderbirdにImportExportToolsをつかってインポート
(4)WindowsのThunderbirdでmbox形式にエクスポート
(5)macにmbox形式ファイルをコピーして改行コードをCRLFからLFに変換(tr -d \r)
(6)macのMail.appにインポート

一応、この方法試してはみたけど、それでもまだ文字化けが発生するメールが存在しました。
確認してみたら(3)の段階で文字化けしているメールがありました。
emlファイルの内容を確認したら、Content-Typeのcharsetにiso-2022-jpと指定していながら、本文がShift_JISなんていう、めちゃくちゃなものでした。

そういえば、昔のメーラーにはそんな愉快なメールを送信してくれるのも存在してたなぁ。
Windows Live メールとかOutlook ExpressとかはContent-Typeの指定なんか無視して表示していたから、なんら問題もなかったんだね。

てなわけで、Thunderbirdを使ったマイグレーション大作戦は大失敗に終わりましたとさ。

まぁ、これで終われたら楽なんだけど。

奥さんが「だんなさんなら何とかしてくれる!」なんて目で見るんです。

てなわけで、おうちで転がっているLinuxを使って、変換プログラムでマイグレーション大作戦りた~ん!です。普通のおうちにはLinuxなマシンなんて転がっていないと思うので、まったく転用が利かない話になってしまいますが。

さて、要はemlファイルからContent-type: charset="…"のを拾って、それに併せてnkfで変換してあげれば良いのです。
ついでに改行コードもLFにしてformailでmbox形式に変換までしちゃいましょう。的なタクティクスで。

で、作った変換スクリプトのソースが以下の通り。ちょっぴり長くなっちゃったけど。

---------------------------------------------------------
#!/bin/bash -f

#メール変換のメイン処理ループ
function mailconv_main() 
{
  # カウンター設定
  max=`ls *.eml|wc -l`
  cnt=1

  # ファイルがなければリターン
  if [ $max -eq 0 ] ; then
    return
  fi

  #出力mboxファイル名の設定
  arc="`pwd`".mbox
  rm -f "$arc"

  #カレントディレクトリemlファイル読み込み
  for item in *.eml
  do
    #ファイルが存在しなければ次のループへ
    if [ ! -f $item ] ; then
       continue
    fi
    opt=""
    #メールからContent-Type text/plain; charset=の行を取得
    contenttype=`perl -p -e 's/;\r\n//g' < "$item" | grep -i 'Content-Type:.*charset=' | head -1` 
    if [ ! -z "$contenttype" ] ; then
      #charsetの指定から文字コードを取得
      charset=`echo $contenttype | sed -e 's/.* charset=\(.*\)/\1/' | sed -s 's/"//g' | tr [A-Z] [a-z]`

      #文字コードに併せてnkfのオプションを設定
      if [[ "$charset" =~ utf-8 ]]; then
        opt="-w";
      elif [[ "$charset" =~ iso-2022-jp ]]; then
        opt="-j";
      elif [[ "$charset" =~ us-ascii ]]; then
        opt="-j";
      elif [[ "$charset" =~ iso-8859-1 ]]; then
        opt="-j";
      elif [[ "$charset" =~ shift_jis ]]; then
        opt="-s";
      elif [[ "$charset" =~ windows-31j ]]; then
        opt="-s";
      elif [[ "$charset" =~ cp932 ]]; then
        opt="-s";
      elif [[ "$charset" =~ euc-jp ]]; then
        opt="-e";
      else
        echo "Unknown Charset : $item : $contenttype : $charset"
      fi
    fi
    if [ -z "$opt" ] ; then
      # jis, shift_jis, utf-8に当てはまらない場合はjisを指定
      opt="-j"
    fi
    #変換対象の表示
    echo "$arc : $cnt/$max $opt"
    # nkfを使用して文字コードを変更 -m0を指定する
    nkf -m0 -Lu $opt $item | formail >> $arc

    #カウントアップ
    cnt=`expr $cnt + 1`
  done
  return 0
}

#カレントディレクトリ以下のディレクトリを検索
find . -type d | while read directory
do
  pushd "$directory"
  #変換メインをコール
  mailconv_main
  popd
done
---------------------------------------------------------
後は出来上がった*.mboxファイルをmacにコピーして、Mail.appでmbox形式のインポートをするだけっと。

とりあえず、奥さんのメール2万通ぐらい変換しても文字化するようなメールは見つかってないからこれで大丈夫かな。
macでもnkfをインストールすれば使えそうなきがするけど、どうなんだろう。
sedとかperlとかformailは使えるみたいだしね。
nkfの代わりにiconvを使うという手もあるだろうけど、iconvは文字の自動認識がないから難しいだろうなぁ。

【今日の結論】
nkfさまさまだね。

2014年5月21日水曜日

Mac Book Proがおうちにやってきちゃった

奥さんがMac Book Proを手に入れた。Mavericks‎でRetinaなご機嫌なやつだ。


なんでも、友達の仕事の手伝いをしているので、その友達が貸し与えてくれたらしい。
なので、うちの家計からの出費は0である。
持つべきものは人脈なのである。
うらやましい限りのリア充なのである。
自分はまったく縁がないけど。

で、早速セットアップのお手伝いを、
「だんなさん、素敵!!」
という目でお願いされて、嬉々としてやることになった。
どうやらWindowsからMacに完全移行してしまう気らしい。

てなわけで、本日は長文にて格闘記なんか書いてみる。

まずはWindowsからMacへのデータ移行から。
Macにデータを持っていくのには、いの一番に「移行アシスタント」を使ってデータ移行をしてしまうのが良いらしい。まぁ、ものの本によるとだけど。

で、早速移行元のWindowsにAppleサイトから移行アシスタント(Windows Migration Assistant)をダウンロードしてセットアップ。
そのほかにも以下の手順を実施した。

・WindowsのマシンにはEthernetが装備されていたので、Wi-fi等を無効化して、Ethernetオンリーに変更。
・WindowsUpdateを無効化(しないと移行アシスタントで警告が表示される)。
・電源管理でスリープを無効化。
・ウイルス対策ソフトをアンインストール(スキャンを無効化するだけでもいいかも)。
・msconfig.exeを起動して、スタートアップ、サービスの内容を必要最低限が起動されるように設定。

こんな具合に、ネット上でやっておけばいいこと調べて実施した。

で、万全を期して移行元Windowsで移行アシスタントを起動!。

Windowメールうんたらかんたらのダイアログが表示されて、Windowメールが起動中だからというメッセージで移行アシスタントが途中停止っと。

・・・・。
さすがアップル。Windowsメールなんて使ってないのだけどね。まぁ、Windows Liveメールはつかってるから、その性かな。

とりあえず、再度実行して、Windowsメールの整理なんたらかんたらのダイアログでおもむろにキャンセルすることに。
すると、Macから接続待ち画面に何とか遷移できるようになった。
これで移行元のWindowsの設定は完了と。

さぁ、お待ちかねのMac Book Proの起動!
充電もばっちりだ。

「ば~ん」
あぁ、感動の起動音。
しばし、その音に酔いしれる。

とりあえずは画面の指示に従って、ロケールやことえりの設定する。

MacにはEthernetが無いので、Wi-fiのセットアップを実施。
別のPCから無線LANルータの管理画面で確認したところ、見慣れないMACアドレスの無線クライアントが接続していることが確認できた。
おそらくMac Book Proだろう。
DHCPでIPも振られているし、pingで接続確認もできた。MacのWi-fiの設定に問題は無さそうだ。

だが、ここからが長かった。本当に長かった。
Windows側で移行アシスタントが待ちになっているのにも関わらず、Macでは次のステップの移行元の検出でWindowsが表示されない。検索されない。移行元が全く認識されないのだ。
待てど暮らせど検索画面に出てこない。

さすがアップル。

で。Windowsをセーフティーモードで立ち上げたりとか、ファイアウォールを無効化したりとか、ありとあらゆる手を尽くした。

で、最後の手段とばかり他のWindowsPCに移行アシスタントをセットアップしてみると、このPCはチャンと検出された。
でも、肝心の移行元のWindowsは検出されない。
とりあえず、Mac側には問題なく、原因は移行元のWindowsだと、仮断定することに。
なのでWindowsの設定を再度確認っと。

で、そうこうしているうちに3時間経過。しかしもって、まったく移行元は検出されない。

それでもなんとか、移行アシスタントのログが
C:\Users\<ユーザ名>\AppData\Local\Temp\SystemMigration.log
にでていることが判る程度までにはたどり着いた。

正常に検出されたWindowsのものと比較してみると、ログのなかに
SMBonjour: DNSServiceRegister failed: -65563
という一文が出力されているのに気がついた。

正常ならば、
SMBonjour: Published AL-41368482 on 1050
と出力されるはず。

Bonjourって、iTunesをネット越しに同期とるとかに使うやつだよね。
Apple版Computer Browserみたいなやつだよね。
よくわからないけど。

上のメッセージの前にバージョンも出力されているので、確認してみると、明らかに検出されるWindowsと違う。
どうやら、ず~と前にiTunesをインストールした際のバージョンがそのまま使われているらしい。
もしかして、これが原因か?

で、ものは試しとばかりに移行元のWindowsの「プログラムと機能」からBonjourをアンインストールして、再度移行アシスタントをインストールしてみることに。
すると移行アシスタントのインストールでBonjourも一緒にインストールされているのが確認できた。

で、自動的にアシスタントが再実行された。
今度は即座にMac側に移行元WindowsPCが検出されましたとさ。

判ってしまえば、なんてことない、単純な解決策。
世の中のトラブルシューティングなんてこんなもんだよね。

その後は順調にデータ移行中。
あとは、寝て待てというか、さすがに奥さんが監視するらしい。

なので、今日はここまで。

明日からはMacのお勉強だね。


【今日の結論】
Appleの製品をインストールするときは、Bonjourを前もって必ずアンインストールしましょう。