文字コードと BOM の問題

最終更新： 2026年5月16日

文字化けやコードページのエラーは、ほぼすべて一つの原因にたどり着きます。 ファイルが UTF-8 のバイト順マーク (BOM) を失っていることです。Daxlate は CSV を 常に UTF-8 (BOM 付き) で書き出します。これは Windows の Excel がダブルクリックで 開くときに期待する形式なので、往復処理が壊れている場合は、途中で別のツールが ファイルを保存し直したことがほとんどです。以下の各症状に、原因と対処を示します。

症状: Excel で CSV を開くと文字化けする #

原因: UTF-8 の BOM を取り除くツール、または従来のコードページ（例: Windows-1252）に変換するツールで、ファイルが開かれたか保存し直されています。

対処: アプリの**ファイル → 翻訳をエクスポート…**からエクスポートし直して ください。Daxlate の CSV 出力は常に BOM 付き UTF-8 で、これは Windows の Excel がダブルクリックで開くときに期待する形式です。ほかから来たファイルを扱っている 場合は、インポート前に Notepad++ や VS Code で BOM 付き UTF-8 として保存し 直してください。

症状: 「コードページの不一致」や解析エラーでインポートに失敗する #

原因: UTF-8 以外で保存されているため、ASCII 以外の文字がパーサーに届く前に 壊れています。

対処: 文字コードを扱えるエディター（Notepad++、VS Code、Sublime）でファイル を開き、BOM 付き UTF-8 として保存し直してから、もう一度インポートしてください。

症状: 絵文字や珍しい CJK 文字がラウンドトリップで落ちる #

原因: 基本多言語面を超える Unicode に完全対応していないエディターで スプレッドシートが開かれたか、Excel 以外の一部のツールの「CSV として保存」で 従来形式の CSV として保存されています。

対処: 絵文字、珍しい CJK 文字、歴史的文字など追加面の文字を含む内容では、 CSV より XLSX を選んでください。XLSX の保存形式は曖昧さがありませんが、CSV は 書き出した側が選んだ文字コードに左右されます。

症状: インポートのプレビューに「不明な列を無視しました: …」と出る #

原因: Daxlate のヘッダーの形（Object ID、Type、Parent、Name、 Caption ({culture})、Description ({culture})）に合わない列がファイルにあり ます。翻訳者がメモ用の列を足すことがあり、インポート側は全体を失敗させる代わり に警告付きでその列を落とします。

対処: 想定内の警告なら無視して構いません。想定していたカルチャーが検出され ない場合は、列見出しを確認してください。括弧付きで有効な .NET のカルチャー コードを含む Caption (xx-XX) または Description (xx-XX) である必要があります。