ファイル

【C#】CSV文字コード変換の完全手順：Shift-JIS・UTF-8・BOM対応でExcelの文字化けを防ぐ

2025-04-30更新日: 2025-04-30

C#でCSVの文字化けを防ぐには、読み書き時にStreamReaderやStreamWriterへEncodingを明示すればよいでしょう。

Shift‐JISの読み込みはEncoding.GetEncoding(932)、UTF-8でExcel互換を保つならBOM付きnew UTF8Encoding(true)を使い先頭にBOMを付与します。

BOM確認で自動判定し適切なエンコードへ再保存すると運用が安定します。

目次から探す

CSVと文字エンコーディングの基礎
- CSVファイルの構造
- 主要エンコーディングの特徴
文字化けが起きる主な原因
- Excelで開く際の自動判定ミス
- Webダウンロード時のContent-Type不足
C#でCSVを読み込む方法
- StreamReaderでの基本実装
- CsvHelperライブラリ活用
C#でCSVを書き出す方法
- StreamWriterでのエンコーディング指定
- File.WriteAllBytesで直接バイト列を書き込む
文字コード自動判定ロジック
- BOM検出アルゴリズム
- Udeライブラリでの汎用推定
既存CSVの一括変換ツール開発
- コマンドラインの設計
- Parallel.ForEachによる高速化
Excelと高い互換性を保つ設定
テストと品質保証
- NUnitによるユニットテスト
- 大容量ファイルのメモリ消費検証
よくあるエラーとトラブルシューティング
セキュリティと運用上の注意
- エンコード指定漏れが引き起こすXSS
- ファイル名文字化けとZIP圧縮の相性
使用API・ライブラリ索引
- System.IOとSystem.Textの主要クラス
- NuGetで入手できる便利パッケージ
まとめ

CSVと文字エンコーディングの基礎

CSVファイルを扱う際に文字コードの理解は非常に重要です。

ここではCSVファイルの基本的な構造と、代表的な文字エンコーディングの特徴について詳しく解説します。

CSVファイルの構造

CSV(Comma-Separated Values)は、カンマで区切られたテキストデータの形式で、表形式のデータを簡単に保存・交換できるファイルフォーマットです。

Excelや多くのデータ処理ツールで広く使われていますが、仕様がシンプルな反面、細かいルールを理解しておかないと文字化けやデータの誤読が起きやすいです。

フィールド区切りと改行コードの扱い

CSVファイルの基本は「フィールド(列)をカンマ(,)で区切る」ことです。

1行が1レコード(行)に対応し、複数のフィールドがカンマで区切られています。

名前,年齢,住所
山田太郎,30,東京都

ただし、フィールド内にカンマや改行が含まれる場合は、単純にカンマで区切るだけでは正しく読み込めません。

そこで、フィールド全体をダブルクォート(“)で囲むルールがあります。

改行コードは通常、Windows環境ではCR+LF(\r\n)、Unix/LinuxやmacOSではLF(\n)が使われます。

CSVファイルの改行コードが環境によって異なるため、読み込み時に改行コードを正しく認識することが重要です。

ダブルクォートのエスケープルール

フィールド内にダブルクォートを含めたい場合は、ダブルクォートを2つ連続で書くことでエスケープします。

例えば、フィールドにHe said "Hello"という文字列を入れたい場合は、以下のように記述します。

"彼は""こんにちは""と言った",25,大阪

このルールを守らないと、CSVのパーサーがフィールドの区切りを誤認識し、データが崩れる原因になります。

主要エンコーディングの特徴

CSVファイルの文字コード(エンコーディング)は、ファイルの読み書きやExcelでの表示に大きく影響します。

ここでは代表的なエンコーディングの特徴を解説します。

UTF-8

UTF-8はUnicodeの符号化方式の一つで、世界中の文字を扱えるため国際的に最も広く使われています。

ASCIIコードと互換性があり、英数字は1バイト、日本語などの多バイト文字は複数バイトで表現されます。

UTF-8のCSVは多言語対応に優れていますが、Excelの古いバージョンや設定によっては文字化けが起きることがあります。

特にBOM(Byte Order Mark)が付いていないUTF-8ファイルは、ExcelがShift-JISとして誤認識しやすいです。

BOM付きとBOMなしの差異

BOMはファイルの先頭に付加される特別なバイト列で、ファイルのエンコーディングを示す役割があります。

UTF-8のBOMは3バイト(0xEF, 0xBB, 0xBF)で、これがあるとExcelはUTF-8として正しく認識しやすくなります。

種類	BOMの有無	Excelでの認識	備考
UTF-8	あり	正しくUTF-8	文字化け防止に有効
UTF-8	なし	Shift-JISと誤認識	文字化けの原因になりやすい

ただし、BOM付きUTF-8は一部のツールや環境でBOMを余計な文字として扱うことがあるため、用途に応じて使い分けが必要です。

Shift-JIS

Shift-JISは日本語Windows環境で長く使われてきた文字コードで、日本語の漢字やひらがな、カタカナを2バイトで表現します。

日本の多くの既存システムやExcelの標準設定がShift-JISを前提としているため、互換性が高いです。

ただし、Shift-JISはUnicodeではないため、多言語対応が弱く、特殊文字や絵文字の扱いに制限があります。

また、Shift-JISのファイルをUTF-8として読み込むと文字化けが発生します。

Windows環境との互換性

WindowsのExcelはデフォルトでShift-JIS(コードページ932)を想定してCSVを読み書きします。

そのため、Shift-JISで保存されたCSVはExcelで文字化けしにくいです。

一方、UTF-8で保存したCSVはBOMがないとExcelで文字化けすることが多いです。

最近のExcelバージョンではUTF-8対応が改善されていますが、互換性を考慮するとShift-JISが無難な選択になる場合もあります。

UTF-16

UTF-16はUnicodeの符号化方式の一つで、基本的に2バイト単位で文字を表現します。

UTF-16にはリトルエンディアン(LE)とビッグエンディアン(BE)の2種類があり、BOMでどちらかを判別します。

UTF-16はWindowsの内部文字列表現に近いため、.NET Frameworkの内部処理ではよく使われますが、CSVファイルとしてはあまり一般的ではありません。

UTF-16のCSVはファイルサイズが大きくなりやすく、Excelでも扱いが限定的です。

Endianの概念とBOM

Endian(エンディアン)とは、複数バイトで表現されるデータのバイト順序のことです。

UTF-16ではリトルエンディアン(LE)とビッグエンディアン(BE)があり、BOMで判別します。

UTF-16 LEのBOM：0xFF 0xFE
UTF-16 BEのBOM：0xFE 0xFF

BOMがない場合、どちらのエンディアンか判別できず、文字化けや読み込みエラーの原因になります。

UTF-16のCSVファイルを扱う場合は、BOMの有無とエンディアンを必ず確認してください。

文字化けが起きる主な原因

Excelで開く際の自動判定ミス

ExcelでCSVファイルを開くとき、ファイルの文字コードを自動判定しますが、この判定が誤ると文字化けが発生します。

特にUTF-8とShift-JISの判別ミスが多いです。

UTF-8誤認識パターン

UTF-8でエンコードされたCSVファイルをBOMなしで保存した場合、ExcelはそのファイルをShift-JISとして読み込むことがあります。

これにより、日本語の文字が正しく表示されず、文字化けが起きます。

例えば、UTF-8で「こんにちは」と書かれたCSVをBOMなしで保存し、Excelで開くと以下のように表示されることがあります。

正しい表示(UTF-8対応のエディタ)：「こんにちは」
Excelでの誤表示(Shift-JISとして読み込み)：「ã\u0081\u0093ã\u0082\u0093ã\u0081«ã\u0081¡ã\u0081¯」

この問題を防ぐには、UTF-8のBOMを付加して保存するか、Excelの「データ」タブから「テキストファイルのインポート」を使い、文字コードを明示的に指定して読み込む方法があります。

Shift-JIS誤認識パターン

逆に、Shift-JISでエンコードされたCSVファイルをExcelがUTF-8として読み込もうとすると、やはり文字化けが発生します。

Shift-JIS特有のバイト列がUTF-8として解釈されるため、文字が崩れます。

例えば、Shift-JISで「東京」と書かれたCSVをUTF-8として読み込むと、以下のような文字化けが起きます。

正しい表示(Shift-JIS対応のエディタ)：「東京」
Excelでの誤表示(UTF-8として読み込み)：「æ\u009D\u008Eä\u009D\u009B」

この場合も、Excelのインポート機能で文字コードを指定するか、Shift-JISで保存したファイルをそのまま開くのが安全です。

Webダウンロード時のContent-Type不足

WebブラウザでCSVファイルをダウンロードする際、HTTPレスポンスヘッダーのContent-Typeが適切に設定されていないと、ブラウザやExcelが文字コードを誤認識し、文字化けが起きることがあります。

ブラウザ自動判定の限界

ブラウザはContent-Typeヘッダーのcharsetパラメータを参照して文字コードを判定しますが、これがない場合は独自の判定ロジックに頼ります。

判定が不正確なため、特に日本語のCSVファイルで文字化けが発生しやすいです。

また、Excelに連携して開く場合も、ブラウザから渡されたファイルの文字コード情報が不足していると、Excelが誤った文字コードで読み込むことがあります。

HTTPヘッダー設定例

CSVファイルをWebサーバーから配信する際は、以下のようにContent-Typeヘッダーを正しく設定することが重要です。

Shift-JISの場合

Content-Type: text/csv; charset=Shift_JIS
Content-Disposition: attachment; filename="data.csv"

UTF-8の場合(BOM付き推奨)

Content-Type: text/csv; charset=UTF-8
Content-Disposition: attachment; filename="data.csv"

この設定により、ブラウザやExcelは文字コードを正しく認識し、文字化けを防げます。

また、ASP.NETや他のWebフレームワークでCSVを返す場合は、レスポンスヘッダーに上記のContent-Typeを明示的に指定し、ファイルのエンコードも一致させることが大切です。

C#でCSVを読み込む方法

StreamReaderでの基本実装

C#でCSVファイルを読み込む際、最も基本的な方法はStreamReaderを使うことです。

StreamReaderはファイルのテキストを1行ずつ読み込めるため、CSVの各行を処理しやすいです。

Encoding未指定のリスク

StreamReaderのコンストラクタでエンコーディングを指定しない場合、デフォルトでシステムの標準エンコーディング(Windowsでは通常Shift-JIS)が使われます。

これがファイルの実際のエンコーディングと異なると、文字化けが発生します。

例えば、UTF-8で保存されたCSVをエンコーディング指定なしで読み込むと、文字化けや例外が起きることがあります。

逆にShift-JISのファイルをUTF-8指定で読み込んでも同様です。

必ずファイルのエンコーディングに合わせてEncodingを指定してください。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "sample.csv";
        // Shift-JISで読み込む例
        using (var reader = new StreamReader(filePath, Encoding.GetEncoding("Shift_JIS")))
        {
            while (!reader.EndOfStream)
            {
                string line = reader.ReadLine();
                Console.WriteLine(line);
            }
        }
    }
}

ヘッダー1,ヘッダー2,ヘッダー3
データ1,データ2,データ3

このようにエンコーディングを指定することで、正しく日本語を読み込めます。

改行コードの自動検出

StreamReaderは改行コードを自動的に認識します。

WindowsのCR+LF(\r\n)、Unix/Linux/macOSのLF(\n)どちらでも問題なく読み込めます。

そのため、特別な設定をしなくても異なる環境で作成されたCSVファイルを読み込めるのが便利です。

ただし、ファイル内で改行コードが混在している場合は、行の分割が意図しない結果になることがあるため注意してください。

CsvHelperライブラリ活用

CsvHelperはC#でCSVを扱う際に非常に便利なライブラリです。

パースやマッピング、型変換など多機能で、複雑なCSV処理を簡単に実装できます。

ConfigurationでのEncoding指定

CsvHelper自体はTextReaderを受け取るため、StreamReaderでエンコーディングを指定してから渡します。

これにより、文字コードを正しく扱えます。

using System;
using System.IO;
using System.Text;
using CsvHelper;
using System.Globalization;
class Program
{
    static void Main()
    {
        string filePath = "sample.csv";
        using (var reader = new StreamReader(filePath, Encoding.GetEncoding("Shift_JIS")))
        using (var csv = new CsvReader(reader, CultureInfo.InvariantCulture))
        {
            while (csv.Read())
            {
                var field1 = csv.GetField(0);
                var field2 = csv.GetField(1);
                var field3 = csv.GetField(2);
                Console.WriteLine($"{field1} | {field2} | {field3}");
            }
        }
    }
}

ヘッダー1 | ヘッダー2 | ヘッダー3
データ1 | データ2 | データ3

このようにStreamReaderのエンコーディング指定とCsvReaderの組み合わせで、文字化けなくCSVを読み込めます。

カスタムマッピングと型変換

CsvHelperはCSVの列をクラスのプロパティにマッピングでき、型変換も自動で行えます。

例えば、以下のようにクラスを定義し、マッピングを設定します。

using System;
using System.Globalization;
using System.IO;
using System.Text;
using CsvHelper;
using CsvHelper.Configuration;
public class Record
{
    public string Name { get; set; }
    public int Age { get; set; }
    public DateTime JoinDate { get; set; }
}
public sealed class RecordMap : ClassMap<Record>
{
    public RecordMap()
    {
        Map(m => m.Name).Name("名前");
        Map(m => m.Age).Name("年齢");
        Map(m => m.JoinDate).Name("入社日").TypeConverterOption.Format("yyyy/MM/dd");
    }
}
class Program
{
    static void Main()
    {
        string filePath = "sample.csv";
        using (var reader = new StreamReader(filePath, Encoding.GetEncoding("Shift_JIS")))
        using (var csv = new CsvReader(reader, CultureInfo.InvariantCulture))
        {
            csv.Context.RegisterClassMap<RecordMap>();
            var records = csv.GetRecords<Record>();
            foreach (var record in records)
            {
                Console.WriteLine($"名前: {record.Name}, 年齢: {record.Age}, 入社日: {record.JoinDate:yyyy-MM-dd}");
            }
        }
    }
}

名前: 山田太郎, 年齢: 30, 入社日: 2020-04-01
名前: 佐藤花子, 年齢: 25, 入社日: 2021-07-15

この例では、CSVの「名前」「年齢」「入社日」列をRecordクラスのプロパティにマッピングし、日付のフォーマットも指定しています。

CsvHelperが自動で型変換を行うため、文字列からintやDateTimeへの変換を手動で書く必要がありません。

このようにCsvHelperを使うと、エンコーディングの指定だけでなく、複雑なCSVの読み込み処理も簡潔に実装できます。

C#でCSVを書き出す方法

StreamWriterでのエンコーディング指定

CSVファイルを書き出す際に文字コードを正しく指定することは、Excelなどでの文字化けを防ぐために非常に重要です。

StreamWriterを使う場合、エンコーディングを明示的に指定してファイルを作成します。

UTF8Encoding(true)でBOM付き生成

UTF-8でBOM(Byte Order Mark)付きのCSVファイルを作成するには、UTF8Encodingのコンストラクタにtrueを渡してBOMを付加する設定を行います。

BOM付きUTF-8はExcelでの文字化けを防ぐ効果があります。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "utf8_bom.csv";
        // UTF-8 BOM付きのエンコーディングを作成
        var utf8BomEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: true);
        using (var writer = new StreamWriter(filePath, false, utf8BomEncoding))
        {
            writer.WriteLine("ヘッダー1,ヘッダー2,ヘッダー3");
            writer.WriteLine("データ1,データ2,データ3");
        }
        Console.WriteLine("UTF-8 BOM付きCSVファイルを作成しました。");
    }
}

UTF-8 BOM付きCSVファイルを作成しました。

このコードでは、UTF8Encoding(true)を使ってBOM付きUTF-8エンコーディングを生成し、StreamWriterに渡しています。

これにより、ファイルの先頭にBOMが付加され、Excelで開いたときにUTF-8として正しく認識されます。

Encoding.GetEncoding(932)でShift-JIS出力

Shift-JIS(コードページ932)でCSVを書き出す場合は、Encoding.GetEncoding(932)を使ってエンコーディングを指定します。

Shift-JISは日本のWindows環境で標準的に使われているため、Excelでの互換性が高いです。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "shiftjis.csv";
        // Shift-JISエンコーディングを取得
        var shiftJisEncoding = Encoding.GetEncoding(932);
        using (var writer = new StreamWriter(filePath, false, shiftJisEncoding))
        {
            writer.WriteLine("ヘッダー1,ヘッダー2,ヘッダー3");
            writer.WriteLine("データ1,データ2,データ3");
        }
        Console.WriteLine("Shift-JISエンコードのCSVファイルを作成しました。");
    }
}

Shift-JISエンコードのCSVファイルを作成しました。

Shift-JISで保存したCSVは、Excelで開いたときに文字化けしにくいのが特徴です。

ただし、UTF-8に比べて多言語対応が弱い点に注意してください。

File.WriteAllBytesで直接バイト列を書き込む

File.WriteAllBytesを使うと、バイト配列を直接ファイルに書き込めます。

これにより、BOMの付加やエンコーディングの細かい制御が可能です。

先頭にBOMを付与する手順

UTF-8のBOMを手動で付与してCSVファイルを書き出す例です。

まずBOMのバイト配列を取得し、CSVデータのバイト配列と結合してから書き込みます。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "utf8_bom_manual.csv";
        string csvData = "ヘッダー1,ヘッダー2,ヘッダー3\nデータ1,データ2,データ3";
        // UTF-8 BOMのバイト配列を取得
        byte[] bom = new UTF8Encoding(true).GetPreamble();
        // CSVデータをUTF-8でバイト配列に変換
        byte[] csvBytes = Encoding.UTF8.GetBytes(csvData);
        // BOMとCSVデータを結合するバイト配列を作成
        byte[] fileBytes = new byte[bom.Length + csvBytes.Length];
        Buffer.BlockCopy(bom, 0, fileBytes, 0, bom.Length);
        Buffer.BlockCopy(csvBytes, 0, fileBytes, bom.Length, csvBytes.Length);
        // ファイルに書き込み
        File.WriteAllBytes(filePath, fileBytes);
        Console.WriteLine("UTF-8 BOM付きCSVファイルを手動で作成しました。");
    }
}

UTF-8 BOM付きCSVファイルを手動で作成しました。

この方法は、StreamWriterを使わずにバイト単位で制御したい場合に有効です。

BOMの付加漏れを防ぎ、Excelでの文字化けを回避できます。

追記時のエンコード整合性

File.WriteAllBytesはファイル全体を書き換えるため、追記(append)には向いていません。

追記したい場合はFileStreamやStreamWriterの追記モードを使う必要があります。

追記時にエンコーディングが異なると、ファイル内で文字コードが混在し、文字化けや読み込みエラーの原因になります。

例えば、最初はBOM付きUTF-8で書き込み、追記時にBOMなしUTF-8やShift-JISで追記すると不整合が起きます。

追記時は以下のポイントに注意してください。

追記モードで開く場合は、BOMは最初の書き込み時のみ付加する
追記時のエンコーディングは最初の書き込みと同じにする
可能なら追記は避け、一度にまとめて書き込む設計にする

以下は追記モードでUTF-8(BOMなし)で追記する例です。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "utf8_bom_append.csv";
        // 最初の書き込み(BOM付き)
        var utf8BomEncoding = new UTF8Encoding(true);
        using (var writer = new StreamWriter(filePath, false, utf8BomEncoding))
        {
            writer.WriteLine("ヘッダー1,ヘッダー2,ヘッダー3");
        }
        // 追記(BOMなし)
        var utf8NoBomEncoding = new UTF8Encoding(false);
        using (var writer = new StreamWriter(filePath, true, utf8NoBomEncoding))
        {
            writer.WriteLine("データ1,データ2,データ3");
        }
        Console.WriteLine("UTF-8 BOM付きファイルに追記しました。");
    }
}

UTF-8 BOM付きファイルに追記しました。

このように、追記時はBOMなしのエンコーディングを使い、ファイルの整合性を保つことが重要です。

文字コード自動判定ロジック

BOM検出アルゴリズム

CSVファイルの文字コードを自動判定する際、最も基本的かつ確実な方法はファイルの先頭にあるBOM(Byte Order Mark)を検出することです。

BOMは特定のエンコーディングを示すバイト列で、これを読み取ることでUTF-8やUTF-16の判定が可能です。

UTF-8・UTF-16LE・UTF-16BE判定

BOMはファイルの先頭に付加される特別なバイト列で、以下のようなパターンがあります。

エンコーディング	BOMバイト列(16進)	バイト数
UTF-8	EF BB BF	3
UTF-16 LE	FF FE	2
UTF-16 BE	FE FF	2

これらのバイト列をファイルの先頭から読み取り、該当するパターンと一致すれば、そのエンコーディングであると判定できます。

具体的な判定手順は以下の通りです。

ファイルの先頭4バイトを読み込みます。
先頭3バイトが0xEF 0xBB 0xBFならUTF-8と判定。
先頭2バイトが0xFF 0xFEならUTF-16リトルエンディアン(LE)と判定。
先頭2バイトが0xFE 0xFFならUTF-16ビッグエンディアン(BE)と判定。
いずれにも該当しなければBOMなしと判断し、Shift-JISなど他のエンコーディングを推定する必要があります。

以下はC#でのBOM検出のサンプルコードです。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "sample.csv";
        Encoding encoding = DetectEncoding(filePath);
        Console.WriteLine($"判定されたエンコーディング: {encoding.EncodingName}");
    }
    static Encoding DetectEncoding(string filePath)
    {
        byte[] bom = new byte[4];
        using (var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read))
        {
            fs.Read(bom, 0, 4);
        }
        if (bom[0] == 0xEF && bom[1] == 0xBB && bom[2] == 0xBF)
        {
            return Encoding.UTF8;
        }
        else if (bom[0] == 0xFF && bom[1] == 0xFE)
        {
            return Encoding.Unicode; // UTF-16 LE
        }
        else if (bom[0] == 0xFE && bom[1] == 0xFF)
        {
            return Encoding.BigEndianUnicode; // UTF-16 BE
        }
        else
        {
            // BOMなしの場合はShift-JISを仮定
            return Encoding.GetEncoding(932);
        }
    }
}

この方法はBOMが付いているファイルに対しては非常に正確ですが、BOMがないUTF-8やShift-JISの判別はできません。

Udeライブラリでの汎用推定

BOMがないファイルや多様なエンコーディングに対応するためには、バイト列の統計的解析を行う文字コード推定ライブラリを使う方法があります。

C#ではUde(Universal Detector)というライブラリが有名です。

導入手順と精度検証

導入手順

UdeはNuGetパッケージとして提供されているため、Visual Studioのパッケージマネージャーから簡単に導入できます。

コマンドラインからは以下のようにインストールします。

Install-Package Ude

使用例

以下はUdeを使ってファイルの文字コードを推定するサンプルコードです。

using System;
using System.IO;
using Ude;
class Program
{
    static void Main()
    {
        string filePath = "sample.csv";
        using (FileStream fs = File.OpenRead(filePath))
        {
            CharsetDetector detector = new CharsetDetector();
            detector.Feed(fs);
            detector.DataEnd();
            if (detector.Charset != null)
            {
                Console.WriteLine($"推定された文字コード: {detector.Charset}");
                Console.WriteLine($"信頼度: {detector.Confidence * 100:F2}%");
            }
            else
            {
                Console.WriteLine("文字コードの推定に失敗しました。");
            }
        }
    }
}

精度検証

UdeはUTF-8、Shift-JIS、ISO-8859-1、UTF-16など多くのエンコーディングを判別可能です
特にUTF-8とShift-JISの判別に強く、BOMなしのファイルでも高い精度で推定できます
ただし、短いファイルや単純なASCII文字のみのファイルでは判定が難しく、信頼度が低くなることがあります
実運用では、信頼度が一定以上(例：80%以上)であればそのエンコーディングを採用し、低い場合はユーザーに選択を促すなどの対策が望ましいです

Udeを使うことで、BOMなしのCSVファイルでも文字コードを自動判定しやすくなり、文字化けのリスクを大幅に減らせます。

既存CSVの一括変換ツール開発

コマンドラインの設計

CSVファイルの文字コードを一括で変換するツールを作成する際、コマンドラインから操作できる設計にすると自動化やバッチ処理に便利です。

ここでは入力・出力ディレクトリの指定や上書きオプション、バックアップ機能の設計ポイントを解説します。

入力・出力ディレクトリ指定

ツールの基本的な使い方として、変換対象のCSVファイルが格納されている「入力ディレクトリ」と、変換後のファイルを保存する「出力ディレクトリ」を指定できるようにします。

入力ディレクトリ

変換対象のCSVファイルを検索するフォルダパス。

サブフォルダも含めて再帰的に処理することが多いです。

出力ディレクトリ

変換後のCSVファイルを保存するフォルダパス。

入力ディレクトリと同じにすると上書きになるため、別フォルダを指定することが推奨されます。

コマンドライン例：

CsvConvertTool.exe -input "C:\Data\OriginalCSVs" -output "C:\Data\ConvertedCSVs"

プログラム内ではDirectory.GetFilesやDirectory.EnumerateFilesを使い、SearchOption.AllDirectoriesで再帰的にファイルを取得します。

var inputFiles = Directory.EnumerateFiles(inputDir, "*.csv", SearchOption.AllDirectories);

上書きフラグとバックアップ

出力ディレクトリを入力ディレクトリと同じにした場合、既存ファイルを上書きするかどうかのフラグを用意します。

上書きを許可しない場合はエラーにするか、バックアップを作成してから上書きします。

上書きフラグ

-overwriteオプションで上書きを許可するか指定。

バックアップ機能

上書き時に元ファイルを別フォルダや拡張子変更で保存。

例：filename.csv → filename.csv.bak

コマンドライン例：

CsvConvertTool.exe -input "C:\Data\CSVs" -output "C:\Data\CSVs" -overwrite -backup

バックアップはファイルコピーで実装します。

if (backupEnabled)
{
    string backupPath = filePath + ".bak";
    File.Copy(filePath, backupPath, overwrite: true);
}

Parallel.ForEachによる高速化

大量のCSVファイルを一括変換する場合、逐次処理では時間がかかるため、並列処理で高速化を図ります。

Parallel.ForEachを使うと簡単に複数ファイルを同時処理できます。

ファイル数増大への対応

Parallel.ForEachはスレッドプールを利用して効率的に並列処理を行いますが、ファイル数が非常に多い場合はメモリ消費やI/O負荷に注意が必要です。

最大並列度の制御

ParallelOptions.MaxDegreeOfParallelismで同時実行スレッド数を制限し、過負荷を防止。

var options = new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount };
Parallel.ForEach(inputFiles, options, file =>
{
    // 変換処理
});

例外処理

並列処理中に例外が発生しても他のファイル処理を継続できるように、try-catchを各スレッド内に設けます。

進捗バー表示

ユーザーに処理状況を分かりやすく伝えるため、コンソールアプリケーションで進捗バーを表示することが有効です。

並列処理中でもスレッドセーフに進捗を更新する工夫が必要です。

スレッドセーフなカウンター

Interlocked.Incrementを使い、処理済みファイル数を安全にカウント。

進捗表示の更新

処理ごとに進捗を計算し、コンソールの同じ行に表示を更新。

using System.Threading;
int totalFiles = inputFiles.Count();
int processedCount = 0;
Parallel.ForEach(inputFiles, options, file =>
{
    try
    {
        // 変換処理
    }
    catch (Exception ex)
    {
        // エラーログなど
    }
    finally
    {
        int done = Interlocked.Increment(ref processedCount);
        Console.Write($"\r処理中: {done}/{totalFiles} ファイル");
    }
});
Console.WriteLine("\n変換処理が完了しました。");

このように設計することで、大量のCSVファイルを効率よく安全に一括変換でき、ユーザーに進捗をリアルタイムで伝えられます。

Excelと高い互換性を保つ設定

CRLF改行での保存

Windows環境で作成されたCSVファイルは、改行コードとしてCRLF(キャリッジリターン＋ラインフィード、\r\n)を使うのが標準です。

ExcelはCRLFを改行コードとして認識するため、これを守ることでファイルの互換性が高まります。

Environment.NewLine強制

C#のEnvironment.NewLineは実行環境に応じた改行コードを返します。

Windowsでは\r\n、Unix系では\nです。

CSVをWindowsのExcelで開くことを想定する場合、改行コードをEnvironment.NewLineで統一すると安全です。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "excel_compatible.csv";
        var lines = new[]
        {
            "ヘッダー1,ヘッダー2,ヘッダー3",
            "データ1,データ2,データ3"
        };
        using (var writer = new StreamWriter(filePath, false, Encoding.GetEncoding("Shift_JIS")))
        {
            foreach (var line in lines)
            {
                writer.Write(line);
                writer.Write(Environment.NewLine); // CRLFを環境に合わせて出力
            }
        }
        Console.WriteLine("CRLF改行でCSVを保存しました。");
    }
}

CRLF改行でCSVを保存しました。

このようにEnvironment.NewLineを使うことで、Windows環境でのExcel互換性を確保しつつ、他環境でも適切な改行コードが使われます。

先頭ゼロ付き数値の保持

ExcelはCSVを開く際、数値として認識できる文字列は自動的に数値型に変換します。

そのため、郵便番号や電話番号など「先頭にゼロが付く数値」は、ゼロが消えてしまう問題が発生します。

シングルクォート挿入

先頭ゼロを保持するための簡単な方法は、該当セルの値の先頭にシングルクォート'を挿入することです。

Excelはシングルクォートを文字列のマークとして扱い、表示時にはシングルクォートを除いて先頭ゼロを保持します。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "leading_zero.csv";
        using (var writer = new StreamWriter(filePath, false, Encoding.GetEncoding("Shift_JIS")))
        {
            writer.WriteLine("郵便番号,電話番号");
            writer.WriteLine("'01234','09012345678'"); // シングルクォートで囲む
        }
        Console.WriteLine("先頭ゼロ付き数値をシングルクォートで保存しました。");
    }
}

先頭ゼロ付き数値をシングルクォートで保存しました。

この方法は簡単で効果的ですが、CSVの仕様上はシングルクォートは文字列の一部として扱われるため、他のツールで読み込む際は注意が必要です。

数式・改行入りセルのエスケープ方法

CSVのセル内に数式や改行が含まれる場合、Excelで正しく認識させるためには適切なエスケープが必要です。

数式

セルの値が=で始まるとExcelは数式として扱います。

数式として扱いたくない場合は、先頭にシングルクォートを付けるか、ダブルクォートで囲みます。

改行入りセル

セル内に改行\nや\r\nが含まれる場合、セル全体をダブルクォートで囲みます。

さらに、ダブルクォート自体がセル内にある場合は、ダブルクォートを2つ連続で書く必要があります。

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "escaped_cells.csv";
        using (var writer = new StreamWriter(filePath, false, Encoding.GetEncoding("Shift_JIS")))
        {
            // 数式を文字列として扱うためにシングルクォートを付加
            writer.WriteLine("\"名前\",\"計算式\",\"備考\"");
            writer.WriteLine("\"山田太郎\",\"'=SUM(A1:A10)'\",\"改行入り\nセル\"");
            // 改行入りセルはダブルクォートで囲み、改行はそのまま記述
        }
        Console.WriteLine("数式・改行入りセルをエスケープして保存しました。");
    }
}

数式・改行入りセルをエスケープして保存しました。

この例では、

数式セルは'=SUM(A1:A10)'のようにシングルクォートで囲み、Excelが数式として評価しないようにしています
改行入りセルはダブルクォートで囲み、改行コードをそのまま含めています

Excelはこの形式を正しく解釈し、セル内の改行や数式を文字列として表示します。

CSVの仕様に準拠したエスケープを行うことで、Excelとの互換性を高められます。

テストと品質保証

NUnitによるユニットテスト

C#でCSVの文字コード変換や読み書きを行う処理を開発する際、ユニットテストを導入して品質を保証することが重要です。

特に文字コードの変換結果が正しいかどうかは、バイト列レベルでの厳密な比較が求められます。

NUnitは.NET環境で広く使われているテストフレームワークで、簡単にテストコードを作成できます。

期待バイト列との厳密比較

文字コード変換のテストでは、変換後のファイルやデータのバイト列が期待通りであるかをチェックします。

文字列の比較だけではなく、エンコーディングやBOMの有無、改行コードまで含めて厳密に検証することがポイントです。

以下はNUnitを使ったサンプルテストコードです。

UTF-8 BOM付きでCSVを書き出す処理の結果を、期待されるバイト列と比較しています。

using System;
using System.IO;
using System.Text;
using NUnit.Framework;
[TestFixture]
public class CsvEncodingTests
{
    private readonly string testFilePath = "test_utf8_bom.csv";
    [SetUp]
    public void Setup()
    {
        if (File.Exists(testFilePath))
            File.Delete(testFilePath);
    }
    [Test]
    public void WriteUtf8BomCsv_CreatesExpectedByteSequence()
    {
        string csvContent = "ヘッダー1,ヘッダー2\nデータ1,データ2";
        byte[] expectedBom = new UTF8Encoding(true).GetPreamble();
        byte[] expectedContent = Encoding.UTF8.GetBytes(csvContent);
        // ファイル書き込み処理(テスト対象)
        using (var writer = new StreamWriter(testFilePath, false, new UTF8Encoding(true)))
        {
            writer.Write(csvContent);
        }
        // 実際のファイルバイトを取得
        byte[] actualBytes = File.ReadAllBytes(testFilePath);
        // 期待バイト列を結合
        byte[] expectedBytes = new byte[expectedBom.Length + expectedContent.Length];
        Buffer.BlockCopy(expectedBom, 0, expectedBytes, 0, expectedBom.Length);
        Buffer.BlockCopy(expectedContent, 0, expectedBytes, expectedBom.Length, expectedContent.Length);
        // バイト列の長さを比較
        Assert.AreEqual(expectedBytes.Length, actualBytes.Length, "ファイルサイズが一致しません。");
        // バイト列の内容を1バイトずつ比較
        for (int i = 0; i < expectedBytes.Length; i++)
        {
            Assert.AreEqual(expectedBytes[i], actualBytes[i], $"バイト位置{i}が一致しません。");
        }
    }
}

このテストでは、

UTF-8のBOM付きエンコーディングでCSVを書き出す処理を実行
期待されるBOMとCSV文字列のバイト列を結合して期待値を作成
実際に書き出されたファイルのバイト列と比較
バイト単位で一致しなければテスト失敗

このようにバイト列の厳密比較を行うことで、文字コードやBOMの付加漏れ、改行コードの違いなどを検出できます。

大容量ファイルのメモリ消費検証

CSVファイルが大容量になると、読み込みや書き込み時のメモリ消費が問題になります。

メモリ不足による例外やパフォーマンス低下を防ぐため、バッファサイズやストリーム操作の最適化が必要です。

バッファサイズとストリーム操作

StreamReaderやStreamWriterは内部でバッファを使って効率的にファイルを読み書きします。

バッファサイズを適切に設定することで、メモリ使用量とI/O性能のバランスを調整できます。

バッファサイズの指定

コンストラクタでバッファサイズを指定可能です。

デフォルトは4KB程度ですが、大容量ファイルでは64KBや128KBに増やすとI/O回数が減り高速化します。

逐次処理の推奨

ファイル全体を一度に読み込むのではなく、1行ずつ処理することでメモリ消費を抑えられます。

例：大容量ファイル読み込み時のバッファ指定

using System;
using System.IO;
using System.Text;
class Program
{
    static void Main()
    {
        string filePath = "large.csv";
        // 64KBのバッファサイズを指定
        int bufferSize = 64 * 1024;
        using (var reader = new StreamReader(filePath, Encoding.UTF8, detectEncodingFromByteOrderMarks: true, bufferSize: bufferSize))
        {
            string line;
            while ((line = reader.ReadLine()) != null)
            {
                // 行単位で処理
                ProcessLine(line);
            }
        }
    }
    static void ProcessLine(string line)
    {
        // 処理内容(例：パースや変換)
    }
}

メモリ消費の検証

実際に大容量ファイルを読み込むテストを行い、メモリ使用量をモニタリングします。

必要に応じてバッファサイズを調整し、GC発生頻度やピークメモリを抑制します。

書き込み時も同様にバッファサイズを指定可能

using (var writer = new StreamWriter("output.csv", false, Encoding.UTF8, bufferSize))
{
    // 書き込み処理
}

このようにバッファサイズを適切に設定し、逐次処理を徹底することで、大容量CSVファイルの読み書きでも安定したメモリ使用とパフォーマンスを実現できます。

よくあるエラーとトラブルシューティング

ArgumentException:無効なコードページ

C#でCSVファイルの文字コードを指定して読み書きする際、Encoding.GetEncodingメソッドに無効なコードページ番号や名前を渡すとArgumentExceptionが発生します。

例えば、存在しないコードページ番号やサポートされていないエンコーディング名を指定した場合です。

原因例

コードページ番号が間違っている(例：Encoding.GetEncoding(99999))
エンコーディング名のスペルミス(例：Encoding.GetEncoding("Shift-JIS")ではなく"Shift_JIS")
実行環境に該当コードページがインストールされていない

対処法

正しいコードページ番号や名前を使います。日本語Windows環境でShift-JISは932、名前は"Shift_JIS"が正しい
.NET Coreや.NET 5以降では一部のコードページがデフォルトでサポートされていないため、System.Text.Encoding.CodePagesパッケージをインストールし、Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)を呼び出してコードページを有効化する必要があります

using System.Text;
using System.Text.Encoding.CodePages;
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
var shiftJis = Encoding.GetEncoding("Shift_JIS");

例外発生時は例外メッセージを確認し、指定したエンコーディングが正しいか検証してください

OutOfMemoryException:巨大ファイル

非常に大きなCSVファイルを一度にメモリに読み込もうとすると、OutOfMemoryExceptionが発生することがあります。

特にFile.ReadAllTextやFile.ReadAllBytesでファイル全体を読み込む場合に起こりやすいです。

原因

ファイルサイズが利用可能なメモリを超えている
64bit環境でもメモリ断片化や他プロセスの影響で十分な連続メモリが確保できない

対処法

ファイル全体を一度に読み込むのではなく、StreamReaderで1行ずつ逐次読み込み処理を行います
バッファサイズを適切に設定し、メモリ消費を抑えます
必要に応じてファイルを分割して処理します
64bitプロセスで実行し、利用可能なメモリを増やす

using (var reader = new StreamReader("large.csv", Encoding.UTF8))
{
    string line;
    while ((line = reader.ReadLine()) != null)
    {
        // 1行ずつ処理
    }
}

混在改行コードによる読み込み失敗

CSVファイル内で改行コードが混在していると、StreamReaderやCSVパーサーが正しく行を認識できず、読み込みエラーやデータの破損が発生することがあります。

例えば、WindowsのCRLF\r\nとUnixのLF\nが混ざっているケースです。

問題点

行の区切りが不明瞭になり、1行が複数行に分割されたり、逆に複数行が1行として扱われます
CSVのフィールド内に改行が含まれている場合、適切にダブルクォートで囲まれていないと誤認識されます

対処法

CSVファイル作成時に改行コードを統一します。Windows環境ならCRLFに統一するのが望ましい
既存ファイルの改行コードを正規化するツールやスクリプトを使います
CSVパーサーの設定で改行コードの扱いを調整できる場合は適切に設定します
フィールド内改行は必ずダブルクォートで囲み、ダブルクォートはエスケープします

改行コードの正規化例(C#)

string content = File.ReadAllText("mixed_newline.csv");
content = content.Replace("\r\n", "\n").Replace("\r", "\n").Replace("\n", "\r\n");
File.WriteAllText("normalized.csv", content, Encoding.UTF8);

この例では、まずすべての改行コードをLFに統一し、その後CRLFに変換しています。

これにより混在した改行コードを統一できます。

これらのトラブルはCSVの文字コード変換や読み書きでよく遭遇するため、原因を理解し適切に対処することが重要です。

セキュリティと運用上の注意

エンコード指定漏れが引き起こすXSS

CSVファイルをWebアプリケーションなどで生成・配布する際に、文字コードのエンコード指定を適切に行わないと、クロスサイトスクリプティング(XSS)攻撃のリスクが高まります。

特にCSVファイルをブラウザで直接開いたり、Excelなどのアプリケーションで読み込む際に、悪意のあるスクリプトが実行される可能性があります。

具体的な問題点

CSVファイル内に=cmd|'/C calc'!A0や=HYPERLINK("javascript:alert(1)")のような数式やスクリプトが含まれていると、Excelがこれを数式として解釈し、意図しないコードが実行されることがあります
文字コードが不適切であると、悪意のあるコードが正しくエスケープされずに実行されるリスクが増加します
WebサーバーがContent-Typeやcharsetを正しく指定しないと、ブラウザが誤った文字コードでファイルを解釈し、XSS攻撃の入口になることがあります

CSVファイルの生成時に、文字コードを明示的に指定し、BOM付きUTF-8など安全なエンコーディングを使用します
CSV内のセルに数式やスクリプトが含まれる可能性がある場合は、先頭にシングルクォート'を付けて文字列として扱うようにします
WebサーバーのHTTPレスポンスヘッダーでContent-Typeにtext/csv; charset=UTF-8など正しい文字コードを指定し、ブラウザの誤解釈を防ぐ
ユーザーからの入力をCSVに出力する場合は、必ずサニタイズやエスケープ処理を行い、悪意のあるコードが混入しないようにします

これらの対策を講じることで、CSVファイルを介したXSS攻撃のリスクを大幅に低減できます。

ファイル名文字化けとZIP圧縮の相性

CSVファイルを複数まとめて配布する際にZIP圧縮を利用することが多いですが、ZIPファイル内のファイル名の文字コードが適切に扱われないと、ファイル名が文字化けする問題が発生します。

特に日本語ファイル名でこの問題が顕著です。

問題の原因

ZIPフォーマット自体はファイル名の文字コードを明示的に規定していません。多くのZIPツールはShift-JISやCP437など異なるエンコーディングを使うため、解凍時に文字化けが起きやすい
Windowsの標準ZIP機能はShift-JISを前提にしていることが多く、UTF-8でファイル名を保存したZIPを解凍すると文字化けする場合があります
一方、MacやLinuxのZIPツールはUTF-8を使うことが多く、環境間での互換性が問題になります

ZIP圧縮時にファイル名のエンコーディングを明示的にUTF-8に設定できるツールやライブラリを使います
.NETでZIPを作成する場合は、System.IO.Compression.ZipArchiveを使い、EntryNameEncodingプロパティにEncoding.UTF8を指定することでUTF-8でファイル名を保存できます

using System.IO;
using System.IO.Compression;
using System.Text;
string zipPath = "archive.zip";
string fileToAdd = "日本語ファイル名.csv";
using (var zip = ZipFile.Open(zipPath, ZipArchiveMode.Create))
{
    var entry = zip.CreateEntry(fileToAdd, CompressionLevel.Fastest);
    // EntryNameEncodingを指定してUTF-8でファイル名を保存
    zip.EntryNameEncoding = Encoding.UTF8;
    using (var entryStream = entry.Open())
    using (var fileStream = File.OpenRead(fileToAdd))
    {
        fileStream.CopyTo(entryStream);
    }
}

配布先の環境に合わせてZIPツールの仕様を確認し、必要に応じてファイル名のエンコードを調整します
可能であればファイル名に英数字のみを使うか、ファイル名のエンコードに関する注意書きを添付します

これらの対応により、ZIP圧縮時のファイル名文字化けを防ぎ、ユーザーがスムーズにファイルを利用できるようになります。

使用API・ライブラリ索引

System.IOとSystem.Textの主要クラス

C#でCSVファイルの文字コード変換や読み書きを行う際に頻繁に利用する、System.IOとSystem.Text名前空間の主要クラスを紹介します。

クラス名	説明	主な用途
`File`	ファイルの読み書きや操作を簡単に行う静的メソッドを提供。	ファイルの読み書き、バイト列の入出力
`FileStream`	ファイルへのストリームアクセスを提供。バイト単位での読み書きが可能です。	大容量ファイルの逐次読み書き、バッファ制御
`StreamReader`	テキストファイルを読み込むためのクラス。エンコーディング指定が可能です。	CSVファイルの行単位読み込み
`StreamWriter`	テキストファイルへの書き込みを行うクラス。エンコーディング指定が可能です。	CSVファイルの書き込み
`Encoding`	文字エンコーディングを表す抽象クラス。UTF-8、Shift-JISなどのエンコーディングを取得可能です。	文字列とバイト列の変換、エンコーディング指定
`UTF8Encoding`	UTF-8エンコーディングの実装。BOMの有無を指定可能です。	UTF-8での読み書き、BOM付きファイル作成
`Encoding.GetEncoding`	指定したコードページや名前のエンコーディングを取得。	Shift-JISなどの特定エンコーディング取得
`Buffer`	バイト配列のコピーや操作を効率的に行う静的メソッドを提供。	バイト配列の結合や部分コピー

これらのクラスを組み合わせて、CSVファイルの読み込み時に正しいエンコーディングを指定したり、書き込み時にBOMを付加したりすることができます。

例えば、StreamReaderやStreamWriterのコンストラクタでEncodingを指定することで、文字化けを防止できます。

NuGetで入手できる便利パッケージ

C#でCSVの文字コード変換やパースを効率的に行うために、NuGetで配布されている便利なパッケージがいくつかあります。

代表的なものを紹介します。

パッケージ名	機能概要	特徴・用途
CsvHelper	高機能なCSVパーサー・ライター。マッピングや型変換が簡単。	複雑なCSVの読み書き、カスタムマッピング対応
Ude	文字コード自動判定ライブラリ(Universal DetectorのC#移植版)	BOMなしファイルの文字コード推定に有効
System.Text.Encoding.CodePages	.NET Core/.NET 5+でコードページエンコーディングをサポート	Shift-JISなどのコードページを利用可能にする
SharpZipLib	ZIPやGZipなど圧縮ファイルの操作ライブラリ。	ZIP圧縮・解凍時のファイル名エンコーディング制御に利用可能

導入例(CsvHelper)

Visual Studioのパッケージマネージャーコンソールで以下を実行します。

Install-Package CsvHelper

導入例(Ude)

Install-Package Ude

これらのパッケージを活用することで、文字コードの自動判定や複雑なCSVの読み書き処理を簡潔に実装でき、開発効率と品質を向上させられます。

まとめ

この記事では、C#でCSVファイルの文字コード変換を行う際の基本知識から具体的な実装方法、文字化けの原因や対策、効率的な一括変換ツールの設計、Excelとの互換性を保つポイントまで幅広く解説しました。

文字コードの自動判定やBOMの扱い、エンコーディング指定の重要性を理解し、適切なAPIやライブラリを活用することで、文字化けを防ぎつつ高品質なCSV処理が実現できます。

参考文献

2025-04-30更新日: 2025-04-30

CSVと文字エンコーディングの基礎

CSVファイルの構造

フィールド区切りと改行コードの扱い

ダブルクォートのエスケープルール

主要エンコーディングの特徴

UTF-8

BOM付きとBOMなしの差異

Shift-JIS

Windows環境との互換性

UTF-16

Endianの概念とBOM

文字化けが起きる主な原因

Excelで開く際の自動判定ミス

UTF-8誤認識パターン

Shift-JIS誤認識パターン

Webダウンロード時のContent-Type不足

ブラウザ自動判定の限界

HTTPヘッダー設定例

C#でCSVを読み込む方法

StreamReaderでの基本実装

Encoding未指定のリスク

改行コードの自動検出

CsvHelperライブラリ活用

ConfigurationでのEncoding指定

カスタムマッピングと型変換

C#でCSVを書き出す方法

StreamWriterでのエンコーディング指定

UTF8Encoding(true)でBOM付き生成

Encoding.GetEncoding(932)でShift-JIS出力

File.WriteAllBytesで直接バイト列を書き込む

先頭にBOMを付与する手順

追記時のエンコード整合性

文字コード自動判定ロジック

BOM検出アルゴリズム

UTF-8・UTF-16LE・UTF-16BE判定

Udeライブラリでの汎用推定

導入手順と精度検証

既存CSVの一括変換ツール開発

コマンドラインの設計

入力・出力ディレクトリ指定

上書きフラグとバックアップ

Parallel.ForEachによる高速化

ファイル数増大への対応

進捗バー表示

Excelと高い互換性を保つ設定

CRLF改行での保存

Environment.NewLine強制

先頭ゼロ付き数値の保持

シングルクォート挿入

数式・改行入りセルのエスケープ方法

テストと品質保証

NUnitによるユニットテスト

期待バイト列との厳密比較

大容量ファイルのメモリ消費検証

バッファサイズとストリーム操作

よくあるエラーとトラブルシューティング

ArgumentException:無効なコードページ

OutOfMemoryException:巨大ファイル

混在改行コードによる読み込み失敗

セキュリティと運用上の注意

エンコード指定漏れが引き起こすXSS

ファイル名文字化けとZIP圧縮の相性

使用API・ライブラリ索引

System.IOとSystem.Textの主要クラス

NuGetで入手できる便利パッケージ

まとめ

関連記事