將日文銀行對帳單轉換為 Excel (MUFG、SMBC、Mizuho 等)
日文銀行對帳單結合了漢字描述、Shift_JIS 編碼、半形片假名和日文年號日期,這些在非日文版 Excel 中會出現問題。本文將說明如何正確轉換這些對帳單。
您的 MUFG 取引明細 (交易明細) 在 PDF 中看起來結構完美。但若在非日本地區的 Excel 中開啟,問題便會接踵而來:漢字字元會變成亂碼 (文字化け),「令和8年3月2日」這樣的令和年號日期對您的英文試算表毫無意義,像「ヤマダ タロウ」這樣的半形片假名寄件人姓名會變成無法辨識的符號,而全形數字「123,456」則無法計算,因為它們與半形數字是不同的 Unicode 字元。
核心問題在於:日本銀行業的字元編碼和格式慣例是基於日文語系系統。全銀系統 (Zengin) 銀行間支付網絡 — 每天處理約 650 萬筆交易和 12 兆日圓 — 歷史上要求所有名稱都使用半形片假名,這項傳統至今仍出現在現代銀行對帳單上。當您將這些資料移至非日文電腦時,編碼錯誤幾乎是必然的。
無論您是身在東京的外籍居民,需要處理 MUFG 對帳單以進行本國報稅;或是稅理士 (稅務會計師),需要將客戶資料匯入 freee 或 Money Forward;或是需要整合日本子公司資料的國際企業;亦或是管理青色申告 (Blue Return) 簿記的自由工作者 — 核心問題都是相同的:從日文銀行對帳單 PDF 中提取結構化、可供試算表使用的資料。
本指南將涵蓋日文對帳單的特定格式挑戰、您會遇到的主要銀行,以及如何準確轉換它們。
日文銀行對帳單在 Excel 中出現問題的原因
日文銀行對帳單帶來了一系列獨特的挑戰,這些挑戰不僅僅是簡單的數字格式問題。問題涵蓋了字元編碼、數字系統、日期慣例以及舊有的銀行間格式。
1. Shift_JIS 與 UTF-8 編碼 (亂碼)
對於任何在日本境外處理日文金融資料的人來說,這是最大的問題。
大多數日文銀行以 Shift_JIS (代碼頁 932) 匯出 CSV 檔案 — 這是一種早於 UTF-8 的編碼標準,僅涵蓋日文字元。當您在預期 UTF-8 的系統上開啟 Shift_JIS 檔案時,每個日文字元都會變成亂碼。日文對此有一個詞:文字化け (mojibake),字面意思是「字元轉換」。
| 您應該看到的 | UTF-8 顯示的 |
|---|---|
| 振込 カ)ヤマダ タロウ | 振込 カ)ヤマダ |
| 三菱UFJ銀行 | 三è±UFJ銀行 |
| 口座振替 電気代 | å£åº§æŒ¯æ›¿ 電気代 |
反之亦然:在日文語系 Excel 中開啟 UTF-8 檔案也可能產生不同的亂碼輸出。
Shift_JIS 檔案沒有 位元組順序標記 (BOM) — 沒有標頭告知軟體應使用哪種編碼,這使得問題更加複雜。自動偵測不可靠,特別是當檔案包含日文字元和拉丁文字的混合時 (所有銀行對帳單都是如此)。
2. 全形與半形字元 (全角 vs. 半角)
這是日文獨有的,幾乎讓所有非日文開發者措手不及。
日文電腦使用兩種寬度來表示許多字元。全形字元 (全角) 佔用兩個拉丁字元的空間;半形字元 (半角) 佔用一個。
| 全形 (全角) | 半形 (半角) | 是同一個字元嗎? |
|---|---|---|
| 123,456 | 123,456 | 相同的數字,不同的位元組 |
| カード | カード | 相同的詞彙 (「卡」),不同的編碼 |
| ,(コンマ) | , (逗號) | 相同的標點符號,不同的位元組 |
| (スペース) | (空格) | 相同的空格,不同的位元組 |
包含「123,456」(全形) 的儲存格在螢幕上看起來與「123,456」相同,但 Excel 會將全形版本視為文字,而非數字。您無法對其進行加總、排序或在公式中使用。標準的逗號取代功能也無法匹配全形逗號。
銀行對帳單可能會混合使用寬度:金額可能是半形,而描述則使用全形字元。轉換器必須將所有內容正規化為一致的半形以進行計算。
3. 來自全銀系統的半形片假名
全銀系統 (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萬日圓」。但銀行對帳單顯示的是完整數字。
- 對帳單上每三位數一個逗號 — 儘管日文數字系統以四位數分組 (萬 = 10,000,億 = 100,000,000)。金融文件遵循國際慣例。
6. 獨立的存款和提款欄位
與使用單一金額欄位 (正數表示存入,負數表示提款) 的西方銀行對帳單不同,日文對帳單通常使用兩個獨立的欄位:
- 入金 (nyūkin) — 存款/貸項
- 出金 (shukkin) — 提款/借項
每個交易的一個欄位總是空的。轉換為 Excel 時,您需要決定:保留兩欄格式,還是合併為單一帶符號的金額欄位?無論哪種選擇,都要求轉換器理解日文欄位結構。
主要日文銀行及其對帳單
MUFG (三菱UFJ銀行)
日本資產規模最大的銀行 (約 2.9 兆美元),擁有約 5,700 萬個個人存款帳戶。隸屬於三菱 UFJ 金融集團。透過網路銀行 (企業用 BizSTATION,零售用 三菱UFJダイレクト) 提供 PDF 對帳單和 CSV 匯出。CSV 匯出使用 Shift_JIS 編碼。
SMBC (三井住友銀行)
日本第二大商業銀行,擁有約 2,700 萬零售客戶。隸屬於三井住友金融集團。網路銀行 (SMBCダイレクト) 提供 PDF 和 CSV 下載。
Mizuho (みずほ銀行)
第三大巨型銀行,擁有約 2,400 萬零售客戶和 1,260 萬網路銀行訂戶。網路銀行 (みずほダイレクト) 提供交易下載。
Japan Post Bank (ゆうちょ銀行)
按帳戶數量計算為最大銀行,擁有約 1.2 億個客戶帳戶,總資產超過 205 兆日圓。透過約 24,000 個分支機構 (主要為簽約郵局) 營運。幾乎遍及日本每個市町村。「Yucho Tsucho」應用程式提供數位存摺存取。其帳號系統獨特,與標準日文銀行帳號不同。
Rakuten Bank (楽天銀行)
日本最大的網路銀行,擁有超過 1,760 萬個帳戶,存款超過 13 兆日圓。存款年增長率為 16.5%,而巨型銀行為 3.8%。完全數位化,具備 CSV 匯出功能。
地方銀行 (Regional Banks)
日本約有 97 家地方銀行 — 61 家第一級銀行和 36 家第二級銀行。每個縣通常至少有一家地方銀行總部設在其縣廳所在地。範例:橫濱銀行 (横浜銀行)、千葉銀行 (千葉銀行)、靜岡銀行 (静岡銀行)。各地方銀行的對帳單格式差異很大。
SBI Shinsei Bank / Sony Bank
SBI Shinsei Bank 和 Sony Bank 以提供英文網路銀行服務而聞名 — 這在日本很少見。因此受到外籍居民的歡迎。兩者都提供 PDF 和 CSV 匯出。
方法一:使用 PDFSub (推薦)
PDFSub 原生支援日文銀行對帳單 — 包括上述所有編碼和格式挑戰。
運作方式
-
上傳您的取引明細書 — 從任何日文銀行拖放 PDF 檔案。PDFSub 會從 20,000 多個支援範本中自動偵測銀行格式。
-
自動格式處理 — 轉換器會自動:
- 偵測並將 Shift_JIS 編碼轉換為 UTF-8
- 將全形數字 (123) 正規化為半形 (123) 以進行計算
- 將全形逗號、空格和標點符號轉換為標準字元
- 將日文年號日期 (令和8年3月2日) 解析為標準日期 (2026-03-02)
- 將半形片假名寄件人姓名翻譯為可讀的全形字元
- 合併存款/提款欄位或將其保留為單獨的欄位
- 辨識日文銀行術語 (振込、振替、口座振替 等)
-
審查與驗證 — 在預覽中檢查提取的交易。餘額會根據對帳單的期初和期末殘高 (餘額) 進行驗證。
-
下載 — 匯出為 Excel (.xlsx)、CSV (UTF-8)、QBO (QuickBooks)、OFX (Xero, Wave)、QFX (Quicken) 或 JSON。
為何 PDFSub 適用於日文對帳單
支援 133 種語言,包括日文。 提取引擎理解日文銀行術語 — 振込、振替、入金、出金、口座振替、手数料、利息 — 並將它們映射到結構化欄位。
自動處理編碼。 無需手動偵測或在 Shift_JIS 和 UTF-8 之間轉換。PDFSub 會識別編碼並將所有內容正規化為 UTF-8,並正確處理漢字、平假名、片假名和混合寬度字元。
支援所有主要日文銀行。 從三大巨型銀行 (MUFG、SMBC、Mizuho) 到日本郵政銀行的 1.2 億個帳戶、樂天銀行、遍布所有 47 個縣的地方銀行,以及對英文友善的銀行,如 SBI Shinsei Bank 和 Sony Bank。
瀏覽器優先的隱私保護。 對於來自網路銀行的數位 PDF,文字提取完全在您的瀏覽器中進行。檔案絕不會離開您的設備。伺服器端處理僅用於掃描文件或存摺照片。
全形正規化。 數字、逗號、空格和標點符號都會自動從全形正規化為半形 — 確保金額在您的試算表中被視為數字,而非文字。
方法二:使用您銀行的 CSV 匯出
大多數主要日文銀行都透過網路銀行提供 CSV 交易下載。以下是您會遇到的情況:
您會得到什麼
- 編碼: 幾乎總是 Shift_JIS (而非 UTF-8)
- 分隔符: 標準逗號 (,)
- 日期格式: 在 CSV 中通常是 YYYY/MM/DD (西方格式),儘管有些銀行使用年號日期
- 欄位: 通常是 日付 (日期)、摘要 (描述)、入金額 (存款)、出金額 (提款)、殘高 (餘額)
限制
Shift_JIS 編碼。 在任何非日文系統上開啟 CSV 都會產生亂碼。您需要在匯入時明確設定編碼:在 Excel 中,使用「資料」→「取得資料」→「從文字/CSV」→ 選擇「日文 (Shift-JIS)」編碼。
半形片假名名稱。 寄件人/收款人姓名將以全銀系統的半形片假名顯示。即使對於日文母語人士來說,這些名稱也難以閱讀,對於非日文使用者來說則不可能閱讀。
有限的歷史記錄。 網路銀行 CSV 匯出通常涵蓋 3-12 個月。更長的歷史記錄需要單獨下載每個期間的對帳單。
無標準化格式。 與德國 CAMT.053/MT940 或法國 CAMT.053/FEC 標準不同,日文銀行 CSV 沒有通用格式。每家銀行都有自己的欄位順序、命名和結構。
描述中的全形字元。 交易描述可能包含全形數字和標點符號,需要在分析前進行正規化。
方法三:手動複製貼上 (不推薦)
日文對帳單存在嚴重問題:
- 漢字和片假名字元在應用程式之間可能無法正確貼上
- 編碼轉換會靜默失敗 — 看起來正確的字元可能是錯誤的 Unicode 碼點
- 全形數字貼上後會變成無法計算的文字
- 半形片假名名稱貼上後在非日文系統上無法閱讀
- 年號日期在英文版 Excel 中沒有自動轉換為公曆日期
- 獨立的存款/提款欄位需要手動合併
- 沒有針對期初/期末餘額的驗證
對於任何數量的交易,這種方法都是不切實際的。
您應該了解的日文金融系統
全銀系統 (Zengin System)
日本核心的國內銀行間支付清算網絡,成立於 1973 年。連接日本幾乎所有私人銀行,每天處理約 650 萬筆交易,總額約 12 兆日圓。
全銀檔案格式使用固定寬度 120 位元組記錄,並以半形片假名編碼名稱。這種舊有格式是銀行對帳單上寄件人/收款人姓名以半形片假名而非漢字顯示的原因。較新的 ZEDI (全銀 EDI) 系統支援完整漢字,並正朝向符合 ISO 20022 標準的 XML 訊息發展,但許多對帳單上仍保留舊有格式。
青色申告 (Blue Return) 與 白色申告 (White Return)
日文報稅有兩個層級:
| 特點 | 青色申告 (Blue Return) | 白色申告 (White Return) |
|---|---|---|
| 申請 | 必須提前申請 | 預設狀態 |
| 簿記 | 詳細複式記帳 | 簡單收支 |
| 特別扣除 | 最高 ¥650,000 (使用電子報稅) | 無 |
| 虧損結轉 | 是,最多 3 年 | 否 |
青色申告的申報者 — 獲得較大稅務扣除 — 必須維護詳細的財務記錄,因此準確的銀行對帳單轉換對於其簿記至關重要。
合格發票系統 (インボイス制度)
該系統於 2023 年 10 月 1 日啟動,要求企業註冊為「合格發票開立者」,才能開立有效發票以抵扣消費稅。此前,年應稅銷售額低於 1,000 萬日圓的企業可免繳消費稅。這項變革顯著增加了小型企業和自由工作者對準確財務記錄的需求。
日文會計軟體
| 軟體 | 主要統計數據 | 目標客戶 |
|---|---|---|
| freee | 約 60 萬訂戶 | 中小企業、自由工作者、新創公司 |
| Money Forward | 279.6 億日圓 SaaS ARR | 中小企業、個人 |
| Yayoi (彌生) | 連續 24 年桌面會計軟體銷量第一 | 中小企業、獨資經營者 |
| TKC | 服務約 11,500 家稅務會計師事務所 | 稅務會計師事務所 |
所有三個主要雲端平台 (freee、Money Forward、Yayoi Online) 都支援 CSV 匯入銀行交易資料。PDFSub 的 Excel 和 CSV 匯出可以直接匯入這些工具。
誰需要日文銀行對帳單轉換?
稅務會計師 (税理士)。 截至 2025 年 12 月,日本約有 82,276 名註冊稅務會計師。他們處理客戶的銀行對帳單,用於簿記、報稅和審計準備。僅 TKC 全國聯合會就有 11,500 家會員事務所。
外籍居民。 截至 2025 年 6 月,日本有 396 萬外籍居民 — 幾乎是 2012 年的兩倍。大多數銀行對帳單完全是日文,沒有英文選項。外籍居民需要轉換後的對帳單,用於本國報稅、簽證續簽以及向海外機構發送財務文件。
申報青色申告的自由工作者。 維持青色申告 (Blue Return) 身份的自僱人士和自由工作者必須保留詳細的複式記帳記錄。將銀行對帳單轉換為 Excel 是分類業務費用和計算 ¥650,000 特別扣除額的起點。
國際企業。 擁有日本子公司的公司需要將日文銀行資料與全球會計系統整合。三大巨型銀行合計作為 19.3% 日本公司的主要銀行,企業銀行業務通常透過 MUFG 的 BizSTATION 或類似入口網站進行。
學生和打工度假簽證持有者。 2024 年日本接待了超過 3,000 萬國際遊客。長期學生和打工度假簽證持有者會在日本開設銀行帳戶 (通常是日本郵政銀行,最容易開戶),並在管理財務或在本國報稅時需要處理對帳單。
在 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。 日本稅法要求保留財務記錄。對於青色申告的申報者,原始銀行對帳單 (或存摺) 是必需的文件。請務必將 PDF 與您轉換後的 Excel 檔案一併保留。
注意混合寬度字元。 如果排序或篩選產生意外結果,請檢查同一欄位中是否存在混合的全形和半形字元。在其他半形儲存格中,一個單一的全形空格會導致不匹配。
常見問題
我可以將 MUFG (三菱UFJ銀行) 對帳單轉換為 Excel 嗎?
可以。MUFG 是日本最大的銀行,擁有約 5,700 萬個個人帳戶。PDFSub 原生處理 MUFG 的 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 和掃描文件。
存摺 (通帳) 條目怎麼辦?
實體存摺在日本仍然很常見,儘管隨著銀行對新存摺收取費用 (MUFG 每年收取 ¥550),其使用量正在下降。存摺條目通常比網路對帳單 PDF 更為簡略,僅顯示縮短的描述。如果您拍攝存摺頁面,PDFSub 的 OCR 模式可以提取交易。
我可以將日文銀行資料匯出到 freee 或 Money Forward 嗎?
PDFSub 匯出為 Excel、CSV (UTF-8)、QBO、OFX、QFX 和 JSON。對於日文會計軟體 (freee、Money Forward、Yayoi),請匯出為 CSV,然後使用軟體內建的銀行交易匯入功能進行匯入。PDFSub 提供的正確編碼和正規化資料可確保乾淨匯入,沒有亂碼或格式問題。
如何處理日文年號日期 (令和)?
PDFSub 會自動將日文年號日期轉換為標準公曆日期。手動轉換:令和年份 + 2018 = 公曆年份 (令和8年 = 2026 年)。平成年份 + 1988 = 公曆年份 (平成31年 = 2019 年)。年號於 2019 年 5 月 1 日更改。
PDFSub 支援多少家日文銀行?
PDFSub 支援全球 20,000 多種銀行格式,包括所有主要日文銀行:三大巨型銀行 (MUFG、SMBC、Mizuho)、日本郵政銀行、樂天銀行、遍布所有 47 個縣的地方銀行,以及對英文友善的銀行,如 SBI Shinsei Bank 和 Sony Bank。
我可以一次轉換多份日文對帳單嗎?
可以。上傳多份取引明細書 (交易明細),PDFSub 會依序處理它們。即使它們來自不同銀行,具有不同的版面配置和編碼慣例,每份對帳單也會被自動偵測並獨立轉換。
免費試用 PDFSub 7 天 — 完全存取 銀行對帳單轉換器 和其他 77+ 種 PDF 工具。無需信用卡。