結論：バイト列に戻す処理と、文字として読む処理は２段階
4例を試すと、Base64からバイト列へ戻せた3例のうち、UTF-8の文章として読めたのは2例でした。PowerShellのFromBase64Stringで戻るのは文字列ではなくバイト列です。その中身をUTF-8などの文字コードで読む工程が続きます。
「Base64として正しい」と「文章として読める」は別の条件です。以下はWindows上のPowerShellで実行した文字データの例です。ブラウザのBase64変換は向きを自動判定するため、同じ入力でも処理の向きが違う場合があります。
Base64変換UTF-8の文字データを変換結果と表示された向きで確認する登録なしで使えます開く
手順：文字データと分かっている例をPowerShellで読む
UTF-8の「日本語」をBase64にした作例は、次の1行で元の文章へ戻りました。ネットワークアクセスやファイル保存を伴わず、作例の文字列を処理して結果を表示するコマンドです。
```powershell
```
結果は「日本語」です。最初の処理がBase64の復号、GetStringがUTF-8としての読み取りです。ここではUTF8Encodingの第2引数をtrueにし、不正なUTF-8を例外として検出します。
2026年10月1日、Windows・PowerShell 7.6.5・.NET 10.0.11で、n=4の架空入力を同じ順に処理しました。
| 入力 | Base64の復号 | 得られたバイト数 | 厳密なUTF-8の読み取り |
|---|---|---|---|
| QUJD | 成功 | 3 | ABC |
| 5pel5pys6Kqe | 成功 | 9 | 日本語 |
| /w== | 成功 | 1 | 例外になった |
| QQ?= | 形式エラー | — | 実行しない |
「/w==」の1バイトは16進数でFFです。Base64としては戻せても、これ単独をUTF-8の文章にはできませんでした。QQ?=にはBase64の文字集合にない「?」が入り、先の段階で止まりました。別のPython処理でも、復号したバイト列とUTF-8の成功・失敗を照合しています。
一次資料：MicrosoftのAPIは返す型と例外条件を分ける
FromBase64Stringの戻り値は、8ビットの符号なし整数の配列です。
Converts the specified string, which encodes binary data as base-64 digits, to an equivalent 8-bit unsigned integer array.
— Microsoft Learn「Convert.FromBase64String(String)」 https://learn.microsoft.com/en-us/dotnet/api/system.convert.frombase64string?view=net-10.0（2026-10-01 到達）
文字列へ読む処理はEncoding.GetString側にあります。公式説明は次のとおりです。
When overridden in a derived class, decodes a sequence of bytes into a string.
— Microsoft Learn「Encoding.GetString」 https://learn.microsoft.com/en-us/dotnet/api/system.text.encoding.getstring?view=net-10.0（2026-10-01 到達）
不正な文字コードを例外にするかは設定で変わります。UTF8EncodingのthrowOnInvalidBytesには、次の説明があります。
true to throw an exception when an invalid encoding is detected; otherwise, false .
— Microsoft Learn「UTF8Encoding(Boolean, Boolean)」 https://learn.microsoft.com/en-us/dotnet/api/system.text.utf8encoding.-ctor?view=net-10.0（2026-10-01 到達）
今回、通常のEncoding.UTF8.GetStringではFFが置換文字「�」になり、上の厳密な設定では例外になりました。これは同じバイト列でも、読み取り方によって結果の扱いが変わる実測です。
間違えやすい点：ブラウザの自動判定は強制デコードではない
現行のBase64変換は、復号結果が妥当なUTF-8になる場合だけデコードと判定します。同じ4例を計算関数へ入れた結果は次のとおりでした。
| 入力 | ツールが表示する向き | ツールの出力 |
|---|---|---|
| QUJD | デコード | ABC |
| 5pel5pys6Kqe | デコード | 日本語 |
| /w== | エンコード | L3c9PQ== |
| QQ?= | エンコード | UVE/PQ== |
後ろ2例は、入力を文字として再びBase64にした結果です。元のバイナリを復元した結果ではありません。ファイルをBase64へ変える機能とも区別が要ります。文字列欄で自動判定されることと、任意のBase64をファイルへ戻せることは同じではありません。
測っていないこと・ここから先は推論
Windows PowerShell 5.1、certutil、Mac・Linuxのコマンドは実行していません。大容量データ、改行を含む入力、Base64URL、data URI、UTF-16やShift_JIS、画像・PDFのファイル復元も対象外です。4例の結果から、すべてのBase64に同じコマンドを使えるとはいえません。
実際の社内PCでコマンドやブラウザツールが利用できるかも未測定です。実行制限、データの取扱い条件、復号後の内容の正当性は、この比較では判断していません。
次の１手：作例で処理の向きを確認する
次の1手は、Base64変換に作例の文字列を入れ、出力と処理の向きを比べることです。文字を読める状態へ戻したのか、入力そのものを再エンコードしたのかを見分けられます。