DICOM编码（1）

关于中文编码的问题，经常出现在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编码值给的是不对的。）

转自： http://blog.sina.com.cn/s/blog_c2be047501017ge1.html