1そもそも「文字コード」って何？
コンピュータは、内部的にはすべてのデータを0と1の数字（バイナリ）で処理しています。「あ」という文字も、「A」という文字も、コンピュータの中では数字の列として保存されています。
この「人間の文字」と「コンピュータの数字」を対応させるルールが文字コードです。
たとえば「A」という文字は、ほぼすべての文字コードで「65」という数字に対応しています。ここまでは共通です。問題は日本語。「あ」という文字を何番の数字に割り当てるかは、文字コードの種類によって違います。
つまり、同じファイルでも「どの文字コードで読むか」によって、表示される文字が変わるということです。これが文字化けの正体です。
文字コードをひとことで言うと
- 文字コード ＝ 「文字」と「数字」の対応表
- 同じ数字でも、対応表が違えば別の文字として表示される
- ファイルを作った側と開く側で対応表が違うと、文字化けが起きる
2UTF-8とShift_JIS ― 何が違うのか
日本でよく使われる文字コードは、主にUTF-8とShift_JISの2つです。それぞれの特徴を見てみましょう。
| 項目 | UTF-8 | Shift_JIS |
|---|---|---|
| 正式名称 | Unicode Transformation Format - 8bit | Shift Japanese Industrial Standards |
| 対応文字 | 世界中のほぼすべての文字 | 日本語 + ASCII（英数字・記号） |
| 半角英数字の容量 | 1文字 = 1バイト |
1文字 = 1バイト |
| 日本語の容量 | 1文字 = 3バイト |
1文字 = 2バイト |
| 主な用途 | Web、API、プログラミング全般 | Windows旧来のソフト、楽天RMS、一部モールCSV |
| 現在の主流 | 世界標準。新しいシステムはほぼUTF-8 | レガシー（旧式）だが日本のEC業務では現役 |
容量の違い ― なぜ気にする必要があるのか
UTF-8は日本語1文字に3バイト、Shift_JISは2バイト使います。「たった1バイトの差」に思えますが、数万行のCSVになると差は大きくなります。
たとえば、日本語が1万文字含まれるCSVファイルの場合：
- UTF-8：約30,000バイト（約30KB）
- Shift_JIS：約20,000バイト（約20KB）
通常の業務ではこの差が問題になることは少ないですが、モール側にファイルサイズ上限がある場合や、大量データの一括アップロードでは意識する必要が出てきます。
いつUTF-8が使われるのか？
現在のIT業界では、UTF-8がデファクトスタンダード（事実上の標準）です。
- Webサイト ―― HTML・CSS・JavaScriptはほぼ100% UTF-8
- API連携 ―― Amazon SP-API、Shopify APIなど、APIのレスポンスはUTF-8
- プログラミング ―― Python、JavaScript、GASなど主要言語はUTF-8前提
- データベース ―― MySQL、PostgreSQLなど、UTF-8（またはutf8mb4）が推奨
- Mac / Linux ―― OSのデフォルト文字コードがUTF-8
ひとことで言えば、「新しい技術」「グローバルなサービス」はすべてUTF-8です。
いつShift_JISが使われるのか？
一方でShift_JISは、日本独自のレガシーシステムで根強く残っています。
- 楽天RMS ―― CSVのダウンロード・アップロードがShift_JIS前提
- 古いWindows環境 ―― メモ帳で保存するとデフォルトがShift_JIS（※Windows 10以降はUTF-8に変更）
- Excel ―― CSVを開くとShift_JISとして解釈しようとする（BOMなしUTF-8だと文字化けしやすい）
- 一部の基幹システム・受発注システム ―― 20年以上前に作られたシステムはShift_JIS
- 一部のモールCSV ―― Yahoo!ショッピングの一部機能など
つまり、EC業務ではUTF-8とShift_JISの「どちらも現役」という状況が続いています。これが問題をややこしくしている最大の原因です。
BOM（Byte Order Mark）という罠
- UTF-8には「BOMあり」と「BOMなし」の2種類がある
- BOMとはファイル先頭に付く「このファイルはUTF-8です」という目印（3バイト）
- ExcelでUTF-8のCSVを文字化けせずに開くにはBOMありが必要
- 一方、プログラムによってはBOMがあるとエラーになるものもある
- ExcelとプログラムでCSVを共有する場合、BOMの有無が地味にハマる
3文字コードが違うとどうなるのか
「文字コードが違うだけでしょ？」と軽く考えていると、実務では予想以上に痛い目に遭います。
パターン1：文字化け
最もよくあるパターンです。UTF-8で作成されたCSVをShift_JISとして開く（またはその逆）と、日本語が全く読めない記号の羅列になります。
「商品名：タオル」
「蝟ｩ蜩∝錐：繧ｿ繧ｪ繝ｫ」
これ自体は「開き直せば済む」話ですが、問題はこの状態で気づかずに上書き保存してしまうケースです。文字化けしたまま保存すると、元のデータは二度と復元できません。
パターン2：一部の文字だけ化ける
全体は読めるのに、特定の文字だけ化けるというパターンもあります。Shift_JISでは表現できない文字（一部の漢字、記号など）がUTF-8のデータに含まれていた場合に起きます。
- 「髙」（はしごだか） ―― 人名・社名に多い。Shift_JISでは表現できない
- 「﨑」（たつさき） ―― 同様にShift_JISの範囲外
- 「〜」（波ダッシュ） ―― UTF-8の「〜」とShift_JISの「～」は別の文字として扱われる
お客様の氏名に「髙橋」「山﨑」が含まれていた場合、Shift_JISに変換した時点で文字が消えたり「?」に置き換わったりします。送り状や納品書に影響が出る可能性があるため、これは見過ごせないトラブルです。
パターン3：データが壊れる（サイレント破損）
最も厄介なのが、見た目は正常なのにデータが壊れているパターンです。
Shift_JISには「ダメ文字」と呼ばれる問題があります。Shift_JISの2バイト目が特定の値（0x5C = バックスラッシュ）になる文字があり、これがプログラムの処理で誤解釈される可能性があります。
- 「表」「十」「ソ」「能」「申」など ―― Shift_JISの2バイト目が 0x5C のため、一部のプログラムで問題が発生
- CSVの区切り文字やエスケープ処理と干渉して、列がずれる・データが欠落することがある
こうしたケースは目視では発見しにくく、「なぜかCSVの取り込みでエラーになる」「データの行数が合わない」といった形で後から発覚します。
文字コードの不一致で起きるトラブルまとめ
- CSVが全面的に文字化けして読めない
- 特定の人名・住所だけ文字が消える・化ける
- 文字化け状態で上書きして元データが消失
- データ取り込み時にエラーが出て処理が止まる
- 列ずれ・データ欠落が発生し、誤った情報でモールを更新してしまう
4改行コードの違い ― CR・LF・CRLF
文字コードと並んで厄介なのが改行コードの問題です。「改行」という目に見えない文字にも、実は種類があります。
| 改行コード | 記号 | バイト表現 | 使われるOS |
|---|---|---|---|
| LF（Line Feed） | \n |
0x0A |
Mac / Linux / Unix |
| CR（Carriage Return） | \r |
0x0D |
古いMac（OS 9以前） |
| CRLF（CR + LF） | \r\n |
0x0D 0x0A |
Windows |
名前の由来はタイプライターの動作です。CR（Carriage Return）は「印字ヘッドを行の先頭に戻す」動作、LF（Line Feed）は「紙を1行送る」動作。Windowsはこの2つを組み合わせたCRLFを改行として使い、Mac/LinuxはLFだけを使います。
改行コードが違うと何が起きるのか
改行コードの違いは、以下のようなトラブルを引き起こします。
- 全行が1行に繋がる ―― LFのファイルを、CRLFしか認識しないプログラムで読むと、改行が無視されて全データが1行になる
- 行末に謎の記号が表示される ―― CRLFのファイルをMac/Linuxで開くと、各行の末尾に
^Mという記号が表示される - CSVの行数がずれる ―― 改行コードが混在していると、プログラムが行の区切りを正しく認識できない
- データ取り込みエラー ―― 受発注システムが特定の改行コードしか受け付けない場合、そもそもファイルを読み込めない
改行 = LF
CRLF前提
or 全行が1行に
EC業務での具体的なトラブル例
改行コードの問題は、EC業務では特に以下のような場面で起きやすいです。
- 商品説明文に改行が含まれるCSV ―― 改行コードの種類によっては、商品説明の途中で行が分割されてCSVの構造が壊れる
- WindowsのPCで作成したCSVをLinuxサーバーの自動処理で読む ―― 改行コードが合わず、データが正しくパースされない
- モールからダウンロードしたCSVの改行コードがモールによって違う ―― 楽天はCRLF、別のシステムはLF、といった混在が発生
改行コード問題のポイント
- 改行コードは目に見えないので、問題が起きるまで気づきにくい
- Windows（CRLF）とMac/Linux（LF）の混在が最大の原因
- CSVの中に改行が含まれるデータがあると、さらにややこしくなる
- 自動処理プログラムでは「入力ファイルの改行コードを統一する」前処理が必要
5EC実務で「文字コード問題」が起きやすい場面
ここまでの知識を踏まえて、EC運営の現場でよくある文字コード・改行コードトラブルをまとめます。
場面1：楽天RMSのCSVダウンロード → 他システムへの取り込み
楽天RMSからダウンロードしたCSVはShift_JIS + CRLFが基本です。これをそのまま自社のシステム（UTF-8前提）に取り込もうとすると文字化けします。毎回手動でExcelで開いて、UTF-8に保存し直して......という作業をしている方も多いのではないでしょうか。
場面2：Amazon SP-APIのレスポンス → CSV出力
Amazon SP-APIからのデータはUTF-8です。これを楽天アップロード用のCSVに変換する場合、Shift_JISに変換する必要があります。このとき、Shift_JISで表現できない文字（「髙」「﨑」など）が含まれていると変換エラーになります。
場面3：複数モールのデータ統合
各モールからダウンロードしたCSVを1つのExcelやスプレッドシートにまとめる作業。モールごとに文字コードが違うため、何も考えずにコピー&ペーストすると特定のモールのデータだけ文字化けする、という事故が起きます。
場面4：外注先・パートナーとのファイル共有
自社はWindows（CRLF / Shift_JIS）、外注先のエンジニアはMac（LF / UTF-8）という環境差がトラブルの原因に。「こちらでは正常に見えるんですけど......」というやり取りが繰り返されることになります。
場面5：GAS・Pythonでの自動処理
Google Apps Script（GAS）やPythonで自動化スクリプトを組む場合、入力ファイルの文字コード判定 → 変換 → 処理 → 出力ファイルの文字コード指定という一連の処理が必要です。ここを正しく実装しないと、「手動でやっていた頃は問題なかったのに、自動化したら文字化けするようになった」という本末転倒な事態が発生します。
EC業務で文字コードが原因のトラブルが多い理由
- モールごとに文字コードが異なる（Shift_JIS系とUTF-8系の混在）
- Windows・Mac・Linuxなど関係者の環境がバラバラ
- CSVという「見た目はシンプルだが内部的には複雑」なフォーマットを多用する
- 「開く」「保存する」だけで文字コードが知らぬ間に変わることがある
- 問題が起きたとき、原因の特定に技術知識が必要
6自力対応の限界と、プロに任せるという選択肢
文字コードと改行コードの問題は、「仕組みを知っていれば避けられる」けれど「知らないと何度でも同じミスを繰り返す」という厄介な性質があります。
一時的な対処なら、ファイルを開くときに文字コードを指定する、Excelの設定を変える、といった方法で乗り切れます。しかし、それを毎日・毎回・担当者全員が間違いなくやり続けるのは現実的でしょうか？
- 担当者が変わったら、また同じ問題が起きる
- 月に数回、気づかないうちに文字化けしたデータがモールに上がっている
- 「いつも通りにやったのに、今回だけエラーになった」の原因がわからない
こうした問題を根本から解決するには、以下のような仕組みが必要です。
文字コード・改行コード問題の根本対策
- 自動変換の仕組み ―― ファイルの文字コードを自動判定し、必要なコードに変換してから処理する
- 改行コードの統一処理 ―― 入力ファイルの改行コードを処理前に統一する前処理を組み込む
- BOMの自動付与・除去 ―― Excelで開くCSVにはBOMを付け、プログラム処理用にはBOMを除去する
- Shift_JIS変換時の文字チェック ―― 変換不能な文字を事前に検出し、代替文字に置き換える or 警告を出す
- ヒューマンエラーが入る余地をなくす ―― 手動で文字コードを選択する必要がない自動処理フローを構築する
これらはGASやPythonのスクリプトで実現可能です。一度仕組みを作ってしまえば、担当者が変わっても文字コードの知識がなくても、正しい形式でデータが処理されます。
とはいえ、「文字コード判定」「エンコーディング変換」「改行コード統一」「BOM処理」「エラー時のフォールバック」......これらを正しく実装するには、文字コードの仕組みを深く理解している必要があります。中途半端な実装は、むしろ新たなバグの温床になります。
もし毎月のCSV業務で「文字化け」「改行のズレ」「取り込みエラー」に時間を取られているなら、その繰り返し作業ごと仕組み化してしまうのが、最も確実な解決策です。