カテゴリー: mac開発

CSV が Excel で文字化けする原因と直し方（Mac で実測）

会計ソフトから落とした CSV を Excel で開いたら、商品名 のはずの列が 蝠刀蜷 になっていた。逆に、自分が Excel で作って送った CSV を「文字化けしてます」と返された。どちらも経験があるのではないでしょうか。

この 2 つ、立場は正反対ですが、詰まっているところは同じです。CSV というファイルには、中身が何の文字コードで書かれているかを記録する欄がありません。

検体は macOS 26.6.2（ビルド 25G83）と Microsoft Excel for Mac 16.107.2 で、自分で作って実際に開いたり保存したりしたものです。

先に結論

困っている場面 やること
もらった CSV を開いたら化けている ダブルクリックをやめる。データ → データ ファイル指定 (Power Query) → テキスト/CSV から開く
自分が渡す CSV を作る 保存形式で「CSV UTF-8」を選ぶ。ただの「CSV（コンマ区切り）」は選ばない
プログラムに読ませる CSV を作る BOM 付きのままでかまいません。読む側で utf-8-sig を指定してもらいます

よく見かける「Shift_JIS で保存し直す」は入れていません。動くことは動くのですが、戻せない代償があります。

CSV には文字コードを書く欄が無い

商品名,数量,金額 から始まる CSV を UTF-8 で保存して、先頭を覗いてみます。

$ xxd -l 12 utf8_nobom.csv
00000000: e595 86e5 9381 e590 8d2c e695            .........,..

e59586 e59381 e5908d が「商品名」を UTF-8 で符号化したバイト列、2c がカンマです。データがいきなり始まっています。ZIP や画像なら先頭にヘッダがあって「これは何か」を名乗るのですが、CSV にはそれがありません。テキストがそのまま置いてあるだけです。

つまり開く側は、書いていないものを推測するしかない。日本語環境の Excel が最初に疑うのは Shift_JIS 系です。UTF-8 のバイト列を Shift_JIS 系として読むと、こうなります。

$ printf '請求書' | iconv -f CP932 -t UTF-8
隲区ｱよ嶌

実際に Excel for Mac で開いた画面がこれでした。

セルに入るはずの値 表示された値
商品名 / 数量 / 金額 蝠刀蜷 / 謨ｰ驥 / 驥鷹｡
請求書 隲区ｱよ嶌
髙橋商店 鬮呎ｩ句膚蠎
①番テーブル 竭逡ｪ繝ｼ繝悶Ν

先頭が 蝠・隲・繝・縺・謨・鬮 あたりで始まっていたら、UTF-8 を Shift_JIS 系として読んだ化け方です。ひらがなの多い言葉は 縺、カタカナは 繝 がよく顔を出します。

BOM が付いていると化けない

ところが、同じ内容でも化けない場合があります。先頭に 3 バイトだけ足したものです。

$ xxd -l 12 utf8_bom.csv
00000000: efbb bfe5 9586 e593 81e5 908d            ............

この ef bb bf が BOM（Byte Order Mark）で、「以下は UTF-8 です」という目印になります。Excel はこれを見て判断を変えます。4 通りの検体を、Finder のダブルクリックと同じ経路で開いた結果です。

検体 結果
UTF-8（BOM なし） 化ける
UTF-8（BOM 付き） 正しく開く
Shift_JIS（CP932） 正しく開く
UTF-16LE（BOM 付き・カンマ区切り） 文字は正しいが、全部 A 列の 1 セルに入る

Microsoft も公式のサポートページで「BOM 付きで保存されていれば UTF-8 の CSV は普通に開ける」と書いています。BOM が唯一の手がかりだ、というのが CSV の文字化けの正体です。

なお file -I は BOM の有無を区別してくれません。BOM あり・なしのどちらも charset=utf-8 と答えます。確かめたいときは上のように xxd -l 3 で先頭 3 バイトを直接見るのが確実です。

もらった CSV が化けているとき

配布元に「BOM 付きで出してください」と言えれば一番早いのですが、たいていそうもいきません。ダブルクリックで開くのをやめて、Excel 側で読み方を指定します。

Mac だと データ → データ ファイル指定 (Power Query) → テキスト/CSV が一番楽でした。

  1. Excel を開く
  2. データタブ → 左端の「データ ファイル指定 (Power Query)」→「テキスト/CSV」
  3. 参照からファイルを選ぶ
  4. プレビューを確認して「読み込む」

BOM なしの UTF-8 を食わせたところ、プレビューの「元のファイル」は 65001: Unicode (UTF-8)、「区切り記号」は コンマ と、どちらも自動で当たっていました。髙橋商店 も ①番テーブル も化けていません。こちらから指定するものが何もない。

同じドロップダウンに テキストから (レガシ) もあって、こちらは「テキスト ファイル ウィザード」が開きます。ファイル → インポート → CSV ファイルと辿っても同じウィザードでした。入口が 2 つあるだけで中身は同じです。ただ、こちらは自動判定してくれません。

  • 1/3 の画面の「元のファイル:」の既定が Japanese (Mac OS)。これが化ける直接の理由です。Unicode (UTF-8) に変えます
  • 2/3 の画面の区切り文字の既定がタブ。ここを「コンマ」にしないと、文字は読めるのに全部が 1 列に入ります

私は最初この 2 つ目を飛ばして、せっかく綺麗に読めた文字列が丸ごと A 列に詰まったのを見ました。Power Query のほうが確実なのは、この 2 か所を自分で当てにいかなくて済むからです。

Power Query が使えるのは、Microsoft の案内ではバージョン 16.69 以降かつ Microsoft 365 のサブスクリプションという条件付きです。手元の 16.107.2 では問題なく出ました。条件を満たさない環境ではレガシ側が受け皿になります。

Excel にこだわらないなら、LibreOffice は BOM なしの UTF-8 をそのまま読めます。文字コードを何も指定せずに開いて正しく表示されたので、中身を確認したいだけならこれが早いです。

自分が渡す CSV を作るとき

こちらのほうが厄介でした。Excel for Mac で「CSV（コンマ区切り）」を選んで保存すると、UTF-8 では書かれません。保存されたファイルの先頭はこうです。

$ xxd -l 12 out_csv.csv
00000000: 8fa4 9569 96bc 2c90 9497 ca2c            ...i..,....,

BOM はなく、8fa4 9569 96bc が「商品名」。Shift_JIS 系のバイト列です。ではこれを CP932 として読めるかというと、読めません。

$ iconv -f CP932 -t UTF-8 out_csv.csv
商品名,数量,金額
請求書,1,1200
_橋商店,3,4500
iconv: iconv(): Illegal byte sequence

2 か所おかしいところがあります。

1 つは 3 行目の _橋商店。元は 髙橋商店 でした。髙（はしごだか）が消えて、アンダースコアになっています。

もう 1 つは最後で止まっていること。① のところで不正なバイト列だと言われています。Excel が書いた ① は 8540 でしたが、CP932 の ① は 8740 です。別のバイトが入っている。

正体は Mac OS Japanese でした。Foundation の kCFStringEncodingMacJapanese で復号すると、①番テーブル まで含めて最後まで素直に読めます。同じ「Shift_JIS 系」と呼ばれていても、Windows の CP932 とは持っている文字が違うのです。

表現できない文字がどうなるかを、もう少し意地悪な検体で確かめました。

元の値 保存後
𠮷野家 __野家
絵文字😀 絵文字__
森鷗外 森_外

置き換わっているのはファイルの中身だけです。画面上のセルには元の文字が残っているので、保存した本人の目には何も起きていないように見えます。

警告が出ないわけではありません。CSV を開いている間、Excel は本文の上に「データ損失の可能性　このブックをコンマ区切り (.csv) 形式で保存すると、一部の機能が失われる可能性があります」というバーを出しています。ただしこれが言っているのは、書式や複数シートを CSV では持てないという形式一般の話で、髙 が _ になることは何も告げません。読み流してしまう種類の警告です。渡した先で初めて「名前が _ になってます」と言われることになります。

Excel for Mac で人に渡す CSV を作るなら、保存形式は「CSV UTF-8」を選んでください。こちらは先頭に efbbbf が付いた UTF-8 で保存されます。

BOM は誰のために付いているのか

その BOM が、渡す先によっては邪魔になります。人ではなくプログラムに読ませたとき。Python で普通に読むとこうです。

$ python3 -c "
import csv, io
raw = open('utf8_bom.csv', encoding='utf-8').read()
row = next(csv.DictReader(io.StringIO(raw)))
print(list(row.keys()))
print(row['商品名'])
"
['\ufeff商品名', '数量', '金額']
Traceback (most recent call last):
  File "<string>", line 6, in <module>
KeyError: '商品名'

先頭の列名が 商品名 ではなく \ufeff商品名 になっています。\ufeff が BOM で、1 文字目として列名に食い込んだ形です。厄介なのは、この文字が幅を持たないこと。Python は repr で見せてくれますが、print() でそのまま画面に出すと見た目は 商品名 のままです。KeyError を見て「列名は合っているのに」としばらく悩むことになります。

これは読む側の設定ひとつで消えます。encoding='utf-8' を encoding='utf-8-sig' に変えるだけ。sig 付きのほうは BOM があれば読み飛ばし、無ければそのまま読むので、BOM 付きと BOM なしを同じコードで扱えます。手元で両方通したところ、どちらも 商品名 が取れました。

つまり「Excel を取るかプログラムを取るか」という板挟みではないのですね。BOM が働いているのはダブルクリックで開いたときの一瞬だけで、Excel の推測に手がかりを渡している。前の節の Power Query 経路も、ウィザードで文字コードを指定する経路も、BOM があろうとなかろうと同じように開きます。

なので、出す側は BOM を付けておく。受け取る側はそれぞれの流儀で読む。それで両方立ちます。本当に困るのは、受け取り先のコードが utf-8 決め打ちで、しかもそこを直せないときだけです。

おまけ:よく見かけるけれど勧めない対処

まず、Shift_JIS で保存し直すという手。上位に出てくる記事の多くがこれを勧めていて、Excel が Shift_JIS 系を素直に読むのは事実なので、動くことは動きます。ただし片道切符です。CP932 に変換できない文字を並べてみます。

文字 CP932
髙 ① ㈱ Ⅲ 斎 変換できる
鷗（鷗外の鷗） 変換できない
𠮷（つちよし） 変換できない
𩸽（ほっけ） 変換できない
😀 変換できない

人名や店名を含む CSV でこれをやると、変換できなかった文字がその場で失われます。あとから UTF-8 に戻しても帰ってきません。しかも Mac 経由だと 髙 まで落ちる（前の節のとおり）ので、Windows の記事に書いてある「Shift_JIS なら大丈夫」がそのまま通用しない。

もう一つ、UTF-16 で保存し直すという手もよく見ます。試したところ、文字化けは確かに直りました。ただし 商品名,数量,金額 が丸ごと A1 セルに入ります。文字は読めるのに表になっていない、という中途半端なところに着地しました。カンマが区切りとして扱われていないわけですが、なぜそうなるのかまでは確かめていません（タブ区切りの UTF-16 で試していないので、そこは断定を避けておきます）。表として使いたいなら、この手は回り道です。

ついでに、化けているように見えて実は別物のこともあります。引用符の中にカンマや改行が入っている CSV は、Excel はきちんと解釈しました。"カンマ, あり" は 1 セルに収まり、セル内改行も改行のまま残ります。列がずれているだけなら文字コードの問題ではないので、先に区切り文字を疑うほうが早道です。

さいごに

開くときはダブルクリックをやめて Power Query から、渡すときは「CSV UTF-8」で保存。実務で必要なのはこの 2 つだけです。

それにしても、と思うのです。ZIP がファイル名の文字コードを宣言する 1 ビットを後から継ぎ足したように、CSV も BOM という後付けの目印で何とかしのいでいる。どちらも、文字コードが 1 つに決まっていなかった時代に生まれた形式で、後から世界が広がった分のつじつまを端っこで合わせている。髙 が _ に変わったときも、Excel は「一部の機能が失われる可能性があります」としか言いません。嘘はついていないのですが、いま消えたのがその 1 文字だとは教えてくれない。警告の粒度というのは難しいものだな、と思いながら見ていました。

余談ですが、同じ原因でこの記事を書いていて WordPressで 「公開に失敗しました。 データベース内の投稿を更新できませんでした。」とでてハマ りました…

ZIP のファイル名が化ける話は別に書いたので、そちらで困っている方はどうぞ

ZIP を解凍するとファイル名が文字化けする原因と直し方(Mac / Windows)

Mac で圧縮した zip を Windows の人に送ったら「ファイル名が 隲区ｱよ嶌_2026蟷ｴ8譛�.txt になってる」と返ってきた。逆に、Windows の人からもらった zip を Mac で開こうとしたら、解凍そのものが Illegal byte sequence で止まった。どちらもよくある話ではないでしょうか。

この 2 つ、症状は正反対に見えますが、原因は同じところにあります。ZIP ファイルの中の、たった 1 ビットです。

検体は macOS 26.5.2(ビルド 25F84)で自分で作って、バイト列まで確かめました。

続きを読む ZIP を解凍するとファイル名が文字化けする原因と直し方(Mac / Windows)

[iOS][OpenSSL] .p12キーストアファイル証明書の中身を確認する

iOS開発で頻繁にお世話になる .p12 ファイル(秘密鍵＋証明書のセット)の情報を確認する方法です。
SHA1フィンガープリント、有効期限、チームID,名前などがコマンドラインから簡単に確認できます。

続きを読む [iOS][OpenSSL] .p12キーストアファイル証明書の中身を確認する

Swift2でリリースビルドの時にログ表示しないようにする

Xcode7(Swift2) でデバッグビルドの時だけデバッグ出力して、プロダクションビルドの時はセキュリティのためデバッグログを削る方法のメモ。

このコードにより、print, debugPrintln, NSLogの出力を制御することができます。

事前準備

XcodeプロジェクトのBuild Settings → Swift Compiler → Other Swift Flags の Debug に「-DDEBUG」を追加して下さい。

コード

AppDelegate.swift の冒頭に以下のグローバル関数を追加します。

他のファイルのほうがわかりやすければAppDelegate以外でも大丈夫です。

// リリースビルドでprint, debugPrintを無効化
func print(object: Any) {
  #if DEBUG
    Swift.print(object, terminator: "")
  #endif
}

func debugPrint(object: Any) {
  #if DEBUG
    Swift.debugPrint(object, terminator: "")
  #endif
}

// リリースビルドでNSLog無効化
func NSLog(message:String){
  #if DEBUG
    Foundation.NSLog(message)
  #endif
}
func NSLog(format:String, _ args:CVarArgType...){
  #if DEBUG
    Foundation.NSLog(String(format: format, arguments: args))
  #endif

}

この記事を書いた理由

print, debugPrintは出てきますが、SwiftでNSLogを非表示にする方法がどうしても出てこなかったので記事にしました。

Swift2から廃止されたprintln, debugPrintlnはここに書いていませんが、print, debugPrint と同様の方法で対応可能です。

ググると NSLogを消す方法として、プレフィクスヘッダファイル(.pchファイル)に #define NSLog を方法が出てきますが、こちらはObjective Cにしか効果がないようなので注意。

おまけ

代替案としては、より細かいログレベル制御が可能なXCGLoggerを使うのも手です。

AppDelegateで

import XCGLogger

let log: XCGLogger = {
  let log = XCGLogger.defaultInstance()
  #if DEBUG
    log.setup(.Debug, showThreadName: true, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)
    #else
    log.setup(.Severe, showThreadName: true, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)
  #endif
  let dateFormatter = NSDateFormatter()
  dateFormatter.dateFormat = "MM/dd/yyyy hh:mma"
  dateFormatter.locale = NSLocale.currentLocale()
  log.dateFormatter = dateFormatter
  
  return log
  }()

としておくと、

log.debug("Debugレベルのログです")
log.info("infoレベルのログです")

のようにログレベルごとのログ出力ができるようになります。

Mac OS X のバッテリー劣化状況を確認する

ほお、と思ったのでメモ。

MacBook AirやMacBook Pro をずっと使っていて、バッテリー(電池)の持ちがなんとなく悪くなった気がするなぁと思った事ありませんか。

そんなときにバッテリーの劣化状況を調べる方法がありました。

ターミナルから、下のコマンドを入力するだけ。

ioreg -c AppleSmartBattery | grep -i Capacity

実行すると、このように出力されます。

$ ioreg -c AppleSmartBattery | grep -i Capacity
    | |           "MaxCapacity" = 4745
    | |           "CurrentCapacity" = 3463
    | |           "LegacyBatteryInfo" = {"Amperage"=3290,"Flags"=7,"Capacity"=4745,"Current"=3463,"Voltage"=8282,"Cycle Count"=282}
    | |           "DesignCapacity" = 5100

MaxCapacityがバッテリーの最大容量、CurrentCapacyty が今のバッテリー残量、DesginCapacityが製品出荷時の(設計された)バッテリー最大容量です。

劣化状況は MaxCapacity ÷ DesginCapacity という計算をすると求められます。

上の例だと 4,745 ÷ 5,100 = 0.930392… となり、製品出荷時から比べるとパフォーマンスが93%(0.93)に減っているので、損耗率は 100 – 93 = 7% となります。

ちなみに上の例は買ってから１年のMacBook Airです。
１年フルに仕事で使ってたのですが、7%しか劣化していないのですね。
もっと劣化してると思っていたけど結構優秀。

【Mac OS X】スクリーンショットの保存場所を変える方法

デフォルトだと画面のスクリーンショット画像を撮るとデスクトップフォルダに保存されます。
裏ワザ、隠し機能的ですが、ターミナルから下のようなコマンドを入力すると画像の保存フォルダを変更することができます。

【ピクチャフォルダに保存する】

$ defaults write com.apple.screencapture location ~/Pictures
$ killall SystemUIServer

ピクチャ以外にも好きなディレクトリにすることもできます。

【ScreenShotsフォルダに保存する】

$ mkdir ~/ScreenShots
$ defaults write com.apple.screencapture location ~/ScreenShots
$ killall SystemUIServer

戻したくなったら下のコマンドで戻すこともできます。

【デフォルト(デスクトップ)に戻す】

$ defaults delete com.apple.screencapture location
$ killall SystemUIServer

以上、クリーンショット保存先を変える方法でした。
散らかってしまいがちなデスクトップもこれで綺麗に整理整頓されるかも。

【Sublime Text 2】Mac OS Xで日本語入力のタブ変換ができなくなった場合の対処方法

Sublime Text 2 をしばらく使っていて、Mac OS Xで日本語入力のタブ変換が出来ないことにふと気づきました。

ひらがなを入力したら変換候補が出てきますが、ここでタブを押して変換候補を切り替えようとしたら、タブキーを押した途端に変換候補の欄が閉じて、入力中の文字が消えてしまう。

カーソルで変換候補を切り替えればいつも通り入力はできます。
でも、つい癖でタブキーを押すたび、入力をやり直すハメになって、手が止まる…。

これじゃいけないとタブ関係のキーバインドを見なおしたら何とかなったので、
修正方法をメモしておきます。

解決方法

メニューからPreferences > Key Bindings – Default を開きます。
すると、下のような怪しい部分があるので…

	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
		"context":
		[
			{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
		]
	},

これをコメントアウトしてしまいます。

/*
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
	{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
		"context":
		[
			{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
		]
	},
*/

あとは保存すればOK。

これで、ストレスなく快適にSublime Text 2を使えるようになりました。

それで原因は？

なんでしょうね…。
色々とプラグインを入れて使っているため、何が原因かは不明なんです。
情報求む。

Mac OS X で pkg-configでエラーになった

普段から OS Xのパッケージ管理には Homebrew を使っています。
Homebrew に含まれる一部パッケージ(pango)のバージョンを変えてインストールする必要があり、自分でビルドしてみようと思ったところすっかりはまってしまいました。

発生した症状

Homebrew でインストールしたパッケージ(cairo)に依存している箇所でエラーになってしまいました。

具体的には ./configure の実行中に pkg-config で依存しているパッケージの.pc ファイルが存在しないと怒られています。

# config.log
pkg-config --cflags --print-errors cairo 

Package xcb-shm was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-shm.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xcb-shm', required by 'cairo', not found

解決するには？

エラーメッセージどおり、環境変数 PKG_CONFIG_PATHの通るところに .pc ファイルを配置するか、環境変数にパスを追加して再実行することで解決しました。

PKG_CONFIG_PATHが空の場合のデフォルトは

/usr/local/lib/pkgconfig

です。

今回は /opt/X11/lib/pkgconfig/ の中に依存している .pcファイルがあったので、パス追加で対応しました。

$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/

再実行し、エラーが出なくなるのを確認します。

$ pkg-config --cflags --print-errors cairo

あとは通常通り、./configure, make などを実行すればOKです。

OS X では(Homebrewでは？) X11 関係の pkgconfigのパッケージ情報ファイル(.pcファイル)は /opt/X11/lib/pkgconfig/ にあるのですね。

Mac OS X でポートを開いているプログラムを調べる

WindowsやLinuxでは netstat の -bオプションや-pオプションでポートを待ち受けているプロセスを調べる事ができるのに、Mac OS Xではそんなオプションが無く困った。

なんとか方法が他にないか調べた所、
Mac OS X では lsof を使うのが一番簡単そう。

$ lsof -i | grep LISTEN

結果はこんな感じになる。

$ lsof -i | grep LISTEN
Dropbox     303   user   19u  IPv4 0xffffff0123456789      0t0  TCP *:17500 (LISTEN)
Dropbox     303   user   25u  IPv4 0xffffff0123456789      0t0  TCP localhost:26165 (LISTEN)
node      56728   user    8u  IPv4 0xffffff0123456789      0t0  TCP *:hbci (LISTEN)
mongod    57071   user    6u  IPv4 0xffffff0123456789      0t0  TCP localhost:28017 (LISTEN)
mongod    57071   user    7u  IPv4 0xffffff0123456789      0t0  TCP localhost:27017 (LISTEN)

調べようと思った動機は mongodb のListenポートをど忘れして確認したかっただけでした。
実行結果を見ると mongodb は TCP localhost:27017, TCP localhost:28017とあるので、
待ち受けているポートはTCPポート27017, 28017の2つですね。