林健的BLOG

　　晚上为 Nokia S60v2 老机型用户写了一个 PC 端的小工具——vCard Assistant，用于将含有中文姓名的 vCard 文件（可以是 GB、UTF-8 或 UTF-16LE 编码的）转换成 ASCII 字节编码 UTF-8 形式；并可将 vCard 3.0 格式转为 2.1 格式，便于在某些对 vCard 中文姓名或 3.0 标签支持不好的手机中导入联系人。效果如下：
　　输入：

BEGIN:VCARD
VERSION:3.0
N:;张三
FN:张三
TEL;TYPE=CELL;TYPE=VOICE:13811112222
EMAIL;TYPE=PREF;TYPE=INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:;李四
FN:李四
EMAIL;TYPE=PREF;TYPE=INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

　　输出：

BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E5=BC=A0=E4=B8=89
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E5=BC=A0=E4=B8=89
TEL;CELL;VOICE:13811112222
EMAIL;PREF;INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E6=9D=8E=E5=9B=9B
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E6=9D=8E=E5=9B=9B
EMAIL;PREF;INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

　　这种格式可以被 Best vCard for S60 等软件读取，导入手机通信录。
　　vCard Assistant 下载地址（包含源代码）：
　　http://files.linjian.org/dotNet/VCardAssistant.zip
　　http://www.linjian.cn/files/dotNet/VCardAssistant.zip
　　（需要 .Net Framework 3.5 平台支持）

---

　　我为什么要写这个东西呢？主要还是自己的需求。我使用的 Nokia 6600 的 PC Suite 只支持从 IBM Lotus Notes、Microsoft Outlook 这类庞大的程序或 Windows Address Book 这种已被放弃的格式中导入联系人。我没有使用这两个商业软件，也不愿使用已经失去官方支持的 WAB 格式，而选择使用跨平台的、广为各类软件支持的 vCard 格式管理联系人，以便在多个系统、软件中直接共享。以前同步联系人时，先将 vCard 导出为 CSV，再使用虚拟机中的 Windows XP 通信录将 CSV 转换成 WAB 格式，然后通过 PC Suite 同步，比较折腾。现在只需要将 vCard 转换一次，通过蓝牙或 Email 发到手机上，用手机端的软件做同步，简便不少。
　　事实上我以前也尝试过用 Google Sync 服务在线同步联系人（Gmail 也支持 vCard 导入导出），但同步过程总是异常停止。换用其它一些 SyncML 同步服务问题依旧。最终我在 mobical 网站发现一句话：“Nokia 6600: This device has a known issue where the synchronization may stop working at any time. As far as we can tell this is a bug in the Nokia software.”原来这是 Nokia 6600 的 bug……我也没有找到其它免费的 SyncML for S60v2 客户端，只能作罢。

　　Native Client（简称 NaCl）和 Xax 分别是 Google 和 Microsoft 近一年来开展的有关在 web 浏览器中安全执行本地代码的研究性工作。它们都已有实验原型，其功能类似于现在的 ActiveX，但相比只能在 IE 中运行的 ActiveX，二者都支持跨操作系统、跨浏览器运行（Xax 还声称可以跨体系结构），同时具备比 ActiveX 更完善的安全模型。这类在本地系统直接运行的代码相比 Flash、Silverlight、Java Applet 等虚拟机、JIT 机制，在性能、功能灵活性方面有优势，也便于移植遗留应用。
　　NaCl 是开源的，其项目主页提供了大量的文档和示例程序，并开放了讨论区。加之 Google IO 大会的宣传，它得到了行业和媒体相对较多的关注，不少人认为它会成为“ActiveX 杀手”。而 Xax 在网上只有一个简单的论文页面，官方没有提供实验产品和更详细的资料下载，因此网络上关注它的文章很少，可能只在学术界为人知晓。
　　NaCl 和 Xax 已发表的论文分别是：
　　● Native Client: A Sandbox for Portable, Untrusted x86 Native Code
　　● Leveraging Legacy Code to Deploy Desktop Applications on the Web
　　从论文可以看出两项工作的侧重点有所不同。NaCl 的论文发表在 S&P/Oakland 2009，主要在论证其模型的安全性，欲打造一个安全且跨平台的 ActiveX 替代品；而 Xax 的论文发表在 OSDI 2008，更强调其软件结构的特性利于遗留应用快速移植到与操作系统、浏览器无关的 web 平台。
　　NaCl 的结构比 Xax 简单，更类似于 ActiveX。它通过浏览器插件加载应用代码，创建一个沙盒进程来执行不可信的代码，直接在浏览器窗口中输出结果。不可信的代码不能直接访问本地文件系统和网络接口，而可以通过 IMC（Inter-Module Communications）间接调用一些可信的服务模块来访问本地资源。这些模块也是一些浏览器插件，可以通过它们实施安全策略。因此，NaCl 客户端安装和运行过程不需要特殊权限。Xax 的结构相对复杂，它的浏览器插件称为 Xax Monitor。Xax Monitor 包含一个 web proxy，浏览器的 HTTP 流量均要经过它。当 Xax Monitor 发现有 Xax 应用的链接时，它会从远程下载 Xax 应用。Xax Monitor 将下载来的应用代码与 PAL（Platform Abstraction Layer）模块连接，作为本地进程（称为“picoprocess”）运行。picoprocess 通过共享内存与 Xax Monitor 交互，由 Xax Monitor 为其执行封装过的、有限的、安全的系统调用（称为“xaxcalls”）。Xax Monitor 同时作为本地的 web server，通过 HTTP 消息与浏览器通信，处理浏览器到 picoprocess 的输入输出。Xax 使用系统特定的机制（Linux 的 ptrace 或 Windows 的虚拟设备驱动）来保证安全，在 Windows 下安装时需要超级用户的权限。
　　NaCl 修改了一套 C/C++ 工具链，开发人员下了大量工夫让这套工具链生成的二进制代码安全可靠。其中包括严格的指令对齐、禁用系统调用和中断（只能通过 IMC 间接调用系统服务）、安全的跳转指令等。使用自己的加载器，使得不含系统调用的二进制代码可以跨操作系统加载执行（限于 x86 平台）。Xax 完成的工作类似，生成代码安全方面没有像 NaCl 那样严格控制，而是通过在运行时使用 Linux 的 ptrace 或 Windows 的虚拟设备驱动来阻止恶意添加的系统调用，同时接管内存分配工作，安全地管理堆上数据分配。
　　Xax 所谓的跨体系结构，目前是在 x86 和 PowerPC 平台上分别做了 ABI（Application Binary Interface）各异的实现，因此运行在不同体系结构上的应用的二进制代码并不能互相兼容，只是说 Xax 机制已能在不同的体系结构上成功实现。作者提出可以用 Binary rewriting 的方法使得 x86 代码在其它平台上翻译执行，做到真正的跨体系结构，不知道现在实现没有。
　　NaCl 的图形输出与本地程序渲染基本无异，用户体验较好，官方给出的 Quake 示例运行得很流畅（下图是在我的 Ubuntu 9.04 / Firefox 3.5 上运行的截图）。而对于 Xax，浏览器只能通过 HTTP 与连接到 Xax Monitor 的 picoprocess 通信，浏览器中的应用界面目前只能使用 HTML、Javascript 等已有技术渲染。论文中给出的 OpenGL 3D 示例使用 PNG 贴图的方式模拟动画输出，达到了 8.8 fps，用户体验比 NaCl、ActiveX 差一些。但相信加强浏览器插件的能力可以改善效果。

　　由于 Xax 没有提供下载试用，所以不方便对比二者实际的编程难度和用户体验。个人感觉从用户角度而言，NaCl 似乎是一项更有吸引力的技术，简单地说它就是安全的、跨操作系统和浏览器的 ActiveX。而 Xax 在部署方式（权限）和界面交互效果方面还有欠缺。从开发人员角度来说，使用 NaCl 或 Xax 开发新应用或移植遗留应用都需要把原来使用系统调用的地方修改成调用 NaCl 可信服务模块或 xaxcalls，同时需要重写界面和 I/O 相关代码。NaCl 对代码有更严格的要求，比如不能使用部分不安全的标准库函数、不能滥用不安全的内嵌汇编指令等。而 Xax 的论文认为向 Xax 移植遗留应用是一件程序化的事，只要按照几个步骤去做，很多修改的代码可以复用。估计类似的步骤也可以应用于 NaCl，从 Quake 的成功移植可以看出 NaCl 在这方面应该不差。

注意：以下论断仅针对目前阶段（2009年7月4日）观察到的 Windows Live 和 Google 服务而言，只代表用户可见的现象，不说明其实现的本质；只说明现状，不代表未来可能的变化。

1. 有关使用非 Hotmail 邮箱注册 Windows Live ID 或使用非 Gmail 邮箱注册 Google Account

1.1.M. 使用原有（非 Hotmail）邮箱注册的 Windows Live ID 与在 Windows Live 网站通过注册 hotmail.com / live.com / live.cn / msn.com 等邮箱得到的 Windows Live ID 的使用范围基本相同，可以直接使用 Messenger、SkyDrive、Spaces、Photos 等服务，只是没有 Hotmail 邮箱（注意：微软启动 Live 战略以后，“Hotmail”的概念泛指一切 Windows Live 邮箱，不限于“hotmail.com”后缀的）。可以认为，通过注册 Hotmail 邮箱得到的 Windows Live ID 只是比用自己原有的邮箱注册的多得到了一个免费邮箱。如果用原有邮箱的 Windows Live ID 登录 Hotmail，会被告知需要开通 Hotmail。

1.1.G. 使用原有（非 Gmail）邮箱注册的 Google Account 与通过注册 gmail.com 邮箱得到的 Google Account 的使用范围基本相同，可以直接使用 Calendar、Documents、Reader、Groups 等服务，只是没有 Gmail 邮箱和 Gtalk 即时通信功能。如果用原有邮箱的 Google Account 登录 Gmail 或 Gtalk，会被告知需要开通 Gmail。

1.2.M. 在已登录原有邮箱注册的 Windows Live ID 后，根据提示开通 Hotmail，相当于重新注册了一个全新的 Windows Live ID，新账号可以使用所有 Windows Live 服务。这个 Windows Live ID 与原先的那个没有任何关联，可以分别独立使用。二者的 Messenger、SkyDrive、Spaces、Photos 等数据独立、互不干扰。

1.2.G. 在已登录原有邮箱注册的 Google Account 后，根据提示开通 Gmail，相当于在原有账号基础上增加了 Gmail 和 Gtalk 服务。这时账户的主 Email 地址自动修改为新的 Gmail 邮箱，原来的邮箱则变成了本账号的关联邮箱。关联邮箱可以同 Gmail 邮箱等价地登录 Google 的各项服务；在部分服务（如 Groups）中，可以使用关联邮箱作为自己的联系方式。但一旦注册了 Gmail，在 Google 的多数服务中就会用 Gmail 邮箱作为用户身份的唯一对外标识。在此之前用户创建的数据不受影响，只是账户名称变了。用户可以解除关联邮箱，解除之后旧数据不会丢失。但需要注意，如果解除关联邮箱之后重新手动关联，部分服务（如 Groups）无法使用新的关联邮箱。

2. 有关 Windows Live Admin Center 和 Google Apps 服务

2.1.M. 在 Windows Live Admin Center 使用自己的域名开通服务，旗下用户得到的服务与在 Windows Live 网站通过注册 Hotmail 邮箱得到的 Windows Live 服务完全一致。自己域名的邮箱就是 Windows Live ID，邮箱后台也是由 Hotmail 提供支持的，名称也叫“Hotmail”。这相当于在 Windows Live 原有的 hotmail.com、live.com、live.cn、msn.com 等域基础上，增加了用户自定义的一个域。

2.1.G. 在 Google Apps 使用自己的域名开通服务，旗下用户得到的服务与一般的 Google Account（无论使用原有邮箱或注册 Gmail）并不相同。自己域名的邮箱并不是可以登录 Google 各项服务的 Google Account，而是仅仅能登录本域的一个账号。Google Apps 相当于为企业、学校等用户群体提供一个适于内部使用的、相对独立于 Google 公共服务平台的“小 Google 服务平台”。在这个小平台中，提供有限的几项服务，如 Mail、Calendar、Documents、Sites、Gtalk 等，不包括 Reader、Groups 等。这些服务体现“内部”特色，在逻辑上与 Google 公共服务平台隔离，例如 Mail 被命名为“[你的域名] Mail”而非“Gmail”；但这并不影响域内用户与其它 Google 用户（包括其它域下的 Google Apps 用户）进行有限的互通，例如可以与跨域的 Gtalk 联系人聊天、共享 Documents 上的文档等。

2.2.M. 通过 Windows Live Admin Center 得到的自己域名的 Windows Live ID 与使用默认域名的 Windows Live ID 处于平行位置，功能等价，没有带来新问题。

2.2.G. 通过 Google Apps 得到的自己域名的账户并不是 Google Account，因此如果用户需要使用完整的 Google 服务，需要另外注册 Google Account。如果用户使用基于 Google Apps 的自己域名的邮箱注册 Google Account，可能带来一些微妙的问题：

2.2.G.1. 总体上说，这与 1.1.G、1.2.G 节所述的“使用原有（非 Gmail）邮箱注册的 Google Account”相似。

2.2.G.2. 对于 Documents 服务，用户分别拥有“Google 公共服务平台”和“本域服务平台”上的两套版本，分别在不同的界面使用不同的密码登录，数据独立。如果注册了 Gmail，则 Gmail（Mail）、Gtalk 服务也类似地维持两套版本。

2.2.G.3. 对于 Calendar、Sites 服务，本质上也有两套版本。如果没有注册 Gmail，则会因账户重名问题只能在优先注册的平台上使用，第二套版本无法启用；如果注册了 Gmail，则可以保证两个平台上拥有不同的账户名称，两套版本可以并存，数据独立。

2.2.G.4. 对于 Reader、Groups 等“本域服务平台”没有提供的服务，可以在“Google 公共服务平台”上使用，不存在多版本问题。

3. 总结及对创建个人 Windows Live / Google 统一账号的建议

3.1. Windows Live 对非原生邮箱账号的处理比 Google 更简单、更易于理解一些，区别一在能否直接使用即时通信工具，二在注册原生邮箱之后对原有账号的影响。我们可以通过单独注册 Gmail 邮箱的方法让 Google 实现类似 Windows Live 的“双账号”行为，但不能在 Windows Live 中为非原生邮箱账号添加额外的 Hotmail。

3.2. Windows Live Admin Center 与 Google Apps 是两个定位有所不同的产品，Windows Live Admin Center 强调用户域与 Windows Live 平台的相对统一，而 Google Apps 强调用户所属组织的独立性。它们的功能行为满足了不同类别用户的需求。

3.3. 对于企业、学校等有特殊需求的用户，或者仅偏好于 Windows Live / Google 一方的用户，以及对账号不在意或不愿公开的用户，不在本文讨论范畴之内。

3.4. 对于追求“使用并公开统一账号，访问 Windows Live / Google 服务”的用户，建议方案为：通过注册 Gmail 邮箱得到 Google Account，享受所有 Google 服务；然后使用这个邮箱注册 Windows Live ID，享受 Hotmail 之外的所有 Windows Live 服务。因为对外统一接口是 Gmail 邮箱，所以 Windows Live 上的联系人可以直接联系到用户，无须经过 Hotmail 邮箱。相反地，如果首先通过注册 Hotmail 邮箱得到 Windows Live ID，再用此邮箱注册 Google Account，则无法使用 Gmail 与 Gtalk。如果用户不在意 Gtalk，则此方案也可行；否则此方案不佳，因为如果用户在此基础上注册了 Gmail 或 Gtalk，多数 Google 服务中的用户账号会变化，不符合“统一账号”要求。

3.5. 对于追求“使用并公开统一的个性化（自己域名的）账号，访问 Windows Live / Google 服务”的用户，没有像上面那样完美的方案。建议的两种方案为：

3.5.1. 使用 Windows Live Admin Center 开通自己域名的邮箱，即可享用所有 Windows Live 功能。使用这个邮箱在 Google 注册账号，即可使用 Gmail、Gtalk 以外的几乎所有 Google 服务。如果用户不在意 Gtalk，则到此为止。如果用户在此基础上注册了 Gmail 或 Gtalk，多数 Google 服务中的用户账号会变化，不符合“统一账号”要求。不过用户也可以在 Google 之外使用自己的服务器搭建 Jabber 服务，与自己的域名绑定，现实与 Gtalk 的互通，但这提升了实现成本和技术难度。

3.5.2. 使用 Google Apps 开通自己域名的邮箱，即可享用部分 Google 服务（关键是有 Mail 和 Gtalk）；然后使用这个邮箱注册 Windows Live ID，享受 Hotmail 之外的所有 Windows Live 服务。再使用这个邮箱注册 Google Account，享受其它 Google 服务。注意不要开通 Gmail，原因同上，且此举是无法恢复原状的！此方案的缺点在于 2.2.G 节所述的部分服务双版本共存或双版本冲突的问题，使用时需要格外注意，防止混淆。

3.6 对于新启用统一账号的用户，3.4、3.5 节提出的方案可以在一定程度上满意其需求。但对于已经在不同平台上使用了不同账号的用户，迁移到新的统一账号上来却是不方便的。主要的问题是用户数据无法同步迁移。目前 Windows Live 和 Google 提供的关联邮箱功能，主要解决的只是多账号登录问题，没有太关注内容同步，这也许是它们下一步有必要努力的方向。

附录A. 我个人的统一账号迁移方案：基于 3.5.2 节方案，前两个步骤相同，但没有注册新的 Google Account 和 Gmail。访问 Google 服务仍然使用原来的 gmail.com 账号。主要的考虑是：

A.1. 我原来在 Windows Live 上使用的服务以个人存储为主、人际交流为辅，内容易迁移；即使不迁移也无妨，因为大多是自己使用，不对外公开交流。因此这个账号可以停止维护，只增加必要的邮件监控或转发。

A.2. 我原来在 Google 上使用的服务以人际交流为主（如 Reader 和 Documents 上的共享、Groups 中的群组和帖子），如果迁移，对个人和其他联系人都有一定的时间和劳动成本。

A.3. 我关注的统一接口的三个要件是 Email / MSN / Gtalk，这一方案满足了此要求。缺陷只是在访问 Google 服务的时候没有使用统一的账号，但这并不影响对外公开的接口。且 Google 双平台 cookie 独立，方便同时登录 Google Account 和 Google Apps 账号，互不干扰。

　　首先声明，我不是搜索引擎方面的专家，以下内容仅仅是实验结果和推测。
　　多语种搜索引擎的设计实现中，会遇到一个问题：多语同文。例如英语之外，还有多种语言使用拉丁字母；俄语之外，也有其它语言使用西里尔字母；汉字不仅在中文中出现，也在日文和韩文中使用；中文还区分简体繁体，字形与其使用地域有一定关联。如果输入一个关键字，这个关键字在使用相同字符体系的不同地区、不同语言中恰好都是合法的词汇，那么应该返回哪种语言的结果集呢？
　　很多搜索引擎都有区域和语言设置，区域选项决定结果集的地域相关性，语言选项决定界面显示或结果集限定的语种。对相当一部分国家来说，区域决定语言。不同搜索引擎对区域和语言设置的敏感程度不同。别的字符体系我没有实验过，但就中文来说，新上线的bing和google还是有一些区别的。我实验的关键字包括但不限于：

简繁日不同形：　价格（價格、価格）、开发（開發、開発）、广东（廣東、広東）；
简繁同形：　　　你好、健康、公路、使用、叫做、智能、孩子、人民；
简日同形：　　　日本、大阪、社会、福祉；
繁日同形：　　　東京、幹線、講師、情報。

　　在google美国，无论搜索简体字还是繁体字，google都会在内部做简繁转换。尽管简繁搜索结果有所不同，但简体的结果中往往也包括了一些繁体页面，反之亦然。如果搜索日文汉字，则结果均为日文网页，不会转换成简体字或繁体字进行相应中文网页检索。在google中国大陆和台湾省的入口，也会执行这项转换。但在google日本，一切汉字均被当作日文汉字处理，结果集以日文为主。如果搜索一些在中文中使用、在日文中不使用的汉字，也会出现一些中文结果。而在google其它地区的入口，如英国、韩国，不执行简繁转换，结果集与输入字形一致。
　　在bing美国，如果搜索简、繁、日不同形的汉字，则会返回相应地区、相应字符集的结果，系统并不进行简繁转换。但如果输入简繁同形、简日同形或繁日同形的汉字，bing好像是会执行一个智能判读，只返回它认为正确的字符集对应的结果集。这个返回结果有时就令人诧异了，例如简繁同形的“你好、健康、公路、使用”返回的大多是港台的页面，而“叫做、智能、孩子、人民”返回的则大多是大陆的页面；简日同形的“日本、大阪、社会、福祉”和繁日同形的“東京、幹線、講師、情報”返回的全都是日本的页面。这严重影响中文用户的使用，所以针对美国市场的bing并不适合直接做中文检索。
　　但bing针对中国大陆、台湾省和日本的入口则综合考虑了区域与语言的因素，返回的内容多是与本地区相关的，不会像美国站那样瞎猜。在中国大陆站输入繁体字或日文汉字，bing会提示用户：想搜索的是不是相应的简体字，或者直接把简体字的结果返回；但在台湾和日本站没有做字形转换。
　　对于汉字多语同文问题，什么样的结果才能最好地满足用户的需求呢？在语言策略上，google也许在尽力保持不同地区搜索结果的一致性，同时也针对特殊的地区执行特殊的语言处理策略（例如在日本，要将所有汉字看作日文汉字；在中国，要处理简体繁体问题），这也许是google追求的技术完美主义抑或是“不作恶”的体现。而bing综合考虑了关键字、区域设置和语言设置，返回与用户所在区域相关、使用指定语言书写的网页，这应该是符合大众用户需求的。在区域策略上，google的默认搜索选项总是搜索全球网页而不是特定地区的网页；而bing默认与特定的区域绑定（在bing的“首选项”中可以体现），本地结果优先呈现，这可能也是二者市场定位的差别。而对于大众以外的需求，搜索引擎的默认策略则不一定能够方便地满足。例如中国用户也常常使用美国版google.com（可以将界面语言设置为中文）取代google.cn，来避免结果被“依法”过滤。而美国版bing即使加上“language:zh_chs”参数，搜索排序效果也明显没有中国版bing好，这应该和它本地化的定位是相关的，鱼和熊掌不可兼得。
　　之所以多语同文会带来这些问题，可能就是因为查询语义和目标语义之间隔了两个语言层：查询语言和目标语言，而这两层之间存在着多对多的映射。Semantic Web和Linked Data在解决语义关联问题的同时，应该也可以解决多语同文的问题。但像Linked Data这样基于人工或半自动化的方法补充元数据及其关联是不是一个好的思路呢？语义的描述和识别究竟应该是人的任务还是应该交给机器来做？如何划分技术提供者、文档作者和文档读者的责任域？这是改进web、创建新的网络文档模型过程中需要考虑的。

　　本月，“.中国”域名正式写入全球根域名系统。我赞同很多网评的观点，不看好“.中国”域名的发展。不过我仍然进行了一项保护性注册（林健.中国 / 林健.cn），借机研究一下多语种域名（IDN）的特性。
　　“.中国”域名目前只有国内的代理商可以注册，不过即使将来国外有了代理商，意义也不大，因为“.cn”、“.中国”的生杀大权还是掌握在国内监管机构手中。之前的一些经历告诉我，那些国内代理商不过是半斤八两。但这次通过新网注册，我感觉被忽悠的程度比以前更严重。在新网注册的“.中国”域名不能修改DNS解析条目，只能设置URL转发。我开始还以为自己没有找到设置的地方，打客服电话（010-58022233）才确认确实没有。可笑的是，客服人员给我的解释是“技术上不可行”。我们知道IDN只是使用Punycode编码了Unicode字符，在DNS服务器端根本不需要什么技术上的变化。难道是有什么政策原因吗？我没有问出来，也没有查到，但从CNNIC的这个介绍来看，不像是要限制用户自己做解析。新网在这个问题上有误导，它没有明文说明它对中文域名和英文域名服务的区别，在中文域名帮助页面又提到：中文域名可以指向其它站点、可以用于电子邮件，很容易使人认为新网自己提供了可配置的DNS解析服务。但要追究起来我也没辙，因为它在网站上确实说的是中文域名固有的性质，而不是新网提供的服务；至于DNS解析，一般用户默认代理商会提供，而如果它没有提供，似乎也没违反什么法规条款。找不到什么十足的理由，我也只能忍了。好在域名的DNS服务器还是允许修改的（如果连这个都不允许，我真的要去讨个说法了），我换一个还不成？试验了一下，发现Godaddy的Off-site DNS不允许添加IDN，而zoneedit允许后缀为“.cn”的IDN，但不接受“.中国（.xn--fiqs8s）”后缀。我猜它们不会是因为政策不允许，也许就是在域名合法性验证的时候没有考虑IDN或IDN后缀吧。不过作为本土服务商的中国E动网倒是支持的，我选择使用它的免费域名解析服务（测试：http://文件.林健.中国）。
　　CNNIC的称“超过80%的网民已经可以使用‘.中国’域名访问互联网”但我测试了一些DNS，并让帮忙同学实验，发现还是有很多DNS服务器没有“.中国”的记录。也许是因为我的调查范围局限于教育网和科技网？换了一个北京联通的DNS（202.106.196.115）是好使的。
　　在服务商支持方面，Godaddy的空间可以绑定IDN（测试：http://test.林健.中国），而Google Apps暂不支持。Windows Live Admin Center也可以绑定IDN开通电子邮件服务，但可能由于它那里的DNS中还没有“.中国”记录，MX验证无法通过，只有“.cn”的地址可用（可以给我发邮件试试：文件@林健.cn）。因此如果想拿中文域名开服务，还是查查自己的服务商有没有限制。
　　客户端方面，IE、Firefox、Chrome、Safari、Opera等主流浏览器都支持Unicode自动转换为Punycode。而邮件客户端方面，邪恶的Foxmail会干这件事，Outlook、Windows Live Mail、Koomail等不支持。主流免费邮箱中，我还没有发现哪一家的web界面可以自动转换Punycode。有趣的是中国移动139邮箱在发送的时候虽然不能自动转换Punycode，但收到来自“xn--5nqy36c@xn--nyq587c.cn”的邮件，却可以自动转换为“文件@林健.cn”显示。
　　体验的结果：我对中文域名的看法没有改变，对IDN的机制和现状有了进一步的了解。中文域名在现阶段估计也只适合保护性注册，难以被用户接受，因此也难以投入商用。其主要原因：URL已经不是当今互联网的主要入口了，搜索引擎等模式日趋成为主导。尽管我认为这个趋势是反REST原理的，但是用户的习惯、市场的走势总会使得技术不得不低下头。在web技术因为不断的渐进性扩充而变得臃肿，偏离了最初的原则时，也许下一代互联网交互模型就快诞生了。
　　（本文中出现的测试用子域名和邮箱不保证长期有效）