小狼毫的圆点号（间隔号）与众不同

[GoogleCodeExporter]

請寫下能夠重現此狀況的操作步驟：
1. 
打开Winwods自带Notepad程序，用小狼毫输入圆点号，用谷歌拼音
、华宇拼音 输入圆点号。
2. 小狼毫输入的，呈现方框，余者不会。
3. 
在Wordpad中输入，放大来看，发现小狼毫输入的圆点，与众不�
��。

所得的結果是這個樣： Notepad中，圆点呈现方框。
預期結果該是那個樣： Notepad中，圆点应为圆点。

請提供以下信息，幫我們定位問題。

1. 輸入法的款式：小狼毫
   輸入法版本號：0.9.26.1

2. 操作系統類型：Windows
   操作系統版本：7 SP1 英文

3. 輸入方案名稱：朙月拼音、地球拼音

還想再說幾句：圆点号（间隔号），常用来隔开西方人的姓��
�名，如：亚伯拉罕·林肯。

Original issue reported on code.google.com by novvo...@gmail.com on 13 Oct 2013 at 3:33

[GoogleCodeExporter]

按鍵「*」對應的選項中收錄了這兩個符號 U+30FB, U+00B7 
前者是全角的中點，後者是半角的西文中點。用戶可根據使��
�場景取捨。

在中國大陸，習慣上借用 U+00B7 
作爲間隔號，一些簡體中文的字體把 U+00B7 
顯示成中文符號的寬度。

在微軟雅黑等新字體中，U+00B7 
被處理爲西文符號，只佔半個漢字的寬度，搭配中文不太協��
�。全角符號 U+30FB 在微軟雅黑中可正確顯示。其 Unicode 
說明爲「片假名中點」，然而在 Unicode 
裏面中文、日文是共用一套標點符號的，Mac 
OS自帶的拼音輸入法已有將其用於中文全角間隔號的先例。

參考鏈接：

http://zh.wikipedia.org/wiki/%E9%97%B4%E9%9A%94%E5%8F%B7

http://www.zhihu.com/question/20271115

Original comment by contral...@gmail.com on 14 Oct 2013 at 8:24

[GoogleCodeExporter]

U+30FB KATAKANA MIDDLE DOT 
是日文专用标点符号，绝大多数中文字体都不支持它。「然��
�在 Unicode 
裏面中文、日文是共用一套標點符號的」这个说法在这个标��
�符号上并不对。
而且 U+30FB KATAKANA MIDDLE DOT 和 U+00B7 MIDDLE DOT 
二者不是全角半角的对应关系。U+30FB 
是正常的东亚字符，它有个 legacy 的半角版本 U+FF65 HALFWIDTH 
KATAKANA MIDDLE DOT。U+00B7 是中文借用西文的非 ASCII 
字符，和弯引号一样没有全角半角可言，样式如何全凭字体��
�计。

中文环境下除非特意做 hacking，否则不应当使用非主流的 
U+30FB，以免带来问题——比如在 fallback 
不可靠（没有使用支持 U+30FB 的字体并且没能 fallback 
到日文字体）的环境下无法显示。
微软雅黑有好多个标点都很奇葩，这整个字体就是个怪胎，��
�了它而影响所有平台的用户得不偿失。而且个人感觉从 
typography 角度来看，间隔号用半宽其实没什么不好的。

建议还是提升 U+00B7 的优先级，将 U+30FB 的优先级降低。
并且最后在选单中 comment U+00B7 为「间隔号」，而 U+30FB 
为「片假名中点」。

Original comment by liang...@gmail.com on 21 Oct 2013 at 6:45

[GoogleCodeExporter]

好。

Original comment by contral...@gmail.com on 21 Oct 2013 at 6:56

• Changed state: Accepted

[GoogleCodeExporter]

佛振真好说话……

另外多说几句。

OS X 自带中文输入法在标点符号方面有很多怪癖，比如：

- 用 U+22EF MIDLINE HORIZONTAL ELLIPSIS 当中文省略号用
- 用 U+2500 BOX DRAWINGS LIGHT HORIZONTAL 当中文破折号用
- 以及 U+30FB 这个事情

这些怪癖为中文互联网带来了许多互通问题（比如 Mac 
用户输入的破折号和省略号在 Windows 
用户那里看不到）。苹果输入法团队曾经很不懂中文，实在��
�是个值得学习的榜样。
近来版本的 OS X 
自带中文输入法其实已经在这方面改善了不少，标点符号的��
�些非主流字符基本都已经换掉了。

Original comment by liang...@gmail.com on 21 Oct 2013 at 7:07

[GoogleCodeExporter]

Original comment by contral...@gmail.com on 31 Oct 2013 at 7:57

• Changed state: Fixed

[GoogleCodeExporter]

我刚刚才意识到：
现在除了自动标记的「全角/半角」，是不是其实没有办法给�
��隔号和片假名中点标上它们的名字？

Original comment by liang...@gmail.com on 5 Nov 2013 at 12:11

[GoogleCodeExporter]

是。

Original comment by contral...@gmail.com on 5 Nov 2013 at 2:22

[GoogleCodeExporter]

如果真的决心要避免用户使用 U+30FB KATAKANA MIDDLE 
DOT，又无法标记名称，可能需要把 U+30FB 
挪到最后（第7个）去藏着（真正需要它的专业用户自然会找�
��它，或者自定义排序）……不然连我看到连续两个圆点在候
选条中都会糊涂得不知道该用哪个。
如果不尽全力避免用户误用 
U+30FB，那么尽管现在已经大动干戈地改了那么多处候选字符��
�词组里的字符，中州韵恐怕还是会向各种文件和网站中释放�
��少 U+30FB，这样很遗憾……

另外我不知道把 U+30FB 统一改成 U+00B7 
会不会导致台湾用户反对。虽然 U+30FB 
既不是台湾最常用的字符选择（他们经常用「．」U+FF0E 
FULLWIDTH FULL 
STOP），还会造成兼容问题，但至少看起来像是对的。而 
U+00B7 经常都会被西文字体显示为并非一汉字宽的 propotional 
模样。
维基百科社区曾经有过热烈的争论…… 
http://zh.wikipedia.org/zh/Help_talk:%E5%A6%82%E4%BD%95%E8%BE%93%E5%85%A5%E9%97%
B4%E9%9A%94%E5%8F%B7

Original comment by liang...@gmail.com on 5 Nov 2013 at 6:05

[GoogleCodeExporter]

我沒有決心要避免使用他。相反如果有人相中了第二個圓點��
�我還會爲他通過輸入法挑選到一個有用的符號而感到高興。

Original comment by contral...@gmail.com on 7 Nov 2013 at 7:03

[GoogleCodeExporter]

问题恰恰就在于「相中、挑選」。
现在的情况导致用户在未知风险的情况下误用 
U+30FB。把两个几乎一样的字符摆在并不了解事情后果的用户��
�前，用户选了 U+00B7 还是 U+30FB 
并不是信息对等的「相中」和「挑選」，完全是被迫赌博。
误用片假名中点而遭受困扰时不会有多少人有能力排除问题��
�只会觉得困惑。你可能会为他感到高兴，但绝大多数情况下�
��，这个字符对他并不比 U+00B7 更有用，而 U+30FB 
给他造成问题时却没人管他了。
没有必要在这种事情上给大部分用户带来麻烦。真正想用 
U+30FB 
的专业用户也不会因为它的默认排序有变化而受到多少影响��
�

Original comment by liang...@gmail.com on 8 Nov 2013 at 10:27

[GoogleCodeExporter]

如果顯示效果相同，用戶有啥理由不選２而一定要選３呢。
如果顯示效果不同，用戶選了視覺上符合他需要的，這不很��
�嘛。
高手們才要講究內碼用得合理合法，你所擔心的問題，太專��
�了。但是專業的人，是不會誤用的。
不明真相的用戶打字的目的，往往就只是爲了讓人看、或者��
�印出來看？
等等吧，如果有「用戶」反映強烈那就再改一次，如果沒有��
�說明這對普通用戶不造成困擾……

Original comment by contral...@gmail.com on 8 Nov 2013 at 11:29

[GoogleCodeExporter]

我的观点是：这两个字符外形相近，普通用户分不清他们，��
�是误用 U+30FB 时面临隐患；即使一些用户认为 U+30FB 
的外形更符合他们的需求，他们也是在不了解风险的情况下��
�择的。
「不明真相的用戶打字的目的，往往就只是爲了讓人看、或��
�打印出來看」——这句话说得很对。而 U+30FB 
的问题恰恰就在于它无法保障这种基础需求——用户这边输��
�得好好的，结果把文件给别人发过去，一经转手，就不知道�
��段文本会显示成什么样了，而且甚至自己把一段文本复制到
另一个地方都会显示出方框。完全不可靠。

我担心的问题并不专业，但这确实是专业界应当担心的问题��
�而且专业人士（包括我这种半专业的）遇到两个近似字符时�
��会困扰，不知这俩字符谁是谁——我每次输入间隔号时都得
想一下「噢……现在还没发布新版，片假名中点在更默认的��
�置，所以后面那个是我要的间隔号」才能确认。普通用户只�
��觉得，「好奇怪啊，这输入法居然有两个圆点，该选哪个呢
？要不然随便选一个？」
输入法是中文用户生活中的基础设施，保证输出可靠的字符��
�这是最基本的责任。

这不是「內碼用得合理合法」的问题，这是保证输出的字符��
�造成问题。这纯粹是在实际应用中规避风险的考量，不是理�
��上哪个字符的语义或者什么更合理。

你肯定明白，有没有用户联系上你来反映问题，和这个问题��
�否对不少用户造成困扰，这两件事关系很小……
嗯，先等等吧……我再多嘴就显得很不尊重开发者了……

Original comment by liang...@gmail.com on 8 Nov 2013 at 11:49

[GoogleCodeExporter]

嗯……算了，聽上去有點道理，那就改改吧，也好讓我喜歡��
�※出現在第一頁。
只是強迫症怎麼辦？我一向把相似的符號放在一起，看上去��
�是精心整理過的。

Original comment by contral...@gmail.com on 9 Nov 2013 at 6:35