日本語ファイル文字化け対策ガイド

対象:ChatGPT / Claude 生成ファイル、PowerShell、ZIP、日本語ファイル名、Apache httpd、Tomcat、VS Code、ISE、メモ帳、サクラエディタ
作成日:2026-06-13 / 推奨運用:Windows Server 2022・Windows PowerShell 5.1 互換を重視

目次

  1. 最初に決めるべき推奨ルール
  2. なぜ文字化けするのか
  3. S-JIS / UTF-8 / UTF-8 BOM付き / Unicode の違い
  4. Windows・各エディタ・PowerShell の関係
  5. Apache / Tomcat の conf・xml を扱う注意点
  6. 文字コード確認方法
  7. PowerShellでの安全な読み書きサンプル
  8. ZIPと日本語ファイル名の注意点
  9. 症状別の原因と対処
  10. チーム運用ルール・チェックリスト
  11. 参考情報

1. 最初に決めるべき推奨ルール

結論:日本語を含むPowerShellスクリプトを Windows PowerShell 5.1 でも実行するなら、.ps1 / .psm1 / .psd1 は「UTF-8 BOM付き」を標準にしてください。 VS Codeの既定はUTF-8 BOMなしなので、そのまま保存すると Windows PowerShell 5.1 で日本語文字列が壊れることがあります。
最優先

PowerShell本体

UTF-8 BOM付きで保存。日本語のコメント、文字列、ハッシュキー、ログ文言を含める場合は特に必須。

推奨

Apache / Tomcat設定

UTF-8 BOMなしまたはASCII範囲中心。特にディレクティブ名、属性名、パス、セクション名に日本語を入れない。

要注意

INI / conf / properties

読む側の仕様に合わせる。PowerShell用ならBOM対応の読み取り関数を使う。アプリが読む設定はBOMなしが無難。

安定化

ZIP

AI生成成果物のZIP内ファイル名は英数字を標準化。日本語名はmanifestやHTML内タイトルに記載。

ファイル種別ごとの標準

ファイル種別 推奨文字コード 理由 禁止・注意事項
.ps1 .psm1 .psd1 UTF-8 BOM付き Windows PowerShell 5.1 が BOMなしUTF-8の日本語をANSI/CP932として誤認しやすいため。 VS Codeの既定保存のままにしない。日本語のハッシュキー・switch句・関数名はできれば避ける。
PowerShellが出力するログ .log .csv 運用閲覧重視:UTF-8 BOM付き
機械処理重視:UTF-8 BOMなし
Excel、メモ帳、Windows系運用者が開くならBOM付きの方が誤認が少ない。PowerShell 7やLinux連携ならBOMなしが扱いやすい。 > リダイレクトや Out-File の既定に任せない。
Apache httpd.conf *.conf .htaccess UTF-8 BOMなし、可能ならASCII中心 設定ファイルはhttpdのディレクティブを記述するテキストファイル。BOMや全角空白が構文エラー原因になり得る。 日本語はコメントに限定。パスは半角英数字・スラッシュ中心。WindowsでもApache設定内は / を推奨。
Tomcat server.xml context.xml web.xml UTF-8 BOMなし + XML宣言 <?xml version="1.0" encoding="UTF-8"?> XMLとしての整合性を優先。Java/Tomcat系の設定はUTF-8で統一し、UTF-16LEやCP932混在を避ける。 コメント以外に日本語を入れる場合は、読み取るJava側・外部ツール側の仕様も確認。
INI / 独自設定ファイル PowerShell専用:UTF-8 BOM付き可
他アプリも読む:UTF-8 BOMなし推奨
先頭BOMが [Monitor] の前に混入すると、単純な正規表現やセクション判定が失敗することがある。 読み取り側でBOM除去・UTF-8/CP932判定を実装する。
HTML / Markdown / 手順書 UTF-8。HTMLは <meta charset="UTF-8"> を明記 ブラウザ表示・共有・検索の互換性が高い。 添付ZIP内ファイル名は英数字にする。本文タイトルは日本語でよい。
運用上の割り切り: 「PowerShellスクリプト本体」はUTF-8 BOM付き、「Apache/Tomcatが読む設定ファイル」はUTF-8 BOMなし、というように用途ごとに標準を分けるのが最も事故が少ないです。

2. なぜ文字化けするのか

1
作成
ChatGPT/Claude/VS Code/メモ帳/ISE/サクラで日本語入りファイルを作る。
2
保存
UTF-8 BOMなし、UTF-8 BOM付き、CP932、UTF-16LEなどで保存される。
3
移動・ZIP展開
ZIP内ファイル名や展開ツールの解釈がずれる。
4
読み取り
PowerShell 5.1、Apache、Tomcat、独自スクリプトが別の文字コードとして読む。
5
障害化
文字化け、構文エラー、INIセクション不一致、ログ文字化けが発生。

典型例:UTF-8の日本語をCP932として読んだ場合

「ユーザーエージェント」というUTF-8文字列を、Windowsの古い日本語コードページ寄りの解釈で読むと、繝ヲ繝シ繧カ繝シ... のような文字化けになります。質問中の例1はこのパターンです。

UTF-8 E3 83 A6 E3 83 BC E3 82 B6 ...

本来はUTF-8として読むべきバイト列をCP932など別の規則で読むと、PowerShellの switch 句、ハッシュリテラル、引用符、全角記号が壊れ、構文解析エラーになります。

重要:「文字化けしてもコメントだけなら動く」場合もありますが、文字列リテラル、ハッシュキー、switch条件、正規表現、XML属性値、パス、INIセクション名に日本語が含まれると、処理そのものが壊れます。

3. S-JIS / UTF-8 / UTF-8 BOM付き / Unicode の違い

呼び方 正確な意味 日本語Windowsでの扱い 長所 事故ポイント
S-JIS / Shift_JIS / CP932 / ANSI 日本語Windowsのレガシーコードページ。厳密にはShift_JISとMicrosoft CP932は完全同一ではない。 古いWindowsアプリ、古いCSV、古いバッチ、レガシー設定で使われがち。 古い日本語Windowsツールとの相性が良い。 Unicode文字を表現できない。UTF-8と混在すると 繝 系の文字化けが起きる。
UTF-8 BOMなし Unicodeを可変長バイトで表す現在主流の形式。先頭にBOMがない。 VS CodeやPowerShell 7の既定に近い。 Web、Linux、Git、API、クロスプラットフォームで扱いやすい。 Windows PowerShell 5.1では、日本語入り .ps1 がANSIと誤認されることがある。
UTF-8 BOM付き UTF-8の先頭に EF BB BF を付けた形式。 Windows PowerShell 5.1の日本語入りスクリプトには安全。 「このファイルはUTF-8」と認識させやすい。 INIの [Section] 先頭やUnix系ツールではBOMが邪魔になることがある。
Unicode Windowsの保存ダイアログ等では、多くの場合 UTF-16 LE を指す。 Windows PowerShell 5.1の Out-File や > で作られやすい。 Windows内部表現と相性が良い。 Apache/Tomcat/CSV/通常のテキスト処理では想定外になりやすい。ファイルサイズも大きい。

BOMのバイト列

形式先頭バイト意味
UTF-8 BOM付きEF BB BFUTF-8であることを示す目印。
UTF-16 LEFF FEWindowsで「Unicode」と表示されることが多い。
UTF-16 BEFE FFビッグエンディアンのUTF-16。
UTF-8 BOMなし / CP932目印なしファイル先頭だけでは確実な判定が難しい。
覚え方: BOMなし は「身分証なし」。読む側が賢ければ問題ありませんが、Windows PowerShell 5.1のように古い前提で読む側では誤認します。 BOM付き は「UTF-8の名札付き」。ただし名札そのものを文字として読んでしまうツールでは邪魔になります。

4. Windows・各エディタ・PowerShell の関係

全体マトリクス

ツール 既定・特徴 日本語PowerShellでの推奨 確認・変更ポイント
Windows PowerShell 5.1 Windows標準搭載。出力系コマンドの既定エンコードが一貫しない。BOMなしUTF-8の日本語スクリプトをANSIとして誤認しやすい。 .ps1 はUTF-8 BOM付き。ファイル出力は -Encoding UTF8 を明示。> だけに頼らない。 $PSVersionTable.PSVersion、[Text.Encoding]::Default、ファイル先頭バイト確認。
PowerShell 7 x64 既定はUTF-8 BOMなし。-Encoding utf8BOM、utf8NoBOMなどを明示しやすい。 PowerShell 7専用ならUTF-8 BOMなし可。ただし5.1互換が必要ならBOM付きで統一。 pwsh -NoProfileで確認。$PSVersionTable.PSEdition がCore。
Visual Studio Code 既定はUTF-8 BOMなし。下部ステータスバーで現在のエンコードを確認可能。 PowerShell 5.1用スクリプトでは files.encoding を utf8bom にするか、保存時に「Save with Encoding → UTF-8 with BOM」。 設定 files.encoding、files.autoGuessEncoding、右下の文字コード表示。
Windows PowerShell ISE Windows PowerShell 5.1向け。古いWindows運用ではまだ使われる。 日本語スクリプトはUTF-8 BOM付きまたはUTF-16LEで保存。混在編集時は保存後に確認。 ISEだけで完結させず、PowerShellの先頭バイト確認コマンドで検査。
メモ帳 Windowsバージョン・アプリ更新により保存時の候補や既定が変わる。ANSI、UTF-8、UTF-8 BOM付き、UTF-16系を選べる環境がある。 設定ファイルの一時修正には使えるが、PowerShellや本番confの標準編集ツールにはしない。 「名前を付けて保存」の文字コード欄を毎回確認。
サクラエディタ タイプ別設定で新規作成時の文字コード・改行・BOM付加を指定できる。 拡張子別に既定を設定。.ps1 はUTF-8+BOM、.conf/.xml はUTF-8 BOMなし等。 ステータスバーの文字コード、設定 → タイプ別設定一覧 → ウィンドウ → デフォルトの文字コード。

VS Code の推奨設定例

VS Code全体をUTF-8 BOM付きにすると、Apache/Tomcat設定ファイルにもBOMが入りやすくなります。したがって、全体既定はUTF-8 BOMなしのまま、PowerShellファイルだけBOM付きにする方が安全です。

{
  // 全体は UTF-8 BOMなし
  "files.encoding": "utf8",
  "files.autoGuessEncoding": true,

  // PowerShellだけ UTF-8 BOM付きにしたい場合
  "[powershell]": {
    "files.encoding": "utf8bom"
  }
}
注意:VS Codeで開いた時に右下が UTF-8 と表示されても、BOM付きかBOMなしかを必ず確認してください。PowerShell 5.1用途では UTF-8 with BOM を選ぶのが安全です。

5. Apache / Tomcat の conf・xml を扱う注意点

Apache

httpd.conf は「設定ディレクティブのテキスト」

Apache httpdの設定ファイルは、httpdの動作を制御するディレクティブを含むテキストファイルです。読み込み対象に一時ファイルや想定外のファイルが混ざると起動失敗の原因になります。

Tomcat

server.xml はXMLとして管理

Tomcatの server.xml、context.xml、web.xml はXMLとしての整合性が重要です。UTF-8で統一し、XML宣言と実ファイルのエンコードを合わせます。

PowerShell

読む側は複数エンコード対応にする

Apache/Tomcat設定ファイルは複数人が別エディタで修正しがちです。解析スクリプト側はBOM検出、UTF-8妥当性確認、CP932フォールバックを実装します。

Apache設定ファイルの実務ルール

項目推奨理由
ファイル文字コード UTF-8 BOMなし、またはASCII中心 BOMや全角文字がディレクティブ先頭・パス・ログフォーマットに混入すると検出しにくい。
日本語利用 原則コメントのみ ディレクティブ値、パス、ログフォーマット名、環境変数名に日本語を入れない。
パス表記 Windowsでも C:/Apache24/conf/... のようにスラッシュ推奨 Apache公式ドキュメントでも、非Unix環境の設定ファイルではスラッシュ使用が推奨されている。
Include IncludeOptional conf/extra/*.conf のように対象を限定 ディレクトリ全体Includeは、一時ファイルやバックアップファイルを誤読しやすい。
Web表示文字コード AddDefaultCharset や AddCharset は「HTTP応答」の文字コード制御 これらはブラウザへ返すContent-Typeのcharsetであり、httpd.conf自体の読み取り文字コードを直す設定ではない。

Tomcat設定ファイルの実務ルール

項目推奨理由
XML設定 <?xml version="1.0" encoding="UTF-8"?> と実ファイルを一致 XML宣言と実際の保存エンコードが違うと、外部ツールやJava側で読めない場合がある。
BOM UTF-8 BOMなし推奨 XMLパーサーはBOMを扱える場合が多いが、周辺のテキスト処理・差分・スクリプト解析ではBOMなしが安定。
URI文字コード Tomcat 9のHTTP Connectorでは URIEncoding の既定はUTF-8 URLデコードの文字コードと設定ファイル自体の文字コードは別問題。混同しない。
日本語コメント 可。ただし保存形式を統一 コメントだから安全とは限らない。PowerShell等で解析する場合は文字コード判定が必要。
properties Javaアプリ仕様を確認 古いJavaの .properties はISO-8859-1前提の歴史があり、アプリ側の読み方に依存する。
避けるべき運用:Apache/Tomcatが読む本番設定ファイルを、メモ帳・ISE・VS Code・サクラエディタで各人が自由な文字コードで保存する運用。
本番反映前に文字コード検査を必ず入れてください。

6. 文字コード確認方法

Visual Studio Code

  1. ファイルを開く。
  2. 画面右下の UTF-8 などの表示を確認。
  3. クリックして Reopen with Encoding または Save with Encoding を選択。
  4. PowerShell 5.1用なら UTF-8 with BOM で保存。

設定は Ctrl + , → files.encoding。

Windows PowerShell ISE

  1. ISE上の表示だけで判断しない。
  2. 保存後にPowerShellコマンドで先頭バイトを確認。
  3. 他エディタで開き直し、UTF-8 BOM付きであることを確認。

ISEは編集用としては便利ですが、文字コードの見える化が弱いため、検査コマンドと併用します。

メモ帳

  1. 「名前を付けて保存」を開く。
  2. 画面下部の「文字コード」欄を確認。
  3. PowerShell 5.1用なら UTF-8 BOM付き を選ぶ。
  4. Apache/Tomcat confならUTF-8、ただしBOM有無に注意。

Windows更新により選択肢や既定が変わることがあるため、保存時確認をルール化します。

サクラエディタ

  1. ステータスバーの文字コード表示を確認。
  2. 設定 → タイプ別設定一覧 → 対象タイプ → ウィンドウ。
  3. 「デフォルトの文字コード」と「BOM」を拡張子別に設定。
  4. 保存時も文字コードを確認。

拡張子別に .ps1 と .conf の標準を分けられる点が利点です。

PowerShellで先頭BOMを確認する簡易コマンド

# 先頭4バイトを16進表示
$path = ".\sample.ps1"
$bytes = [System.IO.File]::ReadAllBytes((Resolve-Path $path))
[BitConverter]::ToString($bytes[0..([Math]::Min(3, $bytes.Length - 1))])

# 判定例
# EF-BB-BF-xx : UTF-8 BOM付き
# FF-FE-xx-xx : UTF-16 LE
# FE-FF-xx-xx : UTF-16 BE
# それ以外     : UTF-8 BOMなし、CP932、ASCII等の可能性

7. PowerShellでの安全な読み書きサンプル

7.1 Windows PowerShell 5.1 / PowerShell 7 両対応の読み取り方針

Apache/Tomcat/INI/CSVを読むスクリプトは、ファイルの文字コードを決め打ちしない方が安全です。以下の順で判定します。

1
BOM確認
UTF-8/UTF-16のBOMがあればそれを採用。
2
UTF-8検査
BOMなしでもUTF-8として妥当か確認。
3
CP932フォールバック
日本語Windowsのレガシーファイルとして読む。
4
BOM除去
先頭行の U+FEFF を除去。
5
ログ出力
出力エンコードを明示。

7.2 安全なテキスト読み取り関数

function Read-TextFileSafe {
    param(
        [Parameter(Mandatory)]
        [string]$Path
    )

    if (-not (Test-Path -LiteralPath $Path)) {
        throw "File not found: $Path"
    }

    $bytes = [System.IO.File]::ReadAllBytes($Path)

    if ($bytes.Length -ge 3 -and
        $bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) {
        $enc = New-Object System.Text.UTF8Encoding($true)
        $text = $enc.GetString($bytes)
    }
    elseif ($bytes.Length -ge 2 -and $bytes[0] -eq 0xFF -and $bytes[1] -eq 0xFE) {
        $text = [System.Text.Encoding]::Unicode.GetString($bytes)
    }
    elseif ($bytes.Length -ge 2 -and $bytes[0] -eq 0xFE -and $bytes[1] -eq 0xFF) {
        $text = [System.Text.Encoding]::BigEndianUnicode.GetString($bytes)
    }
    else {
        # まずBOMなしUTF-8として厳密に読む
        try {
            $utf8Strict = New-Object System.Text.UTF8Encoding($false, $true)
            $text = $utf8Strict.GetString($bytes)
        }
        catch {
            # 日本語Windowsのレガシー想定
            $text = [System.Text.Encoding]::GetEncoding(932).GetString($bytes)
        }
    }

    # 先頭BOMが文字として残った場合の保険
    return ($text -replace "^\uFEFF", "")
}

7.3 INI読み取り時のBOM対策

function Read-IniFileSafe {
    param([Parameter(Mandatory)][string]$Path)

    $content = Read-TextFileSafe -Path $Path
    $result = [ordered]@{}
    $section = ""

    foreach ($rawLine in ($content -split "`r?`n")) {
        $line = $rawLine.Trim()

        if ($line -eq "" -or $line.StartsWith(";") -or $line.StartsWith("#")) {
            continue
        }

        # [Monitor] の前にBOMが紛れた場合も除去
        $line = $line -replace "^\uFEFF", ""

        if ($line -match "^\[(.+)\]$") {
            $section = $Matches[1].Trim()
            if (-not $result.Contains($section)) {
                $result[$section] = [ordered]@{}
            }
            continue
        }

        if ($line -match "^\s*([^=]+?)\s*=\s*(.*)$") {
            if ($section -eq "") {
                $section = "Global"
                if (-not $result.Contains($section)) {
                    $result[$section] = [ordered]@{}
                }
            }
            $key = $Matches[1].Trim()
            $value = $Matches[2].Trim()
            $result[$section][$key] = $value
        }
    }

    return $result
}

7.4 出力時はエンコードを必ず明示

用途Windows PowerShell 5.1PowerShell 7
UTF-8 BOM付きログ Set-Content -Encoding UTF8 Set-Content -Encoding utf8BOM
UTF-8 BOMなしログ .NETの UTF8Encoding($false) を使う Set-Content -Encoding utf8NoBOM または utf8
CSVをExcelで開く Export-Csv -Encoding UTF8 を基本 Export-Csv -Encoding utf8BOM を基本
リダイレクト > は避ける。UTF-16LEになり得る。 UTF-8になりやすいが、重要ファイルでは明示。

7.5 Windows PowerShell 5.1でUTF-8 BOMなしを書きたい場合

function Write-Utf8NoBom {
    param(
        [Parameter(Mandatory)][string]$Path,
        [Parameter(Mandatory)][string]$Text
    )

    $enc = New-Object System.Text.UTF8Encoding($false)
    [System.IO.File]::WriteAllText($Path, $Text, $enc)
}

function Write-Utf8Bom {
    param(
        [Parameter(Mandatory)][string]$Path,
        [Parameter(Mandatory)][string]$Text
    )

    $enc = New-Object System.Text.UTF8Encoding($true)
    [System.IO.File]::WriteAllText($Path, $Text, $enc)
}
実装方針: 生成スクリプトでは、日本語ラベルは処理ロジックから分離し、最後の出力直前に付与するのが安全です。関数名、変数名、ハッシュキー、switch条件は英数字に寄せると、万一の文字化けでも構文破壊を避けやすくなります。

8. ZIPと日本語ファイル名の注意点

ZIPのファイル名は、ZIP作成ツールが「UTF-8ファイル名である」というフラグを正しく立てるか、展開ツールがそれを正しく読むかに依存します。PKWAREの仕様では、General Purpose Bit Flagのbit 11が立っている場合、ファイル名とコメントはUTF-8として扱われます。

事故が少ない運用

  • ZIP内のファイル名・フォルダ名は英数字、ハイフン、アンダースコアに統一。
  • 日本語の正式名称は README.html、manifest.csv、資料タイトルに記載。
  • 例:ApacheLogReport_20260605.zip、scripts/Export-ApacheReportToExcel.ps1

事故が起きやすい運用

  • ZIP内に 自作ツールPowerShell、ログ関連 など日本語フォルダ名を入れる。
  • 作成環境と展開環境でZIPツールが異なる。
  • AI生成ZIPをそのままサーバへ持ち込み、展開結果を確認せず実行する。

ZIP成果物の推奨構成

ApacheLogTool_20260613.zip
├─ README.html                  # 日本語説明はここに集約
├─ manifest.csv                 # 日本語名と英数字ファイル名の対応表
├─ scripts/
│  ├─ Monitor-ApacheLog.ps1     # UTF-8 BOM付き
│  └─ ApacheLogLib.psm1         # UTF-8 BOM付き
├─ conf/
│  └─ monitor.ini               # 仕様に応じてUTF-8 BOM付きまたはBOMなし
└─ sample/
   └─ apache_access_sample.log
ポイント: 「中身の日本語」と「ZIP内ファイル名の日本語」は別問題です。本文・ログ・HTML内の日本語は維持しつつ、ZIP上のファイル名だけ英数字にするのが実務上は最も安全です。

9. 症状別の原因と対処

症状 よくある原因 対処 恒久対策
繝ヲ繝シ... のような文字化け UTF-8の日本語をCP932/SJISとして読んだ。 元ファイルをUTF-8として開き直し、UTF-8 BOM付きで保存。 PowerShell 5.1用 .ps1 はUTF-8 BOM付きに統一。
PowerShellで ハッシュ リテラルのキーの後に '=' が存在しません 日本語のハッシュキーや文字列が壊れ、構文として読めなくなった。 文字コードを修正して再保存。可能ならキー名は英数字化。 日本語は表示用リソースへ分離し、ロジック部はASCII中心。
switch -Regex のケース行で構文エラー 日本語文字列・引用符・セミコロン等が文字化けし、ケース句として認識されない。 UTF-8 BOM付きで保存し直す。 VS CodeのPowerShell言語設定を utf8bom にする。
INIの [Monitor] が見つからない 先頭BOMが [ の前に不可視文字として混入。 読み取り時に ^\uFEFF を除去。 INI parserをBOM対応にし、設定ファイル仕様も明文化。
実行ログの日本語が文字化け 出力ファイルのエンコード、コンソールコードページ、閲覧エディタの解釈が不一致。 Set-Content/Add-Content に -Encoding を明示。 ログ標準をUTF-8 BOM付きまたはUTF-8 BOMなしのどちらかに決める。
Apache/Tomcat設定の解析スクリプトが失敗 conf/xmlがCP932、UTF-8 BOM付き、UTF-16LEなど混在。スクリプトがUTF-8固定で読んでいる。 安全な読み取り関数でBOM/UTF-8/CP932を判定。 設定ファイルの標準文字コードと変更手順をチームで統一。
ZIP展開後に日本語ファイル名が文字化け ZIP内ファイル名のUTF-8フラグ、作成ツール、展開ツールの解釈差。 英数字ファイル名に変更して再配布。 ZIP内ファイル名は英数字に統一し、日本語名はmanifestで管理。

10. チーム運用ルール・チェックリスト

10.1 文字コード標準ルール

ルール内容必須度
R-01 Windows PowerShell 5.1で実行する日本語入り .ps1/.psm1/.psd1 はUTF-8 BOM付き。 必須
R-02 Apache/Tomcatが直接読む設定ファイルはUTF-8 BOMなし、またはASCII中心。BOM付きで保存しない。 必須
R-03 日本語ファイル名をZIP内部に入れない。英数字名 + manifestで管理。 強く推奨
R-04 ファイル出力時は -Encoding または.NET Encodingを明示。> のみは禁止。 必須
R-05 本番反映前に先頭BOM・UTF-16LE・CP932混入をチェック。 必須
R-06 各エディタの既定文字コードを棚卸しし、手順書に記録。 推奨

10.2 本番反映前チェックリスト

確認対象OK条件
PowerShellスクリプトのBOM *.ps1 *.psm1 日本語入りなら先頭 EF BB BF。
Apache/Tomcat設定のBOM *.conf *.xml *.properties 原則BOMなし。UTF-16LEではない。
全角空白 conf、ini、ps1 ディレクティブ名・キー名・パス周辺に全角空白がない。
ZIP展開後ファイル名 成果物ZIP 展開後のファイル名が英数字で、文字化けがない。
PowerShell構文検査 *.ps1 powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\script.ps1 -WhatIf 等で構文エラーなし。
Apache構文検査 Apache設定 httpd.exe -t でSyntax OK。
Tomcat XML検査 Tomcat設定 起動前にバックアップ取得。XMLとして壊れていない。

10.3 一括検査用PowerShellサンプル

param(
    [string]$Root = "."
)

$targets = Get-ChildItem -LiteralPath $Root -Recurse -File |
    Where-Object { $_.Extension -in ".ps1",".psm1",".psd1",".conf",".ini",".xml",".properties",".csv",".log",".txt" }

$result = foreach ($f in $targets) {
    $bytes = [System.IO.File]::ReadAllBytes($f.FullName)
    $head = if ($bytes.Length -ge 4) { [BitConverter]::ToString($bytes[0..3]) } else { [BitConverter]::ToString($bytes) }

    $encoding = "UnknownOrNoBOM"
    if ($bytes.Length -ge 3 -and $bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) { $encoding = "UTF-8 BOM" }
    elseif ($bytes.Length -ge 2 -and $bytes[0] -eq 0xFF -and $bytes[1] -eq 0xFE) { $encoding = "UTF-16 LE" }
    elseif ($bytes.Length -ge 2 -and $bytes[0] -eq 0xFE -and $bytes[1] -eq 0xFF) { $encoding = "UTF-16 BE" }

    $warning = @()
    if ($f.Extension -in ".ps1",".psm1",".psd1" -and $encoding -ne "UTF-8 BOM") {
        $warning += "PowerShell script is not UTF-8 BOM"
    }
    if ($f.Extension -in ".conf",".xml",".properties" -and $encoding -match "UTF-16") {
        $warning += "Config file is UTF-16"
    }
    if ($f.Name -match "[^\x00-\x7F]") {
        $warning += "Non-ASCII file name"
    }

    [pscustomobject]@{
        Path     = $f.FullName
        Ext      = $f.Extension
        Encoding = $encoding
        Head     = $head
        Warning  = ($warning -join "; ")
    }
}

$result | Format-Table -AutoSize

10.4 AIへファイル作成を依頼する時の指定文例

以下のルールでファイルを作成してください。
1. ZIP内のファイル名・フォルダ名は英数字、ハイフン、アンダースコアのみ。
2. 日本語の説明はHTML/README本文に記載し、ファイル名には使わない。
3. PowerShellの .ps1/.psm1 は UTF-8 BOM付きで保存。
4. Apache/Tomcatが読む .conf/.xml は UTF-8 BOMなしで保存。
5. PowerShellスクリプト内の関数名・変数名・ハッシュキーは英数字中心。
6. 日本語ログや日本語列名が必要な場合は、出力直前に付与する。
7. ファイル出力時は必ず -Encoding または .NET Encoding を明示する。

11. 参考情報

このHTMLファイルについて: 本ファイル自体は UTF-8 BOM付き で保存しています。ブラウザ表示用に <meta charset="UTF-8"> も明記しています。