妥協的な解決策
今回は、Mac で Zipファイルが文字化け等する
場合の妥協的な解決策をお話します。
Zipファイルを送信・配信する場合は
・取り扱うファイル名は半角英数字のみ
Zipファイルを受信・ダウンロードする場合は
以下の2つのアプリを使います。
・Keka
・Zipeg
Keka で文字化けしたら Zipeg で解凍する感じです。
これで、技術的な気遣いをしなくても
文字化けや解凍できないという状態を
かなり回避することができるのではないかと思います。
技術的な気遣いなしで日本語を使えば化ける
そもそもコンピュータのデータは
『0』と『1』の並びだけで出来ています。
『0』と『1』だけでどうやって
アラビア数字の『2』を表すのでしょうか？
『0』と『1』だけでどうやって
日本語の『あ』を表すのでしょうか？
例えば『00110010』という並びを『2』として扱おう！
コンピュータの世界では、このようなルールを決めることで
『2』や『あ』を表すことにしています。
ルールの作り方は何通りもあります。
あるコンピュータでは『00110010』
という並びで『2』を表すけれど、
別のコンピュータでは『00110010』
という並びが『$』を表すとしたらどうでしょう？
その結果は文字化けです。
問題の 1つはこのようなルールが沢山あるということです。
コンピュータ同士が、ルールを共有していないのに
データを共有すると起きるのが文字化けです。
規格化
文字化けは困ります。
そこで、共通のルールを設けるために
規格化の流れがおきました。
その結果として ISO/IEC646 という
国際標準が作られました。
これは世界中で広く受け入れられているため、
そこで規定されている半角の英数字は
文字化けする可能性はとても低くなっています。
ISO/IEC 646 は ASCII が元になっています。
しかし、上図のように一部の文字は各国ごとに
異なる字を割り当てて良いことになっています。
そのようなわけで、正確には
ASCII から 『#$@[\]^`{|}~』 を除いた字だけは
ほとんど文字化けすることがないのです。
日本語については
Windows では Microsoft コードページ 932 (CP932) が、
Mac では NFD の UTF-8 が、
GNU/Linux では NFC の UTF-8 が使われるというような、
異なるルールでデータ交換することとなるため文字化けします。
NFD は Normalization Form Canonical Decompression の略で、
『が』を『か』と『゛』のように分けて考える形式です。
NFC Normalization Form Canonical Compression の略で、
『が』は『が』のまま一文字で考える形式です。
Zipファイルを送る相手の OS と解凍ソフトを考慮したり、
あるいは逆にコチラの OS と解凍ソフトを考慮してもらったり
というのは手間なので取り扱うファイル名は
半角英数字に限定するのが一番手っ取り早いです。
そうは言っても、相手から送られてくる
ものはどうしようもないです。
相手側のルールと自分側のルールの両方が分かれば
明示的に変換することで文字化けを直すことはできます。
自分で明示的に直すのは面倒です。
とはいえ、全自動で確実に文字化けを直すことはできません。
そこで、完全ではなくとも自動的に文字化けを何とかしてくれる
ようなソフトを利用するのが手っ取り早いです。
冒頭でご紹介したように
以下の 2つである程度は改善できると思います。
・Keka
・Zipeg
以上、完全な解決策ではないのですが
少しでも問題解決のお役に立てば幸いです。
お問い合わせについて
業務として技術コンサルティングやシステム設計・開発を行っております。
気になることがありましたらご相談下さい。
ご相談のみで完結する場合、コンサルティング費用の目安は
内容によりますが1時間で5千円〜1万円ていどです。
コンサルティングや開発を検討されるその前に、
まずはお気軽にコメントやメールでご連絡下さい。
※ご契約前のコメントやメールでのやりとりは無料です。
