Visual Studioで日本語が文字化けする、UTF-8とShift_JISが混在する、WindowsとLinuxで改行コードの差分が増える――こうした問題は、保存時のエンコード、開く時のエンコード、チーム全体の既定ルールを分けて管理すると大きく減らせます。
2026年4月24日のMicrosoft公式GitHub履歴では、該当ドキュメントにメタデータ・所有者関連の更新が入っています。一方、Microsoft Learnページ上の表示では最終更新日は2026年3月12日のままです。つまり今回のポイントは「Visual Studioに突然新機能が追加された」というより、エンコード保存・既定エンコード・エンコード指定で開く手順を、開発チームの運用に落とし込むことにあります。(GitHub)
Visual Studioの最新動向: Save and open files with encodingで何が変わったか
Microsoft Learnの「Save and open files with encoding」は、Visual Studioで特定の文字エンコードを使ってファイルを保存する方法と、ファイルを開くときにエンコードを指定する方法を説明している公式ドキュメントです。Visual Studioでは、双方向言語のサポートや文字化け回避のために、ファイル保存時・読み込み時のエンコード指定が重要になります。(Microsoft Learn)
2026年4月24日のGitHub履歴を見ると、同ページには「自動挿入されたdocfxメタデータの削除」と「所有者情報の更新」に関するコミットが入っています。実務上は、IDEの挙動変更というより、公式手順を再確認するための更新と捉えるのが安全です。(GitHub)
開発者、DevOpsエンジニア、platform teamが特に見るべきポイントは次の4つです。
| 確認ポイント | 実務上の意味 | 取るべき対応 |
|---|---|---|
| エンコードウィジェットから保存できる | 開いているファイルをすばやく別エンコードで保存できる | 文字化け修正や単発変換に使う |
| Save with Encodingが使える | 名前を付けて保存しながらエンコードと改行コードを指定できる | 変換前後のファイルを分けて検証する |
| 既定の保存エンコードを設定できる | 新規作成・保存時のばらつきを減らせる | チーム標準がある場合に設定する |
| Open Withから開く時のエンコードを指定できる | 誤検出されたファイルを正しく開ける | 文字化けしたまま保存しない |
Visual Studio 2022 version 17.13のリリースノートでは、保存時の既定エンコードを指定できる機能が「Customize file encoding」として説明されています。チェックを外した場合はVisual Studioの既定動作に任され、チェックした場合は指定したエンコードを可能な範囲で使用します。指定したエンコードで保存できない場合は、Visual Studioがダイアログで通知する説明もあります。(Microsoft Learn)
Visual Studioでエンコード管理が重要になる場面
エンコードは、普段は意識されにくい設定です。しかし一度ずれると、文字化けだけでなく、ビルド失敗、レビュー不能な巨大差分、API連携エラー、海外拠点との開発トラブルにつながります。
特に注意したいのは、次のようなケースです。
- 日本語コメント、リソースファイル、SQL、CSV、設定ファイルを扱う
- 既存の業務アプリでShift_JIS、Windows-31J、CP932系のファイルが残っている
- Windows開発者とLinux/macOS開発者が同じリポジトリを触る
- Visual Studio、VS Code、JetBrains系IDEなど複数エディターを併用している
- グローバルチームで右から左へ書く言語、アクセント付き文字、多言語UIを扱う
- CI/CDでファイル生成、コード生成、静的解析を実行している
新規プロジェクトならUTF-8を基本候補にしやすいですが、レガシー環境では「とにかくUTF-8へ変換すればよい」とは限りません。既存ツール、帳票、外部システム、コンパイラ設定、データ取り込み先が特定の文字コードを前提にしている場合があるためです。
ファイル単位でエンコードを指定して保存する手順
開いているファイルだけをエンコード指定で保存したい場合は、Visual Studioのエディター右下にあるエンコードウィジェットを使います。
| 手順 | 操作 |
|---|---|
| 1 | エディター下部の右下にあるエンコードウィジェットをクリックする |
| 2 | Save with Encoding、日本語UIでは「エンコードで保存」に相当する項目を選ぶ |
| 3 | 表示されたダイアログで保存したいエンコードを選ぶ |
| 4 | OKを選んで保存する |
Microsoft Learnでは、この手順でファイルを保存できること、使用可能なエンコードのドロップダウンが表示されることが説明されています。(Microsoft Learn)
この操作は、文字化けしたファイルを直すときや、特定のファイルだけUTF-8に変換したいときに便利です。ただし、文字化けした状態で上書き保存しないことが重要です。誤ったエンコードで開いた内容を保存すると、元のバイト列が失われ、復元が難しくなる場合があります。
安全に作業するなら、次の順序にします。
- まずGitで作業ツリーがクリーンな状態か確認する
- 対象ファイルを開き、文字化けしていないか確認する
- 必要なら別エンコードで開き直す
Save with Encodingで保存する- 差分を確認し、文字の置換や余計な改行変更がないか見る
- ビルド、テスト、画面表示、データ取り込みを確認する
名前を付けて保存しながらエンコードと改行コードを指定する
既存ファイルをそのまま上書きするのが不安な場合は、名前を付けて保存する方法が向いています。Visual Studioでは、File > Save <Filename> Asから保存ダイアログを開き、保存ボタンのドロップダウンでSave with Encodingを選択できます。続く詳細保存オプションで、エンコードと行末文字を指定できます。(Microsoft Learn)
| 指定項目 | 何を決めるか | 使いどころ |
|---|---|---|
| Encoding | UTF-8、UTF-16、各種コードページなどの文字エンコード | 文字化け回避、既存システムとの互換性確保 |
| Line endings | CRLF、LFなどの行末形式 | Windows/Linux/macOS間の差分抑制 |
行末形式の指定は、異なるOSのユーザーとファイルをやり取りする場合に便利だとMicrosoft Learnでも説明されています。(Microsoft Learn)
実務では、エンコード変更と改行コード変更を同じコミットに混ぜないことをおすすめします。両方を一度に変えると、レビュー画面ではファイル全体が変更されたように見え、実際の修正箇所が分からなくなります。
おすすめは次の分け方です。
| コミット | 内容 |
|---|---|
| 1つ目 | エンコード・改行コードの正規化だけを行う |
| 2つ目 | 実際のコード修正、文言修正、機能修正を行う |
この分け方にすると、レビュー担当者は「変換だけの差分」と「ロジック変更」を別々に確認できます。
既定のエンコードを設定してチーム内のばらつきを減らす
ファイル単位の変換だけでは、チーム全体のばらつきは防ぎきれません。新規ファイルを作るたびに開発者ごとの設定が反映されると、UTF-8、BOM付きUTF-8、Shift_JISなどが混在する可能性があります。
Visual Studioでは、保存時の既定エンコードを設定できます。Microsoft Learnでは、Tools > OptionsからEnvironment > Documentsを開き、Save files with a specific encodingに相当するチェックボックスを有効にして、保存エンコードを選ぶ手順が説明されています。Visual Studio 2022 version 17.13 Preview 1以降では、同様に保存時の既定エンコードを設定できるとされています。(Microsoft Learn)
日本語UIでは表示名がバージョンや言語パックで少し異なる場合がありますが、探す場所はおおむね次の流れです。
| 目的 | 操作の目安 |
|---|---|
| 既定エンコードを設定する | ツール > オプション > 環境 > ドキュメント |
| 設定を有効にする | 「特定のエンコードでファイルを保存する」に相当する項目をオンにする |
| エンコードを選ぶ | 「保存エンコード」に相当するドロップダウンから選択する |
| 反映する | OKで保存する |
ただし、この設定だけで既存ファイルが一括変換されるわけではありません。既存ファイルの変換は、ファイル単位で保存し直すか、別ツールを使って計画的に行う必要があります。
エンコード指定でファイルを開く手順
文字化けしているファイルを修正する時に最も危険なのは、「文字化けしたまま保存する」ことです。まず正しいエンコードで開けているかを確認しましょう。
プロジェクト内のファイルをエンコード指定で開く場合は、ソリューションエクスプローラーで対象ファイルを右クリックし、Open With、日本語UIでは「プログラムから開く」に相当する項目を選びます。エンコード指定に対応したエディターを選ぶと、エンコード選択ダイアログから使用するエンコードを指定できます。(Microsoft Learn)
プロジェクト外のファイルを開く場合は、File > Open > Fileからファイルを選び、OpenボタンのドロップダウンでOpen Withを選択します。その後は、プロジェクト内ファイルと同じようにエンコードを指定します。(Microsoft Learn)
多くのVisual Studioエディターはエンコードを自動検出できますが、自動検出は万能ではありません。特にBOMなしUTF-8、Shift_JIS系、古い生成ファイル、外部システムから受け取ったCSVでは、目視確認が欠かせません。
文字化けを見つけた時の安全な対応
| 状況 | やってはいけないこと | 安全な対応 |
|---|---|---|
日本語が���や不自然な記号になっている | そのまま保存する | 保存せず閉じ、別エンコードで開き直す |
| 一部の文字だけ化けている | 目視で手修正して保存する | 元ファイルのエンコードと変換履歴を確認する |
| 文字化けと改行差分が同時に出た | まとめてコミットする | エンコード変換と改行変更を分ける |
| CIでだけ失敗する | ローカル表示だけで判断する | ビルド環境のOS、コンパイラ、読み込みツールを確認する |
どのエンコードを選ぶべきか
エンコード選びに絶対解はありません。判断基準は「そのファイルを誰が、どのツールで、どの環境から読むか」です。
| ファイル・用途 | 基本方針 | 注意点 |
|---|---|---|
| 新規のソースコード | UTF-8を第一候補にする | BOM有無はチーム規約に合わせる |
| C#、JavaScript、TypeScript、JSON、YAMLなど | UTF-8で統一しやすい | 外部ツールがBOMを嫌う場合がある |
| 既存の日本語業務アプリ | 既存エンコードを確認してから変更する | Shift_JIS、CP932前提のツールが残っている場合がある |
| CSV | 取り込み先の仕様を優先する | Excel、API、バッチ処理で期待値が違うことがある |
| XML、HTML | ファイル内の宣言と実際のエンコードを一致させる | 宣言だけUTF-8で中身が別エンコードだと事故になりやすい |
| C++ソース | 保存エンコードとコンパイラ設定をセットで見る | /utf-8はソース文字セットと実行文字セットをUTF-8に指定するオプションとして説明されている |
C++では、ファイル保存時のエンコードだけでなく、MSVCの文字セットオプションも確認が必要です。Microsoft Learnでは、/utf-8が/source-charset:utf-8と/execution-charset:utf-8を指定するのと同等であると説明されています。(Microsoft Learn)
DevOps・platform teamは.editorconfigでルール化する
個人のVisual Studio設定だけでは、チーム全体の一貫性は担保できません。複数のIDE、複数OS、CI/CDを含む開発では、リポジトリ側にルールを置くことが重要です。
Visual Studioは.editorconfigをサポートしており、.editorconfigの設定はVisual Studioのグローバルなテキストエディター設定より優先されます。また、Visual Studioではcharset、end_of_line、indent_style、indent_sizeなどのEditorConfigプロパティがサポートされています。(Microsoft Learn)
たとえば、リポジトリ全体をUTF-8とLFで統一したい場合は、次のような設定を検討できます。
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = trueWindows中心の.NET業務アプリでCRLFを維持したい場合は、次のようにします。
root = true
[*]
charset = utf-8
end_of_line = crlf
insert_final_newline = trueただし、.editorconfigは置けば終わりではありません。Microsoft Learnでは、EditorConfigを追加しても既存コードのスタイルは自動的には変換されず、Format DocumentやCode Cleanupを実行するまで既存スタイルは変わらないと説明されています。(Microsoft Learn)
エンコード運用でも同じ発想が必要です。ルールを追加した後は、既存ファイルをいつ、どの範囲で、どのコミットで変換するかを決めましょう。
既存リポジトリでエンコードを整理する手順
既存プロジェクトでは、いきなり全ファイルをUTF-8に変換するのは危険です。安全に進めるなら、次の流れにします。
| フェーズ | 作業 | 確認ポイント |
|---|---|---|
| 調査 | 対象拡張子と現在のエンコードを洗い出す | .cs、.cpp、.sql、.config、.csvなどを分ける |
| 方針決定 | UTF-8化する範囲と維持する範囲を決める | 外部システム、帳票、古いツールの依存を確認する |
| 検証 | 小さなブランチで一部ファイルを変換する | ビルド、テスト、画面表示、データ取り込みを確認する |
| ルール化 | Visual Studio設定や.editorconfigを整える | 新規ファイルが同じ形式で作られるか確認する |
| 本番反映 | 変換だけのPRを作る | ロジック変更を混ぜない |
| 定着 | コーディング規約やレビュー観点に追加する | 新規ファイルのエンコードをレビューで見る |
ポイントは、変換作業をリファクタリングや機能修正と混ぜないことです。エンコード変換は見た目以上に影響範囲が広いため、単独のPRにして、問題があれば戻せるようにしておくべきです。
よくある失敗と回避策
文字化けしたファイルをそのまま保存してしまう
最も避けたい失敗です。文字化けは表示だけの問題に見えても、保存した時点で内容が破壊される場合があります。
対策はシンプルです。文字化けを見つけたら、編集せずに閉じます。その後、Open Withから別のエンコードで開き直し、正しく表示される状態を確認してから保存します。
既定エンコードを変えたのに既存ファイルが直ったと思い込む
既定エンコード設定は、主に今後の保存や新規ファイルのばらつきを減らすためのものです。すでに存在するファイルの中身を自動で安全に変換する万能機能ではありません。
既存ファイルは、対象を絞って変換し、差分と動作確認を行う必要があります。
UTF-8 BOM付きとBOMなしを区別していない
UTF-8にはBOM付きとBOMなしがあります。どちらが正しいかは、プロジェクトと利用ツールによって異なります。
たとえば、あるツールではBOM付きの方が判定しやすく、別のCLIやパーサーではBOMが問題になることがあります。チームで「UTF-8」とだけ書くのではなく、必要なら「UTF-8 without BOM」「UTF-8 with BOM」まで明記しましょう。
プロジェクトファイルを通常ファイルと同じように保存しようとする
Microsoft Learnでは、プロジェクトファイルをエンコード付きで保存するには、先にプロジェクトをアンロードする必要があると説明されています。プロジェクトをアンロードするまで、Save File Asに相当するオプションは有効になりません。(Microsoft Learn)
.csproj、.vbproj、.vcxproj、.props、.targetsなどを扱う場合は、IDE上での操作だけでなく、変更後のビルド確認も必ず行いましょう。
エンコード変更と自動整形を同時に実行する
エンコード変換、改行コード変更、インデント整形、コードクリーンアップを同時に行うと、差分が大きくなりすぎます。
レビューしやすくするには、次のように分けます。
- エンコード・改行コードの整理
- フォーマット整形
- 実際のコード修正
この順番にすると、問題が起きた時に原因を切り分けやすくなります。
グローバル開発での実務判断基準
海外拠点やOSS、オフショア開発を含むチームでは、「自分のVisual Studioで読めるか」だけでは不十分です。
次の観点で決めると、後から揉めにくくなります。
| 観点 | 確認すること |
|---|---|
| 利用OS | Windowsだけか、Linux/macOSも使うか |
| 利用IDE | Visual Studioだけか、VS Codeや他IDEも使うか |
| ビルド環境 | CIがWindowsかLinuxか、コンテナか |
| 外部連携 | CSV、XML、SQL、設定ファイルを外部システムが読むか |
| 言語 | 日本語、中国語、韓国語、アラビア語、ヘブライ語などを含むか |
| 既存資産 | 古いツールや帳票が特定コードページを前提にしていないか |
原則として、新規コードはUTF-8を標準にしやすいです。一方で、既存資産が多いプロジェクトでは、全体方針と例外ルールを分けて定義する方が現実的です。
例としては、次のようなルールです。
- 新規ソースコードはUTF-8 without BOM
- 既存の帳票テンプレートは当面Shift_JISを維持
- CSVは連携先仕様に従う
- XMLは宣言と実ファイルのエンコードを一致させる
- 変換作業は機能修正と別PRにするこの程度まで明文化しておくと、レビュー時の判断がぶれにくくなります。
まず取るべきアクション
Visual Studioのエンコード設定で最初にやるべきことは、全ファイルを一気に変換することではありません。まずは、チームの現状を見える化することです。
最初の1時間でできる作業は次の通りです。
- 文字化けやエンコード混在が起きているファイル種別を洗い出す
- Visual Studioの
Tools>Options>Environment>Documentsで既定エンコード設定を確認する - 代表的なファイルを
Save with Encodingで保存できるか試す - 文字化けするファイルを
Open Withからエンコード指定で開けるか確認する .editorconfigでcharsetとend_of_lineを管理するか検討する- エンコード変換だけの小さな検証PRを作る
今回のMicrosoft公式ソースの更新ポイントは、派手な新機能ではなく、Visual Studioのエンコード管理を開発プロセスに組み込む重要性を再確認できる点にあります。個人設定、ファイル単位の保存、開く時の指定、リポジトリルールを組み合わせれば、文字化けや不要な差分に振り回される時間を減らせます。
まずは1つのリポジトリで、標準エンコード、BOM有無、改行コード、例外ファイルを決めてください。そのうえで、Visual Studioの既定エンコード設定と.editorconfigを揃えるのが、チーム開発で最も再現性の高い対策です。
コメント