跳至主要内容

本文經 J-Compass 編輯流程調查與事實查核；編輯團隊於發布前審核資料來源及準確性。 了解我們的編輯方法 →
本譯文僅供參考，以方便閱讀。內容以英文版本為準。 閱讀英文原文 →

日語標點符號與排版規範

日語標點符號由一套精簡而獨特的符號體系構成。它們用於斷句、列舉、引用對話、表示範圍，並塑造混合書寫系統的視覺節奏。1 少數符號與英語共享相同外形（如 ？ 和 ！），但絕大多數標點均不相同（如 。、「」・ー〜…）。符號周邊的排版規範——包括全形方框占位、詞與詞之間無空格，以及混合語言文本中全形與半形的分野——往往比符號本身更容易讓初學者感到困惑。12

概述​

一句話概括日語標點​

日語的核心標點清單十分精簡：句點「。」（句號）、讀點「、」（逗號）、鉤括號「「」」（引號）、雙重鉤括號「『』」（雙引號及作品名書名號）、中黑「・」（間隔號）、長音符「ー」（片假名長音標記）、波浪號「〜」（wave dash）、三點省略號「…」（成對使用）、感嘆號「！」以及疑問號「？」。1

這些符號在預設情況下全都是「全形」（full-width / 全角）字符。每一個符號都佔據與一個漢字或假名字符相同大小的完整方塊字框，這正是理解其周邊排版規則與符號本身同樣重要的原因。1

簡明歷史：古典日語幾乎沒有標點，明治時期的白話文引入了現代標點體系​

近代以前的日語在書寫時通常沒有斷句符號。直到 19 世紀從歐洲語言進行大量翻譯時，標點符號才在日語書寫中普及開來。1

現代日語標點符號體系主要形成於明治時期（1868–1912 年）。當時歐洲印刷術的引進和翻譯作品的激增，促使人們在白話文書寫中建立規範的標點體系。13 隨後的國家級數位化編碼確立則要晚得多：1978 年的 JIS C 6226（1987 年更名為 JIS X 0208）正式將這套標點符號與假名、漢字一同編碼進數位文字體系中。3

日本中央政府的官方公文文體規範屬於 20 世紀的發展成果。1951 年（昭和 26 年），日本頒布了第一部官方公文指南《公用文作成の要領》。該指南後於 2022 年（令和 4 年 1 月 7 日）被文化審議會建議《公用文作成の考え方》正式取代，後者是現行日本中央政府公文的權威規範，文內多處對其進行了引用。45

歷史年份是核心基準，而非裝飾性細節

1868–1912 年的明治維新時期、1978 年 JIS C 6226 編碼的確立，以及令和 4 年 1 月 7 日（2022 年 1 月 7 日）《公用文作成の考え方》的改革，是支撐本文所有內容的骨架基準。當未來的政策修訂對官方規則進行調整時，變動的正是基於這三個時間節點所確立的規範。43

常見標點一覽​

符號日文名稱羅馬字中文名稱主要功能
。句点kuten句號用於句末斷句1
、読点tōten逗號切分從句、分隔列舉項1
「 」鍵括弧kagikakko鉤括號 / 單引號引用台詞、對話或強調1
『 』二重鍵括弧nijū-kagikakko雙重鉤括號 / 雙引號嵌套引用、標註書名或作品名1
・中黒nakaguro中黑 / 間隔號外國人名間隔、短詞列舉分隔1
ー長音符chōonpu長音符在片假名中將前接母音延長一拍1
〜波ダッシュnami-dasshu波浪號表示範圍、拖長母音尾音16
……三点リーダーsanten rīdā三點省略號（成對使用）表示停頓、省略、無語或沉默17
！感嘆符kantanfu感嘆號表示強調、驚嘆1
？疑問符gimonfu疑問號表示疑問（用於口語體或被允許的正式語境）1

下文將對每個符號展開詳細說明。

句子邊界符號​

句點 。：句號（kuten，口語常稱 maru）​

句點在 Unicode 中的編碼為 U+3002（IDEOGRAPHIC FULL STOP）。其形態是一個小空心圓圈，而不是實心圓點，用於標誌句子的結束。1

它的排版位置依附於字符字框，而非整行基線。在橫排文本中，該符號位於前一個字符字框的右下角；在直排文本中，則位於字符字框的右上角。1 句點後不額外添加空格，因為該符號自身已經佔據了獨立完整的方塊字框空間。

W3C JLReq（日語排版需求）規範將句點歸入 cl-06（句點類），並在 §3.1.9 中詳細規定了行尾避頭尾規則。89

明日あした学校がっこうに行いきます。1
「明天我要去學校。」

在日常隨筆或網路閒聊中，句點常常被省略，尤其是當短句獨立成行或置於引號內時，換行本身就承擔了劃分句界的職責。10 該符號在口語中的俗稱為「マル」（maru，意為圓圈），學習者在聽到正式的「句點」之前，通常先熟悉這個口語名稱。110

讀點 、：逗號（tōten）​

讀點在 Unicode 中的編碼為 U+3001（IDEOGRAPHIC COMMA）。1 它用於斷開複句、分隔並列項，並調控文章的朗讀節奏。其放置位置往往取決於閱讀節奏而非嚴格的文法結構：由作者決定讀者應當在哪裡稍作停頓。1

與句點類似，讀點在橫排文本中位於前一個字符字框的右下角，在直排文本中位於右上角，後面不添加多餘空格。它屬於 W3C 字符類別 cl-07（讀點類），並遵循 JLReq §3.1.9 的行尾定位規則。89

私わたしはパンを食たべて、コーヒーを飲のみました。10
「我吃了麵包，喝了咖啡。」

りんご、みかん、ぶどうを買かいました。1
「我買了蘋果、蜜柑和葡萄。」

在橫排官方公文中選用「、」而非「，」

1951 年的《公用文作成の要領》曾規定在橫排官方公文中使用全形西式逗號「，」。然而，2022 年的《公用文作成の考え方》將橫直兩種書寫方向的標準統一恢復為「、」，使日本中央政府公文風格與大眾普遍習慣保持一致。沿用舊指南習慣仍在使用「，」的作者如今已與最新標準脫節。411

為什麼兩者統稱為「句讀點」（kutōten）​

「句讀點」（kutōten）是日本學校教科書和出版風格指南中對句點與讀點的合稱。1 2022 年文化審議會建議《公用文作成の考え方》正是以該詞作為章節標題來歸納其現代標點使用規則。4 當日語老師對你說「注意你的句讀點」時，指的就是這兩者。

引號與括號類符號​

「 」：鉤括號（kagikakko），預設引號​

鉤括號在 Unicode 中的編碼為 U+300C（LEFT CORNER BRACKET）與 U+300D（RIGHT CORNER BRACKET）。W3C JLReq 將其劃分為 cl-01（始め括弧類，前括號類）與 cl-02（終わり括弧類，後括號類）。8

它們是日常書寫中用於直接引語、引用短語以及對單個詞彙進行特異性強調的標準引號。1

先生せんせいは「おはようございます」と言いいました。1
「老師說了句：『早上好。』」

這兩個 Unicode 字符同時適用於橫排和直排。渲染引擎會自動處理視覺旋轉：前括號「 在橫排中位於左上方，而在直排中則旋轉定位至右上方。1

句號在引號內還是引號外：兩種形式並存

傳統文學出版習慣將句末的句號「。」置於閉合括號「」內（如：「こんにちは。」）。而現代網路文本和日常隨筆中，括號內末尾的句號往往直接省略（如：「こんにちは」）。W3C JLReq 在 §3.1.9 中涵蓋了行尾定位規則，但將括號內是否保留句號交由出版社自身的排版風格自行決定。因此實際建議是理解這兩種寫法均屬於常見形式。91

『 』：二重鉤括號（nijū-kagikakko），用於嵌套引用與作品名稱​

雙重鉤括號在 Unicode 中的編碼為 U+300E（LEFT WHITE CORNER BRACKET）與 U+300F（RIGHT WHITE CORNER BRACKET）。1 它們承擔兩個主要功能：第一個是在外層「 」引用內部嵌套次級引用；第二個功能則是標明作品名稱。

因為日語沒有西文斜體（Italics）的排版傳統，書籍、電影、漫畫、報紙和歌曲名稱通常都使用『 』加以包裹，起到類似中文書名號的作用。1

彼かれは「先生せんせいが『静しずかに』と言いった」と話はなした。1
「他說道：『老師說了要“安靜”。』」

夏目なつめ漱石そうせきの『こころ』を読よみました。1
「我讀了夏目漱石的《心》。」

學習者起初往往容易忽略其作為書名號的作用。一旦掌握了這一點，閱讀日本書籍封面、電影海報和參考文獻時就會容易很多。

〈 〉 與 《 》：較少見的單角括號與雙角括號​

這些使用頻率較低的角括號主要出現在學術論文、古典文獻輯錄和部分純文學小說中。學習者一般只需能夠辨認即可，無需主動頻繁使用：當文本中出現 〈 〉 或 《 》 時，將其理解為某種特定的強調或專業術語標記即可。1

括號朝向隨書寫方向變化​

括號字符在 Unicode 底層是書寫方向中立的。它們的視覺朝向會根據文本是採用從左至右的橫排（横書き）還是自上而下的直排（縦書き）而自動調整。1 W3C JLReq §3.1.5（行首前括號的處理）與 §3.1.9（行尾後括號、句點、讀點與中點的處理）對兩種排版方向作出了統一的邊界規整要求，排版渲染引擎會自動旋轉字形。9

存儲在磁碟上的底層字符代碼並未改變，旋轉由排版引擎完成。這也是為什麼直接複製橫排文本中的引文貼上到直排版面中時，無需手動更換括號符號的原因。

分隔符與列舉符號​

中黑 ・：中點分隔符（nakaguro，亦稱 nakaten、nakapotsu）​

中黑在 Unicode 中編碼為 U+30FB（KATAKANA MIDDLE DOT），歸屬於 W3C 字符類別 cl-05（中點類）。它預設佔據完整的全形方塊字框，與其周圍的假名完美對齊。81

中黑在日常書寫中有兩個最主要的分隔用途：第一是分隔用片假名書寫的外國人名（名與姓）（如 バラク・オバマ）；第二是在使用「、」會顯得生硬瑣碎的複合概念中充當列舉分隔符（如 小・中学校）。110

バラク・オバマは元もとアメリカ大統領だいとうりょうです。110
「貝拉克·歐巴馬是前美國總統。」

小しょう・中学校ちゅうがっこうで英語えいごを教おしえています。110
「我在國小和國中教英語。」

該符號還可用於漢字數字中充當小數點（三・一四 = 3.14）、分隔複合頭銜中的職銜名稱，以及在容易混淆成詞的長串假名中釐清界限。1 口語中的叫法包括中點（nakaten）、中ぽつ（nakapotsu）以及中黑（nakaguro）。1

円周率えんしゅうりつは三さん・一いち四よんです。1
「圓周率是 3.14。」

作為列舉分隔符的「・」 vs 作為名字分隔符的「・」​

這兩種功能在頁面上的符號外觀完全一致，但遵循不同的規則。

對於用片假名書寫的外來人名，使用中點分隔是正規排版的強制要求。在名與姓之間使用「、」在文法上是錯誤的，並非單純的風格選擇。1

而作為並列列舉符時，中黑則與讀點「、」存在競爭關係，具體取決於語體與排版風格。當並列項結構高度對齊緊湊（如 小・中・高 表示國小、國中、高中）或是單字縮寫時，優先使用「・」；在連貫的長篇正文敘述中，則更傾向於使用「、」。1

範圍、重複與長音符號​

長音符 ー：chōonpu，片假名長音連接線​

長音符在 Unicode 中編碼為 U+30FC（KATAKANA-HIRAGANA PROLONGED SOUND MARK），屬於 W3C 字符類別 cl-10（長音記號）。8 它的作用是將前面的母音延長一拍（一拍的音長），是片假名外來語詞彙和擬聲擬態詞的標準長音表示法。除了極少數俏皮風格或漫畫誇張字體外，它在平假名中極其罕見。110

コーヒーを一杯いっぱいください。10
「請給我一杯咖啡。」

スーパーで買かい物ものをします。10
「我去超市買東西。」

在直排文本中，長音符會自動旋轉為一根豎線，以順應文本縱向流動，準確延長字列中前一個字的母音發音。1

波浪號 〜：wave dash​

波浪號在 Unicode 中編碼為 U+301C（WAVE DASH）。它於 1991 年隨 Unicode 1.0 引入，作為 JIS C 6226-1978 / JIS X 0208 字符集的相容字符。6

它在日常書寫中有三個主要功能：標明區間範圍（5時〜6時、東京〜大阪）、在標題與副標題之間起到分隔作用，以及在口語或賣萌語境下拉長母音尾音（おいしい〜）。110

営業えいぎょう時間じかんは午前ごぜん9時くじ〜午後ごご6時ろくじです。10
「營業時間為上午 9 點至下午 6 點。」

東京とうきょう〜大阪おおさかの新幹線しんかんせんに乗のりました。1
「我搭乘了東京至大阪的新幹線。」

このケーキ、おいしい〜！10
「這個蛋糕太好吃了〜！」

兩個外觀幾乎完全相同的碼位

U+301C（WAVE DASH）與 U+FF5E（FULLWIDTH TILDE，全形波浪號 ～）的顯示外觀幾乎毫無二致。微軟對 Shift_JIS 的 CP932 擴充實現將歷史字節 0x8160 映射到了 U+FF5E 而非 U+301C。其結果是，舊式 Windows 日文系統與標準 Unicode 文本在哪個才是「正統」碼位的問題上存在分歧；日本的 Windows 使用者即使在輸入波浪連接符時，也常常會預設敲出 U+FF5E。2612 此外，Unicode 最初給出的字符樣張甚至將其顛倒印成了「先下沉後上升」的波形，該錯誤直到 2015 年的 Unicode 8.0.0 才被勘誤更正。6

々：漢字疊字符（noma，同之字點）​

「々」在 Unicode 中編碼為 U+3005（IDEOGRAPHIC ITERATION MARK）。它代表重複前一個漢字：例如「人人」寫作「人々」（hitobito，人們），「時時」寫作「時々」（tokidoki，有時）。1 雖然從嚴格意義上講它屬於疊字迭代標記而非標點符號，但初學者在學習基礎識字教材時通常會將其與「。」和「「」」一同接觸。1

人々ひとびとが公園こうえんに集あつまりました。1
「人們聚集在公園裡。」

時々ときどき日本語にほんごの本ほんを読よみます。1
「我有時間會讀日語書。」

停頓、省略與強調符號​

三點省略號 …：成對使用為 ……​

三點省略號在 Unicode 中編碼為 U+2026（HORIZONTAL ELLIPSIS），在 U+2025（TWO DOT LEADER）還有一個兩點的近親符號。1 該字符本身就是一個獨立的完整字形，而不是由三個句號簡單拼湊出來的。7

正規正式出版物的排版規範通常使用連續的六個點，即輸入兩個字符：……。只有在排版版面極度狹窄的情況下，才允許使用單獨的三點省略號。1 橫排文本中，點通常排布在基線上或字框中間；直排文本中，則在整列文字中水平居中對齊。1

彼かれは何なにも言いわなかった……。7
「他一句話也沒說……」

あの……ちょっといいですか。1
「那個……請問方便耽誤您一下嗎？」

漫畫中的省略號比看起來蘊含更多資訊量

在漫畫或文字冒險遊戲中，如果一個對話框或分格只包含「……」（甚至更長的一長串省略號），它代表著一陣完整的沉默、尷尬或無語。這種視覺厚重感往往在英譯過程中被弱化，以至於英文版常常將其翻譯成一個完整的句子，而非保留點狀符號。17 當學習者閱讀日語原文並看到整段僅有省略號時，那些點本身就是角色的台詞。

感嘆號 ！與 疑問號 ？​

！在 Unicode 中編碼為 U+FF01（FULLWIDTH EXCLAMATION MARK），？ 為 U+FF1F（FULLWIDTH QUESTION MARK）；其半形形式 U+0021 和 U+003F 也會在混合語言語境中出現。兩者均屬於 W3C 字符類別 cl-04（区切り約物，斷句標點類）。82

這兩個符號在古典日語中均不存在，都是明治時期隨著吸收歐洲印刷排版規則而引入的外來標點。1

它們廣泛應用於日常隨筆、小說、漫畫與商業廣告中。但在傳統正式文體中，由於句末助詞「か」本身已標明疑問語氣，且句尾陳述語氣即可表達感嘆，因而以往通常不使用這兩個符號。1

危あぶない！　車くるまが来くるよ。1
「危險！車來了！」

本当ほんとうですか？　信しんじられない。1
「真的嗎？真不敢相信。」

在官方公文中正式引入這兩個符號是有確切日期的近期改革。日本文化審議會建議《公用文作成の考え方》（令和 4 年 1 月 7 日，2022 年 1 月 7 日）正式允許在中央政府的宣傳、說明類材料以及記錄原始發音的談話記錄中，使用「？」與「！」。45 該文件還規定了間距規則：當「？」或「！」後面同一行內仍有文本時，標點後應空一格。只要在同一文檔中保持規範一致，此空格使用全形或半形均可。411 W3C JLReq §3.1.6（斷句標點與連字符的排版）同樣規範了行中留空規則，規定 cl-04 字符非處於行尾時，其後需附加全形間距。9

口語俗稱：マル、びっくりマーク、はてなマーク​

在日常交流、發簡訊或手寫交流中，學習者除了正式的漢字名稱外，經常會聽到這些通俗叫法：句點常被稱為「マル」（maru，圓圈）；感嘆號被稱為「びっくりマーク」（bikkuri māku，吃驚符號）；疑問號被稱為「はてなマーク」（hatena māku，納悶/疑問符號）或「クエスチョンマーク」（kuesuchon māku）。110 如果一個日本人對你說「這裡加一個 びっくり」，他指的是加一個感嘆號，而不是要發出驚叫聲。

空格與字符寬度規範​

標準日文正文中詞與詞之間不留空格​

日語正文在詞與詞之間不使用空格隔開。書寫系統依靠漢字、平假名與片假名的相互交替穿插來自然呈現詞界。這種不同字符系統混合排版的視覺節奏承擔了英語中空格的分割功能。110

空格僅在非常有限的特定場景下使用：兒童繪本、初學者教材、部分國小低年級課本，以及在原稿紙（原稿用紙）中每個標點獨佔一格時的規範。1 學習者從教材過渡到原生日語讀物時，會失去空格這一詞界輔助，必須適應依靠字符系統的交替來斷句辨詞。

某些體裁中專有名詞周圍的全形空格​

全形空格（全角スペース，Unicode U+3000 IDEOGRAPHIC SPACE）插入一個完整的方塊空格，在正式書信、政府公文及某些報紙風格中用於襯托並突顯人名。1 在原稿紙排版中，段落首行縮排同樣使用該全形空格。此外，在要求將姓與名填寫在同一輸入框中的各類網路表單中，姓與名之間也常用全形空格分隔。1

混合文本中的全形（zenkaku）與半形（hankaku）標點​

Unicode 編碼區段 U+FF00–U+FFEF（半形及全形字符）的引入，是為了讓東亞早期的歷史編碼（如 1969 年的 JIS X 0201、1978 年的 JIS X 0208 以及 Shift_JIS）能夠無損映射轉換為 Unicode。213314 其中 U+FF01–U+FF5E 將 ASCII 的 0x21–0x7E 映射為全形形式；U+FF61–U+FF9F 則編碼了半形片假名及其相關標點（JIS X 0201 中字節 0xA1–0xDF 的映射）。214

在日語排版術語中，「全形」（全角，zenkaku）字符佔據與漢字完全相同的正方形字框寬度，而「半形」（半角，hankaku）字符則大約佔據其一半的寬度。2

實際排版規則正如上述圖表所示：日文正文與日文字符並列時使用全形 。、「」；西文字符塊（網址 URL、程式代碼、學術拉丁學名、英文引文）內部使用半形 . , " "；嵌入在日文中的完整英文句子則採用半形西文標點。Unicode 字符集為每種西文標點都同時提供了全形與半形形式，作者可根據上下文精準選擇。2

表單輸入的困境：為什麼你的地址表單會被拒收​

日本的各類網頁表單常常對字符寬度有嚴格限制，往往要求數字必須為「半形」、片假名必須為「全形」，甚至有時恰恰相反。此類規則因網站而異，且表單自身很少給出明確的錯誤提示。2 2022 年的《公用文作成の考え方》對官方公文的輸入寬度做出了明確規定：在橫排公文中，阿拉伯數字預設採用半形，同時沿用「、」作為逗號規範。411

半形片假名是歷史遺留問題，而非排版風格

半形片假名（ｶﾀｶﾅ）之所以至今仍殘存在收據明細、ATM 終端機螢幕、火車站 LED 顯示螢幕以及部分陳舊的零售與銀行系統中，是因為 1969 年的單字節編碼限制。甚至日本主要的跨行轉帳結算系統直到 2018 年才徹底摒棄半形假名。現代網頁文本已嚴格避免使用半形假名。13 當姓名表單要求填寫「全形假名」時，若輸入半形字符則會被視作錯誤的字符集，而非僅僅是字級偏小。

延伸了解​

在片假名外來人名名與姓之間誤用「、」​

中黑「・」是用片假名書寫外國姓名時的標準姓名分隔符。在名與姓之間使用「、」會被讀者理解為兩個獨立並列的人物，而不是單個人的全名。1 正確的規範是：

バラク・オバマは元もとアメリカ大統領だいとうりょうです。110
「貝拉克·歐巴馬是前美國總統。」

將單個「…」誤當作正規印刷品中的省略號​

正式出版物的排版規範使用兩個 U+2026 字符連成六個點「……」。單獨的三點省略號僅在版面極其局促時作為妥協方案使用。在文學性正文中，句末只放一個「…」會顯得不夠規範與隨意。1 標準規範寫法如下：

彼かれは何なにも言いわなかった……。17
「他一句話也沒說……」

用三個句點拼接冒充省略號​

連續敲打三個半形英文句點（...）並不是日語省略號。日語中的三點省略號是獨立的字體字形，有著自身獨特的字距與中心對齊參數。敲打三個句號不僅在視覺間距上明顯脫節，還會破壞排版引擎的字距微調與分行換行計算。7 正確的做法是輸入成對的 U+2026：

彼かれは何なにも言いわなかった……。17
「他一句話也沒說……」

在法律或學術公文中濫用「！」或「？」​

2022 年的《公用文作成の考え方》僅允許在具有宣傳、導讀性質的政府普及材料或直接引語錄音整理中採用「！」和「？」。法律條文、政府行政法令以及正規學術論文中，仍然依賴助詞「か」以及嚴謹的陳述句型來傳達疑問與強調，而不使用感嘆號或問號。4

逗號的位置關乎語感節奏，而非文法限制​

讀點「、」的放置是作者對語言節奏的掌控，而非一成不變的句法規則。過多的逗號讀起來拖沓累贅，過少的逗號則讓人喘不過氣。

標準的寫作建議是朗讀句子，在語意自然換氣停頓處放置「、」。日語中不存在類似英語「連詞前必須加逗號」的機械規則。1

句號放在閉引號「」內還是外​

傳統的文學出版習慣將句號「。」置於閉合括號「」內（如：「こんにちは。」）；而現代網路書寫及輕便體裁中，括號內的句號往往直接被省略（如：「こんにちは」）。出版物中這兩種情況均有存在，相比死記某一種規則，能夠辨識並理解出版社的風格偏好更為實用。91

波浪號「〜」存在兩個不同的 Unicode 碼位​

U+301C（WAVE DASH）與 U+FF5E（FULLWIDTH TILDE）在顯示上幾乎無法肉眼分辨。微軟 CP932 Shift_JIS 的歷史實現將波浪線映射到了 U+FF5E，導致新舊文本在「哪個才是正規碼位」上存在衝突。現代輸入法通常會自動替使用者完成轉換，因此對學習者來說這主要是識讀層面的背景知識，而非書寫時的負擔。2612

為什麼古典日語沒有標點符號​

近代以前的日語不使用斷句標點。古人依賴係結法則（係り結び）、句末終助詞以及動詞形態的活用變化來清晰界定文法邊界。現代標點符號是明治維新（1868–1912 年）期間伴隨西方印刷技術全面引進的，解決了日語書寫體系此前並未迫切感受到的斷句需求。1

半形片假名是歷史產物，而非現代書寫規範​

半形片假名（ｶﾀｶﾅ）的誕生純粹是因為 1969 年的 JIS X 0201 單字節編碼無法在 8 位空間內容納全形字符。雖然它至今仍保留在小票和終端設備中，但在現代網路出版中早已被棄用。學習者如果在現代網頁上看到它，應將其視作一種歷史遺留現象，而非可效仿的排版風格。13

參見​

References​

Footnotes​

  1. Wikipedia contributors. "Japanese punctuation." Wikipedia. https://en.wikipedia.org/wiki/Japanese_punctuation ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37 ↩38 ↩39 ↩40 ↩41 ↩42 ↩43 ↩44 ↩45 ↩46 ↩47 ↩48 ↩49 ↩50 ↩51 ↩52 ↩53 ↩54 ↩55 ↩56 ↩57 ↩58 ↩59 ↩60 ↩61 ↩62 ↩63 ↩64 ↩65 ↩66 ↩67 ↩68 ↩69 ↩70 ↩71 ↩72 ↩73

  2. Wikipedia contributors. "Halfwidth and fullwidth forms." Wikipedia. https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Wikipedia contributors. "JIS X 0208." Wikipedia. https://en.wikipedia.org/wiki/JIS_X_0208 ↩ ↩2 ↩3 ↩4

  4. 文化審議会. 『公用文作成の考え方（建議）』（付）「公用文作成の考え方（文化審議会建議）」解説. 令和4年1月7日. 文化庁. https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/hokoku/93657201.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. 文化庁 報道発表. 「文化審議会建議『公用文作成の考え方』について」. https://www.bunka.go.jp/koho_hodo_oshirase/hodohappyo/93650001.html ↩ ↩2

  6. Wikipedia contributors. "Wave dash." Wikipedia. https://en.wikipedia.org/wiki/Wave_dash ↩ ↩2 ↩3 ↩4 ↩5

  7. Mandelin, Clyde. "Encountering Japanese Ellipses in English Translations." Legends of Localization, 8 September 2013. https://legendsoflocalization.com/articles/japanese-ellipsis-usage/ (limitation: localization industry source; used here for the manga-ellipsis weight convention) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. W3C. Requirements for Japanese Text Layout, Appendix A, "Character Classes" (cl-01 through cl-10). https://www.w3.org/TR/jlreq/#character_classes ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. W3C. Requirements for Japanese Text Layout, §3.1, "Line Composition Rules for Punctuation Marks." https://www.w3.org/TR/jlreq/#line_composition_rules_for_punctuation_marks ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  10. Croes, Jaered Koichi, and Kristen Dexter. "Japanese Punctuation: The Definitive Guide." Tofugu, 21 March 2016. https://www.tofugu.com/japanese/japanese-punctuation/ (limitation: language-learning publisher, used here only for natural example sentences also attested elsewhere) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15

  11. 神楽坂編集室. 「公用文における数字・記号の書き方」 (summary of the 2022 文化審議会建議 公用文作成の考え方 rules on 句読点 and 符号). https://kagurazaka-editors.jp/official-document-number/ (limitation: secondary summary; used only where it corroborates the primary 文化庁 PDF on the ?/! spacing rule) ↩ ↩2 ↩3

  12. Microsoft Corporation (Shawn Steele). cp932 to Unicode table (Table format A, Table version 2.01). Published by The Unicode Consortium under WindowsBestFit vendor mappings. https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT (entry 0x8160 0xFF5E #FULLWIDTH TILDE). ↩ ↩2

  13. Wikipedia contributors. "Half-width kana." Wikipedia. https://en.wikipedia.org/wiki/Half-width_kana ↩ ↩2 ↩3

  14. The Unicode Consortium. The Unicode Standard, "Halfwidth and Fullwidth Forms" (block U+FF00–U+FFEF). Code chart and block introduction. https://www.unicode.org/charts/PDF/UFF00.pdf ↩ ↩2