您来自 MUFG 的取引明細（交易明细）在 PDF 中看起来结构完美。但在日本以外的 Excel 中打开它，问题就会接踵而至：汉字会变成乱码（文字化け），令和时代的日期“令和8年3月2日”对您的英文电子表格毫无意义，半角片假名的发件人姓名如“ﾔﾏﾀﾞﾀﾛｳ”会变得难以辨认，全角数字“１２３，４５６”由于是不同的 Unicode 字符且与半角等效字符不同，因此无法计算。

核心问题在于：日本银行业务依赖于假定为日文环境的字符编码和格式约定。Zengin 银行间支付网络——每天处理约 650 万笔交易和 12 万亿日元——历史上要求所有姓名使用半角片假名，这一遗留问题至今仍体现在现代银行账单上。当您将这些数据移至非日文计算机时，几乎肯定会出现编码错误。

无论您是在东京的外国居民，需要处理 MUFG 账单以向母国报税；还是作为一名税理士（zeirishi），将客户数据导入 freee 或 Money Forward；或是一家国际企业整合日本子公司的数据；抑或是一名自由职业者管理 Blue Return（青色申告）簿记——核心问题都是一样的：从日本银行账单 PDF 中提取结构化、可用于电子表格的数据。

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

Convert Japanese bank statements to Excel - handling kanji, Shift_JIS encoding, and Japanese era dates

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

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

1. Shift_JIS 与 UTF-8 编码（乱码）

这是任何在日本以外处理日本金融数据的人面临的最大问题。

大多数日本银行以 Shift_JIS（代码页 932）格式导出 CSV 文件——这是一种早于 UTF-8 的编码标准，仅包含日文字符。当您在期望 UTF-8 的系统上打开 Shift_JIS 文件时，每个日文字符都会变成乱码。日本人对此有一个词：文字化け (mojibake)，字面意思是“字符转换”。

应显示内容	UTF-8 显示内容
振込カ）ヤマダタロウ	æŒ¯è¾¼ ã‚«ï¼‰ãƒ¤ãƒžãƒ€
三菱UFJ銀行	ä¸‰è±UFJéŠ€è¡Œ
口座振替電気代	å£åº§æŒ¯æ›¿ é›»æ° - ä»£

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

Shift_JIS 文件没有字节顺序标记 (BOM)——没有标头告诉软件使用哪种编码——这使得问题更加复杂。自动检测不可靠，尤其是在文件包含日文和拉丁字符（所有银行账单都包含）混合的情况下。

2. 全角与半角字符

这是日本独有的，几乎让所有非日文开发者措手不及。

日本计算系统对许多字符使用两种宽度。全角字符占据两个拉丁字符的空间；半角字符占据一个。

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

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

银行账单可能混合使用宽度：金额可能是半角的，而描述则使用全角字符。转换器必须将所有内容标准化为一致的半角以进行计算。

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 日元。数字经常达到六位或七位数。
以“万”为单位的思维。 日本人以“万”（10,000）为单位思考。3,000,000 日元的薪水在心理上是“300 万日元”。但银行账单显示的是完整数字。
账单上每 3 位数字一个逗号——尽管日本数字系统按 4 位分组（万 = 10,000，亿 = 100,000,000）。财务文件遵循国际惯例。

6. 分开的存款和取款列

与西方银行账单使用单一金额列（正数表示贷方，负数表示借方）不同，日本账单通常使用两列分开：

入金 (nyūkin) - 存款/贷记
出金 (shukkin) - 取款/借记

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

主要日本银行及其账单

MUFG（三菱UFJ銀行）

日本资产规模最大的银行（约 2.9 万亿美元），约有 5700 万个人存款账户。隶属于三菱日联金融集团。通过网上银行（企业使用 BizSTATION，零售使用三菱UFJダイレクト）提供 PDF 账单和 CSV 导出。CSV 导出使用 Shift_JIS 编码。

SMBC（三井住友銀行）

日本第二大商业银行，约有 2700 万零售客户。隶属于三井住友金融集团。网上银行（SMBCダイレクト）提供 PDF 和 CSV 下载。

Mizuho（みずほ銀行）

第三大综合银行，约有 2400 万零售客户和 1260 万网上银行用户。网上银行（みずほダイレクト）提供交易下载。

日本邮政银行（ゆうちょ銀行）

账户数量最多，拥有约 1.2 亿客户账户，总资产超过 205 万亿日元。通过约 24,000 个网点（大部分是合同邮局）运营。几乎覆盖日本所有市町村。其“Yucho Tsucho”应用程序提供数字存折访问。独特的账户编号系统，不同于标准的日本银行账户号码。

乐天银行（楽天銀行）

日本最大的在线银行，拥有 1760 万以上账户，存款超过 13 万亿日元。与大型银行 3.8% 的年增长率相比，其存款年增长率为 16.5%。完全数字化，具有 CSV 导出功能。

地方银行（地方銀行）

日本约有97 家地方银行——61 家一级银行和 36 家二级银行。每个都道府县通常至少有一家地方银行以其首府为总部。例如：横滨银行（横浜銀行）、千叶银行（千葉銀行）、静冈银行（静岡銀行）。各地方银行的账单格式差异很大。

SBI 控股银行 / 索尼银行

SBI 控股银行和索尼银行以提供英语网上银行而闻名——在日本非常罕见。因此受到外国居民的欢迎。两者都提供 PDF 和 CSV 导出。

方法 1：使用 PDFSub（推荐）

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

Step-by-step process for converting Japanese bank statements with PDFSub

工作原理

上传您的取引明細書 - 从任何日本银行拖放 PDF 文件。PDFSub 从 20,000 多个支持的模板中自动检测银行格式。
自动格式处理 - 转换器自动执行以下操作： - 检测并将 Shift_JIS 编码转换为 UTF-8 - 将全角数字（１２３）标准化为半角（123）以便计算 - 将全角逗号、空格和标点符号转换为标准字符 - 解析日本历日期（令和8年3月2日）为标准日期（2026-03-02） - 将半角片假名发件人姓名转换为可读的全角 - 合并存款/取款列或将其保留为单独的列 - 识别日本银行术语（振込、振替、口座振替等）
审查和验证 - 在预览中检查提取的交易。余额根据账单的期初和期末残高（balance）进行验证。
下载 - 导出为 Excel（.xlsx）、CSV（UTF-8）、QBO（QuickBooks）、OFX（Xero、Wave）、QFX（Quicken）或 JSON。

PDFSub 适用于日本账单的原因

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

自动处理编码。 无需手动检测或在 Shift_JIS 和 UTF-8 之间转换。PDFSub 识别编码并将所有内容标准化为 UTF-8，并正确处理汉字、平假名、片假名和混合宽度字符。

支持所有主要日本银行。 从三大综合银行（MUFG、SMBC、Mizuho）到日本邮政银行的 1.2 亿账户，乐天银行，所有 47 个都道府县的地区银行，以及像 SBI 控股银行和索尼银行这样对英语友好的银行。

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

全角标准化。 数字、逗号、空格和标点符号全部从全角自动标准化为半角——确保金额在电子表格中被视为数字，而不是文本。

方法 2：使用银行的 CSV 导出

大多数主要的日本银行都通过网上银行提供 CSV 交易下载。以下是您将遇到的情况：

您将获得什么

编码： 几乎总是 Shift_JIS（不是 UTF-8）
分隔符： 标准逗号（,）
日期格式： CSV 中通常是 YYYY/MM/DD（西历），但有些银行使用年号日期
列：通常是日付（日期）、摘要（描述）、入金額（存款）、出金額（取款）、残高（余额）

局限性

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

半角片假名姓名。 发件人/收件人姓名将显示为 Zengin 系统中的半角片假名。即使是母语为日语的人也很难阅读，非日语使用者更不可能。

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

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

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

方法 3：手动复制粘贴（不推荐）

日本账单的问题很严重：

汉字和片假名字符在应用程序之间粘贴时可能不正确
编码转换会静默失败——看起来正确的字符可能是错误的 Unicode 代码点
全角数字粘贴为无法计算的文本
半角片假名姓名粘贴后在非日文系统上无法阅读
年号日期在英文 Excel 中没有自动转换为公历日期的功能
分开的存款/取款列需要手动合并
无法根据期初/期末余额进行验证

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

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

Zengin 系统（全銀システム）

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

Zengin 文件格式使用固定宽度的 120 字节记录，并对姓名使用半角片假名编码。这种遗留格式是为什么银行账单上的发件人/收件人姓名显示为半角片假名而不是汉字的原因。较新的 ZEDI（Zengin EDI）系统支持全汉字，并正朝着符合 ISO 20022 的 XML 消息传递发展，但遗留格式在许多账单上仍然存在。

Blue Return（青色申告）与 White Return（白色申告）

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

特征	Blue Return（青色申告）	White Return（白色申告）
申请	必须提前申请	默认状态
簿记	详细的复式记账	简单的收支记录
特别扣除	最高 650,000 日元（使用电子税务）	无
亏损结转	是，最多 3 年	否

申请 Blue Return 的纳税人——他们可以获得更大的税收减免——被要求维护详细的财务记录，这使得准确转换银行账单对于他们的簿记至关重要。

合格发票制度（インボイス制度）

该制度于 2023 年 10 月 1 日启动，要求企业注册为“合格发票发行者”，才能为消费税抵扣发行有效发票。此前，年应税销售额低于 1000 万日元的企业可免征消费税。这一变化极大地增加了小企业和自由职业者准确记录财务的需求。

日本会计软件

软件	主要数据	目标
freee	约 60 万订阅用户	中小企业、自由职业者、初创公司
Money Forward	279.6 亿日元 SaaS ARR	中小企业、个人
Yayoi（弥生）	连续 24 年桌面会计软件排名第一	中小企业、个体经营者
TKC	服务约 11,500 家税务会计师事务所	税务会计师事务所

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

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

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

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

申报 Blue Return 的自由职业者。 自雇人士和自由职业者，如果保持 Blue Return（青色申告）身份，必须维护详细的复式记账记录。将银行账单转换为 Excel 是对业务费用进行分类和计算 650,000 日元特别扣除额的第一步。

国际企业。 拥有日本子公司的公司需要将日本银行数据与全球会计系统合并。三大综合银行共同服务于 19.3% 的日本公司，其公司银行业务通常通过 MUFG 的 BizSTATION 或类似门户进行。

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

在 Excel 中处理日本金融数据的技巧

首先检查乱码。 如果任何日文文本显示为乱码字符（Ã¤、â€、Ã© 等），则文件使用了错误的编码打开。请使用 Shift_JIS 编码重新导入，或使用 PDFSub 的 UTF-8 Excel 导出以完全避免此问题。

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

理解两列格式。 日本账单使用分开的入金（存款）和出金（取款）列。如果您的分析需要单一的带符号金额，请创建一个公式：=IF(deposit_cell<>"", deposit_cell, -withdrawal_cell)。

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

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

注意混合宽度字符。 如果排序或过滤产生意外结果，请检查同一列中是否混有全角和半角字符。一个全角空格出现在其他半角单元格中也会导致不匹配。