你的观察很有意思——明明系统和Office区域都是日语，默认应该用Shift-JIS（代码页932）导出CSV，却出现了字符丢失的情况。核心原因其实和Excel使用的编码范围以及你文件中的字符是否在该编码的支持范围内有关，具体拆解如下：

• Excel导出普通CSV确实用的是代码页932，但它的字符集有局限
  日文Windows的系统默认代码页是932（微软版Shift-JIS），Excel在导出非UTF-8的CSV时，确实会使用这个编码。但要注意：932的字符集范围远小于Unicode，它只覆盖了常用的日文汉字、假名、符号，对于一些扩展日文汉字、特殊符号、emoji，或者来自其他编码的罕见字符，932没有对应的编码映射，Excel就会把这些无法表示的字符替换成'?'。

• 你可能误解了“默认编码支持所有日文字符”
  很多人以为Shift-JIS能覆盖所有日文字符，但实际上并非如此。比如一些JIS X 0213标准中的汉字（比旧版JIS X 0208新增的那些）、或者Unicode私用区域的字符，都不在932的支持范围内。如果你的Excel文件里包含这类字符，导出时必然会被替换。

• Excel的导出逻辑：无法编码的字符直接丢弃替换
  当你选择“另存为CSV”时，Excel会检查每个字符是否能被当前代码页（这里是932）表示。如果不能，它不会尝试转义或者用其他方式保留，而是直接替换为'?'——这是Excel处理这类情况的硬规则，和区域设置无关，只要字符超出当前编码的范围就会触发。

你提到打开CSV时Excel默认用Shift-JIS 932打开，这也验证了导出的文件确实是932编码，问题出在字符本身无法被该编码表示，而不是Excel用了错误的编码导出。

内容的提问来源于stack exchange，提问作者Firebrandt