将日本银行对账单转换为 Excel (三菱UFJ、三井住友、瑞穗等)

您从三菱UFJ银行获取的 取引明细 (交易明细) 在 PDF 中看起来结构非常完美。但如果在日本以外的地区使用 Excel 打开它，问题就会接踵而至：汉字变成了乱码 (mojibake/文字化け)；令和年号日期“令和8年3月2日”对您的英文电子表格毫无意义；半角片假名付款人姓名（如“ﾔﾏﾀﾞ ﾀﾛｳ”）变成了无法读取的符号；而全角数字“１２３，４５６”则无法进行计算，因为它们与半角等效数字在 Unicode 中是不同的字符。

问题的核心在于：日本银行业运行在假设系统为日语环境的字符编码和格式规范之上。全银 (Zengin) 跨行支付网络——每天处理约 650 万笔交易和 12 万亿日元——历史上要求所有姓名使用半角片假名，这一遗产至今仍体现在现代银行对账单上。当您将这些数据移动到非日语系统的计算机时，编码错误几乎是必然的。

无论您是居住在东京、需要处理三菱UFJ账单以进行母国税务申报的外国居民，还是将客户数据导入 freee 或 Money Forward 的税理士 (税务会计师)，亦或是整合日本子公司数据的跨国企业，或者是管理“青色申报” (Blue Return) 账目的自由职业者——核心问题都是相同的：如何从日本银行对账单 PDF 中提取结构化、可直接用于电子表格的数据。

本指南涵盖了日本账单的特定格式挑战、您会遇到的主要银行，以及如何准确地转换它们。

为什么日本银行对账单在 Excel 中会出错

日本银行对账单带来了一系列独特的挑战，这些挑战超出了简单的数字格式。问题涵盖了字符编码、计数系统、日期惯例和遗留的跨行格式。

1. Shift_JIS 与 UTF-8 编码 (文字乱码)

这是在日本境外处理日本财务数据的单体最大问题。

大多数日本银行导出的 CSV 文件使用 Shift_JIS (代码页 932)——这是一种早于 UTF-8 的编码标准，仅涵盖日语字符。当您在预期 UTF-8 的系统上打开 Shift_JIS 文件时，每个日语字符都会变成乱码。日语中有一个专门的词来形容这种现象：文字化け (mojibake)，字面意思是“文字转化”。

您应该看到的	UTF-8 显示的
振込 カ）ヤマダ タロウ	振込 カ）ヤマダ
三菱UFJ銀行	三è±UFJ銀行
口座振替 電気代	å£åº§æŒ¯æ›¿ 電気代

反之亦然：在日语环境的 Excel 中打开 UTF-8 文件也可能产生不同的乱码输出。

由于 Shift_JIS 文件没有字节顺序标记 (BOM)，即没有告诉软件应使用哪种编码的文件头，问题变得更加复杂。自动检测是不可靠的，尤其是当文件中混合了日语字符和拉丁文本时（所有银行对账单都是如此）。

2. 全角与半角字符 (全角 vs. 半角)

这是日本特有的现象，几乎会让所有非日本开发人员措手不及。

日语计算中对许多字符使用两种宽度。全角字符 (全角) 占用两个拉丁字符的空间；半角字符 (半角) 占用一个空间。

全角 (全角)	半角 (半角)	是否为相同字符？
１２３，４５６	123,456	数字相同，字节不同
カード	ｶｰﾄﾞ	词义相同（“卡”），编码不同
，（逗号）	, (逗号)	标点相同，字节不同
（空格）	(空格)	空格相同，字节不同

单元格中包含的“１２３，４５６”（全角）在屏幕上看起来与“123,456”完全一样，但 Excel 会将全角版本视为文本而非数字。您无法对其进行求和 (SUM)、排序或在公式中使用。标准的逗号查找替换也无法匹配全角逗号。

银行对账单可能会混合使用不同宽度：金额可能是半角，而描述则使用全角字符。转换器必须将所有内容规范化为一致的半角形式以便计算。

3. 来自 Zengin 系统的半角片假名

全银 (Zengin) 跨行支付清算系统——日本国内支付的中枢——历史上要求所有姓名必须以 半角片假名 (半角カナ) 传输，且限制在 20 个字符以内。

这产生了一个特定问题：在您的银行对账单上，转账付款人姓名显示为类似于 ﾔﾏﾀﾞ ﾀﾛｳ 的形式，而不是 山田 太郎 (Yamada Taro)。即使是日本母语者也会觉得半角片假名难以阅读。

更糟糕的是：在半角片假名中，浊音符号 (dakuten) 是独立字符。全角字符“ガ” (ga) 是单个字符，但在半角中它变成了两个：“ｶﾞ” (ka + 浊音符)。这会使包含浊音的姓名长度翻倍，并破坏任何依赖字符位置计数的文本处理。

4. 日本年号日期 (和历)

日本在公历之外还使用自己的年号历法。当前的年号是 令和 (Reiwa)，始于 2019 年 5 月 1 日。

日本年号日期	对应公历
令和8年3月2日	2026年3月2日
R8.03.02	2026年3月2日
令和7年12月15日	2025年12月15日

英文 Excel 没有日本年号的概念。它无法将“令和8年”解析为 2026 年。即使是缩写格式“R8.03.02”也无法识别。

好消息是：日本使用 年-月-日顺序（从大到小），符合 ISO 8601 标准。当账单使用西历日期时，它们显示为 2026/03/02——比欧洲的 DD/MM/YYYY 格式更少歧义。挑战纯粹在于使用年号日期时。

年号交替问题： 2019 年的历史账单可能跨越平成到令和的过渡期（平成结束于 2019 年 4 月 30 日）。同一年 2019 年既是平成 31 年也是令和 1 年。转换器必须正确处理这两个年号。

5. 整数货币 (无小数)

日元没有子单位——没有“分”。日本银行对账单上的所有金额都是整数：¥1,234,567 确切代表 1,234,567 日元。

这实际上简化了转换的一个方面（无需处理小数点），但也引入了其他特点：

• 大数字是常态。 典型的月薪为 300,000-500,000 日元。房租可能是 80,000-200,000 日元。数字经常达到六位或七位。
• “万”单位思维。 日本人以“万” (man, 10,000) 为单位思考。3,000,000 日元的薪水在心理上是“300万日元”。但银行对账单显示完整数字。
• 账单上每 3 位一个逗号——尽管日语计数系统是按 4 位分组的（万 = 10,000，亿 = 100,000,000）。财务文件遵循国际惯例。

6. 独立的存入和支出列

与使用单一金额列（正数代表贷方，负数代表借方）的西方银行对账单不同，日本账单通常使用两个独立的列：

• 入金 (nyūkin) —— 存入/贷方
• 出金 (shukkin) —— 支出/借方

每笔交易中总有一列是空的。在转换为 Excel 时，您需要决定：保留两列格式，还是合并为带正负号的单一金额列？无论哪种选择，转换器都需要理解日本的列结构。

---

主要日本银行及其对账单

三菱UFJ银行 (MUFG)

按资产计算是日本最大的银行（约 2.9 万亿美元），拥有约 5700 万个个人存款账户。隶属于三菱日联金融集团。通过网上银行提供 PDF 账单和 CSV 导出（企业用 BizSTATION，个人用 三菱UFJ Direct）。CSV 导出使用 Shift_JIS 编码。

三井住友银行 (SMBC)

日本第二大商业银行，拥有约 2700 万零售客户。隶属于三井住友金融集团。网上银行 (SMBC Direct) 提供 PDF 和 CSV 下载。

瑞穗银行 (Mizuho)

第三大巨型银行，拥有约 2400 万零售客户和 1260 万网上银行订户。网上银行 (瑞穗 Direct) 提供交易下载。

日本邮政银行 (ゆうちょ銀行)

按账户数量计算是最大的银行，拥有约 1.2 亿个客户账户，总资产超过 205 万亿日元。通过约 24,000 个网点（主要是代办邮局）运营。触角延伸至日本几乎每个市镇。“Yucho Tsucho”应用程序提供数字存折访问。其独特的账号系统与标准日本银行账号不同。

乐天银行 (Rakuten Bank)

日本最大的网上银行，拥有 1760 万+ 账户，存款超过 13 万亿日元。存款年增长率为 16.5%，而巨型银行为 3.8%。全数字化，具备 CSV 导出功能。

地方银行 (Regional Banks)

日本拥有约 97 家地方银行——61 家第一级地方银行和 36 家第二级地方银行。每个县通常至少有一家总部设在其首府城市的地方银行。例如：横滨银行 (横浜銀行)、千叶银行 (千葉銀行)、静冈银行 (静岡銀行)。不同地方银行的账单格式差异很大。

SBI 新生银行 / 索尼银行

SBI 新生银行 和 索尼银行 因提供英文网上银行而闻名——这在日本非常罕见。因此深受外国居民欢迎。两者均提供 PDF 和 CSV 导出。

---

方法 1：使用 PDFSub (推荐)

PDFSub 原生支持处理日本银行对账单——包括上述所有的编码和格式挑战。

工作原理

1. 上传您的 取引明细书 —— 拖放来自任何日本银行的 PDF。PDFSub 会从 20,000 多个支持的模板中自动检测银行格式。

2. 自动格式处理 —— 转换器会自动：

   • 检测并将 Shift_JIS 编码转换为 UTF-8
   • 将全角数字 (１２３) 规范化为半角 (123) 以便计算
   • 将全角逗号、空格和标点符号转换为标准字符
   • 将日本年号日期 (令和8年3月2日) 解析为标准日期 (2026-03-02)
   • 将半角片假名付款人姓名转换为易读的全角字符
   • 合并存入/支出列或保留为独立列
   • 识别日语银行术语（振込、振替、口座振替等）

3. 查看并验证 —— 在预览中检查提取的交易。余额会根据账单的期初和期末 残高 (余额) 进行验证。

4. 下载 —— 导出为 Excel (.xlsx)、CSV (UTF-8)、QBO (QuickBooks)、OFX (Xero, Wave)、QFX (Quicken) 或 JSON。

为什么 PDFSub 适用于日本账单

支持包括日语在内的 133 种语言。 提取引擎理解日语银行术语——振込、振替、入金、出金、口座振替、手数料、利息——并将其映射到结构化字段。

自动处理编码。 无需手动检测或在 Shift_JIS 和 UTF-8 之间转换。PDFSub 识别编码并将其规范化为 UTF-8，妥善处理汉字、平假名、片假名和混合宽度字符。

支持所有主要的日本银行。 从三大巨型银行（三菱UFJ、三井住友、瑞穗）到拥有 1.2 亿账户的日本邮政银行、乐天银行、遍布 47 个都道府县的地方银行，以及像 SBI 新生银行和索尼银行这样对英文友好的银行。

浏览器优先的隐私保护。 对于来自网上银行的数字 PDF，文本提取完全在您的浏览器中完成。文件永远不会离开您的设备。服务器端处理仅用于扫描文档或存折照片。

全角规范化。 数字、逗号、空格和标点符号都会自动从全角规范化为半角——确保在电子表格中金额被视为数字而非文本。

---

方法 2：银行的 CSV 导出

大多数主要的日本银行通过网上银行提供 CSV 交易下载。以下是您可以预期的内容：

您将获得什么

• 编码： 几乎总是 Shift_JIS (而非 UTF-8)
• 分隔符： 标准逗号 (,)
• 日期格式： CSV 中通常为 YYYY/MM/DD (西历)，尽管有些银行使用年号日期
• 列： 通常为 日付 (日期)、摘要 (描述)、入金額 (存入金额)、出金額 (支出金额)、残高 (余额)

局限性

Shift_JIS 编码。 在任何非日语系统上打开该 CSV 都会产生乱码。您需要在导入时显式设置编码：在 Excel 中，使用 数据 → 获取数据 → 来自文本/CSV → 选择“日语 (Shift-JIS)”编码。

半角片假名姓名。 付款人/收款人姓名将以来自 Zengin 系统的半角片假名显示。即使对于日本母语者来说，这些也很难阅读，对于非日语使用者来说则完全无法理解。

历史记录有限。 网上银行 CSV 导出通常涵盖 3-12 个月。更长的历史记录需要分别下载每个时段的账单。

没有标准化格式。 与德国的 CAMT.053/MT940 或法国的 CAMT.053/FEC 标准不同，日本银行 CSV 没有通用格式。每家银行使用自己的列顺序、命名和结构。

描述中的全角字符。 交易描述可能包含全角数字和标点符号，在分析前需要进行规范化。

---

方法 3：手动复制粘贴 (不推荐)

对于日本账单，手动操作的问题非常严重：

• 汉字和片假名字符在应用程序之间粘贴时可能无法正确显示
• 编码转换会静默失败——看起来正确的字符可能是错误的 Unicode 码位
• 全角数字粘贴后作为文本无法计算
• 半角片假名姓名可以粘贴，但在非日语系统上无法阅读
• 年号日期在英文 Excel 中无法自动转换为公历日期
• 独立的存入/支出列需要手动合并
• 无法针对期初/期末余额进行验证

对于任何数量的交易，这种方法都是不切实际的。

---

您应该了解的日本金融系统

全银系统 (Zengin System)

日本核心的国内跨行支付清算网络，成立于 1973 年。连接了日本几乎所有的私人银行，每天处理约 650 万笔交易，总额约 12 万亿日元。

Zengin 文件格式 使用固定宽度的 120 字节记录，姓名使用半角片假名编码。这种遗留格式就是为什么银行对账单上的付款人/收款人姓名显示为半角片假名而非汉字的原因。较新的 ZEDI (Zengin EDI) 系统支持完整汉字，并正在向符合 ISO 20022 的 XML 消息传递转型，但遗留格式在许多账单上依然存在。

青色申报 (Blue Return) vs. 白色申报 (White Return)

日本的税务申报有两个级别：

特性	青色申报 (青色申告)	白色申报 (白色申告)
申请	必须提前申请	默认状态
记账	详细的双重分录	简单的收入/支出
特别扣除	最高 650,000 日元 (配合 e-Tax)	无
亏损结转	是，最长 3 年	否

获得较大税收减免的青色申报者被要求保持详细的财务记录，这使得准确的银行对账单转换对他们的记账至关重要。

合格发票制度 (インボイス制度)

该制度于 2023 年 10 月 1 日启动，要求企业注册为“合格发票发行人”，以便开具用于消费税抵扣的有效发票。此前，年纳税销售额在 1000 万日元以下的企业免征消费税。这一变化显著增加了小企业和自由职业者对准确财务记录的需求。

日本会计软件

软件	关键统计数据	目标群体
freee	约 600,000 订户	中小企业、自由职业者、初创公司
Money Forward	279.6 亿日元 SaaS ARR	中小企业、个人
弥生 (Yayoi)	连续 24 年桌面会计软件第 1 名	中小企业、个体经营者
TKC	服务约 11,500 家税理士事务所	税理士事务所

所有三大主流云平台（freee、Money Forward、Yayoi Online）都支持银行交易数据的 CSV 导入。PDFSub 的 Excel 和 CSV 导出可以直接导入这些工具。

---

谁需要日本银行对账单转换？

税理士 (税务会计师)。 截至 2025 年 12 月，日本约有 82,276 名注册税理士。他们处理客户的银行对账单用于记账、税务申报和审计准备。仅 TKC 全国联合会就有 11,500 家会员事务所。

外国居民。 截至 2025 年 6 月，有 396 万外国居民居住在日本——几乎是 2012 年数字的两倍。大多数银行对账单完全是日语，没有英文选项。外国居民需要转换后的账单用于母国税务申报、签证续签以及向海外机构发送财务证明。

申报青色申报的自由职业者。 维持青色申报 (青色申告) 状态的自雇人士和自由职业者必须保持详细的双重分录记账记录。将银行对账单转换为 Excel 是对业务支出进行分类和计算 650,000 日元特别扣除的起点。

跨国企业。 拥有日本子公司的公司需要将日本银行业务数据与全球会计系统整合。三大巨型银行共同担任 19.3% 日本公司的主力银行，企业银行业务通常通过三菱UFJ的 BizSTATION 或类似门户运行。

学生和打工度假签证持有者。 2024 年日本接待了超过 3000 万国际游客。长期学生和打工度假签证持有者会开设日本银行账户（通常是在最容易办理的日本邮政银行），在管理财务或在母国报税时需要处理对账单。

---

在 Excel 中处理日本财务数据的技巧

首先检查乱码。 如果任何日语文本显示为乱码字符（ä, â€, é 等），说明文件是以错误的编码打开的。请使用 Shift_JIS 编码重新导入，或使用 PDFSub 的 UTF-8 Excel 导出来完全避免此问题。

验证数字类型。 导入后，测试金额是否为实际数字：点击单元格并检查 Excel 在编辑栏中是否显示数字，或者对一列尝试使用 =SUM()。如果 SUM 返回 0 但单元格显示数字，则说明这些值是伪装成数字的全角文本。

理解双列格式。 日本账单使用独立的 入金 (存入) 和 出金 (支出) 列。如果您的分析需要单一的正负金额，请创建一个公式：=IF(存入单元格<>"", 存入单元格, -支出单元格)。

转换年号日期。 如果您收到年号日期：令和年份 + 2018 = 公历年份。因此，令和8年 = 2026，令和7年 = 2025。对于平成日期（2019 年 5 月之前）：平成年份 + 1988 = 公历年份。

保留原始 PDF。 日本税法要求保留财务记录。对于青色申报者，原始银行对账单（或存折）是必需的证明文件。请务必将 PDF 与转换后的 Excel 文件一起保存。

留意混合宽度字符。 如果排序或筛选产生意外结果，请检查同一列中是否混合了全角和半角字符。即使是在半角单元格中包含一个全角空格也会导致匹配失败。

---

常见问题解答

我可以将三菱UFJ银行 (MUFG) 的账单转换为 Excel 吗？

可以。三菱UFJ是日本最大的银行，拥有约 5700 万个个人账户。PDFSub 原生处理三菱UFJ的 PDF 账单，将日语格式——包括 Shift_JIS 编码、半角片假名付款人姓名以及独立的存入/支出列——转换为干净的、UTF-8 编码的电子表格数据。

如何修复日语乱码 (mojibake)？

当 Shift_JIS 编码的文件被作为 UTF-8 打开（或反之亦然）时，就会出现乱码。PDFSub 通过自动检测编码并以 UTF-8 导出，完全避免了这个问题。如果您正在处理原始 CSV 文件，请在导入 Excel 时指定“日语 (Shift-JIS)”编码：数据 → 获取数据 → 来自文本/CSV → 选择编码。

日本银行 PDF 是否存在 OCR 问题？

从网上银行下载的账单是具有可选文本的原生数字 PDF——提取速度快且准确。只有对于扫描的纸质账单或存折照片 (通帳の写真) 才需要 OCR。日本的存折文化意味着许多用户会拍摄存折页面而不是下载 PDF。PDFSub 可以处理数字 PDF 和扫描文档。

存折 (通帳) 条目怎么办？

实体存折在日本仍然很常见，尽管随着银行对新存折收费（三菱UFJ每年收取 550 日元），其使用率正在下降。存折条目通常比网上账单 PDF 更简略，仅显示缩短的描述。如果您拍摄存折页面，PDFSub 的 OCR 模式可以提取这些交易。

我可以将日本银行数据导出到 freee 或 Money Forward 吗？

PDFSub 支持导出为 Excel、CSV (UTF-8)、QBO、OFX、QFX 和 JSON。对于日本会计软件（freee、Money Forward、弥生），请导出为 CSV 并使用软件内置的银行交易导入功能。来自 PDFSub 的编码正确、规范化的数据可确保顺利导入，不会出现乱码或格式问题。

如何处理日本年号日期 (令和)？

PDFSub 会自动将日本年号日期转换为标准公历日期。手动转换方法：令和年份 + 2018 = 公历年份 (令和8年 = 2026)。平成年份 + 1988 = 公历年份 (平成31年 = 2019)。年号在 2019 年 5 月 1 日发生变更。

PDFSub 支持多少家日本银行？

PDFSub 全球支持 20,000 多种银行格式，包括所有主要的日本银行：三大巨型银行（三菱UFJ、三井住友、瑞穗）、日本邮政银行、乐天银行、遍布 47 个都道府县的地方银行，以及像 SBI 新生银行和索尼银行这样对英文友好的银行。

我可以一次转换多份日本账单吗？

可以。上传多份 取引明细书 (交易明细)，PDFSub 会按顺序处理它们。每份账单都会被自动检测并独立转换，即使它们来自具有不同布局和编码规范的不同银行。

---

免费试用 PDFSub 7 天 —— 全面使用 银行对账单转换器 和其他 77 多种 PDF 工具。无需信用卡。