据教育部的《标点符号用法》4.3.3.3 条：表示声音巨大或声音不断加大时，可叠用叹号；表达强烈语气时，也可叠用叹号，最多叠用三个叹号。在没有异常强烈的情感表达需要时不宜叠用叹号。

因此，错误事例中「德國隊竟然戰勝了巴西隊！！」是符合语法的正确用法。

但重复使用标点确实不太「好看」。

在 简体中文 -> 空格 -> 中英文之间需要增加空格 -> 完整的正确用法 示例中，每个句号后面都有一个空格。

不知道后续的 全角标点与其他字符之间不加空格 表示的全角符号是否包括 全角标点 与 汉字。

以及 简体中文 -> 标点符号 -> 使用全角中文标点 的示例中，叹号和问号结束一句话的时候，后面都是没有接空格的。

一些由中文、英文共同组成的特殊词组应当怎么处理？
例如：「U盘」还是「U 盘」？

Unicode 的 middle dot 與 hyphenation point 都是半形，但 CNS11643 與 HKSCS 分別將後者與前者訂為全形，但字體一於少理。

建議一律改用 U+30FB katakana middle dot。在任何支援該字的字體，均顯視為全形。

在正確與錯誤的示例中均出現了

她竟然對你說「喵」？！

那麼這個示例應該算正確的還是錯誤的？

在维基百科中，使用“条目”一词，词典中才使用“词条”。

內文包含數字時，當使用半形字符

正確：

這件蛋糕只賣 1000 元

錯誤：

這件蛋糕只賣 １０００ 元

举例：® ©

情景：Node.js® 是一个基于 Chrome V8 引擎的 JavaScript 运行时。

✍️

这个蛋糕只卖 １０００ 元
那个乱七八糟的东西就不需要这么多钱

这个蛋糕只卖１０００元
那个乱七八糟的东西就不需要这么多钱

个人觉得不需要增加空格（现在示例里面是加了空格的）

中文和英文之间一般都要加空格。但参考下面的例子：

• 我最爱的产品是简书和豆瓣FM，你呢？
• 我最爱的产品是简书和豆瓣 FM，你呢？

由于“豆瓣FM”是一个专有名词，而且在句子中和”简书“并列，如果加了空格就会有种割裂感。

（我有一个类似的个人参考，在 GitCafe 上：写作规范）

The future solution.
Might be good to mention it.

空格之神 ( https://chrome.google.com/webstore/detail/paphcfdffjnbcgkokihcdjliihicmbpd )
自动排版网页，在中英文之间加上空格，效果基本符合本指北。

只是以前发现的一个插件，并不是给它打广告。

使用方块引号的方式，在大陆地区是明确地违反国标[1]的行为，正规出版物上必然要禁止。
有鉴于此，这条倡议就完全变成了个人喜好，而让本文的指导建议上的意义大打折扣。

[1] http://www.moe.gov.cn/ewebeditor/uploadfile/2015/01/13/20150113091548267.pdf

仓主，你好。

首先，很感谢你建立了这样一个仓库。
我是文字排版强迫症晚期患者，无法直视任何排版凌乱、中英文粘连不清的文章。
每次见到这样的行为，我都会把你的这个仓库发给作者。

为了方便转贴，我弄了个短链接 git.io/ppzb 。

另外，我觉得 Git 的 commit log 都是句子，一般我会强迫自己首字母大写，结尾有个半角的点。

再次拜谢。

例如：

刚刚买了一台 iPhone，好开心！
刚刚买了一台 iPhone ，好开心！

想问下，『切换到dev分支之后』这句话怎样添加空格比较好

1. 切换到 dev分支 之后
2. 切换到 dev 分支之后
3. 切换到 dev分支之后

诸如此类的更绕的还有『切换到远程master分支之后』

尊敬的开发者、维护人员：
你们好！

在下国语不精，谨以普通话、简体字陈述。

了解本项目之前，我排版主要依据如下标准：

• 中华人民共和国国家标准GB/T 15834—2011号《标点符号用法》
• 中华人民共和国新闻出版行业标准CY/T 154—2017号《中文出版物夹用英文的编辑规范》

其中部分规则与此处略有出入，例如：

• 中英文之间需要增加空格

  异于《中文出版物夹用英文的编辑规范》第8.1节：

  中文文本中夹用英文时，应根据所选用的中英文字体、字符间距以及排版的视觉效果决定英文词句与中文文字之间是否留有空格间距。如留空格，应保证体例的统一。

• 不重复使用标点符号

  #32 已讨论。

• 简体中文使用直角引号

  #83 称其不合规，但根据《标点符号用法》第5.2节“竖排文稿标点符号的位置和书写形式”：

  5.2.3 引号改用双引号“﹃”“﹄”和单引号“﹁”“﹂”，……

  直角引号在竖排文稿中是正确用法，但一般的文本不包含排版信息，故其合规与否取决于打开方式。

为减少读者疑虑，我谨提议：在指北中引述各地现行标准，并指出对其取舍的考量。

感谢你们对该项目的辛勤付出！

#106

修正繁體中文用詞，歡迎指教。

鍵接 -> 超連結

指北 -> 指南

使用全角中文标点 一节指出了如下 “正确” 用法：

核磁共振成像（NMRI）是什么原理都不知道？JFGI！

但是我在实际使用中发现如下规则更好：

• 对于词末/句末的分隔类标点，与其前面的字符保持一致：使用半角字符当且仅当其前面为半角字符（半角字母数字等）。例如：

  Good: 核磁共振成像一般简写为 NMRI.

  Bad: 核磁共振成像一般简写为 NMRI。

• 对于配对的标点（括号、引号等），当其内部的第一个和最后一个字符都是半角字符时，使用半角符号（注意与前后的文字保持空格间距）：

  Good: 核磁共振成像 (NMRI) 是什么原理

  Bad: 核磁共振成像（NMRI）是什么原理
  Bad: 核磁共振成像(NMRI)是什么原理

  • 特殊情况：单个字母或数字表示选项或类似含义时，可以使用全角符号

    Good: （A 或 B）
    Also good: (A 或 B)

  • 边界情况：若配对标点中内容的第一个和最后一个字符为全角半角各一个时，根据内容主体，两种括号均可：

    Good: NMRI (Nuclear Magnetic Resonance Imaging, 核磁共振成像) 是……
    Also good: NMRI（Nuclear Magnetic Resonance Imaging, 核磁共振成像）是……

  • 例外：直引号「」不使用本规则

hint is a simple markdown lint / hint cli tool for Chinese document to be integrated with travis.

A simple markdown lint / hint cli-tool, for markdown developer integrated with travis.

一个简单的 markdown 静态检查的控制台 cli 工具，可以方便 markdown 开发者轻松集成 travis 自动检测。

目前在高速迭代中，目前版本可以实现基本的检测。目前使用 hint 做 travice-ci 集成的项目：

• JS-Sorting-Algorithm
• hint

希望能加入到推荐中，分享给更多的人使用。

如果可以的话，我会发起一个 pr。

鉴于很多人现在总说三者通用，或者“的得”通用，有时候还是比较头疼

“以下用法略帶有個人色彩，既：無論是否遵循下述規則，從語法的角度來講都是正確的。” 中的 “既” 应当为 “即”。

项目介绍中「Chiense Copywriting Guidelines」拼写有误。

在 #108 中，liyishuai 的一个评论写出

似乎在假定“文字间距即空格”，或“无空格则无间距”

我认为本指导有一些这样的假定。

尽管 text-spacing to the rescue? 一节中写明了：有一些地方可以实现自动增加中英文之间的间距，但没有广泛应用，所以建议随手添加空格。

但我认为，这一部分的主旨与章节含义已经产生了偏差。

章节提倡添加空格，但没有写明自动添加间距时的处理方式，即默认这种自动产生的间距是章节所述“空格”的一种，而这与计算机中“空格”的含义不同，“空格”字符理应被视为间距的一种。

因此建议将本文所述“空格”修改为“间距”，并在其下明确可以使用“空格”字符来产生间距。

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

觉得内容挺不错的，想转载到自己的 Blog , 先征求下原创意见。

各位维护者你们好，按照现行的标准，因为日期混合了中文+数字，所以日期格式似乎应该写成如下的格式：

这条 ISSUSE 在 2019 年 12 月 25 日 发布

个人感觉日期部分有些太空，是否可以考虑将日期中间的空格删除，修改为：

这条 ISSUSE 在 2019年12月25日 发布

将日期和普通的英文、数字空格的用法区分开。

类似于 10 元/小时这种该如何添加空格呢？还是应该使用类似 10 Yuan/Hour 英语格式或者 10 元每小时的中文格式？
在整句话中，比如「今天租用了一台 10 元/小时的比亚迪小车」，该如何正确使用空格？

批量更新商品信息后，导出的 SKU 名称显示“未指定中文名称”。

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Any idea?

请问，有没有notepad++ 或 sublime 或 vscode 的自动排版插件？

在本指南里的“遇到完整的英文整句、特殊名詞，其內容使用半形標點”章节，使用了这种不符合标准的例子：

推薦你閱讀《Hackers & Painters: Big Ideas from the Computer Age》，非常的有趣。

而根据 CY/T 154-2017 标准第10条——中文句子中夹有英文书籍名、报刊名时，不应借用中文书名，而应以英文斜体表示；中文句子内夹有英文文章的标题，标题应使用英文正体字，以中文引号标示。

例如：

**注意：**这是一个不可逆的操作！
请点击**「这里」**来完成操作。

这样在一些解析器上是可行的。在 GFM 中的 Emphasis and strong emphasis 是这么讲：

A left-flanking delimiter run is a delimiter run that is (1) not followed by Unicode whitespace, and either (2a) not followed by a punctuation character, or (2b) followed by a punctuation character and preceded by Unicode whitespace or a punctuation character. For purposes of this definition, the beginning and the end of the line count as Unicode whitespace.

A right-flanking delimiter run is a delimiter run that is (1) not preceded by Unicode whitespace, and either (2a) not preceded by a punctuation character, or (2b) preceded by a punctuation character and followed by Unicode whitespace or a punctuation character. For purposes of this definition, the beginning and the end of the line count as Unicode whitespace.

大概意思是：左右两侧的定界符，里边第一个是标点符号，外边就要紧接一个标点符号或者空格。

所以我想到两种方法：

1. 定界符外添加空格

   注意： 这是一个不可逆的操作！
   请点击 「这里」 来完成操作。

2. 全角标点符号放置于定界符外

   注意：这是一个不可逆的操作！
   请点击「这里」 来完成操作。

大家怎么看？

Hello。

请问，大会于 2011年11月11日 举办中的数字跟年需要空格吗？

In the section concerning abbreviations, this sentence is used as a example:

我們需要一位熟悉 JavaScript、HTML 5，至少理解一种框架（如 Backbone.js、AngularJS、React 等）的前端開發者。

A WHATWG blog states that “HTML5” should not contain spaces :

What’s the right way to spell “HTML5”? The short answer is: “HTML5” (without a space).

One can also see this on the W3C HTML5 homepage.

Ref: #18 (comment)

在 2011 年 12 月 31 日发布的《标点符号用法》中有以下规定：“4.3.3.3 表示声音巨大或声音不断加大时，可叠用叹号；表达强烈语气时，也可叠用叹号，最多叠用三个叹号。在没有异常强烈的情感表达需要时不宜叠用叹号。”

在處理 microsoft/vscode-python#496 時發現中文界並沒有普遍被接受的刪節號用法。或許應該解釋刪節號有自己的字元，不要使用三個句點 ... 甚至有人會用 。。。。

台灣標準規範刪節號應居格中，一格三點，共兩格六點。在 Unicode 定義中，由於一般字型的刪節號（U+2026 horizontal ellipsis）採用西式標準置底，許多軟體、文本改用 U+22EF midline horizontal ellipsis，如 Apple 所有軟體均使用此字元，但亦有聲音認為此為錯誤用法，應使用 U+2026。另外由於六點佔的空間略大，許多軟體只使用一格三點，以維持選單排版緊湊。由於目前沒有普遍被接受的使用慣例，我個人對於應使用一或兩個，以及應該使用哪個字元並沒有特別意見（或許可以在爭議部分建議個人偏好）。

不要使用不道地的縮寫

筆誤：道地
應爲：地道

rt

因为表面上谷歌把 AngularJS 更名为 Angular 了。

而实际上两者的关系复杂到连 维基百科 都没写明白怎么回事：

• Angular 无中文维基页面，英文维基是 Angular (web framework)
• AngularJS 中文维基是 Angular，英文维基是 AngularJS

所以别淌这个浑水了。

在使用中，發現一些邊緣情況：

1. 如 #48, #102 所言，「2019 年 12 月 25 日」這樣的寫法使得日期距離太大，影響美觀。

2. 如 #59 所言，專有名詞應當不空格，例如應當寫為「U盘」而不是「U 盘」。但「專有名詞」的判斷十分模糊，如「維生素C」、「Unicode聯盟」是否應當添加空格？

3. （接第 2 條）在同一上下文中，很可能同時出現「來 M」和「M巾」，此時若判斷前者非專有名詞，而後者為專有名詞，就會出現排版上不一致的情況，影響美觀。

4. 「豆瓣FM」等按照官方所定義的格式不添加空格，但上下文的其他短語添加空格，在某些字型下差異明顯，影響美觀。

進一步地，對於在 HTML 中的排版，有以下疑問：

1. 有中文譯名的英文專有名詞，在中文環境下，是否應當標注為英文環境？

如：

<p lang="zh-HK">使用 Google 搜尋</p>

還是：

<p lang="zh-HK">使用 <span lang="en-US">Google</span> 搜尋</p>

2. 沒有中文譯名的英文專有名詞，在中文環境下，是否應當標注為英文環境？

如：

<p lang="zh-HK">使用 JavaScript 編寫</p>

還是：

<p lang="zh-HK">使用 <span lang="en-US">JavaScript</span> 編寫</p>

3. 中英混合的詞，在中文環境下，英文部分是否應當標注為英文環境？

如：

<p lang="zh-CN">豆瓣FM</p>

還是：

<p lang="zh-CN">豆瓣<span lang="en-US">FM</span></p>

使用的示例：

推荐你阅读《Hackers & Painters: Big Ideas from the Computer Age》，非常的有趣。

通常不推荐对英文标题使用中文书名号，习惯上使用引号、斜体或下划线来表示英文标题、文章和书名等。

所以示例应为：

推荐你阅读 "Hackers & Painters: Big Ideas from the Computer Age"，非常的有趣。

关于使用全角还是半角引号，目前还需要讨论。
可以参考：https://qks.cqut.edu.cn/info/1017/1325.htm

文档中未生成目录。请问是使用了不兼容 GFM 的语法，还是有意留下的彩蛋呢？

{:.no_toc}

    * TOC {:toc}

如果是意外，可以试试这个工具 DocToc，自动生成 TOC，便于项目管理 😄 也避免了手动书写带中文锚点。

例如我很 😄。

如何处理表情符号和文本，标点之间的留白？