VB.NETのChar/String型に潜む深淵：文字コードの罠を乗り越える文字列比較の極意とレガシー連携の鉄則
長きにわたり、VBAシステムやレガシーアーキテクチャの最前線でコードと格闘してきた者として、私は数え切れないほどの「動かない」「文字化けする」「なぜか比較がうまくいかない」という報告を受けてきた。その多くは、表面的な知識では見過ごされがちな、Char型とString型にまつわる深い理解の欠如、そして文字コードという名の深淵が引き起こす問題だった。
本稿では、VB.NETにおけるChar型とString型の表層と深層を掘り下げ、特に初心者が見落としがちな暗黙の型変換の罠、そして文字コード差異が引き起こす予期せぬバグの回避策を、私の経験に基づいた「鉄則」として提示する。Windows APIの呼び出し、メモリ最適化、そしてレガシー環境との連携といった、業務システムの安定稼働に不可欠な極限の知見を、諸君に授けよう。
1. Char型とString型の表層と深層：見かけと実体の乖離
VB.NETにおいて、単一の文字を扱う`Char`型と、文字列を扱う`String`型は、一見すると直感的で分かりやすい。しかし、その背後には.NET Frameworkが提供するUnicodeの世界と、OSや外部システムが持つ多様な文字コードの概念が複雑に絡み合っている。
1.1. Char型とString型の根本的な違い
- Char型 (`System.Char`):
- 単一のUnicode文字を表す値型（Structure）である。
- 内部的には16ビット（2バイト）の符号なし整数（`System.UInt16`）として、UTF-16コードユニットを保持する。
- リテラルはシングルクォーテーションで囲み、末尾に`c`を付加する（例: `’A’c`）。
- サロゲートペア（補助文字）のような、16ビットで表現できない文字の場合、Char型一つではその文字全体を表現できない。これは後述のString型で初めて完全な文字として扱われる。
- String型 (`System.String`):
- 0個以上のCharオブジェクトのシーケンス、つまり文字列を表す参照型（Class）である。
- .NETのStringは、内部的にUTF-16エンコーディングで文字データを保持する。
- 不変（immutable）である。一度生成されたStringオブジェクトの内容は変更できない。文字列操作（結合、置換など）を行うたびに、新しいStringオブジェクトが生成される。
- リテラルはダブルクォーテーションで囲む（例: `”Hello”`）。
この根本的な違い、特に「値型か参照型か」「不変か可変か」は、パフォーマンス、メモリ管理、そして暗黙の型変換の挙動に決定的な影響を与える。
1.2. .NET内部のUnicodeとUTF-16の現実
.NET Frameworkおよび.NET Core/.NET 5+は、String型をUTF-16エンコーディングで統一的に扱っている。これは、多言語対応の基盤であり、開発者が意識することなく様々な言語の文字を扱えるように設計されている。
しかし、「UTF-16で統一されているから安心」と油断してはならない。システムが外部（ファイル、データベース、ネットワーク通信、Windows APIなど）と連携する際には、必ず「文字コード変換」の壁に直面する。外部データがUTF-8、Shift-JIS、EUC-JPなどの異なるエンコーディングで存在する場合、適切な変換処理を行わなければ、あっという間に文字化けという名のバグが蔓延する。
2. 暗黙の型変換の甘美な罠：コンパイラの親切心と開発者の油断
VB.NETコンパイラは、開発者の便宜を図るため、ある程度の暗黙の型変換を許可する。特に`Option Strict Off`が指定されている場合、その自由度は著しく高まり、潜在的な問題を隠蔽してしまう。
2.1. CharとString間の「優しい」変換、そしてその裏側
- CharからStringへの変換:
`Dim myChar As Char = “A”c`
`Dim myString As String = myChar` ‘ 暗黙的に myChar.ToString() が呼ばれる
これは安全な変換であり、問題は少ない。`Char`型は単一の文字を表すため、`String`型に変換されても意味が変わることはない。
- StringからCharへの変換:
`Dim myString As String = “B”`
`Dim myChar As Char = myString(0)` ‘ StringのインデクサでCharを取得。明示的。
`Dim myAnotherChar As Char = “B”c` ‘ これはCharリテラルなのでOK
罠: `Option Strict Off`の環境下で、次のようなコードを記述してしまうと、一見動くように見えて、実は危険な状況を生む。
`Dim myChar As Char = “B”` ‘ Option Strict Off ならコンパイル可能！
この場合、`myChar`には文字列`”B”`の最初の文字である`’B’c`が代入される。もし文字列が空だったり、複数文字であったりした場合、予期せぬ結果（実行時エラーや意図しない文字の代入）となる。
鉄則1: `Option Strict On`を常に使用する。
プロジェクトのプロパティで`Option Strict`を`On`に設定することは、VB.NET開発における最も基本的な安全対策である。これにより、このような暗黙的で危険な型変換はコンパイルエラーとなり、早期に問題を検出できる。
2.2. 文字コード差異が引き起こす文字化けと誤判定
問題の核心は、異なるエンコーディングで生成された文字列データが、適切な変換なしに.NETの`String`型に渡されたときに発生する。
具体的なシナリオ:
1. あるファイルがShift-JISエンコーディングで保存されている。
2. このファイルを`File.ReadAllText()`などで読み込む際、エンコーディングを指定しなかった（または誤ったエンコーディングを指定した）。
3. 結果として、.NET内部の`String`型には、本来のShift-JISバイト列がUTF-16として「誤解釈」された文字データが格納される。
4. この「誤解釈された」文字列と、別の正しい文字列（例: コード中に記述されたリテラル文字列）を比較すると、見た目は同じでも内部のコード値が異なるため、`=`演算子や`String.Equals()`が`False`を返す。これが「文字化けによる比較失敗」の典型だ。
例: Shift-JISで「表」という文字（`&H95` `&X5C`）が、UTF-8やDefaultエンコーディングで読み込まれると、全く異なる文字や疑問符として表現されることがある。
3. 文字化けを回避し、正確な文字列比較を行うための鉄則
システム連携やレガシー環境の保守において、文字コードの問題は避けられない。この深淵を乗り越えるための具体的な「鉄則」を提示する。
3.1. 意識的なエンコーディング管理：I/Oの基本
ファイル、ネットワーク、データベース、そしてWindows APIからのデータ取得時には、必ずエンコーディングを明示的に指定せよ。
.net
Imports System.IO
Imports System.Text
Module EncodingExample
Sub Main()
Dim filePath As String = “C:\temp\sample_sjis.txt”
Dim content As String = “これはShift-JISで保存されたテスト文字列です。𠮟” ‘ 補助文字も含む
‘ 1. Shift-JISでファイルを書き込む
Try
‘ Shift-JISエンコーディングを明示的に指定して書き込み
File.WriteAllText(filePath, content, Encoding.GetEncoding(“Shift_JIS”))
Console.WriteLine($”‘{filePath}’ にShift-JISで書き込みました。”)
Catch ex As Exception
Console.WriteLine($”書き込みエラー: {ex.Message}”)
End Try
‘ 2. 誤ったエンコーディングでファイルを読み込む (Defaultエンコーディング)
Console.WriteLine(Environment.NewLine & “— 誤ったエンコーディングでの読み込み —“)
Try
‘ エンコーディングを指定しないと、システムのデフォルトエンコーディングで読み込まれる
‘ 日本語Windows環境では通常Shift-JISだが、異なる場合やUTF-8ファイルでは問題が起きる
Dim readContentDefault As String = File.ReadAllText(filePath)
Console.WriteLine($”デフォルトエンコーディングでの読み込み: {readContentDefault}”)
‘ 補助文字 ‘𠮟’ (U+20B9F) はShift-JISでは表現できないため、ここでは文字化けしているはず
‘ または、Shift-JISエンコーディングの挙動により、そもそも書き込み時に別の文字に変換されている可能性も
If readContentDefault.Contains(“テスト文字列”) Then
Console.WriteLine(“部分一致はするが、補助文字は化けている可能性が高い。”)
End If
Console.WriteLine($”Length: {readContentDefault.Length}”) ‘ UTF-16コードユニット数
Catch ex As Exception
Console.WriteLine($”読み込みエラー (デフォルト): {ex.Message}”)
End Try
‘ 3. 正しいエンコーディングでファイルを読み込む (Shift-JIS)
Console.WriteLine(Environment.NewLine & “— 正しいエンコーディングでの読み込み —“)
Try
‘ Shift-JISエンコーディングを明示的に指定して読み込み
Dim readContentSjis As String = File.ReadAllText(filePath, Encoding.GetEncoding(“Shift_JIS”))
Console.WriteLine($”Shift-JISエンコーディングでの読み込み: {readContentSjis}”)
‘ ここでも補助文字は化ける、あるいは別の文字になっている可能性が高い
‘ なぜなら、Shift-JISには補助文字を表現する術がないため、
‘ 書き込み時に既に変換されているか、読み込み時に代替文字になっているからである
If readContentSjis.Contains(“テスト文字列”) Then
Console.WriteLine(“基本的な文字列は正しく読み込まれた。”)
End If
Console.WriteLine($”Length: {readContentSjis.Length}”)
Catch ex As Exception
Console.WriteLine($”読み込みエラー (Shift-JIS): {ex.Message}”)
End Try
‘ 4. UTF-8でファイルを書き込み、読み込む
Dim utf8FilePath As String = “C:\temp\sample_utf8.txt”
Try
File.WriteAllText(utf8FilePath, content, Encoding.UTF8)
Console.WriteLine($”‘{utf8FilePath}’ にUTF-8で書き込みました。”)
Dim readContentUtf8 As String = File.ReadAllText(utf8FilePath, Encoding.UTF8)
Console.WriteLine($”UTF-8エンコーディングでの読み込み: {readContentUtf8}”)
If readContentUtf8.Contains(“𠮟”) Then
Console.WriteLine(“補助文字も正しく読み込まれた。”)
Else
Console.WriteLine(“補助文字が正しく読み込まれなかったか、表示環境の問題。”)
End If
Console.WriteLine($”Length: {readContentUtf8.Length}”)
Catch ex As Exception
Console.WriteLine($”UTF-8処理エラー: {ex.Message}”)
End Try
‘ 5. バイト配列を介した文字コード変換
Console.WriteLine(Environment.NewLine & “— バイト配列を介した文字コード変換 —“)
Dim originalBytes As Byte() = Encoding.UTF8.GetBytes(“こんにちは”)
‘ UTF-8 -> Shift-JIS (中間でStringを経由しない)
Dim sjisBytes As Byte() = Encoding.Convert(Encoding.UTF8, Encoding.GetEncoding(“Shift_JIS”), originalBytes)
Dim sjisString As String = Encoding.GetEncoding(“Shift_JIS”).GetString(sjisBytes)
Console.WriteLine($”UTF-8 -> Shift-JIS 変換: {sjisString}”)
‘ Shift-JIS -> UTF-8 (中間でStringを経由しない)
Dim utf8BytesConverted As Byte() = Encoding.Convert(Encoding.GetEncoding(“Shift_JIS”), Encoding.UTF8, sjisBytes)
Dim utf8StringConverted As String = Encoding.UTF8.GetString(utf8BytesConverted)
Console.WriteLine($”Shift-JIS -> UTF-8 変換: {utf8StringConverted}”)
‘ 警告: Encoding.Default はシステムのカルチャに依存するため、使用は推奨されない
‘ Console.WriteLine($”システムデフォルトエンコーディング: {Encoding.Default.WebName}”)
Console.ReadKey()
End Sub
End Module
解説: `System.Text.Encoding`クラスを徹底的に活用すること。`Encoding.GetEncoding(“Shift_JIS”)`, `Encoding.UTF8`, `Encoding.Unicode`などを使い分け、データの入出力時には常に適切なエンコーディングを指定する。`Encoding.Default`はシステムのデフォルトに依存するため、環境によって挙動が変わり、トラブルの温床となる。特にサーバーサイドやクロスプラットフォーム開発では、決して使用してはならない。
3.2. 文化に依存しない文字列比較 (Invariant Culture)
文字列比較は、単に文字コードが一致するかどうかだけでなく、「カルチャ」（国や地域の設定）によってその挙動が大きく変わる場合がある。例えば、ドイツ語では`ß`と`ss`が等価とみなされたり、トルコ語では大文字の`I`と小文字の`i`の挙動が英語とは異なったりする。
システム内部での比較や、ファイルパス、IDのようなカルチャに依存しない厳密な比較が必要な場合は、`String.Compare`メソッドと`StringComparison`列挙体を活用する。
.net
Imports System
Imports System.Globalization ‘ カルチャ関連の名前空間
Module StringComparisonExample
Sub Main()
Dim s1 As String = “Straße” ‘ ドイツ語で「道」
Dim s2 As String = “Strasse”
‘ 1. “=” 演算子による比較 (通常はOrdinalIgnoreCaseに近いが、完全に同じではない)
Console.WriteLine($”‘{s1}’ = ‘{s2}’ (デフォルト演算子): {s1 = s2}”) ‘ False
‘ 2. CurrentCulture (現在のカルチャ) に基づく比較
‘ ドイツ語カルチャでは ‘ß’ と ‘ss’ は等価と見なされる
Console.WriteLine(Environment.NewLine & “— CurrentCultureに基づく比較 —“)
Dim currentCulture As CultureInfo = CultureInfo.CurrentCulture
Console.WriteLine($”Current Culture ({currentCulture.Name})”)
Console.WriteLine($”Compare (CurrentCulture): {String.Compare(s1, s2, StringComparison.CurrentCultureIgnoreCase) = 0}”) ‘ ドイツ語環境なら True
‘ 3. InvariantCulture (不変カルチャ) に基づく比較
‘ 言語や地域に依存しない、英語圏の規則に基づいた比較
Console.WriteLine(Environment.NewLine & “— InvariantCultureに基づく比較 —“)
Console.WriteLine($”Compare (InvariantCulture): {String.Compare(s1, s2, StringComparison.InvariantCultureIgnoreCase) = 0}”) ‘ False
‘ 4. Ordinal (序数) 比較: 最も厳密な比較
‘ 文字のバイナリ値（UTF-16コードユニット値）に基づいて比較。最も高速で、ロケール非依存。
‘ これが「文字コードが完全に一致するか」を判断する鉄則。
Console.WriteLine(Environment.NewLine & “— Ordinal比較 (鉄則) —“)
Console.WriteLine($”Compare (Ordinal): {String.Compare(s1, s2, StringComparison.Ordinal) = 0}”) ‘ False
Console.WriteLine($”Compare (OrdinalIgnoreCase): {String.Compare(s1, s2, StringComparison.OrdinalIgnoreCase) = 0}”) ‘ False (バイナリ値が異なるため)
Dim s3 As String = “file.txt”
Dim s4 As String = “FILE.TXT”
Console.WriteLine(Environment.NewLine & “— ファイル名比較の例 —“)
Console.WriteLine($”‘{s3}’ = ‘{s4}’ (デフォルト演算子): {s3 = s4}”) ‘ False
Console.WriteLine($”Compare (Ordinal): {String.Compare(s3, s4, StringComparison.Ordinal) = 0}”) ‘ False
Console.WriteLine($”Compare (OrdinalIgnoreCase): {String.Compare(s3, s4, StringComparison.OrdinalIgnoreCase) = 0}”) ‘ True (Windowsはファイル名を大文字小文字区別しないため、これを使うことが多い)
‘ 注意: Windowsのファイルシステムは通常、大文字小文字を区別しないため、
‘ ファイル名比較には StringComparison.OrdinalIgnoreCase が適切である場合が多い。
‘ Linuxなど大文字小文字を区別するシステムでは Ordinal が必要。
Console.ReadKey()
End Sub
End Module
鉄則2: ロケールに依存しない厳密な比較には`StringComparison.Ordinal`か`StringComparison.OrdinalIgnoreCase`を使用する。
特に、システムの内部ID、ハッシュ値の生成、プロトコル上の文字列比較、セキュリティ関連の検証など、文字コード値そのものが重要で、かつカルチャによる解釈の違いを許容しない場面では、`Ordinal`（大文字・小文字も区別する）または`OrdinalIgnoreCase`（大文字・小文字を区別しない）を用いるべきだ。これはバイナリ比較に近く、最も高速で予測可能な結果をもたらす。
3.3. Windows APIとの連携における文字コードの壁
レガシーなWindows API（Win32 API）をP/Invokeで呼び出す際、文字コードは最大の落とし穴の一つとなる。Win32 APIには通常、ANSI版（末尾に`A`が付く、例: `GetWindowTextA`）とUnicode版（末尾に`W`が付く、例: `GetWindowTextW`）が存在する。
.NETの`String`はUTF-16であるため、基本的にはUnicode版のAPI (`LPWStr`を期待するもの) と相性が良い。しかし、古いDLLや特定のAPIがANSI文字列 (`LPStr`を期待するもの) しか受け付けない場合がある。
.net
Imports System.Runtime.InteropServices ‘ P/Invoke関連の名前空間
Imports System.Text
Module WindowsApiEncodingExample
‘ Win32 API関数の宣言
‘ GetShortPathNameA: ANSI版 (CharSet.Ansiを指定)
‘ .NETのString(UTF-16)からANSIへの変換は、CLRのマーシャラが自動で行う
Private Shared Function GetShortPathNameA( _
ByVal lpszLongPath As String, _
<[In](), Out()> ByVal lpszShortPath As StringBuilder, _
ByVal cchBuffer As Integer _
) As Integer
End Function
‘ GetShortPathNameW: Unicode版 (CharSet.Unicodeを指定)
‘ .NETのString(UTF-16)からUnicodeへの変換は、CLRのマーシャラが自動で行う
Private Shared Function GetShortPathNameW( _
ByVal lpszLongPath As String, _
<[In](), Out()> ByVal lpszShortPath As StringBuilder, _
ByVal cchBuffer As Integer _
) As Integer
End Function
Sub Main()
Dim longPath As String = “C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE” ‘ 日本語パスでもテスト
‘ Shift-JISでしか表現できない文字（例：機種依存文字など）をパスに含めると、ANSI版で問題が起こる可能性もある
Console.WriteLine($”元のパス: {longPath}”)
‘ 1. ANSI版APIの呼び出し
Console.WriteLine(Environment.NewLine & “— ANSI版 (GetShortPathNameA) —“)
Dim shortPathBufferAnsi As New StringBuilder(260) ‘ MAX_PATHは260文字 (null終端含む)
Dim resultAnsi As Integer = GetShortPathNameA(longPath, shortPathBufferAnsi, shortPathBufferAnsi.Capacity)
If resultAnsi = 0 Then
Console.WriteLine($”ANSI版エラー: {Marshal.GetLastWin32Error()} ({New System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error()).Message})”)
Else If resultAnsi > shortPathBufferAnsi.Capacity Then
‘ バッファが足りない場合のリトライ
shortPathBufferAnsi.Capacity = resultAnsi
resultAnsi = GetShortPathNameA(longPath, shortPathBufferAnsi, shortPathBufferAnsi.Capacity)
If resultAnsi > 0 Then
Console.WriteLine($”ANSI版ショートパス: {shortPathBufferAnsi.ToString()}”)
Else
Console.WriteLine($”ANSI版リトライエラー: {Marshal.GetLastWin32Error()}”)
End If
Else
Console.WriteLine($”ANSI版ショートパス: {shortPathBufferAnsi.ToString()}”)
End If
‘ 2. Unicode版APIの呼び出し
Console.WriteLine(Environment.NewLine & “— Unicode版 (GetShortPathNameW) —“)
Dim shortPathBufferUnicode As New StringBuilder(260)
Dim resultUnicode As Integer = GetShortPathNameW(longPath, shortPathBufferUnicode, shortPathBufferUnicode.Capacity)
If resultUnicode = 0 Then
Console.WriteLine($”Unicode版エラー: {Marshal.GetLastWin32Error()} ({New System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error()).Message})”)
Else If resultUnicode > shortPathBufferUnicode.Capacity Then
‘ バッファが足りない場合のリトライ
shortPathBufferUnicode.Capacity = resultUnicode
resultUnicode = GetShortPathNameW(longPath, shortPathBufferUnicode, shortPathBufferUnicode.Capacity)
If resultUnicode > 0 Then
Console.WriteLine($”Unicode版ショートパス: {shortPathBufferUnicode.ToString()}”)
Else
Console.WriteLine($”Unicode版リトライエラー: {Marshal.GetLastWin32Error()}”)
End If
Else
Console.WriteLine($”Unicode版ショートパス: {shortPathBufferUnicode.ToString()}”)
End If
Console.WriteLine(Environment.NewLine & “— API選択の考慮事項 —“)
Console.WriteLine(“・レガシーDLLがANSI文字列のみを期待する場合を除き、基本的にはUnicode版API (`CharSet:=CharSet.Unicode`) を使用すること。”)
Console.WriteLine(“・これは.NETのStringがUTF-16(Unicode)であるため、マーシャリングのオーバーヘッドが最小限に抑えられ、文字化けのリスクも低い。”)
Console.WriteLine(“・バッファを要するAPI呼び出しには `StringBuilder` を使用し、バッファサイズの不足に注意すること。”)
Console.ReadKey()
End Sub
End Module
鉄則3: Windows API呼び出しでは、可能な限り`CharSet.Unicode`を指定し、Unicode版のAPIを使用する。
これにより、.NETのStringとAPIが期待する文字列形式（UTF-16）が一致するため、余計な文字コード変換によるオーバーヘッドや文字化けのリスクを最小限に抑えられる。どうしてもANSI版APIを呼び出す必要がある場合は、`CharSet.Ansi`を指定し、文字コード変換がCLRのマーシャラによって行われることを意識する。特に、Shift-JISなどマルチバイト文字を含む文字列をANSI APIに渡す際は、意図しない文字化けやデータ損失の可能性を常に考慮せよ。バッファを必要とするAPI呼び出しには`System.Text.StringBuilder`が不可欠だ。
4. オブジェクトのライフサイクルとパフォーマンスへの影響
Char型とString型の特性は、パフォーマンスとメモリ使用量にも大きな影響を与える。特にStringの「不変性」は、意識しないと深刻なボトルネックになり得る。
4.1. Stringの不変性とメモリフットプリント
Stringオブジェクトは一度作成されると変更できない。これは、文字列を結合したり、一部を置換したりするたびに、新しいStringオブジェクトがヒープに生成されることを意味する。
.net
Module StringPerformanceExample
Sub Main()
Dim s As String = “”
Dim sw As New Stopwatch()
sw.Start()
For i As Integer = 0 To 99999 ‘ 10万回の文字列結合
s &= i.ToString() ‘ この行が新しいStringオブジェクトを繰り返し生成する
Next
sw.Stop()
Console.WriteLine($”String結合 (10万回): {sw.ElapsedMilliseconds} ms, Length: {s.Length}”)
sw.Reset()
sw.Start()
Dim sb As New StringBuilder() ‘ StringBuilderを使用
For i As Integer = 0 To 99999
sb.Append(i.ToString())
Next
Dim finalString As String = sb.ToString() ‘ 最後に一度だけStringオブジェクトを生成
sw.Stop()
Console.WriteLine($”StringBuilder使用 (10万回): {sw.ElapsedMilliseconds} ms, Length: {finalString.Length}”)
Console.ReadKey()
End Sub
End Module
この例が示すように、ループ内で`String`の結合を繰り返すと、指数関数的にパフォーマンスが劣化する。これは、大量のStringオブジェクトが生成され、ガベージコレクション（GC）の負荷が増大するためだ。
鉄則4: 頻繁な文字列操作が必要な場合は、`System.Text.StringBuilder`を使用する。
`StringBuilder`は内部的に可変長の文字バッファを持ち、文字列操作を効率的に行うことができる。最終的に`ToString()`メソッドを呼び出すことで、目的の`String`オブジェクトを一度だけ生成する。これにより、GCの負荷を大幅に軽減し、パフォーマンスを向上させることができる。
4.2. Char型の軽量さと注意点
`Char`は値型であるため、`String`と比較して非常に軽量だ。単一の文字を扱う場合、`Char`はスタックに直接格納されるか、より大きなオブジェクトの一部として埋め込まれるため、ヒープへの割り当てやGCの対象となることは少ない。
しかし、`Char`型の配列を`String`に変換したり、多数の`Char`を連結して`String`を生成したりする際には、やはり新しい`String`オブジェクトがヒープに生成されることを忘れてはならない。メモリ効率を最大限に高めるためには、`Char`配列を直接操作し、必要なときにのみ`String`に変換する戦略も有効だ。
5. レガシー環境と新世代環境の狭間で
VB.NETが持つChar/String型の挙動は、レガシーなVB6/VBA環境から現代の.NET Core/.NET 5+環境への橋渡しにおいても、重要な考慮事項となる。
5.1. VB6/VBAとの比較：BSTRの時代
VB6やVBAの`String`は、内部的にはCOMの`BSTR`（Basic String）という形式だった。`BSTR`はUnicode（UTF-16）をサポートしていたが、API呼び出しの多くはANSI（システムデフォルトのコードページ）を前提としていたため、明示的な変換なしにUnicode文字列をANSI APIに渡すと文字化けが発生する可能性があった。
VB.NETへの移行プロジェクトでは、VBAコードでファイルI/OやAPI呼び出しを行っている箇所を徹底的に洗い出し、.NETの`Encoding`クラスと`CharSet`属性を用いた適切な文字コード変換ロジックを再実装する必要がある。これが、古い資産を新環境で安定稼働させるための最も手間のかかる、しかし最も重要な作業となる。
5.2. .NET Frameworkと.NET Core/.NET 5+：普遍的な原則
Char型とString型の基本的な概念、UnicodeとUTF-16の内部表現、そして`StringBuilder`の重要性は、.NET Frameworkでも.NET Core/.NET 5+でも普遍的に変わらない。
しかし、.NET Core/.NET 5+はクロスプラットフォームを志向しており、Windows以外のOS（Linux、macOS）で動作する可能性が高い。これらのOSでは、ファイルシステムのデフォルトエンコーディングやカルチャ設定がWindowsとは異なる場合が多い。例えば、LinuxのデフォルトはUTF-8であることが一般的だ。
鉄則5: クロスプラットフォーム開発では、常にエンコーディングとカルチャを明示的に指定し、環境依存の挙動を排除する。
`Encoding.Default`や`CultureInfo.CurrentCulture`のような、実行環境に依存する設定は極力避け、`Encoding.UTF8`や`StringComparison.Ordinal`、`CultureInfo.InvariantCulture`などの、普遍的な指定を用いるべきだ。
結論：基礎の掌握がシステムを支える
Char型とString型、一見すると単純なデータ型だが、その背後には文字コード、エンコーディング、カルチャ、パフォーマンス、メモリ管理、そしてレガシーシステムとの連携という、複雑かつ深遠な概念が横たわっている。
「文字化け」という現象は、単なるバグではない。それは、システムが外部世界と適切にコミュニケーションできていないという、設計や実装の根本的な欠陥を告げる警鐘だ。
我々シニアエンジニア、そしてシステム管理者は、この基礎の基礎を徹底的に掌握し、表面的な挙動に惑わされることなく、その深層に潜む原理を理解しなければならない。
魂を込めて言おう。
「文字コードを制する者は、システムを制す。」
この鉄則を胸に刻み、諸君のシステムが常に堅牢で信頼性の高いものであることを願う。
