您來自 MUFG 的「取引明細」(交易明細單) 在 PDF 中看起來結構完美。但如果在日本以外的 Excel 中打開，問題就會接踵而來：漢字會變成亂碼 (文字化け)，令和時代的日期「令和8年3月2日」對您的英文試算表毫無意義，半形片假名的寄件人姓名如「ﾔﾏﾀﾞﾀﾛｳ」會變得無法辨識，全形數字「１２３，４５６」無法計算，因為它們是與半形不同的 Unicode 字元。

核心問題是：日本銀行系統運行時的字元編碼和格式慣例，都假設是日文環境。Zengin 銀行間支付網路——每天處理約 650 萬筆交易和 12 兆日圓——過去要求所有姓名都使用半形片假名，這項遺留問題至今仍出現在現代銀行對帳單上。當您將這些資料轉移到非日文電腦時，幾乎肯定會發生編碼錯誤。

無論您是在東京的外籍居民，為了向母國報稅而處理 MUFG 對帳單；還是身為稅理士 (zeirishi)，將客戶資料匯入 freee 或 Money Forward；或是國際企業合併日本子公司資料；又或是自由工作者管理藍色申告 (青色申告) 的簿記——核心問題都一樣：從日文銀行對帳單 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éŠ€è¡Œ
口座振替電気代	å£åº§æŒ¯æ›¿ é›»æ° - ä»£

反之亦然：在日文環境的 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 時，您需要決定：保留兩個欄位的格式，還是合併為單一帶符號的金額欄位？無論哪種選擇，轉換器都需要理解日文欄位的結構。

主要日本銀行及其對帳單

MUFG (三菱UFJ銀行)

日本資產規模最大的銀行 (約 2.9 兆美元)，擁有約 5,700 萬個人存款帳戶。隸屬於三菱日聯金融集團。透過網路銀行 (企業用戶為 BizSTATION，零售用戶為三菱UFJダイレクト) 提供 PDF 對帳單和 CSV 匯出。CSV 匯出使用 Shift_JIS 編碼。

SMBC (三井住友銀行)

日本第二大商業銀行，約有 2,700 萬零售客戶。隸屬於三井住友金融集團。網路銀行 (SMBCダイレクト) 提供 PDF 和 CSV 下載。

Mizuho (みずほ銀行)

第三大銀行集團，約有 2,400 萬零售客戶和 1,260 萬網路銀行用戶。網路銀行 (みずほダイレクト) 提供交易下載。

日本郵政銀行 (ゆうちょ銀行)

帳戶數量最多，擁有約 1.2 億客戶帳戶，總資產超過 205 兆日圓。透過約 24,000 個分支機構 (大多為委託郵局) 營運。幾乎遍及日本所有市區町村。其「Yucho Tsucho」應用程式提供數位存摺存取。獨特的帳戶編號系統，不同於標準的日本銀行帳戶號碼。

樂天銀行 (楽天銀行)

日本最大的網路銀行，擁有 1,760 萬以上帳戶，存款超過 13 兆日圓。與大型銀行的 3.8% 相比，存款年增長率為 16.5%。完全數位化，具備 CSV 匯出功能。

地區銀行 (地方銀行)

日本約有 97 家地區銀行——61 家一級銀行和 36 家二級銀行。每個縣通常至少有一家地區銀行以其首府為總部。例如：橫濱銀行 (横浜銀行)、千葉銀行 (千葉銀行)、靜岡銀行 (静岡銀行)。不同地區銀行的對帳單格式差異很大。

SBI Sumishin Net Bank / Sony Bank

SBI Sumishin Net Bank 和 Sony Bank 以提供 英文網路銀行 而聞名——在日本非常罕見。因此受到外籍居民的歡迎。兩者都提供 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) - 將半形片假名寄件人姓名轉換為可讀的全形 - 合併存款/提款欄位或將它們保留為獨立欄位 - 識別日文銀行術語 (振込、振替、口座振替等)
審閱和驗證 - 在預覽中檢查提取的交易。餘額會根據對帳單的起始和結束「残高」(餘額) 進行驗證。
下載 - 匯出為 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 Sumishin Net Bank 和 Sony Bank。

瀏覽器優先隱私。 對於來自網路銀行的數位 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 系統 (全銀システム)

日本核心的國內銀行間支付清算網路，成立於 1973 年。連接日本幾乎所有私人銀行，每天處理約 650 萬筆交易，總計約 12 兆日圓。

Zengin 文件格式 使用固定寬度 120 位元組記錄，並對姓名使用半形片假名編碼。這種舊格式是銀行對帳單上的寄件人/收件人姓名顯示為半形片假名而非漢字的原因。較新的 ZEDI (Zengin EDI) 系統支援完整的漢字，並正朝向符合 ISO 20022 的 XML 訊息傳輸發展，但舊格式在許多對帳單上仍然存在。

藍色申告 (青色申告) 與白色申告 (白色申告)

日本的稅務申報有兩個級別：

特點	藍色申告 (青色申告)	白色申告 (白色申告)
申請	必須預先申請	預設狀態
簿記	詳細的複式簿記	簡單的收入/支出
特別扣除	最高 650,000 日圓 (使用 e-Tax)	無
虧損結轉	是，最多 3 年	否

藍色申告申報者——獲得較大的稅務減免——被要求維持詳細的財務記錄，因此準確轉換銀行對帳單對其簿記至關重要。

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

該制度於 2023 年 10 月 1 日啟動，要求企業註冊為「合格發票發行者」，以便為消費稅抵免發行有效的發票。先前，年應稅銷售額低於 1,000 萬日圓的企業可免徵消費稅。這項變更顯著增加了小型企業和自由工作者對準確財務記錄保存的需求。

日本會計軟體

軟體	主要數據	目標
freee	約 600,000 用戶	中小型企業、自由工作者、新創公司
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 年數字的兩倍。大多數銀行對帳單完全是日文，沒有英文選項。外籍居民需要轉換的對帳單以向母國報稅、更新簽證，以及向海外機構提交財務文件。

申報藍色申告的自由工作者。 自營業者和自由工作者維持藍色申告 (青色申告) 身份，必須維護詳細的複式簿記記錄。將銀行對帳單轉換為 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 (反之亦然) 開啟時，就會發生 mojibake。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 Sumishin Net Bank 和 Sony Bank。

我可以一次轉換多份日文對帳單嗎？

可以。上傳多份「取引明細書」(交易對帳單)，PDFSub 會依序處理它們。每份對帳單都會獨立進行自動偵測和轉換，即使它們來自不同的銀行，具有不同的佈局和編碼慣例。

免費試用 PDFSub 7 天 - 在全功能方案 ($20/使用者/月，年繳) 中完全存取銀行對帳單轉換器和 84+ 種其他 PDF 工具。可隨時取消。