关于dicom中的中文乱码

   昨天，在天坛医院刚刚结束了IHE中国2013年第一次测试大会。虽然敝人这次没有参加，不过可以想象各位兄弟都很辛苦。今天正好有时间，发一遍关于DICOM协议中的中文编码的文章，烘托一下IHE的气氛。

   严格地说，目前IHE中国在测试用例的编排上没有强调这个问题，以我看来，这也是目前IHE中国目前非常欠缺的部分：测试用例基本上都是照搬IHE欧洲或北美的用例，我觉得应该结合本土的应用环境增加一些测试用例，哪怕是强调本土化的编码规则。

   从我之前的工作经历来看，关于中文编码的问题，经常出现在DICOM Storage和Modality Worklist两个服务中，这两个环节最容易出现问题，也是很多PACS公司上线前经常担心的问题。以下我分享两个典型的案例，这中例子在国内的PACS实施过程中还是很常见的，鉴于目前工作的保密性，我就不方便透露项目的名称了。

   案例一：某医院PACS上线时，其他设备图像都能顺利地归档，但是有一台CT设备的图像总是归档失败。经过分析，发现这台CT设备传输的图像存在编码问题，技术上说，属于不规范的DICOM图像。基本碰到这个情况的，大部分都是国产的设备，这台设备也不例外，而且还是目前国内知名的企业生产的。由此也呼吁国内的设备生产厂家，在设备外观做漂亮的同时，也把软件部分做得更稳定、更规范。言归正传，分享一下我处理这种问题的思路。首先我是工具软件查看一下DICOM的标签信息，这里有很多免费甚至开源的软件可以使用，给大家推荐几款，比如DCMTK里面的DcmDump, JDICOM里面的EditDicomObject，另外想MyViewPad，Sante DICOM HEX Viewer等也是非常不错的软件。我也经常用这些，不过我当时用的是我们自己开发的一个小工具，跟前面提到的工具在功能上差不多，只不过结合了我们自己的一些使用习惯。当时已查看图像就发现了异常，DICOM标签到Insitution Name就终止了，也就是显示了医院的姓名之后就找不到余下的标签信息了，而且医院名称显示还是中文姓名。通常这种情况下基本就是中文字符编码不规范，导致字符串长度跟DICOM标签中的Length的值不一致，这样遍历标签时，后面的信息全乱了。这个案例就是非常典型的情况，医院的名称使用了中文，没有Specified Characterset标签指定编码方式，通常这种情况下，各个程序都会按照ASCII编码或者当前系统默认编码去读取字符串，所以这台设备的图像第一个潜在风险就是没有显示指明中文的编码方式。当然有一些优秀的软件做的比较深入，可以根据字符串的字节信息去尝试判断编码方式，但是大部分厂家是没有这层逻辑的，而且这种做法也会比较费时间。当然这个案例里面关键的问题还不是因为没有显示指明编码方式，关键的问题在于字符串的长度有问题，这个医院的中文名称有13个汉字，我很诧异做这款软件的兄弟还知道需要将字符串长度补齐为偶数，但是他居然将这个标签的长度设置为14，因为他用的多字节编码，每个汉字应该占两个字节，最后医院名称的长度应该是26个字节，而且显然是偶数不需要补零。类似地，图像里面的检查部分也用的中文，而且犯了同样的错误。

    另外一个案例是关于Modality Worklist的，当时需要连接的设备是锐科的8500，之前使用的是锐科自己的GC PACS，RIS登记的中文姓名能够完美地传输到设备上，但是换了一家PACS厂家之后，只能传输英文，PACS厂家称如果传输中文，设备上显示就变成了乱码。很显然，又是中文编码的问题。其实DICOM协议中，对于中文的worklist传输明确指明了两种编码方式。其一是Unicode编码方式，在 (0008,0005)标签中指明Specified Characterset为ISO_IR 192，比如王小東，DICOM协议建议的编码方式是包含患者的中英文信息，并且严格区分Frist Name和Last Name，姓和名，最后的编码应该是： Wang^ XiaoDong=王^小東=，对应的Unicode字节信息是：0x57 0x61 0x6e 0x67 0x5e 0x58 0x69 0x61 0x6f 0x44 0x6f 0x6e 0x67 0x3d 0xe7

0x8e 0x8b 0x5e 0xe5 0xb0 0x8f 0xe6 0x9d 0xb1 0x3d

另外一种编码方式是我们的国标GB18030，即在Specified Characterset标签中填写GB18030，Wang^XiaoDong=王^小东=对应的字节信息是：0x57 0x61 0x6e 0x67 0x5e 0x58 0x69 0x61 0x6f 0x44 0x6f 0x6e 0x67 0x3d 0xcd

0xf5 0x5e 0xd0 0xa1 0xb6 0xab 0x3d

写代码的朋友应该能看懂这段内容。（不过需要注意的是DICOM标准中对“東”字的UTF-8编码值给的是不对的。）

 

从上面两个案例可以看出，如果大家严格遵从标准，很多问题是可以避免的。由此也可以看出，IHE规范的推广，无论是对软件厂家还是医院，都是有好处的。另外，从我的经验来看，咱们国人不是理解不了这些标准，其实我们很聪明，很快就能明白标准的意思，当然这些标准开始都是英文的，语言上可能多花点时间，但是这不是主要原因，现实中，往往是因为我们过于追求利益，快速完成产品交付，很多软件开发过程都是东拼西凑快速研发出来的，没有详细地设计和严格地遵循标准，相关评审环节也是外行审内行，最后到医院的产品出现这样那样的问题都是情理之中的。

   不过我相信，慢慢都会好转的，有钱有时间了，大家都想做好产品、做高品质的产品，尤其是我们可爱的技术人员。