日语标点符号与排版规范

日语标点符号由一套精简而独特的符号体系构成。它们用于断句、列举、引用对话、表示范围，并塑造混合书写系统的视觉节奏。¹ 少数符号与英语共享相同外形（如 ？ 和 ！），但绝大多数标点均不相同（如 。、「」・ー〜…）。符号周边的排版规范——包括全角方框占位、词与词之间无空格，以及混合语言文本中全角与半角的分野——往往比符号本身更容易让初学者感到困惑。¹²

概述

一句话概括日语标点

日语的核心标点清单十分精简：句点“。”（句号）、读点“、”（逗号）、钩括号“「」”（引号）、双重钩括号“『』”（双引号及作品名书名号）、中黑“・”（间隔号）、长音符“ー”（片假名长音标记）、波浪号“〜”（wave dash）、三点省略号“…”（成对使用）、感叹号“！”以及疑问号“？”。¹

这些符号在默认情况下全都是“全角”（full-width）字符。每一个符号都占据与一个汉字或假名字符相同大小的完整方块字框，这正是理解其周边排版规则与符号本身同样重要的原因。¹

简明历史：古典日语几乎没有标点，明治时期的白话文引入了现代标点体系

近代以前的日语在书写时通常没有断句符号。直到19世纪从欧洲语言进行大量翻译时，标点符号才在日语书写中普及开来。¹

现代日语标点符号体系主要形成于明治时期（1868–1912年）。当时欧洲印刷术的引进和翻译作品的激增，促使人们在白话文书写中建立规范的标点体系。¹³ 随后的国家级数字化编码确立则要晚得多：1978年的 JIS C 6226（1987年更名为 JIS X 0208）正式将这套标点符号与假名、汉字一同编码进数字文字体系中。³

日本中央政府的官方公文文体规范属于20世纪的发展成果。1951年（昭和26年），日本颁布了第一部官方公文指南《公用文作成の要領》。该指南后于2022年（令和4年1月7日）被文化审议会建议《公用文作成の考え方》正式取代，后者是现行日本中央政府公文的权威规范，文内多处对其进行了引用。⁴⁵

历史年份是核心基准，而非装饰性细节

1868–1912年的明治维新时期、1978年 JIS C 6226 编码的确立，以及令和4年1月7日（2022年1月7日）《公用文作成の考え方》的改革，是支撑本文所有内容的骨架基准。当未来的政策修订对官方规则进行调整时，变动的正是基于这三个时间节点所确立的规范。⁴³

常见标点一览

符号	日文名称	罗马字	中文名称	主要功能
。	句点	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）。其形态是一个小空心圆圈，而不是实心圆点，用于标志句子的结束。¹

它的排版位置依附于字符字框，而非整行基线。在横排文本中，该符号位于前一个字符字框的右下角；在竖排文本中，则位于字符字框的右上角。¹ 句点后不额外添加空格，因为该符号自身已经占据了独立完整的方块字框空间。

W3C JLReq（日语排版需求）规范将句点归入 cl-06（句点类），并在 §3.1.9 中详细规定了行尾避头尾规则。⁸⁹

明日あした学校がっこうに行いきます。¹
“明天我要去学校。”

在日常随笔或网络闲聊中，句点常常被省略，尤其是当短句独立成行或置于引号内时，换行本身就承担了划分句界的职责。¹⁰ 该符号在口语中的俗称为“マル”（maru，意为圆圈），学习者在听到正式的“句点”之前，通常先熟悉这个口语名称。¹¹⁰

读点 、：逗号（tōten）

读点在 Unicode 中的编码为 U+3001（IDEOGRAPHIC COMMA）。¹ 它用于断开复句、分隔并列并列项，并调控文章的朗读节奏。其放置位置往往取决于阅读节奏而非严格的语法结构：由作者决定读者应当在何处稍作停顿。¹

与句点类似，读点在横排文本中位于前一个字符字框的右下角，在竖排文本中位于右上角，后面不添加多余空格。它属于 W3C 字符类别 cl-07（读点类），并遵循 JLReq §3.1.9 的行尾定位规则。⁸⁹

私わたしはパンを食たべて、コーヒーを飲のみました。¹⁰
“我吃了面包，喝了咖啡。”

りんご、みかん、ぶどうを買かいました。¹
“我买了苹果、蜜柑和葡萄。”

在横排官方公文中选用「、」而非「，」

1951年的《公用文作成の要領》曾规定在横排官方公文中使用全角西式逗号「，」。然而，2022年的《公用文作成の考え方》将横竖两种书写方向的标准统一恢复为「、」，使日本中央政府公文风格与大众普遍习惯保持一致。沿用旧指南习惯仍在使用「，」的作者如今已与最新标准脱节。⁴¹¹

为什么两者统称为“句读点”（kutōten）

“句読点”（kutōten）是日本学校教科书和出版风格指南中对句点与读点的合称。¹ 2022年文化审议会建议《公用文作成の考え方》正是以该词作为章节标题来归纳其现代标点使用规则。⁴ 当日语老师对你说“注意你的句读点”时，指的就是这两者。

引号与括号类符号

「 」：钩括号（kagikakko），默认引号

钩括号在 Unicode 中的编码为 U+300C（LEFT CORNER BRACKET）与 U+300D（RIGHT CORNER BRACKET）。W3C JLReq 将其划分为 cl-01（始め括弧類，前括号类）与 cl-02（終わり括弧類，后括号类）。⁸

它们是日常书写中用于直接引语、引用短语以及对单个词汇进行特异性强调的标准引号。¹

先生せんせいは「おはようございます」と言いいました。¹
“老师说了句：‘早上好。’”

这两个 Unicode 字符同时适用于横排和竖排。渲染引擎会自动处理视觉旋转：前括号「 在横排中位于左上方，而在竖排中则旋转定位至右上方。¹

句号在引号内还是引号外：两种形式并存

传统文学出版习惯将句末的句号“。”置于闭合括号「」内（如：“こんにちは。”）。而现代网络文本和日常随笔中，括号内末尾的句号往往直接省略（如：“こんにちは」”）。W3C JLReq 在 §3.1.9 中涵盖了行尾定位规则，但将括号内是否保留句号交由出版社自身的排版风格自行决定。因此实际建议是理解这两种写法均属于常见形式。⁹¹

『 』：二重钩括号（nijū-kagikakko），用于嵌套引用与作品名称

双重钩括号在 Unicode 中的编码为 U+300E（LEFT WHITE CORNER BRACKET）与 U+300F（RIGHT WHITE CORNER BRACKET）。¹ 它们承担两个主要功能：第一个是在外层「 」引用内部嵌套次级引用；第二个功能则是标明作品名称。

因为日语没有西文斜体（Italics）的排版传统，书籍、电影、漫画、报纸和歌曲名称通常都使用『 』加以包裹，起到类似中文书名号的作用。¹

彼かれは「先生せんせいが『静しずかに』と言いった」と話はなした。¹
“他说道：‘老师说了要“安静”。’”

夏目なつめ漱石そうせきの『こころ』を読よみました。¹
“我读了夏目漱石的《心》。”

学习者起初往往容易忽略其作为书名号的作用。一旦掌握了这一点，阅读日本书籍封面、电影海报和参考文献时就会容易很多。

〈 〉 与 《 》：较少见的单角括号与双角括号

这些使用频率较低的角括号主要出现在学术论文、古典文献辑录和部分纯文学小说中。学习者一般只需能够辨认即可，无需主动频繁使用：当文本中出现 〈 〉 或 《 》 时，将其理解为某种特定的强调或专业术语标记即可。¹

括号朝向随书写方向变化

括号字符在 Unicode 底层是书写方向中立的。它们的视觉朝向会根据文本是采用从左至右的横排（横書き）还是自上而下的竖排（縦書き）而自动调整。¹ W3C JLReq §3.1.5（行首前括号的处理）与 §3.1.9（行尾后括号、句点、读点与中点的处理）对两种排版方向作出了统一的边界规整要求，排版渲染引擎会自动旋转字形。⁹

存储在磁盘上的底层字符代码并未改变，旋转由排版引擎完成。这也是为什么直接复制横排文本中的引文粘贴到竖排版面中时，无需手动更换括号符号的原因。

分隔符与列举符号

中黑 ・：中点分隔符（nakaguro，亦称 nakaten、nakapotsu）

中黑在 Unicode 中编码为 U+30FB（KATAKANA MIDDLE DOT），归属于 W3C 字符类别 cl-05（中点类）。它默认占据完整的全角方块字框，与其周围的假名完美对齐。⁸¹

中黑在日常书写中有两个最主要的用途：第一是分隔用片假名书写的外国人名（名与姓）（如 バラク・オバマ）；第二是在使用“、”会显得生硬琐碎的复合概念中充当列举分隔符（如 小・中学校）。¹¹⁰

バラク・オバマは元もとアメリカ大統領だいとうりょうです。¹¹⁰
“贝拉克·奥巴马是前美国总统。”

小しょう・中学校ちゅうがっこうで英語えいごを教おしえています。¹¹⁰
“我在小学和初中教英语。”

该符号还可用于汉字数字中充当小数点（三・一四 = 3.14）、分隔复合头衔中的职衔名称，以及在容易混淆成词的长串假名中厘清界限。¹ 口语中的叫法包括中点（nakaten）、中ぽつ（nakapotsu）以及中黑（nakaguro）。¹

円周率えんしゅうりつは三さん・一いち四よんです。¹
“圆周率是3.14。”

作为列举分隔符的“・” vs 作为名字分隔符的“・”

这两种功能在页面上的符号外观完全一致，但遵循不同的规则。

对于用片假名书写的外来人名，使用中点分隔是正规排版的强制要求。在名与姓之间使用“、”在语法上是错误的，并非单纯的风格选择。¹

而作为并列列举符时，中黑则与读点“、”存在竞争关系，具体取决于语体与排版风格。当并列项结构高度对齐紧凑（如 小・中・高 表示小学、初中、高中）或是单字缩写时，优先使用“・”；在连贯的长篇正文叙述中，则更倾向于使用“、”。¹

范围、重复与长音符号

长音符 ー：chōonpu，片假名长音连接线

长音符在 Unicode 中编码为 U+30FC（KATAKANA-HIRAGANA PROLONGED SOUND MARK），属于 W3C 字符类别 cl-10（长音记号）。⁸ 它的作用是将前面的元音延长一拍（一拍的音长），是片假名外来语词汇和拟声拟态词的标准长音表示法。除了极少数嬉皮风格或漫画夸张字体外，它在平假名中极其罕见。¹¹⁰

コーヒーを一杯いっぱいください。¹⁰
“请给我一杯咖啡。”

スーパーで買かい物ものをします。¹⁰
“我去超市买东西。”

在竖排文本中，长音符会自动旋转为一根竖线，以顺应文本纵向流动，准确延长字列中前一个字的元音发音。¹

波浪号 〜：wave dash

波浪号在 Unicode 中编码为 U+301C（WAVE DASH）。它于1991年随 Unicode 1.0 引入，作为 JIS C 6226-1978 / JIS X 0208 字符集的兼容字符。⁶

它在日常书写中有三个主要功能：标明区间范围（5時〜6時、東京〜大阪）、在标题与副标题之间起到分隔作用，以及在口语或卖萌语境下拉长元音尾音（おいしい〜）。¹¹⁰

営業えいぎょう時間じかんは午前ごぜん9時くじ〜午後ごご6時ろくじです。¹⁰
“营业时间为上午9点至下午6点。”

東京とうきょう〜大阪おおさかの新幹線しんかんせんに乗のりました。¹
“我乘坐了东京至大阪的新干线。”

このケーキ、おいしい〜！¹⁰
“这个蛋糕太好吃了〜！”

两个外观几乎完全相同的码位

U+301C（WAVE DASH）与 U+FF5E（FULLWIDTH TILDE，全角波浪号 ～）的显示外观几乎毫无二致。微软对 Shift_JIS 的 CP932 扩展实现将历史字节 0x8160 映射到了 U+FF5E 而非 U+301C。其结果是，旧式 Windows 日文系统与标准 Unicode 文本在哪个才是“正统”码位的问题上存在分歧；日本的 Windows 用户即使在输入波浪连接符时，也常常会默认敲出 U+FF5E。²⁶¹² 此外，Unicode 最初给出的字符样张甚至将其颠倒印成了“先下沉后上升”的波形，该错误直到2015年的 Unicode 8.0.0 才被勘误更正。⁶

々：汉字叠字符（noma，同之字点）

“々”在 Unicode 中编码为 U+3005（IDEOGRAPHIC ITERATION MARK）。它代表重复前一个汉字：例如“人人”写作“人々”（hitobito，人们），“時時”写作“時々”（tokidoki，有时）。¹ 虽然从严格意义上讲它属于叠字迭代标记而非标点符号，但初学者在学习基础识字教材时通常会将其与“。”和“「」”一同接触。¹

人々ひとびとが公園こうえんに集あつまりました。¹
“人们聚集在公园里。”

時々ときどき日本語にほんごの本ほんを読よみます。¹
“我有时间会读日语书。”

停顿、省略与强调符号

三点省略号 …：成对使用为 ……

三点省略号在 Unicode 中编码为 U+2026（HORIZONTAL ELLIPSIS），在 U+2025（TWO DOT LEADER）还有一个两点的近亲符号。¹ 该字符本身就是一个独立的完整字形，而不是由三个句号简单拼凑出来的。⁷

正规正式出版物的排版规范通常使用连续的六个点，即输入两个字符：……。只有在排版版面极度狭窄的情况下，才允许使用单独的三点省略号。¹ 横排文本中，点通常排布在基线上或字框中间；竖排文本中，则在整列文字中水平居中对齐。¹

彼かれは何なにも言いわなかった……。⁷
“他一句话也没说……”

あの……ちょっといいですか。¹
“那个……请问方便耽误您一下吗？”

漫画中的省略号比看起来蕴含更多信息量

在漫画或文字冒险游戏中，如果一个对话框或分格只包含“……”（甚至更长的一长串省略号），它代表着一阵完整的沉默、尴尬或无语。这种视觉厚重感往往在英译过程中被弱化，以至于英文版常常将其翻译成一个完整的句子，而非保留点状符号。¹⁷ 当学习者阅读日语原文并看到整段仅有省略号时，那些点本身就是角色的台词。

感叹号 ！与 疑问号 ？

！在 Unicode 中编码为 U+FF01（FULLWIDTH EXCLAMATION MARK），？ 为 U+FF1F（FULLWIDTH QUESTION MARK）；其半角形式 U+0021 和 U+003F 也会在混合语言语境中出现。两者均属于 W3C 字符类别 cl-04（区切り約物，断句标点类）。⁸²

这两个符号在古典日语中均不存在，都是明治时期随着吸收欧洲印刷排版规则而引入的外来标点。¹

它们广泛应用于日常随笔、小说、漫画与商业广告中。但在传统正式文体中，由于句末助词“か”本身已标明疑问语气，且句尾陈述语气即可表达感叹，因而以往通常不使用这两个符号。¹

危あぶない！　車くるまが来くるよ。¹
“危险！车来了！”

本当ほんとうですか？　信しんじられない。¹
“真的吗？真不敢相信。”

在官方公文中正式引入这两个符号是有确切日期的近期改革。日本文化审议会建议《公用文作成の考え方》（令和4年1月7日，2022年1月7日）正式允许在中央政府的宣传、说明类材料以及记录原始发音的谈话记录中，使用“？”与“！”。⁴⁵ 该文件还规定了间距规则：当“？”或“！”后面同一行内仍有文本时，标点后应空一格。只要在同一文档中保持规范一致，此空格使用全角或半角均可。⁴¹¹ W3C JLReq §3.1.6（断句标点与连字符的排版）同样规范了行中留空规则，规定 cl-04 字符非处于行尾时，其后需附加全角间距。⁹

口语俗称：マル、びっくりマーク、はてなマーク

在日常交流、发短信或手写交流中，学习者除了正式的汉字名称外，经常会听到这些通俗叫法：句点常被称为“マル”（maru，圆圈）；感叹号被称为“びっくりマーク”（bikkuri māku，吃惊符号）；疑问号被称为“はてなマーク”（hatena māku，纳闷/疑问符号）或“クエスチョンマーク”（kuesuchon māku）。¹¹⁰ 如果一个日本人对你说“这里加一个 びっくり”，他指的是加一个感叹号，而不是要发出惊叫声。

空格与字符宽度规范

标准日文正文中词与词之间不留空格

日语正文在词与词之间不使用空格隔开。书写系统依靠汉字、平假名与片假名的相互交替穿插来自然呈现词界。这种不同脚本混合排版的视觉节奏承担了英语中空格的分割功能。¹¹⁰

空格仅在非常有限的特定场景下使用：儿童绘本、初学者教材、部分小学低年级课本，以及在原稿纸（原稿用紙）中每个标点独占一格时的规范。¹ 学习者从教材过渡到原生日语读物时，会失去空格这一词界辅助，必须适应依靠字符脚本的交替来断句辨词。

某些体裁中专有名词周围的全角空格

全角空格（全角スペース，Unicode U+3000 IDEOGRAPHIC SPACE）插入一个完整的方块空格，在正式书信、政府公文及某些报纸风格中用于衬托并突显人名。¹ 在原稿纸排版中，段落首行缩进同样使用该全角空格。此外，在要求将姓与名填写在同一输入框中的各类网络表单中，姓与名之间也常用全角空格分隔。¹

混合文本中的全角（zenkaku）与半角（hankaku）标点

Unicode 编码区段 U+FF00–U+FFEF（半角及全角字符）的引入，是为了让东亚早期的历史编码（如 1969 年的 JIS X 0201、1978 年的 JIS X 0208 以及 Shift_JIS）能够无损映射转换为 Unicode。²¹³³¹⁴ 其中 U+FF01–U+FF5E 将 ASCII 的 0x21–0x7E 映射为全角形式；U+FF61–U+FF9F 则编码了半角片假名及其相关标点（JIS X 0201 中字节 0xA1–0xDF 的映射）。²¹⁴

在日语排版术语中，“全角”（zenkaku）字符占据与汉字完全相同的正方形字框宽度，而“半角”（hankaku）字符则大约占据其一半的宽度。²

实际排版规则正如上述图表所示：日文正文与日文字符并列时使用全角 。、「」；西文字符块（网址 URL、程序代码、学术拉丁学名、英文引文）内部使用半角 . , " "；嵌入在日文中的完整英文句子则采用半角西文标点。Unicode 字符集为每种西文标点都同时提供了全角与半角形式，作者可根据上下文精准选择。²

表单输入的困境：为什么你的地址表单会被拒收

日本的各类网页表单常常对字符宽度有严格限制，往往要求数字必须为“半角”、片假名必须为“全角”，甚至有时恰恰相反。此类规则因网站而异，且表单自身很少给出明确的错误提示。² 2022年的《公用文作成の考え方》对官方公文的输入宽度做出了明确规定：在横排公文中，阿拉伯数字默认采用半角，同时沿用「、」作为逗号规范。⁴¹¹

半角片假名是历史遗留问题，而非排版风格

半角片假名（ｶﾀｶﾅ）之所以至今仍残存在收据小票、ATM 终端屏幕、火车站 LED 显示屏以及部分陈旧的零售与银行系统中，是因为1969年的单字节编码限制。甚至日本主要的跨行转账结算系统直到2018年才彻底摒弃半角假名。现代网页文本已严格避免使用半角假名。¹³ 当姓名表单要求填写“全角假名”时，若输入半角字符则会被视作错误的字符集，而非仅仅是字号偏小。

延伸了解

在片假名外来人名名与姓之间误用“、”

中黑“・”是用片假名书写外国姓名时的标准姓名分隔符。在名与姓之间使用“、”会被读者理解为两个独立并列的人物，而不是单个人的全名。¹ 正确的规范是：

バラク・オバマは元もとアメリカ大統領だいとうりょうです。¹¹⁰
“贝拉克·奥巴马是前美国总统。”

将单个“…”误当作正规印刷品中的省略号

正式出版物的排版规范使用两个 U+2026 字符连成六个点“……”。单独的三点省略号仅在版面极其局促时作为妥协方案使用。在文学性正文中，句末只放一个“…”会显得不够规范与随意。¹ 标准规范写法如下：

彼かれは何なにも言いわなかった……。¹⁷
“他一句话也没说……”

用三个句点拼接冒充省略号

连续敲打三个半角英文句点（...）并不是日语省略号。日语中的三点省略号是独立的字体字形，有着自身独特的字距与中心对齐参数。敲打三个句号不仅在视觉间距上明显脱节，还会破坏排版引擎的字距微调与分行换行计算。⁷ 正确的做法是输入成对的 U+2026：

彼かれは何なにも言いわなかった……。¹⁷
“他一句话也没说……”

在法律或学术公文中滥用“！”或“？”

2022年的《公用文作成の考え方》仅允许在具有宣传、导读性质的政府普及材料或直接引语录音整理中采用“！”和“？”。法律条文、政府行政法令以及正规学术论文中，仍然依赖助词“か”以及严谨的陈述句式来传达疑问与强调，而不使用感叹号或问号。⁴

逗号的位置关乎语感节奏，而非语法限制

读点“、”的放置是作者对语言节奏的掌控，而非一成不变的句法规则。过多的逗号读起来拖沓累赘，过少的逗号则让人喘不过气。

标准的写作建议是朗读句子，在语意自然换气停顿处放置“、”。日语中不存在类似英语“连词前必须加逗号”的机械规则。¹

句号放在闭引号「」内还是外

传统的文学出版习惯将句号“。”置于闭合括号「」内（如：“こんにちは。”）；而现代网络书写及轻便体裁中，括号内的句号往往直接被省略（如：“こんにちは」”）。出版物中这两种情况均有存在，相比死记某一种规则，能够辨识并理解出版社的风格偏好更为实用。⁹¹

波浪号“〜”存在两个不同的 Unicode 码位

U+301C（WAVE DASH）与 U+FF5E（FULLWIDTH TILDE）在显示上几乎无法肉眼分辨。微软 CP932 Shift_JIS 的历史实现将波浪线映射到了 U+FF5E，导致新旧文本在“哪个才是正规码位”上存在冲突。现代输入法通常会自动替用户完成转换，因此对学习者来说这主要是识读层面的背景知识，而非书写时的负担。²⁶¹²

为什么古典日语没有标点符号

近代以前的日语不使用断句标点。古人依赖系结法则（係り結び）、句末终助词以及动词形态的活用变化来清晰界定语法边界。现代标点符号是明治维新（1868–1912年）期间伴随西方印刷技术全面引进的，解决了日语书写体系此前并未迫切感受到的断句需求。¹

半角片假名是历史产物，而非现代书写规范

半角片假名（ｶﾀｶﾅ）的诞生纯粹是因为1969年的 JIS X 0201 单字节编码无法在8位空间内容纳全角字符。虽然它至今仍保留在小票和终端设备中，但在现代网络出版中早已被弃用。学习者如果在现代网页上看到它，应将其视作一种历史遗留现象，而非可效仿的排版风格。¹³

参见

• 混合书写系统：日语如何融合汉字、平假名与片假名
• 竖排书写（縦書き）与横排书写（横書き）
• 振假名：汉字上方的读音标注
• 送假名：当汉字融入平假名
• 片假名中的长音：长音符“ー”的工作原理及平假名为何不用
• 如何用片假名书写你的名字：外语姓名转写规则与示例

References

Footnotes

1. Wikipedia contributors. "Japanese punctuation." Wikipedia. https://en.wikipedia.org/wiki/Japanese_punctuation ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸ ↩³⁹ ↩⁴⁰ ↩⁴¹ ↩⁴² ↩⁴³ ↩⁴⁴ ↩⁴⁵ ↩⁴⁶ ↩⁴⁷ ↩⁴⁸ ↩⁴⁹ ↩⁵⁰ ↩⁵¹ ↩⁵² ↩⁵³ ↩⁵⁴ ↩⁵⁵ ↩⁵⁶ ↩⁵⁷ ↩⁵⁸ ↩⁵⁹ ↩⁶⁰ ↩⁶¹ ↩⁶² ↩⁶³ ↩⁶⁴ ↩⁶⁵ ↩⁶⁶ ↩⁶⁷ ↩⁶⁸ ↩⁶⁹ ↩⁷⁰ ↩⁷¹ ↩⁷² ↩⁷³

2. Wikipedia contributors. "Halfwidth and fullwidth forms." Wikipedia. https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

3. Wikipedia contributors. "JIS X 0208." Wikipedia. https://en.wikipedia.org/wiki/JIS_X_0208 ↩ ↩² ↩³ ↩⁴

4. 文化審議会. 『公用文作成の考え方（建議）』（付）「公用文作成の考え方（文化審議会建議）」解説. 令和4年1月7日. 文化庁. https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/hokoku/93657201.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

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

6. Wikipedia contributors. "Wave dash." Wikipedia. https://en.wikipedia.org/wiki/Wave_dash ↩ ↩² ↩³ ↩⁴ ↩⁵

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) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

8. W3C. Requirements for Japanese Text Layout, Appendix A, "Character Classes" (cl-01 through cl-10). https://www.w3.org/TR/jlreq/#character_classes ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

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 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

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) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵

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) ↩ ↩² ↩³

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). ↩ ↩²

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

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 ↩ ↩²