Re: 中英文字中的間隔

和您探讨这个“空格”的问题实在让我收获很多，有了不少更加深入的思考。
只是因为我几个小时之后就要于凌晨出发去旅行，所以恕我暂时来不及详细阐明我的回应了。

> 您反覆強調加入空格符合中、西文的習慣，但事實上，中文從來不使用「半型空格」；且在一篇中文文章裡中文乃屬「主位」、外文為「客位」，客隨主便下中文遇外文不加空格是較為合理的。空格符合「兼容兩種文字的分詞習慣」又是何以見得呢？

可以说严禁的中文排版中是从来不用半形空格的（此时排除了您上一篇回复的 Yahoo!
奇摩的截图中出现的这种比较不主流的用空格来断句的情况），中文不“要求（我在九月三十日的邮件中反复强调“要求”）”用空格断词，不过加上空格来断词或断句（比如一些幼儿读物和对外汉语读物）往往会让句子的结构更加明了。但如果取消外文中的空格，带来的是阅读难度大大上升。
这是“不要求”与“要求”的区别。
所以我们在交界处试图兼容的时候就尽量在一方可以忍受的范围内满足另一方的要求。

当然，您可以说中外文交界处的文字差别已经是足够明显的断词了，那就引出了我前面一直说得不够清楚的问题，那就是外文文本中的空格的节奏感。这像是一种纯粹视觉美感，也是读者在阅读时的潜意识期待，那就是每个词前后都有空格（这样的视觉样式是来源于语义的，来源于断词）。如果在中文中引用的外文词组或断句前后不插入空格，看起来就像您说的一样“有點擠”。


> 我希望以<span lang="XX">的方式「加上空白」並非為了語意，而是為了美觀（我的意思是，lang="xx"符合語意，但以CSS加上空白則否）。排版軟體提供的漢字、拉丁文間隔我覺得也是為了美觀因素。如果設計師、編輯等認為手加空白才符合語意，當與lang="xx"共用、前後手動加上空白，並取消CSS的前後間隔。

我的思路往往是：理性的美观是最美的。所以我试图思考许多人习惯在中外文之间插入空格的深层原因。我觉得语义（不仅仅是“文字不同”这一语义，还有“断词”的习惯这样的很基本的语义）是根本原因，它影像了人们对文字的感知和决断。

> 再來看下圖（http://cl.ly/2dic），這是我用NeoOffice實驗的漢字、英語（拉丁字母）混用示例（中西文使用相同字體「Hiragino Sans GB」）。
> Content
> 不難看出辦公軟體所加的間隔也小於一個半型空白，美觀與否我覺得還是比較重要的因素。

这个，我不得不说不同的软件有不同的习惯，在 InDesign 中，1/4em 是默认设置。不知这里有没有 QuackXpress 的用户来给个参考例子。

> 討論了這麼多，我也發現了一些矛盾的地方，不得不舉幾個反例：
> （略）
> 這就尷尬了！明明是中文、亞洲方塊字語言或大家都看得懂的阿拉伯數字（應該就不用加「lang="ar"」了吧），但卻又同時是拉丁字母。此時該不該加空格、又該怎麼加（尤其是<en>Chinese</en> <zh>Kungfu</zh>的地方）才好？現在應該沒有zh-pinyin之類的語言屬性值吧？！或其實可以用LA（Latin）？

其实在我看来，因为拼音成文的时候也是要求空格断词的，所以其实我以往在写作中也是写成“找到專屬於 ni 的 ta：”这样的。
顺便说一下，我以为“傑弗瑞想上道館學<span
lang="en">Chinese</span>Kungfu（Gongfu）。”这句话写成“傑弗瑞想上道館學<span
lang="en">Chinese Kungfu</span>（Gongfu）。”为宜。因为“kungfu”（或“kung
fu”）已经是一个英语从汉语借去的词了。日常的汉语语境中我们是不用这个说法的。不过因为我不太清楚台湾的情况（因为台湾对外来文化和外来词汇的吸纳似乎更加自由和包容），所以或许台湾人会对这个词有和我们不一样的认知。
“非中文的漢字羅馬字”，情况与拼音类似，因为它们成文的时候也是需要空格来断词的。
关于“阿拉伯數字”，其实我也一直在想我的做法是不是比较极端，因为我一直也是写成“民國 99 年 10 月 1
日”这样的，阿拉伯数字中的“,”或“.”也是在进行着和半角空格类似的作用。不过我认为阿拉伯数字并不能说是拉丁字母，我们常见的阿拉伯数字的写法只是拉丁字母文字中的书写习惯而已，它不属于任何一个语言。（顺便提一下，如今在阿拉伯世界和印度都还在用“现代阿拉伯数字”的祖先的后代，比如印度数字是这样的“०१२३४५६७८९”，而阿拉伯文中的数字是“۰۱۲۳۴۵۶۷۸۹”；这么看来，从印度数字开始的这一套数字表示方法拥有在不同文字中不同的书写习惯）。中文中的阿拉伯数字书写习惯与拉丁字母中一致，给中文内部的阿拉伯数字标注其他语言或文字的标签是不妥的。

> 再貼一張圖（http://cl.ly/2e6d），取自Yahoo!奇摩台灣新聞首頁，「推測」這是由報社直接提供的新聞稿，Yahoo!並未再加入其它文字編輯。顯示在台灣，正式文書並沒有於中、西文混排時加入半型空白。

这张图中仅仅三行就出现了两种对空格的用法，实在难以看出 Yahoo! 奇摩有统一、一贯并且严格的 typography
准则，所以我觉得这个参考价值不足。大众媒体的精力有限，难以严格遵守 typography 准则，这是很可以理解的。
而如果中文世界也像英文世界一样拥有如此完善而且各领风骚的几个 style
guide，相信也是一件幸事：http://en.wikipedia.org/wiki/Style_guide

只希望在各个新标准的制定中能有一贯坚持的明确理念（最好这个理念还是充分吸取了各类主流观点）就好。

我因为即将启程旅行，不得不暂时退出“空格”的讨论了。
为了避免自己在旅途中 geek 精神一再被猛烈唤起然后没法尽情享受旅行，我将暂时把 public-html-ig-zh@w3.org
加入“标记为已读后存档”的过滤器中，所以可能暂时关注不了进一步的讨论了。
这些天收获颇丰，再次感谢大家。

梁海
北京大学外国语学院印地语二〇〇九级本科
印度新德里
二〇一〇年十月二日

在 2010年10月2日 下午6:26，Ethan Chen <chief@ethantw.net>写道：
>
> 再貼一張圖（http://cl.ly/2e6d），取自Yahoo!奇摩台灣新聞首頁，「推測」這是由報社直接提供的新聞稿，Yahoo!並未再加入其它文字編輯。顯示在台灣，正式文書並沒有於中、西文混排時加入半型空白。
>
>
> 在 Oct 2, 2010 7:35 PM 時， Ethan Chen 寫到：
>
> 所以如果让一个 0.25em的“半型空白”来插入中外文的交界处，它的宽度实际上就不到 0.1em，这实在太小了（甚至比英文排版中最窄的用于 em dash 两端的1/8em 的空白还小），这样达不到兼容两种文字的分词习惯的目的。
>
> 为了达到尽量优美的排版效果，在中外文的交界处使用尽量兼容两方习惯的排版方式（比如增大间距或插入空格），是非常有逻辑而且效果更优的。
>
> 当然不用。因为在英文文本中，英文与引号之间本来就是没有空格的；而中文文本中，中文与引号之间也是没有空格的；于是综合二者的习惯，不用空格。
>
> 您反覆強調加入空格符合中、西文的習慣，但事實上，中文從來不使用「半型空格」；且在一篇中文文章裡中文乃屬「主位」、外文為「客位」，客隨主便下中文遇外文不加空格是較為合理的。空格符合「兼容兩種文字的分詞習慣」又是何以見得呢？
>
> 所以如果让一个 0.25em的“半型空白”来插入中外文的交界处，它的宽度实际上就不到 0.1em，这实在太小了（甚至比英文排版中最窄的用于 em dash 两端的1/8em 的空白还小）
>
> 我希望以<span lang="XX">的方式「加上空白」並非為了語意，而是為了美觀（我的意思是，lang="xx"符合語意，但以CSS加上空白則否）。排版軟體提供的漢字、拉丁文間隔我覺得也是為了美觀因素。如果設計師、編輯等認為手加空白才符合語意，當與lang="xx"共用、前後手動加上空白，並取消CSS的前後間隔。
> 再來看下圖（http://cl.ly/2dic），這是我用NeoOffice實驗的漢字、英語（拉丁字母）混用示例（中西文使用相同字體「Hiragino Sans GB」）。
> 不難看出辦公軟體所加的間隔也小於一個半型空白，美觀與否我覺得還是比較重要的因素。
>
> 討論了這麼多，我也發現了一些矛盾的地方，不得不舉幾個反例：
>
> 遇到中文拼音（羅馬字）的時候，如：
>
> 找到專屬於ni的ta：
> 那個MM很火辣；
> 那個非洲人的HSK（漢語水平考試）成績很好；
> 我想去參觀台灣T'aipei的Shilin夜市；
> 傑弗瑞想上道館學<span lang="en">Chinese</span>Kungfu（Gongfu）。
>
> 遇到非中文的漢字羅馬字的時候，如：
>
> 日本<span lang="ja|en">Tokyo</span>街上的<span lang="ja">sakura</span>真是美呆了；
> 多吃<span lang="ko">kimchi</span>有益身體健康。
>
> 遇到已全球通用的阿拉伯數字的時候
>
> 民國99年10月1日；
> 我剛剛花了美金1,000塊。
>
> 這就尷尬了！明明是中文、亞洲方塊字語言或大家都看得懂的阿拉伯數字（應該就不用加「lang="ar"」了吧），但卻又同時是拉丁字母。此時該不該加空格、又該怎麼加（尤其是<en>Chinese</en> <zh>Kungfu</zh>的地方）才好？現在應該沒有zh-pinyin之類的語言屬性值吧？！或其實可以用LA（Latin）？
>
>
>
>

Received on Saturday, 2 October 2010 18:30:16 UTC