PowerShellを使ってExcelできちんと開けるCSVファイルを作成する方法

PowerShellからCSVファイルを作成し、それをExcelで開いて…という操作は結構需要があり、頻繁に行われるのではないかと思います。ちょっとしたはまりポイントがありますので、そのあたりのTipsを紹介しようと思います。 Export-Csv PowerShellの素敵な点の1つはオブジェクトを簡単にCSVに出力できるコマンドレットが標準で用意されているところだと思います。 ただし、日本語が含まれている場合に、そのまま何も考えずにExport-Csvを実行すると文字化けが発生してしまいます。 これは、Excelで読み込むときにエンコーディングの判定に失敗して文字化けしている…という事ではなく、PowerShellでファイルを吐き出した時に????に変換されてしまっています。なので、出力時にきちんとエンコーディングを指定してあげる必要があります。 どのエンコーディングを使うか、というのは人によって意見が違うかもしれませんが、私はいつもUTF-8を使います。これであればきちんと日本語も出力され、Excelで開いた時にも文字化けもなく意図した通りに開きます。 ExcelでShift-JIS以外の文字コードでは文字化けが発生する問題 実は先ほどの例ではうまくいっていますが、ExcelはCSVファイルはShift-JISにしておかないと文字化けすることが多い困ったやつです。回避策はいくつかあります。以下のあたりが参考になります。 ExcelでUTF-8のCSVを開く方法 (CodeZine編集部ブログ) ExcelでUTF-8エンコーディングされたCSVファイルを開く方法 - 大人になったら肺呼吸 先ほどの例ではBOM付きのUTF-8であったためうまく表示されたわけです。Stirlingでファイルを確認するとファイルの先頭に「EFBBBF」が不可されていることがわかります。 スクリプト内でファイルに出力する場合 Export-Csvを使う場合には-Encodingオプションを付ければよいことはわかりましたが、foreachの中などで、自分で文字列をファイルに出力したいようなときには残念ながら別の問題が発生します。 このようにA列にすべて表示されてしまいます。(※文字化けをしていないのはExcel2010だからなのではないかと思います。) これも回避策としてはいくつかあると思いますがShift-JISで出力するにはAdd-Contentコマンドレットで-EncodingにStringを指定することができます。 UTF-8でBOM付きにしようと思ったら、先にファイルを作成しておくと良いようです。

October 2, 2012 · 1 min · 胡田昌彦

符号化文字集合と文字符号化方式の違い

コンピューターの世界で文字がどのように扱われているかということを理解するには「符号化文字集合」と「文字符号化方式」という2つの異なる概念があり、それぞれがどのようなものであるかを理解することが非常に重要です。これを理解しているかいないかでコンピューターの世界での文字の扱いに関する理解がまったく違ってきますのでぜひ抑えておきましょう。 符号化文字集合 まず符号化文字集合というのは「どのような文字を扱うか」ということを定義するものです。文字といってもアルファベット、ひらがな、カタカナ、数字、記号はもとより日本語には非常に多くの漢字が存在しています。さらに世界に目を向ければいったいどれだけの数の文字が存在しているのでしょうか? ちょっと検索してみると以下のようなサイトが見つかりました。 世界の文字 Written characters of the world ちょっと見てみてほしいのですが、ものすごい数の文字が世の中には存在しています。コンピューターは今でこそ高性能になり、世界中のありとあらゆる文字を使えるようにしてしまおうという構想が現実的に実装できるようになっていますが、歴史的にはごく限られたリソースの中で何とかやりくりをしていた時代の方が長いわけです。そうするとその中では「どの文字を使えるようにするか」ということが非常に重要です。 あなたがコンピューターを「限られたリソースの中で」新しく設計するとしたら、どのような文字を使えるようにしたいと思いますか? リソースには限りがあるので、極力少ない文字の種類で済ませたい かといって通常使う用途に不便するようでは使ってもらえないので必要十分な文字の種類は扱えるようにしたい 世の中に存在しているほかのコンピューターとデータをやり取りできないようでは使い物にならないので、他のコンピューターで使える文字はある程度使えるようにしないといけない このくらいのことはまず考えないといけません。このように考えてみるとどのような文字をコンピューターが扱えるべきなのかという規格があり、世の中に存在するコンピューターがみんなその規格にしたがっていればみんなが幸せになれるはずです。 符号化文字集合の具体例 このような符号化文字集合を定めた規格が複数存在しています。ここでは日本語に深いかかわりを持つもので代表的なもののみを紹介します。 ASCII - Wikipedia JIS X 0201 - Wikipedia JIS X 0208 - Wikipedia 補助漢字 - Wikipedia JIS X 0213 - Wikipedia Unicode - Wikipedia Wikipediaの説明を読むといきなり難しいことが沢山書いてあって混乱するかもしれませんが、まずは「色々あるんだな」くらいに考えておいてもらっていいでしょう。私が考えるポイントは以下です。 アルファベット圏ではアルファベットだけあれば事足りるので、それが定義されているASCIIが主に使われている。 日本語はアルファベットだけでは全然たりないので、ひらがな、カタカナに加えて日常よく使う漢字がまず必要。現在のコンピューターで普通に使える漢字はJIS X 0208で定義されている。 最近のコンピューターではさらに多くの漢字が使えるようにしようという動きがあり、最新のコンピューターではJIS X 0213で定義されている文字(JIS X 0208よりも多くの文字が定義されている)が使えるようになってきた。ただしまだ使えないコンピューターも多くあり、互換性に問題がある。 文字符号化集合が複数あるから互換性の問題が起きるのであって、「世界中の文字を集めた符号化文字集合がひとつあって、それを全てのコンピューターが使えば問題はなくなる」という考えで世界中の文字を集めているのがUnicode。普及はそれなりに進んできたが使えない環境もまだある。 文字符号化方式 コンピューター上では最終的には全てが0と1のデジタルで表現されます。もちろん文字もそうです。ですので符号化文字集合だけがあっても実際にそれをコンピューター上ではどのような0,1の並びで表現するのか、ということが決まっていないとコンピューターでは扱えません。その0,1の並びを定義しているのが文字符号化方式です。 符号化文字集合は複数ありますが、そのそれぞれの集合ごとに1つの文字符号化方式がある・・・というわけではありません。実際にはひとつの文字符号化方式で複数の符号化文字集合を対象にしていますし、ひとつの符号化文字集合に対して複数の文字符号化方式が存在しています。 なぜこのように複雑な関係になっているのかというと、結局それは、「同じ問題でも解き方は複数ある」からだと私は思っています。そしてどれが一番良いのかは「何を目的とするか」によっても変わってきます。 たとえば、アルファベットだけで完結することのできる文化圏の人がいます。そして、アルファベットは文字数が少ないので7ビットもあれば全ての文字を表現できてしまいます。コンピューターにとってきりのいいところで8ビットもあれば十分です。一方私たち日本人はひらがなもカタカナも漢字もありますので8ビットではまったく足りません。このときある人は「8ビットで足りないなら、全ての文字を8ビットを2つくっつけて16ビットで1文字にしよう」と考え、あるひとは「8ビットで足りないなら1文字8ビットのルールは変えないで、使う文字集合を切り替える仕組みを作ろう」と考えたとします。(仮に、です。) これはどちらもコンピューターにルールを教えてあげれば(プログラムをつくれば)コンピュータ上で実現できます。どちらが完全に優れているということもありません。一長一短があります。たとえば16ビットで1文字にすれば「切り替え」を意識しなくてよいので文字の検索などが簡単に実装できます。ですが、16ビットで1文字にしてしまうと1文字8ビットで済む文字にも16ビット使ってしまうので、仮にアルファベットしか使わない文章を書いたとしたら容量が2倍になってしまいます。 この例は解説のために簡略化してあくまでも例として出していますが、実際の文字符号化方式においてもこのようにトレードオフがあり、複数の方式が混在しているのです。 文字符号化方式の具体例 文字符号化方式の具体例としては以下のようなものがあります。 ISO-2022-JP - Wikipedia EUC-JP - Wikipedia Shift_JIS - Wikipedia Microsoftコードページ932 - Wikipedia UTF-8 - Wikipedia UTF-16 - Wikipedia UTF-32 - Wikipedia 沢山あっていきなりだと混乱すると思いますが、まずは以下のような理解をしておくと良いと思います。 ...

February 4, 2009 · 1 min · 胡田昌彦