Previous 　Index 　Next


2009 年 3 月 27 日



anchor

WaterRoof（Freeware)
OS10.4Tiger対応 OS10.5Leopard対応

OSXにネイティブにインストールされているFire wallのコマンド「ipfw」をGUIでコントロールするフロントエンドアプリ。

MacのOSXはOS10.2からシステム環境設定でコントロールできるFirewallを実装した。

しかし本当はOSXのUNIXな部分のDarwinはもともとipfwというFire wallを備えていた。
OS10.2まではシェルにコマンドラインを入力しないとこれが操れなかっただけだ。

今のOSXはFire wallを備えているわけだからほぼ問題ないともいえるのだが、MacoSXのFire wallはいまいち使いにくい、あるいは信頼できないという向きにはipfwを使うという手もある。
現行のLeopardも勿論ipfwはインストールされているので、コマンドラインを操る心得があるなら、今でもipfwは使える。
ただし、心得がない人にはこれはかなり敷居が高いと思う。

ここに ipfwの解説のページを見つけたので興味がある人は参考にしてみてほしい。
ただ、コマンドラインを使うよりもやはりGUIで設定したいという人はこのWaterRoofがある。

インターフェイスはかなり整理されていて、分かりやすいと思う。
「と思う」という曖昧な書き方をしたのは私自身も、こういう詳細なネットワークの知識を身につけているわけではないので、設定の意味がよくわからないところもあるからだ。
今のところ勉強中だから、エラそうに人にお勧めすることもできないのだがなかなか使いやすそうではあると思う。






WaterRoofを起動したままの状態
この表示はすべて素通しのipfwで何も制限していないというルールだ





こちらのウインドウでメニューを選んでいく





メニューから「Configuration Wizard」を開くとこういう設定画面が現れる
シチュエーションに合わせてプルダウンを選んでいくとルールが記述されていく
自分でルールの書き込みをしないでいいのが楽





ウイザードを完了するとこのようにルールが追加される





「Net Connection」を開くとネットワーク上のホスト名のリストが現れる





進行中のネットワークのやり取りの履歴（と思われる）





Firewallのログはこんな感じ





Ready Rule Setsを開くとプリセットのルール集がStatic Rulesに追加されていく
心得があるならこれで大体作って、細かいところをエディットして使うという感じになるだろうか





今何につながっているかという表示


2009 年 3 月 28 日



anchor

Layers（Shareware)
OS10.5Leopard対応

デスクトップ全景だけでなくデスクトップに散らばったウインドウ、アイコン、メニューバー、ドックなどをそれぞれバラして背景をキーで抜いたり抜かなかったりなどいろいろ可能なキャプチャーアプリ。

デスクトップが散らかっている時に、しかもその散らかっているウインドウをそれぞれキャプチャーしたい時などきっと便利。

なれればきっと作業が早くなる。

背景をpngやpsdなどで透明にキャプチャーすることもできるし、影だけ別にキャプチャーすることもできるので、後加工が楽だと思う。
常連さんにBBSでこのアプリの情報をいただいたのだが、まさに私のようなサイトを作っている人にはお勧めできるアプリだと思う。






こういう散らかったデスクトップのキャプチャーを撮りたい時、
普通はひとつずつ隠して片付けながらキャプチャーを撮るしか仕方がない





Layersがこの問題を解決する
このインストラクションに書いてあるホットキーでサッと撮ってしまってもよい





ちなみに設定画面でホットキーの組み合わせも画像の保存先も変更できる





それでもいいのだがもっと便利なのがこのInspector
これで撮りたいアプリやプロセスを選ぶとデスクトップのあらゆるエレメンツを
単体でキャプチャーしたりレイヤーで撮ったりできる





例えば進行中のプログレスバーを選択





すると散らかったデスクトップを片付けることなく
こんなキャプチャーを撮ることができる





このツールバーのボタンの機能はざっとこんな感じ
組み合わせることでいろいろ面白いことができる





例えばスクリーン全体を撮るとこんな感じだが・・・





デスクトップボタンをクリックしてデスクトップを隠したり・・・





エレメンツ単体を撮って他を全部隠すということもできる
さらにこの単体が自動的にフレームの真ん中に来るようにズームインすることもできる





またpsdで保存した画像はこの通りPhotoshop等で開くとレイヤーになっているのが分かる
レイヤーそれぞれを後加工で消したり取り出したりできるので
とりあえず保存しておいて後で加工を考えようという時には便利かも
画像が荒れているのはシェアウエア登録をすると解決するそうだ





ところで余談だがLeopardから採用された
512×512のアイコンが普及してきて力作のアイコンが増えてきた
このアプリのアイコンもよく見るとスゴく凝った作りになっている
これはもうアイコンとかサムネイルとかいうレベルではないと思う


2009 年 3 月 31 日




anchor

WindowsからMacにスイッチ（乗り換え）する時の疑問20
〜WindowsとMacでファイルをやり取りすると文字化けするのは仕様？

Macに乗り換えを考えているWindowsユーザが疑問に思いそうなことに勝手に答えていくこのコーナーを始めて２０回目になる。
今回はMacを使い始めて最初にMacがイヤになりそうな問題を取り上げる。

今のMacは単体で使っていればフリーズもしないし、大抵のことならアプリもサクサク動くし、オンラインウエアも昔とは比べ物にならないくらい充実している。
Windowsから乗り換えてきても快適に使えると思う。
ところが今のパソコンはネットワークマシンだ。そこが最初のつまずきになると思う。

速い話がWindowsユーザにファイルをメールなり共有フォルダなりを通じて渡すと
「文字化けしていて読めないよ」
「壊れてて開かないよ、Macなんか使ってないで真面目にWindowsで送ってよ」
なんてことを言われて不愉快になったりする。

他人がせっかくMacに乗り換えていい気分でやっているのに、文字化けをMacのせいだと決めつけられて、挙句に「Macを使いたがる変人」みたいなことを言われるのは、大きなお世話だ。
大体本当にMacのせいなのだろうか？

そこでこの疑問を取り上げる。


WindowsとMacでファイルをやり取りすると文字化けするのは仕様？

残念なお知らせがある。
結論から書くと上記の問題は「仕様だ」ということになる。

だが、「仕様だ」から仕方がないということではなくて、「仕様だ」から法則性があって、この問題を回避することができるということだ。
MacからWindowsにファイルを渡す時にいくつか知っておくと、トラブルを避けることができるルールというものがある。

その前にまず原因を知ることだ。
トラブルシューティングの要諦は、知っているトラブル対処法をやたら試してみることではなく、まず最初にトラブルの原因を切り分けることだ。
原因が判明すれば大抵のトラブルは解決できる。
この場合も文字が化ける原因が分かれば、化けない文字を使うとかの対処ができる。

MacからWindowsにファイルを渡す時に起きる文字化け、ファイルネームの崩れの原因はいくつか考えられる。

１）ファイルネームに禁止文字を使っている
２）テキストエンコーディングが一致しない
３）Zip等ファイルネームの文字コードの扱いが未サポートの状態でやり取りをしている
４）インストールされていない、あるいは未サポートのフォントでテキストが打たれている
５）機種依存文字を使っている
６）MIMEエンコーディングに問題がある

ざっと思いつくところを挙げると、こんなところが文字化け、ファイルネーム崩れの原因だと思う。
これらに抵触しない法則でファイルを渡せば、Mac、Windows間でも文字化けをすることがない。
事実私は、これらの問題に気をつけているので今MacとWindowsで大量のファイルを行き来させているが特に問題は起きていない。

１）ファイルネームに禁止文字を使っている

OSはそれぞれのベースになっているファイルシステムで、すべてのファイルの管理を行っている。
このファイルシステムで一般的なテキストだけでなく、アプリのリソースやシステムファイルまですべてを管理している。
これはMacやWindowsだけでなくUNIXだろうがどんなOSでも同じことだ。

そしてそれぞれのOSが採用しているファイルシステムには、ファイル管理の都合上特定の約物（記号）で階層などの表現をしているものがある。
もしファイネームにそれと同じ記号が使われていたら、OSはそれが階層やワイルドカードなどのファイルの扱いを示すのか、単なるファイルネームなのかを判別する方法がない。
だから、こうした約物（記号）はファイルネームには使ってはいけないということになる。
Windowsでファイルネームに使用が禁止されているのは、

￥ / : * ＜ ＞ ｜

ということになる。

問題はこのうち「:」以外はMacでは使えてしまうということだ。

Macでは￥や＜ ＞なんかをファイルネームで使っても問題なくファイルとして認識できる。
しかしそれをそのままWindowsに渡すとファイルネームが壊れて「意味不明の破損したファイル」になってしまう。

OSによって禁止文字はそれぞれ微妙に違うので、禁止文字のルールを覚えるのが面倒な人は英数の0〜9、A〜Z、a〜z以外の文字はファイルネームには使えないと覚えておこう。これが一番間違いない。


２）テキストエンコーディングが一致しない

MacとWindowsは違うテキストエンコードを採用しているということをご存知だろうか。 特に日本語で採用されている２バイトのエンコードの不一致が、主に日本語の文字化けの原因になっている。
この２バイト文字の文字コードの問題は、英語などの１バイト言語圏の人にはほとんど理解できないみたいだが、本当にコンピュータの世界を煩雑にしている。


コンピュータの中ではテキストはどのように扱われているかというと、文字に数字を割り当てて、数字の羅列として取り扱っている。
abcdという文字列は8bit=1byteで充分表現できる。
つまり0と1のボタンが８つあれば、256の種別を表現できるので、大文字２６文字小文字２６文字、数字１０文字の英語なら、これで充分だ。
勿論他に「.」や「,」や「!」、「?」等の約物は必要だが、それだってどんなに贅沢に割り振ったって１００もあれば充分表現できる。
だから英語のような言語は１バイトのコードで数字に置き換えることができる。
こういうのを１バイト言語という。

それに対して、日本語や中国語、韓国語などの言語はもっと多くの種別が必要だ。

例えば日本語は
あいうえお
から始まる５０音、
アイウエオ
から始まるカタカナ５０音
それぞれに「がざだば行」、小文字の「ゃ」「ぁ」「ぃ」「ぅ」「ぇ」「ぉ」などが、それぞれカタカナもあって、これだけで軽く１５０を越える。
これに漢字が当用漢字、教育漢字、教育外漢字など合わせると１万数千ある。
どう考えても２５６種類しか区別できない１バイトのコードでは文字を表現できない。

そこでこれらの言語は2byte=16bitの数字の羅列で文字を識別することになっている。
２バイトなら数字の組み合わせは65536通りあるので、日本語のかなやハングルは問題なくカバーできる。
漢字は春秋時代の古中国語まで遡ると、１０万以上の漢字があるそうなので、２バイトでも足りないということになるが、現代生活に必要な語彙は一万数千で足りるとのことなので、これですべての文字を数字に置き換えられるということになる。
これが２バイト言語だ。

問題は日本語の場合でもこの２バイトの文字コードはShift_JIS、EUS、ISO2022JP、UTF-8、UTF-16といろいろあるということだ。
これらの文字コードは一部、あるいは全部に互換性がない。
なのでShift_JISで表記されたテキストは、UTF-8の環境に渡されると、文字化けして何が何だかさっぱり読めないということが起きていた。






典型的なテキストの文字化け
これはShift_JISをUTF-16で開いた時の文字化け
もとは普通の日本語の平文だが中国語の暗号文のようになってしまう
この逆も過激な化け方になる





こちらはShift_JISをEUCで開いた場合の文字化け


最近のMacとWindowsは良好な関係になりつつあるのか、テキストをそのまま渡してテキストの内容自体が文字化けになるということは少なくなってきている。

かつてはMacはWindowsの世界の文字コードなど一切預かり知らぬという態度だったし、Windowsは２バイト言語の国際的なルールには全く無関心だった。
しかし最近ではお互いに交換する文書のテキストコードをある程度は認知してちゃんと表示するようになってきている。
htmlもヘッダでキャラクターセットがEUC-JPであることをちゃんと記述すればWindowsでも文字化けしないでwebサイトを表示するようになってきた。
ただ.txtなどをメモ帳などの簡単なアプリで開く時は、大抵はうまくいくのだがたまに文字化けするというようなことは、今でも起こる。

まずWindowsにテキストを渡す時にはテキストエンコードがShift_JISなど、Windows標準のテキストエンコードになっているかを確認する。






テキストエディットなどは「別名で保存」メニューに入ると
テキストエンコードも選択できるようになっている
Windowsに渡す文章は最初からShift_JIS等のWindows向けエンコードを選択しておく





Smultronなどのもっと高度なエディタは
最初からテキストエンコードを選択して文章を作成できるようになっている


３）Zip等ファイルネームの文字コードの扱いが未サポートの状態でやり取りをしている

このエピソードについては
Windowsで文字化けしないzipを作る
Windowsで文字化けしないパスワード付きzipを作る
Windowsで文字化けしない無圧縮zipを作る、

MacZip4Win

等のアプリの紹介の時に詳しく書いたが、もう一度おさらいしておく。


ファイルシステムは、MacとWindowsの場合全く違うシステムをとっている。
それぞれのファイルネームの文字コードは、MacはUTF-8という文字コードを使っているがWindowsはShift_JISという文字コードを使っている。
昔の旧MacOSはEUCという文字コードを使っていた。

この文字コードが違うとテキストが文字化けしてしまうのは、前項でも取り上げてた通りだが、MacとWindowsではテキストの中味だけでなくファイルシステムも違う文字コードで表現されている・・・というのはどういうことかというと、それぞれのファイルネームも違う文字コードで表現されているということだ。
昔のMacOSとWindowsは頑固に自方式にこだわっていたので、日本語でファイルネームをつけ手渡すと文字化けしていた。
最近はOSXはShift_JISの文字コードのファイルネームを自動的にUTFのファイルシステムでもちゃんと表示できるようにしたし、Windowsの方でもMacから渡されたUTFのファイルネームをちゃんと表示できるようになってきている。
両者の最近の友好関係を象徴しているのかどうかは知らないが、MacOSXでは昔の一部のEUCのファイルネームを表示できなくなっているのを見ると、Macが歩み寄っているのかもしれない。

通常そのままファイルを渡すのはそれでいいのだが、そうした自動変換はZipではサポートされていない。

Windowsの世界ではファイル圧縮の標準的な方式はZipだから、ファイルを渡す時に
「Zipでくれ」
というリクエストをもらうことがある。
OSXは標準でZipをサポートしているから、喜んでZipにして渡すと、
「ファイルが壊れていて開かない」
「文字化けして、意味不明のファイルもある」
「Macなんか使ってないで真面目にWindowsから送ってよ」
ということになってしまう。

これはファイルネームが、文字エンコーディングの違いで化けてしまうことが原因だ。
さらに悪いことに、今でもWindowsの多くはFAT32というファイルシステムのボリュームにインストールされている。
このFAT32という旧式のファイルシステムは、ファイルネームを３２文字までしかサポートしていない。
３２文字というのは１バイト文字で３２文字だから、２バイト文字だともっと少ない文字数で、ファイルネームが切れてしまう。
Windowsの場合は、ファイルの種別はすべてファイルネームの末尾の「.doc」などのように表記される拡張子で識別しているので、ファイルネームが３２文字を越えてしまうと、この拡張子が消えてしまい何のファイルなのか認識できなくなる。
そして、文字化けすると３２文字に収まっていたファイルネームも３２文字を越えてしまい、Windowsでは開かないファイルになってしまう。
これが、ファイルネーム文字化けが原因で、ファイルが壊れるという現象の正体だ。

以下にこれを解決するZipアプリの紹介で、この現象を再現しているので参考にしてほしい。






MacZip4Winの有効性を確認するために下準備
日本語ネームをつけたフォルダの中に日本語のファイルネームをつけたファイルを入れておく





これをMacZip4WinでZIPにする
ZIPにしたいファイル、あるいはフォルダをMacZip4Winのアイコンにドロップするだけ





元ファイルと同じディレクトリにZIP化されたものが生成される





比較のためにシステムデフォの右クリック「◯◯を圧縮」コマンドでZIP化したものも用意





両方のファイルをWindowsに渡す
システムデフォの右クリックで圧縮したZIPはWindowsで見るとこの通り
フォルダ名もファイルネームも皆文字化けしているし
「_MACOSX」等という意味不明なフォルダネームのフォルダも中に入っていたり
フォルダの中には「.DS_Store」というWindowsユーザには
まず意味が分からないファイルも入っていたりもうグダグダ





さらによろしくないのはこの文字化けが原因で拡張子が消えているために
jpegとして認識できていないファイルがいくつかあること
これが「Macなんかで送ってくるからファイルが壊れてるじゃないか」と
Windowsユーザがクレームをつけてくる現象の原因





MacZip4WinでZIP化したものも開いてみるとこの通り
Windowsでもちゃんと日本語として認識できる





またファイルネームも化けていないので拡張子も問題なく機能している
この通りjpegならちゃんとWindows環境でもそのように認識できるようになる


この問題を手作業でクリアするのは結構めんどうな作業が発生する。
というか他のファイルシステムに移してリネームしてから圧縮する必要が出てくるので、多分物理的にやるのは現実的ではない。

こうした問題を解決するために、上記の

Windowsで文字化けしないzipを作る
Windowsで文字化けしないパスワード付きzipを作る
Windowsで文字化けしない無圧縮zipを作る、

MacZip4Win

のようなファイル圧縮アプリ、スクリプトが用意されている。

しかし根本的な解決法は、
「他のプラットフォームにファイルを渡す時には日本語を使わない」
ということに尽きると思うのだが。
これはMacとWindowsの間だけの問題ではなく、それ以外のLinuxなど自分と違うすべてのOSとファイルをやり取りする可能性がある場合、日本語のファイルネームは禁止するというのが唯一の根本的な解決法だ。

上記の記号の制限もプラットフォームごとにバラバラなので、英数文字の大文字小文字、半角数字の0~9以外はファイルネームには使ってはいけないというふうに覚えるのが最も安全だ。
これならどんなプラットフォームが相手でも問題が起きる可能性はほぼない。

『２００９.4.1強い￥の秘密は？／部外者閲覧不可！！』＜＊特別編＞
みたいなファイル名やフォルダ名なんかは言語道断だ。
でも日本語ファイル名にこだわる人達ってこういう禁止文字をやたら使いたがるのだが・・・


４）インストールされていない、あるいは未サポートのフォントでテキストが打たれている

この問題は前に
17)WindowsからMacにスイッチ（乗り換え）する時の疑問17
〜Windowsとのワード、Excelのやり取りはできるの？
 の回でも取り上げた。

フォントの問題も日本語の扱いをややこしくしている。
MacからWindowsにテキストを渡す時に、昔はMacで使っていたフォントとWindowsで採用されているフォントには、深い隔絶があった。
フォント指定に気を使っていないとWindowsに渡した時に、文字抜け、文字化けが起きていた。
中には本当にアラビア語の暗号文みたいになってしまう文字化けもあった。

最近はWindowsもMacに優しくなってきたのか、Windowsにインストールされていないフォントが指定されているテキストを受け取ると自動的にMSゴシックに置き換えて表示するようになった。
Mac側のフォントの互換性の向上も相まって、今では普通にWindowsにワード文書などを渡しても、ほぼ文字化けはしなくなった。
しかし細かいレイアウト崩れや、文字抜けは相変わらず仕方がない。

一番いい方法は、Windowsに渡す文書は
MSゴシック
MS明朝
などのWindowsなら必ず入っているようなフォントをインストールしておき、それ以外のフォントは使わずにテキストを作成するということを心がけるべきだ。
これだけでも不要なトラブルはかなり防げる。

あるいは確実に文字化けもレイアウト崩れも無しに送りたい場合は、フォントエンベッドのPDFで送るかjpeg等の画像で送るかという選択肢もある。（テキストとしては役に立たない局面もあるが）


５）機種依存文字を使っている

例えば有名なのは丸で囲んだ１、２、３というような文字


これとかはMacにもWindowsにもあるのだが、どちらも機種依存文字、つまりその機種だけの独特な文字コードということになる。
例えばWindowsでとか打ってMacに渡すと
というような化け方をする。

（株）という記号もMacでは「？」となってしまう。

それではMacからWindowsに渡すとどうなるかは以下の通り。






Macのテキストエディットで数字を打ってみた
その下の（日）（月）はWindowsでマル１マル２と打ってMacに渡したもの
これをそのままシンプルテキスト、拡張子.txtで保存してWindowsに渡すとどうなるか





Windowsのメモ帳でこれを開いたところ見事に数字は化けて見えない
逆にWindowsからもらって化けていた（日）（月）はちゃんと数字に戻っている
これがMacとWindowsの機種依存文字の扱いの違い





同じテキストを今度は「別名で保存」で「UTF-8」の文字エンコーディングで保存する
これをWindowsに渡すとどうなるか





今度は機種依存文字の数字もちゃんと見えるようになった
逆にWindowsからもらった数字は（日）（月）と化けたままだ
つまりMacで見るのと同じようにWindowsでも見える
これが最近のMacとWindowsの歩み寄りの成果だ





さらに文字エンコーディングとかを触らないでワード文書で保存
WindowsのMSWordで開くとやはりこの通り
最近はMSOfficeに関しては文字化けを気にしないでもよくなりつつある


機種依存文字もUTF等のエンコーディングを使うか、MSOfficeのようなソフトを使うことで、ちゃんと見える可能性が高まっている。
しかし確実ではない。
MacもWindowsもこういう文字はできるだけ使わないのが正しい。

しかし昨日も今日も日常的に というように文字化けしたメールをもらうのだが。


ところでもうひとつ有名な機種依存文字がある。
この記号はどう見えているだろうか？

もしあなたがMacをお使いになっていて、Safariでこのページを見ているなら林檎マークに見えているに違いない。
FirefoxなどのMozillaで見ているなら、FFという文字が入った記号が見えている筈だ。
Windowsで見ている人は、「？」になっているだろうか？


６）MIMEエンコーディングに問題がある

MacからWindowsにテキストなどを渡す時という前提でここまでの文章を書いてきた。
文字化けは主に使われているテキストエンコードなどのルールの違いで起きるというのがここまでの要諦だが、LANで共有フォルダ越しにファイルを渡したりUSBメモリなどでファイルを渡す時にはここまでのことを注意すればいい。

しかし現実には何でもかんでもメールに添付して送るというのが、日常的な光景ではないだろうか。

メールに何でもかんでも添付して、やたら送りつけるのは「ネチケット違反だ」ということをかつては言っていたような記憶がある。
しかし最近ではそんなこともトンといわなくなった。
最近パソコンを使い始めた大量の初心者が何でもかんでも添付ファイルで送りつけてくるために、もはや今ではそれがデファクトスタンダードになってしまった。
私も最初の頃は、
「メールで送りつけてくるな！　LANに共有フォルダを開いているからそこに入れろ」
と言っていたが、いくら言っても通じないばかりか「メールで送って何が悪い？」という感覚が最近では多数派になってしまったので、私もメンドクサイから何でもかんでもメールで送るようになってしまった。
まことに朱に交われば赤くなるという喩え通りだ。


ところが特定の人から「添付ファイルが届かない」という問題が起きることがある。
本文が途中から一部文字化けして、添付ファイルが見えない、あるいは見えても開かないというようなことが起きる。

これは大抵はMIMEに関する問題だ。
私自身も昔Outlook Expressを使っていた頃にはこの問題に相当悩まされた。
それで原因はMIMEというインターネットでのバイナリの扱いを決めたルールに問題があるらしいということを突き止めて、このMIMEについて勉強も少ししてみた。
しかし結局、私には理解できない領域の話だった。

MIMEとは一言でいえば、テキストしか送れないメールというインフラを通じて、テキスト以外のものをあたかもテキストのようにエンコードして送る時の約束ごとのこと。

テキストを７ビットのコードでエンコードして送受信するのがwebの仕組み。
このルールで英語圏などの１バイト言語はテキストとして送られるが、それ以外の２バイト言語やファイルは違うルールでエンコードされる。メールサーバや途中の転送システムはテキストを送る能力しかないため、彼らを騙すためにあたかもExcelファイルやjpegファイルなんかも、テキストに見えるように同じようなコードで送り、受け手がそのMIMEを認識してそれを元通りExcelファイルに戻したり、jpegに戻したりする。

このようにしてメールでもファイルのやり取りができるようになっているわけだが、直接ファイルをそのままやり取りしているわけではないので、お互いのルールが違っているとファイルが渡せない、文字が化けるということが起きる。
特にMIMEは１９９３年に成立したルールなので、まだ非常に新しい。


MIMEのようなところで問題が起きたら実際には、素人さんにはできることはほとんどない。
UNIXメイルを使っているような上級者ならともかく、OSに標準でついてくるメーラをそのまま使っているようなユーザがいじれるようなところは非常に少ない。

私のような初心者がいえるのは、MIMEのような問題に悩まされないためにもOutlook Expressのような旧弊なメーラは使わないということぐらいだ。
最近のMozilla系のThunderbirdとかMacでいえばGyazmailとか、そういうシュアなメールを使おうということしかない。

もっといいのはメールでやたらファイルを添付して送らないことだ。
これは現実的には難しいかもしれないが・・・。



anchor

大量に開いたウインドウを一気に閉じるTips

こういうことがよく起きないだろうか？
大量のフォルダを選択している時に間違って、それをクリックしてしまって大量のウインドウがどばどば開いてしまい、それをしまうのにエラい時間と手間がかかった・・・とか

大量のファイルを選択している時に間違ってコマンド＋Iキーを叩いてしまい、「情報を見る」ウインドウが数十個も開いてしまい、それを片付けるのに往生した・・・とか

そんな奴オランでぇ〜という人は流し読みをしてもらいたいのだが、私はそそっかしいのかこういうミスをよくやる。
そしてその度に「何だかな〜」と思いながら一個ずつ赤ボタンをクリックしてウインドウを閉じている。
しかしそういう時こそ頭を働かせるべきなのだ。

一個ずつ赤ボタンをクリックして閉じるのは最悪の解決法で、もう少しマシな方法はコマンド＋Wキーでひとつずつ閉じるということになる。
しかし、もしFinderでウインドウが大量に開いているのなら、Finderをアクティブにして、
コマンド＋option＋Wキー
を叩いてみよう。
それで数十個も開いてしまったウインドウが一気に閉じる筈だ。

私自身忘れていたTipsなのでメモとして書き留めておく。






大量のファイルを選択したまま間違ってコマンド＋Iキーを叩いてしまって
舌打ちをしている状態ですね、わかります





こういう時に愚直に一個ずつコマンド＋Wキーを叩いて
閉じていくというのも味がある解決法ですが・・・





コマンド＋option＋Wキーというキーを叩いてみよう
一気に閉じるので手っ取り早くデスクトップがかたづく






Previous 　Index 　Next

site statistics
あわせて読みたい