VB.NETにおけるChar型とString型、そして「文字化け」の呪縛を断ち切る極限の文字列設計
業務自動化ツールやレガシーシステム連携の開発現場において、もっとも頻発し、かつ開発者を絶望させるバグの筆頭が「文字化け」と「型不一致エラー」だ。
「VB.NETでテキストファイルを読み込んだら謎の『?』だらけになった」
「CSVのエクスポートで特定の漢字だけが化ける」
「`Char` と `String` の違いをなんとなくでコードを書いているせいで、無駄なメモリ消費とキャストが発生している」
もし君がこのようなトラブルに直面したことがあるなら、それは言語の仕様や文字コード（UnicodeとShift_JISなど）の境界線を正しく理解していないことが原因だ。
今回は、VB.NETにおける `Char` 型と `String` 型の厳密な違いから、外部システムと連携する際に絶対に文字化けを起こさない `System.Text.Encoding` の極意まで、プロダクションコードレベルの知見を交えて徹底的に解説する。
—
1. 境界線の見極め：`Char` 型と `String` 型の本質
まずは、この2つの型がメモリ上でどう振る舞うのかを正しく定義しよう。ここを曖昧にしているプログラマは、大規模なテキスト処理で必ずパフォーマンスを溺死させる。
シングルクォート（`’`) と ダブルクォート（`”`) の決定的な違い
VB.NETにおいて、リテラスの囲い方は型を決定する絶対的な契機だ。
- `Char` 型（シングルクォート）： 例：`C = “A”c` または `Option Strict On` 下での `’A’`
- UTF-16のコードポイントを保持する1文字（2バイト）の構造体（`System.Char`）。
- 文字列ではなく、あくまで「文字」という数値の塊である。
- String 型（ダブルクォート）： 例：`S = “A”`
- 不変（Immutable）な文字列オブジェクト（`System.String`）。
- 内部の実体は `Char` 型の配列であり、終端文字を持たない参照型である。
なぜ「なんとなく」の使い分けが危険なのか？
業務システムでは、しばしば「1文字だけ判定したい」という要件（例：区切り文字のチェック、先頭文字の判定）に出会う。ここで `String` 型同士で比較したり、無駄に `CChar()` や `.ToString()` を乱発すると、不要なヒープ領域のオブジェクト生成（ガベージコレクションの負荷増大）を招く。
極限まで最適化されたコードを書くためには、文字単位の処理には徹底して `Char` 型（あるいはスライス）を使い、文字列のコンテナとしてのみ `String` 型を使う意識を持つべきだ。
—
2. 外部連携の罠：UnicodeとShift_JIS（CP932）の深淵
VB.NET（.NET Framework / .NET Core）の内部世界は、すべて UTF-16（Unicode） で構築されている。
しかし、日本のレガシーな業務システム、基幹系データベース、あるいは古いCSV出力機が要求するのは、いまだに Shift_JIS（正確にはMicrosoft拡張のCP932） であることが多い。
この「内部（UTF-16）」と「外部（Shift_JIS等）」の境界線をハンドリングミスすることが、文字化けのすべての元凶なのだ。
ありがちなアンチパターン
.net
‘ 【悪手】文字コードを意識せず、デフォルトのままでファイルを読み書きする
Dim lines As String() = File.ReadAllLines(“legacy_data.csv”)
このコードは、ファイルがUTF-8で保存されていれば動く。しかし、現場のレガシーシステムが吐き出したShift_JISのファイルだった場合、`ReadAllLines` が環境依存のデフォルトエンコーディング（日本語Windowsなら通常Shift_JISだが、Linux環境やコンテナ上の.NET CoreではUTF-8とみなされる）に依存するため、実行環境によって文字化けする爆弾と化す。
—
3. 【実践】文字化けを完全封殺する `System.Text.Encoding` 活用術
外部ファイルやAPIとのI/Oでは、「どの文字コードでエンコード/デコードされているか」をコード上で明示的に指定するのがプロの鉄則だ。
特に、日本のWindows環境でShift_JISを扱う場合は、JISX0208にMicrosoft独自の拡張文字（㈱や機種依存文字など）を含んだ `Encoding.GetEncoding(“shift_JIS”)` または `Encoding.GetEncoding(932)` を明示的に指定しなければならない。
プロダクション品質の安全なファイル入出力クラス
以下のコードは、文字化けを完全に防ぎ、例外処理とリソース管理を完璧にこなす実用的なモジュールだ。そのままプロジェクトに組み込んで使える。
.net
Imports System.IO
Imports System.Text
Public NotInheritable Class SecureTextIO
‘ 業界標準：Microsoft拡張を含むShift_JIS（CP932）のエンコーディングを取得
Private Shared ReadOnly ShiftJisEncoding As Encoding = Encoding.GetEncoding(932)
”’
”’
”’ ファイルパス
”’
Public Shared Function ReadShiftJisText(filePath As String) As String()
If Not File.Exists(filePath) Then
Throw New FileNotFoundException($”指定されたファイルが見つかりません: {filePath}”)
End If
‘ Encodingを明示することで、実行環境の差異による文字化けを完全にシャットアウトする
Using reader As New StreamReader(filePath, ShiftJisEncoding)
Dim contentList As New List(Of String)()
While Not reader.EndOfStream
contentList.Add(reader.ReadLine())
End While
Return contentList.ToArray()
End Using
End Function
”’
”’
”’ 出力先ファイルパス
”’ 書き出す文字列のコレクション
Public Shared Sub WriteShiftJisText(filePath As String, lines As IEnumerable(Of String))
‘ 既存ファイルを上書き、Shift_JIS（BOMなし）で書き出し
Using writer As New StreamWriter(filePath, False, ShiftJisEncoding)
For Each line As String In lines
writer.WriteLine(line)
Next
End Using
End Sub
End Class
—
4. データベース連携と文字コードの罠
テキストファイルだけでなく、データベース（SQL Server, Oracle, Access等）との接続においても、文字コードの境界線意識は不可欠だ。
1. VB.NET側（String型）は常にUTF-16である。
2. DB側（`NVARCHAR` vs `VARCHAR`）の型定義が勝負の分かれ目。
- `VARCHAR`（可変長非Unicode文字列）に日本語を格納しようとすると、DB側のコードページに依存してしまい、保存時に文字化けやデータ損失（`?`への置き換え）が発生する。
- 対策： SQL ServerなどのRDBに接続する際は、必ず `NVARCHAR` や `NCHAR` を使用し、VB.NET側からもパラメータの型として `DbType.String`（内部的にはUnicode）を明示すること。ADO.NETのコマンドオブジェクトを使用する際は、暗黙の型変換に頼らないのが鉄則である。
—
5. チーフアーキテクトからの提言
文字列処理と文字コードの不一致は、「運が良ければ動く」という性質を持つため、テスト環境をすり抜けて本番環境で突然牙をむく。
- リテラルを扱うときは `Char` と `String` のメモリコストを意識せよ。
- ファイルや外部ストリームを扱うときは、絶対にデフォルトの `Encoding` に頼るな。 `Encoding.GetEncoding(932)` または `Encoding.UTF8` を必ずコードで明示せよ。
- 境界線（Internal: UTF-16 ⇔ External: Shift_JIS/UTF-8）を意識した設計を行え。
この原則をチーム全体で徹底すれば、文字化けに怯える無駄なデバッグ時間はゼロになる。堅牢で美しいコードベースを構築し、真の業務自動化を成し遂げてほしい。
