java 将 utf-8 源数据写入 shift_jis 文件时，全角长音符「ー」（u+ff0d）因不在标准 shift-jis 字符集中而被替换为问号「?」，本文详解其成因并提供兼容性编码、字符映射与安全转换三重解决方案。
java 将 utf-8 源数据写入 shift_jis 文件时，全角长音符「ー」（u+ff0d）因不在标准 shift-jis 字符集中而被替换为问号「?」，本文详解其成因并提供兼容性编码、字符映射与安全转换三重解决方案。
在 Java 中使用 Charset.forName("SHIFT_JIS") 进行文本写入时，若原始字符串包含 Unicode 字符 U+FF0D（FULLWIDTH HYPHEN-MINUS，即日文全角长音符「ー」），该字符并不属于标准 Shift-JIS（JIS X 0201 / JIS X 0208）定义的字符集。因此 JVM 在编码转换过程中无法找到对应字节序列（预期为 0x817C），默认采用 CodingErrorAction.REPLACE 策略，将其替换为 ?（ASCII 0x3F），导致输出文件中出现乱码。
验证这一点可通过命令行复现：
$ echo -en '\uFF0D' | iconv -t SHIFT-JIS iconv: illegal input sequence at position 0
这明确表明：标准 Shift-JIS 编码器拒绝编码 U+FF0D。
✅ 正确解决方案（三选一，推荐组合使用）
1. 使用扩展版 Shift-JIS（Windows-31J / MS932）
Windows-31J（别名 MS932）是 Windows 对 Shift-JIS 的超集扩展，原生支持 U+FF0D → 0x817C，且与绝大多数日本系统兼容：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
public class ShiftJisTest {
public static void main(String[] args) {
String text = "東１－１"; // 注意：此处使用的是 U+FF0D（全角「ー」），非 ASCII '-'
try (BufferedWriter writer = new BufferedWriter(
new OutputStreamWriter(
new FileOutputStream("output_data"),
Charset.forName("Windows-31J") // ✅ 替换为 Windows-31J
)
)) {
writer.write(text);
} catch (IOException e) {
e.printStackTrace();
}
}
}✅ 输出文件十六进制为 93 8C 82 50 81 7C 82 50，其中 81 7C 即为正确长音符编码。
2. 预处理：安全字符映射（兜底策略）
若必须使用严格 SHIFT_JIS（如遗留系统强制要求），可预先将不可编码字符映射为等效可编码字符：
public static String toShiftJisSafe(String input) {
return input.replace("\uFF0D", "\u30FC") // 全角长音符 → 片假名长音符「ー」（U+30FC，Shift-JIS 中编码为 0x817C）
.replace("\uFF0E", "\u30FB"); // 全角句点 → 中点（U+30FB，Shift-JIS 支持）
}
// 使用示例：
String safeText = toShiftJisSafe("東１－１");
// → "東１ー１"（视觉一致，编码可行）⚠️ 注意：U+30FC（KATAKANA-HIRAGANA PROLONGED SOUND MARK）在 Shift-JIS 中确实映射为 0x817C，且显示效果与 U+FF0D 几乎无差别，是行业通用替代方案。
3. 显式配置编码错误策略（不推荐单独使用）
避免静默替换，改用抛异常以暴露问题：
CharsetEncoder encoder = Charset.forName("SHIFT_JIS")
.newEncoder()
.onUnmappableCharacter(CodingErrorAction.REPORT); // 抛出 CharacterCodingException
try (OutputStreamWriter osw = new OutputStreamWriter(
new FileOutputStream("output_data"), encoder)) {
osw.write("東１－１"); // 此处将抛异常，便于定位问题字符
}? 关键总结
-
根本原因：U+FF0D 不在 JIS X 0208 标准 Shift-JIS 字符集中，仅存在于 Microsoft 扩展
Windows-31J； -
首选实践：生产环境一律使用
"Windows-31J"替代"SHIFT_JIS"，它向后兼容且覆盖全部常用日文符号； -
字符校验建议：对从数据库读取的 UTF-8 文本，在写入前用
Charset.isSupported()+encoder.canEncode()做预检； -
工具链提醒：确保编辑器、终端、查看器均以
Windows-31J解码该文件，否则仍可能显示异常。
通过以上任一方法，即可彻底解决全角长音符在 Shift-JIS 场景下的乱码问题，兼顾兼容性、可维护性与国际化健壮性。
