unmappable characterの直し方｜javacの文字コード

error: unmappable character (0x9E) for encoding windows-31j は、javac が、ソースファイルを指定とは違う文字コードで読もうとしたときのエラーです。 日本語の環境では、次のように表示されます。

W.java:1: エラー: この文字(0x9E)は、エンコーディングwindows-31jにマップできません

ソースファイルの文字コードと、javac に伝えている文字コードを合わせれば直ります。

確認環境：OpenJDK 8・11・17・21・25（Linux）で、-encoding を指定して再現しました。日本語のメッセージは -J-Duser.language=ja で表示しました（確認日 2026年10月11日）。

再現① UTF-8 のソースを windows-31j で読む

public class W { public static void main(String[] a){ System.out.println("日本語"); } }

UTF-8 で保存したこのファイルを、javac -encoding windows-31j W.java でコンパイルしました。

W.java:1: error: unmappable character (0x9E) for encoding windows-31j
public class W { public static void main(String[] a){ System.out.println("??????"); } }
                                                                               ^

どの版でもエラーで、class ファイルは作られませんでした。 (0x9E) は、windows-31j として読めなかったバイトの値です。コメントの中の日本語でも、同じエラーになりました（// 日本語のコメント → unmappable character (0x81)）。

エラーにならずに、文字化けすることがある（要注意）

同じ条件でも、文字によってはエラーにならず、文字化けしたまま class ファイルが作られました。

UTF-8 のバイトの並びが、たまたま windows-31j の文字として読めると、エラーにならずに別の文字に変わります。 画面や帳票に「縺」「繧」などが並んでいたら、この形を疑います。エラーが1つでも出たら、警告を消すのではなく、文字コードの指定を直すのが正しい対処です。

再現② Shift_JIS のソースを UTF-8 で読む（JDK 18 以降で起きやすい）

Shift_JIS（cp932）で保存したソースを、JDK 21 で文字コードを指定せずにコンパイルしました。

S.java:3: error: unmappable character (0x93) for encoding UTF-8
        System.out.println("???{??");
                            ^

JEP 400 により、JDK 18 から Java の既定の文字コードは UTF-8 になりました。 JEP 400 では、javac は -encoding を指定しない限り既定の文字コードでソースを読むと説明され、影響が大きいのは「アジアのロケールの Windows を使う人」とされています。以前の版の JDK で、Windows の既定（windows-31j）のまま書いてきたソースを、JDK 18 以降でコンパイルすると、このエラーになります。

長く使うプロジェクトなら、ソースを UTF-8 にそろえるほうが、ほかのツール（Git・IDE・CI）とも合わせやすくなります。

Maven・Gradle での指定

Maven

<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

maven-compiler-plugin の encoding の既定値は ${project.build.sourceEncoding} です（プラグインのドキュメント）。この1行で、javac に -encoding UTF-8 が渡ります。

Gradle

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8'
}

確認環境の Gradle 8.14.3 で options.encoding = 'windows-31j' にすると同じ unmappable character (0x9E) になり、'UTF-8' に直すとコンパイルできました。 Gradle のドキュメントでは、encoding を指定しない（null）と、プラットフォームの既定の文字コードが使われると説明されています。

IDE で動くのに、Maven・Gradle（CI）で止まるときは、ビルドの設定に文字コードが書かれていないことがあります。ビルドの書き方は、既存の記事「Mavenコマンド一覧｜pom.xml書き方とよく使うオプション」「build.gradle書き方｜Groovy/Kotlin DSL対訳と依存設定一覧」で扱っています。

確認の手順（チェックリスト）

よくある質問

Q. 実行したときの文字化け（System.out の表示）とは違いますか。 A. 違います。このエラーはコンパイルのときのものです。確認環境でも、正しくコンパイルできたあと、端末の文字コードによって表示が ??? になることがありました。表示の文字コードは、JDK 18 以降なら -Dstdout.encoding=UTF-8 で指定できました。

Q. ファイルを読むときの文字化けは。 A. 実行中にファイルを読むときの文字コードは別の話です。関連記事の「MalformedInputExceptionの直し方｜Java文字コード」で扱っています。

まとめ

• ソースファイルの文字コードと、javac の -encoding が違うエラー
• for encoding windows-31j は UTF-8 のソースを Shift_JIS 系で読んだ、for encoding UTF-8 はその逆
• 文字によってはエラーにならず「縺薙ｓ縺ｫ縺｡縺ｯ」のように化ける
• JDK 18 から既定が UTF-8（JEP 400）。以前の Shift_JIS のソースで止まる
• Maven は project.build.sourceEncoding、Gradle は options.encoding

参考・出典

確認日はいずれも 2026年10月11日です。

• JEP 400「UTF-8 by Default」：https://openjdk.org/jeps/400
• Apache Maven Compiler Plugin「compiler:compile」（encoding）：https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
• Gradle DSL Reference「CompileOptions」（encoding）：https://docs.gradle.org/current/dsl/org.gradle.api.tasks.compile.CompileOptions.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。