今年もぼちぼちとね。
2015年1月1日木曜日
2014年10月8日水曜日
2014年9月28日日曜日
箱根までドライブ
今日は箱根までドライブ。
新車の香りが車内に漂う、86でドライブです。
8月にネーミングライツで名前の変わったMAZDA(旧TOYO)ターンパイクを登って、大観山駐車場まで。
街中ではそれほど見かけない86ですが、行くとこにいけば、それなりに見かけるんです。
まぁ、ポップする場所はかなり限定されていますが。。。
ご覧のとおり、期せずして、86オフ回の様相と相成りました。
まぁ、お互いに見ず知らずの人たちでしたが。
それにしても、86ナンバーな86多いなぁ。
さて、今日の天気は絶好のドライブ日和でした。
珍しく、富士山の全容見れたし。
帰りは山中湖を回って、道志の道で相模まで。
狭いし、収納ないし、エンジン音うるさいし、サスペンション硬くてガタガタするし。
決して快適とは言えませんが、乗っていて、かなり楽しい車です。
2014年6月14日土曜日
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形式に変換までしちゃいましょう。的なタクティクスで。
で、作った変換スクリプトのソースが以下の通り。ちょっぴり長くなっちゃったけど。
---------------------------------------------------------
後は出来上がった*.mboxファイルをmacにコピーして、Mail.appでmbox形式のインポートをするだけっと。
とりあえず、奥さんのメール2万通ぐらい変換しても文字化するようなメールは見つかってないからこれで大丈夫かな。
macでもnkfをインストールすれば使えそうなきがするけど、どうなんだろう。
sedとかperlとかformailは使えるみたいだしね。
nkfの代わりにiconvを使うという手もあるだろうけど、iconvは文字の自動認識がないから難しいだろうなぁ。
【今日の結論】
nkfさまさまだね。
だめだめですね、移行アシスタント。
てなわけで、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を前もって必ずアンインストールしましょう。
なので、うちの家計からの出費は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を前もって必ずアンインストールしましょう。
2014年2月28日金曜日
登録:
投稿 (Atom)