CSV を Excel に変換

そもそも、なぜ文字化けするのか

日本の業務システムから出てくる CSV は、いまでも Shift-JIS で書かれていることが多くあります。 一方で、それを受け取る側 —— 最近の表計算ソフト、データベース、スクリプト —— はたいてい UTF-8 を前提にしています。Shift-JIS のバイト列を UTF-8 として読むと、 譁�蟄怜喧縺� のような並びになります。これが文字化けです。

やっかいなのは、失敗が失敗に見えないところです。ファイルは開きますし、行数も列数も 合っています。壊れているのは中身だけで、気づくのはたいてい誰かに渡したあとです。

このページはどう扱うか

読み込む前に文字コードを判定します。BOM があればそれに従い、なければ候補ごとに 厳密モードで復号を試します —— Shift-JIS や UTF-8 のような多バイト符号化には 「ありえないバイトの並び」が定義されているので、それに当たった候補は推測ではなく除外できます。 判定できるのは UTF-8、Shift-JIS、Big5、GBK、EUC-KR、UTF-16、Windows-1252 です。

判定した名前は表の上に表示されます（例：Read as SHIFT_JIS; exports are UTF-8.）。 こちらの判断を黙って押しつけないためで、目で確認できるようにしてあります。 そして書き出すファイルは常に UTF-8 です。つまり、ここで .xlsx や .csv に変換すること自体が、 文字化けの修復になります。

変換ツールがよく壊すもの

• 先頭のゼロ。郵便番号の 0123456、社員番号の 007、 品番の 0042 —— 数値として書き込まれると 123456、7、 42 になって戻ってきます。ここでは先頭にゼロがある値は文字列として書くので残ります。
• 長い伝票番号。Excel が正確に保持できるのは 15 桁までです。16 桁の注文番号を数値として 書くと、警告もなく末尾が丸められます。15 桁を超える値は文字列のまま書き出します。
• 区切り文字。カンマ、セミコロン、タブ、縦棒を先頭の数行から判定します。 データベースからの書き出しはタブ区切りのことが多く、カンマ決め打ちのツールに渡すと 1 列になります。

ふつうの数値はちゃんと数値として書き込まれるので、金額の列はそのまま SUM できます。

できないこと（先に書いておきます）

• 日付は文字列のままです。 2026-09-02 は日付シリアル値ではなく、 そのままの文字として入ります。03/04/2026 が 3 月 4 日なのか 4 月 3 日なのかは ファイルの出所を知らないと決められません。推測する変換ツールは「正しく見えるが正しくない」 表を作ります。取り込んだあとに Excel 側で書式を設定してください。
• 数式は作りません。 出来上がるのはデータのブックであって、計算モデルではありません。
• 古い .xls は開けません。 Excel の 97 形式は別のバイナリ形式です。 Excel や Numbers で開いて .xlsx か .csv として保存し直してください（そう表示されます）。

ダウンロードする前に確かめる

ボタンの上に出ている表が、そのまま .xlsx に入る中身です。列が想定どおりに分かれているか、 文字化けしていないか、数値の列が数値として並べ替わるか —— アップロードして結果を受け取る サービスでは、この確認ができません。検索ボックスで絞り込めば、必要な行だけを書き出せます。

毎月おなじ作業になっているなら

一回きりの変換ならこのページで十分です。ただ、同じエクスポートが毎月届いて、 毎月おなじ手直しをしているなら、それは変換ではなく手作業のループです。

TableDI は、すべてが自分のパソコンの中で動くデスクトップ表計算ワークスペースです。 CSV を行数制限なしで取り込み、整形を数式列として保存しておけるので、 翌月の取り込みでは最初から正しい状態になります。 取り込みの仕組み（英語）。

表示言語について：このページとブラウザ内ツールは日本語です。デスクトップアプリ本体の画面は 現在英語です（日本語版は準備中）。