├── Figure ├── Part 5 │ ├── Thumbs.db │ ├── PS3.5_Figure 7.1_1.jpg │ ├── PS3.5_Table 6.1_1.jpg │ ├── PS3.5_Table 7.1_1.jpg │ ├── PS3.5_Table 7.1_2.jpg │ ├── PS3.5_Table 7.1_3.jpg │ ├── PS3.5_Table 7.5_1.jpg │ ├── PS3.5_Table 7.5_2.jpg │ ├── PS3.5_Table 7.5_3.jpg │ ├── PS3.5_Table 6.2_1.1.jpg │ ├── PS3.5_Table 6.2_1.2.jpg │ └── PS3.5_Table 6.2_1.3.jpg └── Part 8 │ ├── PS3.8_1-1.jpg │ ├── PS3.8_6-1.jpg │ ├── PS3.8_7-1.jpg │ ├── PS3.8_7-2.jpg │ ├── PS3.8_7-3.jpg │ ├── PS3.8_7-1-zs.jpg │ ├── PS3.8_Table7-1.jpg │ ├── PS3.8_Table7-2.jpg │ ├── PS3.8_Table7-3.jpg │ ├── PS3.8_Table7-7.jpg │ ├── PS3.8_7-3.svg │ ├── PS3.8_6-1.svg │ ├── PS3.8_7-1.svg │ ├── PS3.8_7-2.svg │ └── PS3.8_1-1.svg ├── README.md ├── Part 8：Network CommunicationSupport for Message Exchange.md └── Part 5：Data Structures and Encoding.md /Figure/Part 5/Thumbs.db: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/Thumbs.db -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_1-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_1-1.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_6-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_6-1.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_7-1.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_7-2.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_7-3.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-1-zs.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_7-1-zs.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_Table7-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_Table7-1.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_Table7-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_Table7-2.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_Table7-3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_Table7-3.jpg -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_Table7-7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 8/PS3.8_Table7-7.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Figure 7.1_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Figure 7.1_1.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 6.1_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 6.1_1.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.1_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.1_1.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.1_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.1_2.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.1_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.1_3.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.5_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.5_1.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.5_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.5_2.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 7.5_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 7.5_3.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 6.2_1.1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 6.2_1.1.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 6.2_1.2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 6.2_1.2.jpg -------------------------------------------------------------------------------- /Figure/Part 5/PS3.5_Table 6.2_1.3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/HEAD/Figure/Part 5/PS3.5_Table 6.2_1.3.jpg -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

DICOM-Chinese

2 | The Chinese version of DICOM 3.0 Standard.
3 |
4 | 5 | ---------- 6 | 7 | DICOM3.0标准中文版开源书籍项目
8 | 9 |
10 | 以开源书籍的方式翻译DICOM协议，自发翻译[DICOM官方标准](http://medical.nema.org/standard.html)，以DICOM协议为切入点，通过阅读、研究、直至翻译，更加全面掌握标准，尤其加深对医疗行业的了解。
11 | 随着国内新医改的逐步深入，各行各业的创业者开始涉足医疗行业，无论出于颠覆旧有体制和现行标准，还是出于对DICOM标准了解不足的角度，未来新的医疗大环境下必然需要标准的更新，或新的标准。称之为DICOMX.X也好，称之为XXX也罢。充分研读现有标准，实时关注当下新需求，为改善或制定适应未来医疗环境的新标做准备……
12 |
13 |
14 | 约定：
15 | 16 | 翻译工作非一人之劳，也定非一人之功。因此需要团队各成员之间协同配合。现约定如下：
17 | >1. 各Part的目录参照DICOM3.0标准官方网站，保留英文标题，方便后续检索以及查阅；
18 | 19 | >2. 各Part的前几部分，诸如Notice and Disclaimer、Foreword、Definitions不进行中文翻译，待后续标准整体翻译工作收尾时，再共同努力给出上述各公共部分的中文翻译；
20 | > 21 | >3. 各Part的Symbols and Abbreviations会有诸多的重合，因此前期刚启动翻译时刻，必然会存在着诸多概念翻译不同的冲突，该冲突平日里可通过QQ群、邮件等方式沟通讨论解决、或者到每个月底统一整合时再修改；
22 | > 23 | >4. 各Part的每一级（例如第二级、第三级、第四级）的内容长度不同，因此翻译工作不做强制要求。只要求每次提交完整一段即可，例如下图红色矩形框都算一段，每次至少提交一个完整段落即可。
24 | >...... 25 | 26 | 备注：
27 | 博文专栏中介绍过DICOM标准中文版书籍的协作模式[DICOM：开源书籍之『DICOM标准中文版』启动计划](http://blog.csdn.net/zssureqh/article/details/46487325)，之所以选择[看云平台](http://www.kancloud.cn/explore)目的是希望更多的、各行各业的人员加入，例如英语专业、非医疗从业者都十分欢迎，对翻译中的语法、**语言表述**，甚至**专业知识点**进行评判修改。
28 | 对于日常工作很少使用版本管理工具的人员来说，看云的操作既简捷明了，又能很好的实现多人协作的目的。当然，如果您是一名IT从业者，已熟练使用SVN和GIT各种版本工具的人员，可以通过**Github**直接发起**Pull requests**请求，待审核通过后合并到master主线中。
29 | 30 |
31 |
32 |
33 | 了解开源书籍项目细节，请浏览[ZSSURE的CSDN Blog](http://blog.csdn.net/zssureqh)
34 | 欢迎有兴趣者加入，联系：zssure@163.com 35 | 36 | 37 | -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-3.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | PS 3.8 Network Communication Support for Message Exchange 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | DICOM ULService Provider 29 | 30 | 31 | Requestor 32 | 33 | 34 | A-ABORTrequest 35 | 36 | 37 | A-ABORTindication 38 | 39 | 40 | Acceptor 41 | 42 | 43 | ( SAP ) 44 | 45 | 46 | ( SAP ) 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_6-1.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | PS 3.8 Network Communication Support for Message Exchange 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 29 | 30 | BOUNDARY: DICOM Upper Layer Service 31 | 32 | 33 | 34 | 36 | 38 | 39 | 40 | Network 41 | 42 | 43 | 45 | 47 | 48 | 49 | TCP/IP Transport Layer 50 | 51 | 52 | 54 | 56 | 57 | 58 | DICOM Upper Layer Protocol for TCP/IP 59 | 60 | 61 | 63 | 65 | 66 | DICOM Application Message Exhange 67 | 69 | Medical ImagingApplication 70 | 71 | 72 | 73 | -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-1.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | PS 3.8 Network Communication Support for Message Exchange 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | DICOM ULService Provider 29 | 30 | 31 | Requestor 32 | 33 | 34 | A-ASSOCIATErequest 35 | 36 | 37 | A-ASSOCIATEconfirmation 38 | 39 | 40 | A-ASSOCIATEindication 41 | 42 | 43 | A-ASSOCIATEresponse 44 | 45 | 46 | Acceptor 47 | 48 | 49 | ( SAP ) 50 | 51 | 52 | ( SAP ) 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_7-2.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | PS 3.8 Network Communication Support for Message Exchange 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | DICOM ULService Provider 29 | 30 | 31 | Requestor 32 | 33 | 34 | A-RELEASErequest 35 | 36 | 37 | A-RELEASEconfirmation 38 | 39 | 40 | A-RELEASEindication 41 | 42 | 43 | A-RELEASEresponse 44 | 45 | 46 | Acceptor 47 | 48 | 49 | ( SAP ) 50 | 51 | 52 | ( SAP ) 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | -------------------------------------------------------------------------------- /Figure/Part 8/PS3.8_1-1.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 13 | 14 | 15 | 16 | 17 | PS 3.8 Network Communication Support for Message Exchange 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | Peer Protocol 32 | OSI End-System 33 | ApplicationPresentationSessionTransportNetworkData LinkPhysical 34 | 35 | Layer 36 | 37 | 38 | OSI End-System 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | Physical Media 161 | 162 | 163 | 164 | -------------------------------------------------------------------------------- /Part 8：Network CommunicationSupport for Message Exchange.md: -------------------------------------------------------------------------------- 1 |

通告与免责声明

2 | 关于本出版物所含内容的专业可靠性，所有设计和审批该文档的参与者已达成共识，但这并不意味着全体参与者一致通过而毫无异议。
3 | 本文档属于美国电气制造商协会(NEMA,National Electrical Manufactures Association)标准指南类出版物，遵循“自愿协商一致性”的标准流程。该流程汇集志愿者并找出对出版物某项议题感兴趣的人。NEMA监督整个流程并制定规则以促进达成共识的公平性，但NEMA并不编写文档，不进行独立测试、评估或验证任何信息的准确性和完整性、以及任何判断的可靠性。
4 | 对于间接或直接使用该文档所产生的任何人身伤害、财产损失、或其他任何自然的、特殊的、间接性、连带性、补偿性的伤害，NEMA不承担任何责任。NEMA声明对于文档中的内容以及该内容是否能够满足读者特定目的或需求不做任何明确或暗示的担保和保证，另外NEMA不保证任何制造商或销售商的产品或服务遵循该标准
5 | ....
6 | ....
7 | ....
8 | 9 |

前言

10 | DICOM标准由DICOM标准委员会制定。
11 | 根据ISO/IEC Directives第三部分指导，DICOM标准文档被分成多个部分。
12 |

1 应用范围与领域

13 | 该文档PS 3部分中介绍的通信协议严格遵循ISO国际化标准组织规定的开放系统互联参考模型（Open Systems Interconnection Basic Reference Model，参见ISO 7498-1 图1-1）。主要涉及的相关层有：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层中的关联控制服务（ACSE，Association Control Services）。本文档中的通信协议符合TCP/IP通用标准，而并不只针对于本标准。应用层协议的其他方面放到本标准的其他部分（PS3.1)来讨论。
14 |
![Figure 1-1 ISO OSI Basic Reference Model](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_1-1.jpg)

15 |
图1-1 ISO OSI Basic Reference Model

16 | 17 | ---------- 18 |

5 约定

19 | 下文中描述各项服务的表格中用到的约定如下：
20 | (=)
21 | 指示（确认）使用的参数值与请求（响应）中的相同。
22 | C
23 | 有条件的（用户可选的）
24 | M
25 | 强制使用 26 | MF
27 | 强制使用确定数值
28 | NU
29 | 未使用的
30 | P
31 | 初始化t提供
32 | U
33 | 用户可选的
34 | UF
35 | 用户可选但数值固定
36 |
37 | 空白项不适用上述约定。
38 | 39 | 40 | 41 | 42 | 43 |

6 网络通信支持环境

44 | 本文档PS3.8中规定的网络通信服务，是支持DICOM应用实体通信的一套基础服务，是OSI表示层（ISO 8822)和OSI关联控制服务ACSE（ISO 8649)的子集，被称为上层服务或UL服务（即，the Upper Layer Service or UL Service）。关于DICOM UL服务详细内容在第7章节介绍。
45 | 上层服务（UL Service）由第9章节中的TCP/IP顶层协议提供。
46 | 图6-1展示了支持DICOM应用实体通信的TCP/IP协议栈。
47 |
![Figure 6-1](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_6-1.jpg)

48 |
图6-1. DICOM网络协议框架

49 |

7 DICOM应用实体的OSI上层服务

50 | 该章节将介绍如何使用OSI关联控制服务元(ACSE)和表示层构建上层服务为DICOM应用实体间的通信提供必要的支持。该上层服务完全遵循关联控制服务元以及OSI表示层规范。
51 | 上层服务内容列于表7-1，如下所示：
52 |
Table 7-1 Upper Layer Services

53 |
![Table 7-1](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_Table7-1.jpg)

54 | 除了介绍上层服务规范，本章节给出了DICOM应用实体使用上层服务各元素时的参数定义。关于上层服务的使用指南在标准第7部分有介绍（参见[PS3.7](http://dicom.nema.org/medical/dicom/current/output/html/part07.html#PS3.7))。
55 |

7.1 A-ASSOCIATE连接服务

56 | 两个DICOM应用实体间连接的建立需要通过关联控制服务元的请求、指示、响应、确认四种原语来完成。下文中将服务的发起者称之为请求方，将接收A-ASSOCIATE指示的使用者称之为接收方。该连接服务是一种确认服务。
57 | 注意：
58 | A-ASSOCIATE连接服务相当于通过点对点接口创建一个信道(详情可参见已弃用的标准第九部分PS3.9）
59 | 图7-1描述了两个DICOM应用实体间连接的建立。
60 |
![Figure 7-1](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_7-1.jpg)

61 |
图7-1 连接请求

62 | 译者注： 63 | >所谓服务原语，是代表响应服务的符号和参数的一种格式化、规范化的表示，它与服务的具体实现方式无关。原语都是发送给服务实体相邻层的，层与层之间的通信原语分为请求（Request）、指示（Indication）、响应（Response）、确认（Confirm）四种。

64 | >图7-1中的SAP，全称Service Accessing Point，即服务访问点。是上层访问下层所提供服务的点。在计算机体系结构中，下层是为相邻上层提供服务的，而下层对它的所有上层都是透明的。

65 | >在传统的点对点（或端到端）的模型中四种原语体现的不是很具体，其原因是点对点（或端到端）的模型将双方实体抽象成了一个点，而未考虑各自内部的OSI开放模型。如果将每个端点展开为OSI层模型，即可理解上述四种服务原语。
66 | 67 | 68 |

7.1.1 A-ASSOCIATE参数

69 | 表7-2列出了DICOM应用实体使用A-ASSOCIATE服务时所需的各项参数。
70 |
Table 7-2 Key A-ASSOCIATE Service Parameters

71 |
![Table 7-2](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_Table7-2.jpg)

72 | 注意：
73 | 关于表中的约定参见该部分第5章节。
74 | 表7-3列出了DICOM应用实体在A-ASSOCIATE服务中的固定值参数或不需要的参数。
75 |
Table 7-3. A-ASSOCIATE Service Parameter (Fixed or Not Used)

76 |
![Table 7-3](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_Table7-3.jpg)

77 |

7.1.1.1 模式（固定值）

78 | 该参数允许使用OSI-ACSE服务中的可选模式进行协商。在DICOM应用实体之间仅允许使用默认的“normal”（正常），因此该参数应始终被设定为“normal”。
79 |

7.1.1.2 应用上下文名称

80 | 该参数定义了请求方建议的应用上下文名称。接收方可以返回相同或不同的应用上下文名称。返回的名称用于标定本次链接应用上下文。关于应用上下文名称的详细讨论请参见[附录A]()。
81 | 应用上下文是一个定义明确的集合，包括应用服务元素、相关选项、以及应用实体间完成交互必须的其他信息。
82 | 注意：
83 | 接收方返回的应用上下文提供了限定协商的机制。倘若请求方不能按照接收方提供的应用上下文进行操作，应当发布一个A-Abort（放弃）请求原语。在标准第7部分（PS3.7）中定义了DICOM应用实体应用上下文名称以及使用规则。
84 |

7.1.1.3 呼叫方应用实体名称

85 | 该参数定义了包含A-ASSOCIATE链接服务请求方的应用实体，基于源DICOM应用名称。关于DICOM应用名称与应用实体名称之间的关系参见[附录C]()。呼叫方应用实体名称与在连接中传递的DICOM消息所含的发起方地址可能相同也可能不同。
86 | 注意：
87 | 接收到A-ASSOCIATE-RQ链接请求的上层用户负责验证呼叫方应用实体名称是否属于已知的远程DICOM应用名称。
88 |

7.1.1.4 被叫方应用实体名称

89 | 该参数用于定义包含预期A-ASSOCIATE服务接收方的应用实体，基于目标DICOM应用名称。关于DICOM应用名称与应用实体名称之间的关系参见[附录C]()。被叫方应用实体名称与在连接中传递的DICOM消息所含的接收方地址可能相同也可能不同。
90 | 注意：
91 | 接收到A-ASSOCIATE-RQ链接请求的上层用户负责验证被叫方应用实体名称是否是它的DICOM应用名称（或其DICOM应用名称之一）。
92 |

7.1.1.5 响应应用实体名称（固定值）

93 | 该参数定义了实际A-ASSOCIATE服务接收者的应用实体名称。在本标准中（[DICOM3.0](http://dicom.nema.org/standard.html)）该参数值应当始终与A-ASSOCIATE指示原语中的被叫方应用实体名称相同。
94 |

7.1.1.6 用户信息

95 | 该参数包括链接的请求方和接收方的DICOM应用实体中的用户信息，其具体含义依赖于原语的应用长下文。关于该参数的详细介绍参见[附录D]()。
96 | 注意：
97 | 1. 该参数给出与‘应用上下文名称’参数相对应的DICOM应用实体的初始化信息。
98 | 2. 附录D详细介绍了用户信息的各个子项，附加子项的定义参见标准第7部分（即PS3.7），另外关于子项中服务类应用消息的详细介绍需要参见标准第4部分（即PS3.4）
99 |

7.1.1.7 结果

100 | 该参数或由连接请求接收方的上层服务提供者的关联控制服务相关函数提供，或直接由上层服务提供者的表示层相关函数提供，用于表示使用连接服务的结果。该参数取下述值之一：
101 | a. 接受；
102 | b. 拒绝（永久）；
103 | c. 拒绝（临时）；
104 | 注意：
105 | 当连接请求方得到的返回结果是“拒绝（永久）”时，意味着该连接请求没有后续接入的必要。例如当远端DICOM应用名称未知时，该状态用于阻止连接的建立。
106 |
107 |

7.1.1.8 结果来源

108 | 该参数值由上层服务提供者给出，指出了产生结果参数以及诊断参数（如果有的话）的来源。参数值如下：
109 | a. 上层服务使用者；
110 | b. 上层服务提供者（关联控制服务相关函数）;
111 | c. 上层服务提供者（表示层相关函数）;
112 | 注意：
113 | 如果7.1.1.7的结果参数返回值为“接受”,该参数对应取值为“上层服务使用者”，即a。
114 |
115 |

7.1.1.9 错误报文

116 | 该参数仅在7.1.1.7 结果参数返回值为“拒绝（永久）”或“拒绝（临时）”时使用，给出与A-ASSOCIATE连接服务结果相关的错误诊断信息。
117 | 如果7.1.1.8 结果来源参数返回值为“上层服务使用者”，该参数取值如下：
118 | a. 没有可参考原因
119 | b. 应用上下文名称不支持
120 | c. 请求应用实体名称无法识别
121 | d. 被请求应用实体名称无法识别
122 | e. 请求应用实体限定词无法识别（参见注释）
123 | f. 请求应用过程调用标识无法识别（参见注释）
124 | g. 请求应用实体调用标识无法识别（参见注释）
125 | h. 被请求应用实体限定词无法识别（参见注释）
126 | i. 被请求应用过程调用标识无法识别（参见注释）
127 | j. 被请求应用实体调用标识无法上识别（参见注释）
128 | 129 | 如果7.1.1.8 结果来源参数返回值为“上层服务提供者（关联控制服务相关功能）”，该参数取值如下：
130 | a. 没有可参考原因
131 | b. 非一般（常用）上层服务版本
132 | 133 | 如果7.1.1.8 结果来源参数返回值为“上层服务提供者（表现层相关功能）”，该参数取值如下：
134 | a. 没有可参考原因
135 | b. 临时阻塞
136 | c. 本地负荷溢出
137 | d. 被请求方地址（表现层）未知
138 | e. 表现层协议版本不支持
139 | f. 表现层服务访问点不可用
140 | 141 | 注意：
142 | 尽管上述部分取值在本标准中未使用，但允许使用其提示由于非法使用参数导致的错误信息。
143 |

7.1.1.10 请求方表现层地址

144 | 该参数是结构化目标地址，包含一个明确的全球网络地址，通常是一个TCP/IP地址。详情参见附录C。
145 |

7.1.1.11 被请求方表现层地址

146 | 该参数是结构化目标地址，包含一个明确的全球网络地址，通常是一个TCP/IP地址。详情参见附录C。
147 |

7.1.1.12 响应中的表现层地址

148 | DICOM3.0标准中，响应中的表现层地址应该与A-ASSOCIATE连接指示原语中的被请求方表现层地址相同。该参数包含一个明确唯一的全球网络地址。
149 |

7.1.1.13 表示上下文定义列表

150 | 该参数用在A-ASSOCIATE的请求或指示原语中，是一个列表，包含一个或多个表示上下文。列表中每一项包含表示上下文标号，抽象语义名称，传输语义名称列表三部分。
151 | 在交互时，表示上下文标号用于区分同一个连接中的不同表示上下文（不同的表示上下文在不同的连接中的标号可能相同）。该标号由连接请求方负责设定，确保每个标号不同即可，且该标号与表示上下文列表中排序无关。
152 | 注意：
153 | 在表示上下文定义列表中，每个表示上下文都与某个抽象语义名称相关联。如果列表中同一个抽象语义名称出现不止一次，每个抽象语义名称下必须单独定义表示上下文，因为每个表示上下文中只允许一种传输语义。
154 |
155 | DICOM应用实体使用的抽象语义的详细定义参见标准第4部分，即PS3.4；传输语义的详细定义参见标准第5部分，即PS3.5。另外附录B中有关于抽象语义和传输语义的进一步讨论。
156 |

7.1.1.14 表示上下文定义结果列表

157 | 该参数用在A-ASSOCIATE的响应和确认原语中，标明请求或指示原语的表示上下文列表（即7.1.1.13中的参数）中每个表示上下文的接受或拒绝情况。表示上下文结果定义列表以结果列表的形式一一对应给出表示上下文定义列表中每一项的结果。每项结果由上层服务使用者在响应服务原语中给出，结果可能是接受（acceptance）、可能是用户端拒绝（user-rejection），也可能是提供端拒绝（provider-rejection），结果可被以任意顺序传送。
158 | 注意：
159 | 结果的顺序可能与原始的排序不同，因此结果不应该按照标号进行排序，且指示方不应假定或依赖于结果的特定顺序。
160 |
161 | 标准规定每一个表示上下文只允许一种传输语义，即使表示上下文定义列表中给出了多种可供选择的传输语义。
162 |

7.1.1.15 表示规定（固定值）

163 | 该参数允许对除了“表示核心”之外的表示功能单元进行协商，但DICOM应用实体中只用到了核心功能单元。因此本协议中该参数总是设置为“Presentation Kernel”，即表示核心。
164 |

7.1.1.16 会话规定（固定值）

165 | 该参数允许对除了“会话核心”之外的会话功能单元进行协商，但DICOM应用实体只使用具有全双工的核心功能单元。
166 |

7.1.1.17 其他参数

167 | 其他在DICOM应用实体交互时非必须的以及本标准中未使用的参数,此处不单独介绍。相关定义可参见开放系统互连中的关联控制服务，即OSI ACSE（ISO 8649)，以及表示层服务，即OSI Presentation Service（ISO 8822）。
168 |

7.1.2 A-ASSOCIATE服务流程

169 | 7.1.2.1
DICOM应用实体（包括上层服务使用者）通过发起A-ASSOCIATE请求原语期望建立一个连接。被请求应用实体由请求原语中的参数定义。在接收到A-ASSOCIATE确认原语之前请求方不允许触发除放弃请求原语（即A-ABORT）以外的任何原语。
170 | 7.1.2.2
上层服务提供者发出A-ASSOCIATE指示原语到被请求应用实体。
171 | 7.1.2.3
被请求应用实体通过发送包含适当结果参数的A-ASSOCATE响应原语，来表示接受或拒绝该链接。上层服务提供者应当发出包含相同结果参数的A-ASSOCIATE确认原语，此时结果源参数应该被设置为上层服务使用者。
172 | 7.1.2.4 如果接收方接受请求后，该链接方可使用。双方应用实体可使用DICOM应用上下文中规定的除A-ASSOCIATE之外的任何有效服务。
173 | 注意：
174 | 这意味着一旦建立连接，双方即可传输DICOM消息（关于DICOM消息的定义参见标准第7部分，即PS3.7）
175 |
176 | 7.1.2.5 如果被请求方应用实体拒绝，该链接建立失败。
177 | 7.1.2.6 上层服务提供者有可能无法支持该请求连接，此刻应当返回包含适当结果参数（即拒绝）的A-ASSOCIATE确认原语给请求方，与此同时设置结果源参数为“上层服务提供者（ACSE相关功能）”或“上层服务提供者（表示层相关功能）”。不发送指示原语，拒绝建立连接。
178 | 7.1.2.7 连接请求方或接收方都有可能通过发送放弃请求原语（即A-ABORT)中断连接服务流程(详情参见7.3章节）。此时远端应用实体会接收到A-ABORT指示原语，中断建立该连接。
179 |

7.2 A-RELEASE解除服务

180 | 应用实体双方间标准的释放服务应当通过关联控制服务中A-RELEASE的请求、指示、响应和确认原语来完成。下文中服务发起者被称为请求方，接收A-RELEASE指示的服务使用者被称为接收方。A-RELEASE释放服务是确认服务。
181 | 图7-2给出了连接双方应用实体间正常的释放服务。
182 | ![](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_7-2.jpg) 183 |
图7-2 连接释放
184 |

7.2.1 A-RELEASE参数

185 | 表7-4列出了A-RELEASE服务的各种参数，包括固定值或本标准中DICOM应用实体未使用的参数。
186 |
Table 7-4 A-RELEASE服务参数

187 |
![](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_Table7-7.jpg)
188 |

7.2.1.1 原因（固定值）

189 | 请求原语中用该参数来定义请求的紧迫程度。本标准中该参数使用设定为“正常”，即“normal”。
190 |

7.2.1.2 结果（固定值）

191 | 在本标准中，该参数总是设置为“确定”，即“affirmative”。 192 |

7.2.2 A-RELEASE服务流程

193 | 7.2.2.1 上层服务使用者要释放连接时需要发送A-RELEASE请求原语，待接收到A-RELEASE确认原语后，再发送A-ABORT请求原语。
194 | 注意：
195 | 倘若A-RELEASE服务请求方没有发送A-ABORT原语，它依然可以接收P-DATA指示原语。
196 | >译者注：上述“注意”的意思是说在A-RELEASE服务使用过程中，如果请求方没有完成整个流程（如上所述中提到的只发送了A-RELEASE请求原语，接收到A-RELEASE确认原语后未接着发送A-ABORT原语），连接不会断开，依然可以接收P-DATA数据。
197 | 198 | 7.2.2.2 上层服务提供者需要发送A-RELEASE指示原语给接收者，随后接收者可发送A-RELEASE响应原语，或A-ABORT请求原语，或P-DATA请求原语。 199 | >译者注：之前关于服务原语（service primitive）在7.1中简单介绍过。如前文所述：在传统的点对点（或端到端）的模型中四种原语体现的不是很具体，其原因是点对点（或端到端）的模型将双方实体抽象成了一个点，而未考虑各自内部的OSI开放模型。如果将每个端点展开为OSI层模型，即可理解上述四种服务原语。下图Figure 7-1-zs将Figure 7-1的OSI模型进行了展开，使得服务原语一目了然。
200 | 201 |
![](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_7-1-zs.jpg)
202 |
Figure 7-1-zs(译者注）

203 | 7.2.2.3 为了完成A-RELEASE服务，接收方在接收到A-RELEASE指示原语后需要反馈A-RELEASE响应原语。作为接收方的DICOM应用实体总是返回结果参数（即7.1.2）为“确定”（即“affirmative”）的A-RELEASE响应原语用于接受请求方释放连接的请求。
204 | 7.2.2.4 在接收方发送A-RELEASE响应原语后，不应在该连接上发送任何原语包括P-DATA请求。
205 | 7.2.2.5 上层服务提供者应当总是发送结果参数（即7.1.2）为“确定”的A-RELEASE确认原语。
206 | 7.2.2.6 双方应用实体均可发送A-ABORT终止请求来中断A-RELEASE释放服务流程。接收方在接收到A-ABORT指示原语后会直接释放连接，但可能造成正在传输中的数据丢失。
207 | 7.2.2.7 当双方应用实体同时发送A-RELEASE服务原语时会发生冲突。此时双方上层服务使用者会受到意外的A-RELEASE指示原语。正确释放连接的流程如下：
208 | a. 连接请求方发送A-RELEASE响应原语。
209 | b. 连接接收方等待对方的A-RELEASE确认原语，带接收后发送A-RELEASE响应原语
210 | c. 连接请求方接收到A-RELEASE确认原语。
211 | 连接应当在ACSE服务使用者双方都收到A-RELEASE确认原语后释放。
212 |

7.3 A-ABORT中止服务

213 | >译者注：**中止**，指（做事）中途停止；使中途停止；**终止**，停止，不再继续。这里翻译成中止比较恰当。 214 | 215 | 216 | 双方应用实体的任意一方皆可通过发起ACSE的中止服务来非正常释放当前连接。该操作是非确认操作（译者注：即不需要握手）。然而，由于A-ABORT中止服务的流程可能会发生冲突，因而不确保指示原语的传输。当发生冲突时，双方应用实体意识到该连接已经被中断。A-ABORT中止服务通过A-ABORT中止请求原语和A-ABORT指示原语完成。（译者注：即对应上文中的“non-confirmed”非确认）
217 | 注意：
218 | 在已建立的连接上发送A-ABORT中止服务请求原语可能会破坏正在传输中的数据。
219 | 图7-3给出了在两个应用实体间中止已建立连接的过程。
220 |
![](https://raw.githubusercontent.com/zssure-thu/DICOM-Chinese/master/Figure/Part%208/PS3.8_7-3.jpg)
221 | -------------------------------------------------------------------------------- /Part 5：Data Structures and Encoding.md: -------------------------------------------------------------------------------- 1 | # 第1节 适用范围和领域 2 | 此章是DICOM标准的第5部分，出版目的是为了促进医疗环境下数字成像计算机系统间的信息交换。这种信息交换可以增强影像诊断和一些潜在的临床应用。DICOM标准为实现这种信息交换提供了协议和数据。 3 | 4 | 该章主要讲述数据结构和数据集的编码。当应用实体通过网络通信时，会有一个数据集包含在DICOM消息中来传递一些通过网络管理的现实世界对像的一些信息。在这个标准的其它应用中，数据集可能有不同的上下文，例如：在媒体交换中，数据集会转化成文件内容的结构。 5 | 6 | 该部分DICOM标准主要阐述： 7 | 8 | a)值的编码 9 | b)数据集的结构和使用 10 | c)数据元素的使用及其与其它元素的关系 11 | d)嵌套数据集的组成及使用 12 | e)包含像素的数据什么样组成及使用 13 | f)如何唯一识别信息 14 | g)标准DICOM传输语法的详述 15 | 16 | 该部分DICOM标准未讲述的有： 17 | 18 | a)消息的结构和语法(第7章详述) 19 | b)命令集的结构及使用(第7章详述) 20 | c)应用服务的详述及分类(第3、4章详述) 21 | d)怎把数据集和网络通信、媒体存储及其它应用关联起来 22 | 23 | # 第2节 引用标准 24 | 25 | # 第3节 术语 26 | 标准中定义了以下术语： 27 | 28 | # 3.1 参考模型 29 | 标准的这部分引用了ISO 7498中的以下项目: 30 | 31 | a)应用实体 32 | b)开放式系统互联协议 33 | 34 | # 3.2 关联控制服务元素 35 | 标准的这部分引用了ISO 8649中的以下项目: 36 | 37 | a)关联 38 | 39 | # 3.3 描述服务 40 | 标准的这部分引用了ISO 8822中的以下项目: 41 | 42 | a)表达上下文 43 | b)表达数据元素(pdv) 44 | c)传输语法 45 | d)传输语法名 46 | 47 | # 3.4 对像识别 48 | 标准的这部分引用了ISO 8824中的以下项目: 49 | 50 | a)开放式互联系统对像识别 51 | 52 | # 3.5 DICOM介绍和概述 53 | 标准的这部分引用了第1章中的以下项目: 54 | 55 | a)属性 56 | b)命令元素 57 | c)数据字典 58 | 59 | # 3.6 DICOM一致性 60 | 标准的这部分引用了第2章中的以下项目: 61 | 62 | a)一致性声明 63 | # 3.7 DICOM信息对像 64 | 标准的这部分引用了第3章中的以下项目: 65 | 66 | a)属性标签 67 | b)信息实体 68 | c)信息对像定义(IOD) 69 | d)多帧图像 70 | # 3.8 DICOM服务类详述 71 | 标准的这部分引用了第4章中的以下项目: 72 | 73 | a)服务对像对类 74 | # 3.9 DICOM支持信息交换的网络通信 75 | 标准的这部分引用了第8章中的以下项目: 76 | 77 | a)DICOM上层协议服务 78 | # 3.10 DICOM数据结构及编码 79 | 以下是此标准的常用定义： 80 | 81 | **标准偏移表**：一个指向多帧压缩图像每一帧的指针表。 82 | 83 | **高字节序**：一种高字节在前低字节在后的字节编码格式。 84 | 85 | **字符集**：一些可以完成指定目标并且与编码无关的字符的有限集合（也称字库）。 86 | 87 | **数据元素**：数据字典中定义的一个数据单元。一个编码过的信息对像定义属性由3部分组成：数据元素标签、值长度、值域。对一些特殊的传输语法来说，数据元素还包含值描述域。 88 | 89 | **数据元素标签**：由一对有序的数字对组成的数据元素的唯一标识符。 90 | 91 | **数据元素类型**：用来表明信息对像或服务对像对类的属性是强制的、条件强制或可选的。也可以转化为数据集中的一个数据元素是强制的、条件强制或可选的。 92 | 93 | **数据集**：交换信息是由一组有组织的与信息对像有直接或间接关系的属性值组成的。在数据集的每一个属性的值都表示为一个数据元素。把一系列数据元素按其标签数字值按递增模式进行排序的过程就是对现实世界对像属性值的编码。 94 | 95 | **确定项**：当一个数据元素的值是一组明确规范的标准值，并且这些值可被使用者扩展时就称作确定项。 96 | 97 | **元素序号**：组成数据元素标签的有序数字对的第二个值。 98 | 99 | **枚举值**：当一个数据元素的值是一组明确规范的标准值，并且这些值可被使用者扩展时这个数据元素的值就是一个枚举值。 100 | 101 | **组号**：组成数据元素标签的有序数字对的第一个值。 102 | 103 | **项**：数据元素值的一个组成部分是具有值表示法为项的序列。一个项包含一个数据集。 104 | 105 | **项界定数据元素**：用来在一个拥有许多项的序列中来标明一个未定义长度的项的末尾，这个元素同时也是一个未定义长度的项的最后一个元素。 106 | 107 | **低字节序**：在多字节二进制数据编码时把最低有效位放在第一位，其余字节按有效位递增编码的方式。 108 | 109 | **嵌套数据集**：一个数据集的数据元素中包含另一个数据集，数据集可以递归包含。只有数据元素的值表示法为项的序列时它才可以包含数据集。 110 | 111 | **像素单元**：一个像素采样值的容器，它可以包含未使用位或数据并非像素采样值的位（例如：覆盖面），像素单元的大小由（0028，0100）位分配值数据元素来确定。 112 | 113 | **像素数据**：具有位深的图形数据编码在像素数据元素里，并且值表示方法为OW/OB。附加描述符元素通常用来表示像素数据元素的内容。 114 | 115 | **像素采样值**：和单个像素相关的数值。一个像素通常由一个或多个像素采样值组成。（彩色图像） 116 | 117 | **私有数据元素**：由使用方定义的附加数据元素，来传递一些不包含在标准数据元素中的信息。私有数据元素的组号都是奇数。 118 | 119 | **重复组**：组号在一个特定区间中的数据元素它们具有相同的元素序号，在各自的组内有相同的含义(相同的数据类型，数据多重性，数据表示方法)。重复组只存在于曲线和覆盖层（分别对应（50xx,eeee）,（60xx,eeee））及一些3.0版本标准以前的残留信息。 120 | 121 | **作废数据元素**：从3.0版本开始不支持的数据元素，应用可以继续使用这些作废元素来达到兼容3.0以前版本的目的，但是这些元素对当前版本来说不是必有的。 122 | 123 | **序列界定项**：用来界定未定义数据长度的序列的项，此项是序列的最后一个项。 124 | 125 | **序列（值表示法SQ）**：包含数据集的数据元素的值表示法，序列是允许嵌套的。 126 | 127 | **标准数据元素**：DICOM标准中定义的数据元素，并且是出现在第6章数据字典中的。 128 | 129 | **传输语法（标准和私有）**：一组允许应用实体间进行模糊协商他们所技能的编码方法（例如:数据元素结构，字节序，压缩模式）的编码规则，这样才能达到允许应用实体间的通信。 130 | 131 | **未定义长度**：一种说明数据元素值长度或项长度未知的方法（值表示法为：SQ,OW,OB）。未定义长度的数据元素和项分别是以数据元素界定项和序列界定项来界定的。 132 | 133 | **唯一标识符（UID）**：一个用来唯一识别多种项的的字符串；来保证在多个国家、城市、供应商及设备间的唯一性。 134 | 135 | **值**：值域的组成部分，一个值域可以由多个这种部件组成。 136 | 137 | **值域**：数据元素中包含数值的区域。 138 | 139 | **值长度**：数据元素中包含值域长度的区域。 140 | 141 | **数据多重性**：表明数据元素的值域中包含的数值的数量。 142 | 143 | **值表示法**：表明数据元素的值域中数据的类型和格式。 144 | 145 | **值表示法域**:当一个数据元素的编码结构为显式时，这种值表示法存储的区域。 146 | 147 | # 3.11 字符处理定义 148 | 标准的这一部分引用了ISO/IEC 2022:1994中的以下项： 149 | 150 | a) 编码字符集 151 | b) 代码扩充 152 | c) 控制字符 153 | d) 指派 154 | e) 转义序列 155 | f) 图形字符 156 | g) 调用 157 | 158 | # 第4节 符号及缩写 159 | 160 | # 第5章 约定 161 | 162 | # 第6章 值的编码 163 | 数据集是由经过编码的现世界对象模型的信息对象定义里的属性数值组成的.这些属性的详细内容及语法都说述在信息对象定义中（PS3.3）.些章主要详述这些值的大体数据类型取值范围和编码方法。数据集的结构即这些值是都包含哪些数据元素将第7章讲述。 164 | 165 | 贯穿这章及DICOM标准的其它章节，都是使用标签来标识具体的属性及它们对应的数据元素。 166 | 167 | # 6.1 支持的字符集 168 | 值可以是由图形和控制符组成的文本或字符串，图形字符集，独立于其编码，被称为一个字符库，鉴于使用DICOM协议进行数据交互的应用所使用的自然语言的语境不同，这里可能会多种不同的字符集。DICOM支持的字符集都定义在ISO 8859中。 169 | 170 | 此外对于日语，DICOM支持以下字符集： 171 | JIS X 0201-1976 信息交换码 172 | 173 | JIS X 0208-1990 用于信息交换的日本图形字符集的代码 174 | 175 | JIS X 0212-1990 用于信息交换的补充日本图形字符集的代码 176 | 177 | 178 | #6.2 已编码的字符值的表示法 179 | 按照些节所引用的ISO标准中的定义，出现在这节中的字符编码后都是以字节型数值表示，其格式为2位10进制数分别表示行、列。 180 | 181 | 这也就是说他的数值可以这样计算（列*16）+行，例如：01/11对应数值为27（1BH）； 182 | 183 | **注：** 184 | 185 | 用2位16进制数的记号法来表示字符的编码将会贯穿此标准的剩余部分；行、列记号法仅使用在6.1章节中用来简化在合适的ISO标准间的穿插引用。 186 | 187 | 字节编码空间被按值域分为4部分： 188 | 189 | CL bytes from 00/00 to 01/15 190 | 191 | GL bytes from 02/00 to 07/15 192 | 193 | CR bytes from 08/00 to 09/15 194 | 195 | GR bytes from 10/00 to 15/15 196 | 197 | **注：** 198 | 199 | ISO 8559不区分码元（如：G0）和其引用表的区位（如：GL）。"G0"这一个词即表示码元，又表示编码表中的区位。ISO/IEC 2022中对码元(G0, G1, G2, 和 G3)和其引用表的区位(GL 或 GR)做出了明确的区分，该标准使用ISO/IEC 2022的语法。 200 | 201 | 表位CL应该调用控制字符集C0，图像字符集G0和G1分别对应表位G1和GL。DICOM中仅使用C0中的部分控制符和C1中的一些字符。 202 | 203 | #6.1.2 图像字符 204 | 205 | 一个字符库或字符集，就是一系列独立于编码方式的图形字符的集合，DICOM中所有涉及到的字符库都是由在ISO 2375中的注册号及'ISO-IR xxx'这种格式构成。 206 | 207 | 许多标准包括ISO 8859（1-9部分）都详述了编码字符集，编码字符集和图形字符集都与字符集中的每一个字符和其对应的编码表示有着一一对应的关系。 208 | 209 | #6.1.2.1 默认字符库 210 | DICOM中字符串的默认库为国际版ISO 646:1990 (ISO-IR 6)的基准G0集，详见附录E有一份DICOM默认字符库及其编码的表格。 211 | 212 | **注：** 213 | 214 | 基准字符集GO和ISO 8859中的普通字符集是相同的。 215 | 216 | #6.1.2.2 默认字符库的扩充及替换 217 | DICOM应用实体可以通过使用特殊字符集（0008，0005）这一属性来扩充和替换默认字符集。 218 | 219 | **注：** 220 | 221 | 特殊字符集使用ISO-IR 6的子集来进行编码。参照表6.2.1中对值表示法"CS"的定义。 222 | 223 | 对于值表示法为"SH","LO","ST","LT","PN","UT"的数据元素其字符库可能为扩充的或替换的（详见6.2）。如果这种扩充或远的字符集被使用了，则相应特殊字符集这一属性(0008,0005)应当被定义在常规服务对象对模型中作为一个属性(参见 PS 3.3)并且要在一致性声明中作以阐明。PS3.2中也给出了一致性声明的参考。 224 | 225 | **注：** 226 | 227 | 1. 在西部、东部及欧洲ENV 41 503 和 ENV 41 508中定义的首选字符集分别为：ISO-IR 100, ISO-IR 101, ISO-IR 144, ISO-IR 126见6.1.2.3节。 228 | 2. 信息对象定义使用不同的字符集不能依赖本身的词汇顺序或字串对比来表示字符串。这些操作只能使用一个给定的字符库不能交叉字符库的界限。 229 | #6.1.2.3 字符库的编码 230 | 使用值表示法SH, LO, ST, LT,PN 和 UT和PS3.3中一个单字节码就可以替代7位默认字符库。 231 | 232 | **注：** 233 | 这种替换字符库不适合于文本值表示法（AE和CS）. 234 | 235 | 替换字符库应该出现在特殊字符集属性（0008，0005）值的第一值，特殊字符集的详细定义参见PS3.3。 236 | 237 | **注：** 238 | 239 | 1. 编码表分为只支持94个字符集的GL区(位组合 从 02/01 到 07/14)加上02/00区间和支持96和94字符集的GR区间(位组合从 10/01 到 15/14 或从 10/00 到 15/15)。默认字符集(ISO-IR 6)通常从GL区调用。 240 | 2. ISO 8859中定义的所有字符集都包含(ISO-IR 6)。这一字符集将常被在编码表的GL区中调用，它和ASCII (ANSI X3.4:1986)是相同的。然而各种各样的扩充及替换都会被映射到编码表中的GL区。 241 | 3. 8位码表JIS X 0201 包含了ISO-IR 14（罗马数字字符）作为G0码元和ISO-IR 13（片假名注意字符）作为G1表码元。ISO-IR 14和ISO-IR 6是相同的，除了位组合05/12表示"¥"(日元符号)和位组合07/14表示上划线。 242 | 243 | 在码表中的GL区调用单字节字符库的2个字符码02/00和 05/12在DICOM标准中有很特殊意义。空格字符是由位组合02/00表示的，可以用来填充数据元素表示法为字符串的值。在表ISO-IR 6中的位组合05/12表示的图像字符"\"（反斜杠），只能被使用在值表示法为UT, ST 和 LT的字符串中。然而位组合05/12被用作多值数据元素的分隔符（详见6.4）。 244 | 245 | **注：** 246 | 247 | 当特殊字符集(0008,0005)的值即不是“ISO_IR 13” 也不是 “ISO 2022 IR 13”，图形字符用ISO-IR 14表中的位组合05/12表示"¥"（日元符号）。 248 | 249 | 删除字符（位组合07/15）不应在DICOM字符串中使用。 250 | 251 | 设定在特殊字符集属性(0008,0005)的值中第一值的替换字符集（或默认字符集的第一位为空）在必要时也可以更深一步扩充为附加编码字符集。附加编码字符集及其扩充机制应当被声明在特殊字符集属性值的附加值域。如果特殊字符集属性只有一个值，那么DICOM 服务对象对实例仅支持一种单字节编码表并且没有扩充编码机制，DICOM服务对象对实例支持的扩充编码机制在ISO/IEC 2022:1994有详细说明。 252 | 253 | **注：** 以下为考虑到对不支持字符集的处理 254 | 255 | DICOM中应用实体之间并不协商字符集，它是由通用服务对象对模型中的附加属性值指明的，因此应用可以应对对它们来说不清楚的字符集，机器可以通过使用四个字符"\nnn"其中"nnn"为3个8进制数分别表示一个字节，来显示和打印这些不能识别的字符。 256 | 257 | 例如对于一个基于ASCII的机器例子如下： 258 | 259 | 字符串：Günther 260 | 261 | 编码后表示法：04/07 15/12 06/14 07/04 06/08 06/05 07/02 262 | 263 | 基于ASCII的机器：G\374nther 264 | 265 | 应用也可能会碰到一些没有办法显示或打印的字符。此时可以通过使用四个字符"\nnn"其中"nnn"为3个8进制数分别表示一个字节，来显示和打印这些不能识别的字符。 266 | 267 | #6.1.2.4 扩充编码方法 268 | 269 | 对于值表示法为SH, LO, ST, LT,PN 或 UT的数据元素，默认字符集或字符集在特殊字符集属性(0008,0005)第一值中指定的，可以扩展使用定义在ISO/IEC 2022:1994中的扩充字符编码技术。 270 | 271 | 如果使用了这种扩充编码技术，那么相关的特殊字符集应该在常规服务对象对模型(PS 3.3)的特殊字符集(0008,0005)属性的第值中作以指明，并且要在一致性声明中做以陈述。 272 | 273 | **注：** 274 | 275 | 1. 特殊字符集属性(0008,0005)定义在PS 3.3 276 | 2. 支持日本汉字,平假名,片假名，韩语的字符集定义在PS3.3，定义汉语等多字节的字符集要等待适合的标准化组织考虑。 277 | 278 | #6.1.2.5 扩充编码的使用 279 | 280 | 当特殊字符集属性(0008,0005)值是多值时DICOM就会使用扩充编码技术，在DICOM中使用扩充编码的方法在ISO/IEC2022:1994中有详细介绍，这种情况下将引入以下假设及限定： 281 | 282 | #6.1.2.5.1 假设初始状态 283 | 284 | - G0码元和G1码元（8位）通常分别被从编码表中的GL和GR区调用，会对这些码元会直接调用指定的字符集，码元G2和G3不使用。 285 | - 首选控制字符集被指定为从编码表的GL区调用的G0码元。G1码元不使用。 286 | 287 | #6.1.2.5.2 扩充编码的限制 288 | - G0和G1码元通常具有位移状态和锁定位位移（SI,SO），在这里不需要和也不就使用 289 | - G2和G3这些未使用的码元，单移位(SS2 和 SS3)也不能使用 290 | - 只有在PS 3.3中说明过的转义序列才可以被用来激活码元 291 | 292 | #6.1.2.5.3 要求 293 | 294 | 特殊字符集属性(0008,0005)值1中指定的字符集，或者当特殊字符集属性(0008,0005)值1缺省时的默认字符集，可以出现在文本型数据元素的值的开始以及每一行(如, CR 和/或 LF之后)或每一页的开始(如, FF之后). 295 | 296 | 如果在一个文本属性值的值域中出现了即不是在特殊字符集属性(0008,0005)值第一值指定的字符集中的字符，或者当特殊字符集属性(0008,0005)值1缺省时的默认字符集时，此时在第一值中指定的字符集或者默认字符集在以下情况可用： 297 | 298 | - 行结尾前(如, CR 和/或 LF之前) 299 | - 页结尾前(如, FF之前) 300 | - 数据元素值结尾前（如，在用来分隔多值文本型数据元素值的05/12之前，这里的05/12对应默认字符集IR-6中的"\"(反斜杠)或IR-14字符集中的“¥”（人民币）） 301 | - 在分隔值表示法为PN的名称组件或名称组件组数据元素值之前 302 | 303 | 如果在文本型数据元素值中使用了和特殊字符集属性(0008,0005)值1中指定的字符集，或者当特殊字符集属性(0008,0005)值1缺省时的默认字符不同的字符集时，此字符集中的转义序列必须按以下情形来插入： 304 | 305 | - 在一行首次使用该字符集之前 306 | - 在一页首次使用该字符集之前 307 | - 在数据元素值中首次使用该字符集之前 308 | - 在值表示法为PN的名称组件或名称组件组数据元素值第一次使用该字符集之前 309 | 310 | **注：** 311 | 312 | 这些要求允许应用跳过文本型数据元素中的行，值 ，组件，和使用指定字符集开始一新行而不用去跟踪路过的文本中的字符集。在RFCs中类似的限制用来描述在网络中多字节字符集的使用。在一行或一个值或一个没有使用扩充编码的组件中不需要使用转义字符串来切换至设定的字符集或默认字符集。当特殊字符集第一值的字符集或默认字符集中仅定义了G0码元或G0码元是可用的，此时就需要一个或非来做转义开关。 313 | 314 | #6.1.2.5.4 应用级别和初始化指示 315 | 316 | 1. 特殊字符集属性(0008,0005)值缺省 317 | 318 | 7位码 319 | 320 | 应用级别：ISO 2022 Level 1 - 初级 7位码 (编码级别 标志 1) 321 | 322 | 初始化指示：ISO-IR 6 (ASCII) as G0 323 | 324 | 不能使用扩充编码 325 | 2. 特殊字符集属性(0008,0005)单值 326 | 327 | 8位码 328 | 329 | 应用级别：ISO 2022 Level 1 - 初级 8位码 (编码级别 标志 11) 330 | 331 | 初始化指示：ISO 8859中定义的字符集之一，或由特殊字符集属性(0008,0005)值1指定的JIS X 0201中的8位编码表，如G0和G1 332 | 333 | 不使用扩充编码 334 | 3. 特殊字符集属性(0008,0005)值多值 335 | 336 | 8位码 337 | 338 | 应用级别：ISO 2022 Level 4 重新设计的图形字符集在一种编码中（编码级别 标志 14） 339 | 340 | 初始化指示：ISO 8859中定义的字符集之一，或由特殊字符集属性(0008,0005)值1指定的JIS X 0201中的8位编码表，如G0和G1。如果特殊字符集属性(0008,0005)值1缺省，ISO-IR 6 (ASCII)被假设为G0，并且G1为未定义的。 341 | 342 | 所有出现在多值属性特殊字符集(0008,0005)中的字符集，都可以加入到扩充编码中。 343 | 344 | #6.1.3 控制字符 345 | 346 | 交互中的文本数据也许需要一种格式化的信息。控制字符就是用来指出一种格式，但是在DICOM中应尽量少的使用，因为有些设备会不正确的使用这些控制字符。ISO 646:1990 和 ISO 6429:1990中定义了控制字符，如下在DICOM中仅使用C0集中的4个控制字符用来对字符串数据进行编码。 347 | [Table6.1_1](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 6.1_1.jpg) 348 | 349 | 在文本字符串中以CR LF作为新行。 350 | 351 | **注：** 352 | 353 | 一些机器（基于UNIX的机器）会把LF (00/10)当作新行。在这种情况下，把期望的DICOM格式为可以转化为相应机器正确的内部表示。 354 | 355 | #6.2 值表示法 356 | 数据元素的值表示法描述了数据元素值的类型及格式，PS3.6按标签列出了所有数据元素的值表示法。 357 | 358 | 所有字符串类型VR的值除了VR为UI类型的，当要附加字符来达到偶数长度时都应使用字符‘SPACE’（20H默认字符集）。VR是UI类型的值要附加字符来达到偶数长度时要使用字符‘NULL’（00H）。 359 | 360 | DICOM以后版本中所有新的VR都应具有7.1.2（例：以下VR：OB,OW,SQ,UN）中定义的那种数据元素结构。 361 | 362 | **注：** 363 | 364 | 因所有新的VR都将按照7.1.2中描述的来定义，所以应用可以通过使用在7.1.2中列出的规则来忽略不识别的VR。 365 | 366 | 一个独立值包括其填充值的总长度不应超出值的限定长度，除了如在6.4中描述的那种多值域中的最后一个值这种情况。 367 | 368 | **注：** 369 | 370 | 值表示法的长度以及可扩展及替换的字符集都明确限定到字符而非字节，如表6.2_1，这是因为一个编码表中一个字符与其字节数的对照关系可能应其采取的字符集的不同而不同。 371 | 372 | 扩展编码时使用的转义序列不应包括在字符数的总数中。 373 | 374 | 375 | [Table6.2_1](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 6.2_1.1.jpg) 376 | [Table6.2_2](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 6.2_1.2.jpg) 377 | [Table6.2_3](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 6.2_1.3.jpg) 378 | 379 | #6.2.1 VR为PN的数据元素中的形意字符及语音字符 380 | 381 | 代表人名的字符串是以有5个组件的组件组形式编码的。由于名字写法有音意及形意的方式，可能会使用到多达3种的组件组，组件组的分隔符应该用“=”（3DH）。3个组件组的显示顺序为：单字节表示，形意表示，音意表示。 382 | 383 | 任何组件组都可能不出现，包括第一个组件组。考虑在这种情况下，一个人名可能会由一个或多个“=”分隔符开始。空组件组也需要分隔符，填充空组件及其分隔符可被忽略。 384 | 385 | 第一组件组应使用不带扩展编码的单字节字符集编码，此字符集应是特殊字符集属性标签(0008,0005)中值1所表述的字符集，如果特殊字符集属性标签(0008,0005)中无值或没有出现，则应使用默认字符集ISO-IR 6。 386 | 387 | 第二个组应当使用形意字符，这些字符集通常为特殊字符集属性标签(0008,0005)中值2-n中所限定的字符集，并且也能使用ISO 2022转义符。 388 | 389 | 第三组应该使用音意字符，这些字符集通常为特殊字符集属性标签(0008,0005)中值1-n中所限定的字符集，并且也能使用ISO 2022转义符。 390 | 391 | 分隔符"^","="已经从特殊字符集属性标签(0008,0005)中值1中所限定的字符集中去除了，如果特殊字符集属性标签(0008,0005)中无值或没有出现，则应使用默认字符集ISO-IR 6。 392 | 393 | 在每一个人名数据元素值的开始，假设有以下初始条件：如果特殊字符集属性标签(0008,0005)中值1不存在，引用默认字符集ISO-IR 6，如果如果特殊字符集属性标签(0008,0005)中值1存在，使用值1限定的字符集。 394 | 395 | 在每一个人名数据元素值的最后，以及组件分隔符“^”,"="这后，如果特殊字符集属性标签(0008,0005)中值1不存在，则应将字符集切换成默认字符集ISO-IR 6，如果特殊字符集属性标签(0008,0005)中值1存在，则切换成值1限定的字符集。 396 | 397 | 每一个组件组的最大长度为64个字符，包含其中的分隔符。 398 | 399 | #6.2.2 UN未知值表示法 400 | 401 | UN值表示法应被使用给私有数据元素或以前数据元素编码中出现的使用默认传输语法（隐匿小端）但不同于UN的值表示法，并且这种值表示法在现在是未知的。既然值表示法是未知的那么其值对大小端字序是不敏感的，并且也不是字节互换类型的数据（见7.3）。这种情况下，对未指明数据长度的序列，其值应属于为隐式值表示法模式。详见7.8章中对私有数据元素的详述及第10节与附录A中对传输语法的讨论。 402 | 403 | UN值表示法不能被使用给私有创造者数据元素（如其VR为LO,详见7.8.1） 404 | 405 | **注**： 406 | 407 | 1、其它（非默认）DICOM传输语法都使用显示VR编码，因此，私有及或标准数据元素值域中的值在编码及解码中只要使用非默认传输语法中的一种，并在此期间没有被转换成DICOM默认传输语法的都将会有一个已知的值表示法。 408 | 409 | 2、如果在某一时刻，应用知道一个属性为NU的VR的实际VR（例如拥有其合适的数据字典），他可以假设此属性的值域是以式VR小端字序编码的，不考虑当前传输语法。 410 | 411 | 3、当一个数据元素的值表示法未知并且其必须有一个VR时就当使用UN这种VR。UN表明此数据元素的值表示法为未知。 412 | 413 | 4、值表示法为UN的长度域可以使用值“未知长度（unknow length）”,这种情况下其值可被假设为以隐式VR编码，详见7.5.1来了解如何解析一个VR为UN的数据元素。 414 | 415 | 5、一个使用UN VR的标准数据元素的例子如SOP类定义中附加的3类型或U类型标准属性。当一个实际应用不支持新属性（并实际碰到）时可将其转换为UN VR。 416 | 417 | #6.3枚举值及其确定项 418 | 419 | 某一数据元素的值可以在一系列满足其VR的明确值中选择。这些确切值就是在3.4及3.5中详细限定的枚举值或确定项中其一。 420 | 421 | 当一个确切数值是一个数据元素唯一接受的值时在这种情况下就应使用枚举值。一个拥有枚举值的数据元素其值如果不等于在此标准中定义的任何一个值时当拥有一个在对像或服务对像对类定义中定义的一个无效值。 422 | 423 | **注**： 424 | 425 | 1、一个拥有枚举值的例子是病人性别（0010，0040）：它被限定为值为“M”,“F”,“0”中的一个，不应有其它值。 426 | 427 | 2、此标准以后的修改可以使用枚举值来给数据元素添加一系列允许值。这些自身附加信息可以修改其服务类UID也可以不修改，取决于数据元素的语义。 428 | 429 | 确定项是在当一个显式确切值可能会被使用者扩展引入新值时使用的。这些新值应在一致性声明中作以描述，并且不应和在此标准中定义的值有相同含义。拥有确定项的数据元素的值不与包含在此标准中定义的任何一个确定值相等时不应被认为是一个无效值。 430 | 431 | **注**： 432 | 433 | 拥有确定项的数据元素的例子如解释类型ID（4008，0210）。它被定义拥有标准中定义的一系列值中的一个，”REPORT” 或 “AMENDMENT” (3.3).因为这个数据元素拥有确定项其使用者可能会定义其它的解释类型ID。 434 | 435 | #6.4数据多重性VM及分界 436 | 437 | 数据元素的数据多重性限定了在些数据元素的值域验证码时可能出现的值的个数。每一个数据元素的VM属性都在3.6中明确说明了，如果一个元素的值域中编码的值的个数是可变的，它应表示为用一个下划线连接的两个数值：如1-10表示这一个元素中可能会有1-10个值。 438 | 439 | **注**： 440 | 441 | 在3.0以前的标准中元素的多重性中出一个“S”表明其只有一个值，在3.0中用“1”表示。 442 | 443 | 当一个数据元素拥有多个值时，这些值应当以下面的方法来分界： 444 | 445 | -对于字符串，用5CH（在使用ISO IR- 6字符集的情况下是反斜线“\”）来分隔两个值。 446 | 447 | 注：在固定长度及可度变长度的字符串中都可使用反斜线（“\”）来作分隔符。 448 | 449 | -固定长度的多重二进制值应当是一个没有分隔符的序列。 450 | 451 | 在多重字符串值中的每一个串都可能是偶数长度或奇数长度的，但是整个值域的长度（包括“\”）应该是偶数的。当其长度为奇数时可在其最后一个值的后面使用填充字符来弥补长度，这种情况下最后一个值的长度将会增加1. 452 | 453 | 注：当固定长度的字符串也出现上面这种情况时也可使用填充字符。 454 | 455 | 在VR为UI的多重值中只可在最后一个UID的值后面附加NULL(00H)来弥补数据长度，当其值域数据长度不是偶数时。 456 | 457 | VR为 SQ, OF, OW, OB 或 UN的值通常多重性都是1. 458 | 459 | #第7章 数据集 460 | 461 | 一个数据集表示了一个现实世界信息对像的实例，数据集是由数据元素组成的。数据元素包含了这个对象的属性的编码值。具体内容及其语义都在信息对象定义中有详述（3.3）。 462 | 463 | 一个数据集的构成，物质及编码及其数据元素都在这一章进行讨论。像素，图层及曲线这些数据元素的解析取决于其它相关元素。 464 | 465 | #7.1数据元素 466 | 467 | 一个数据元素是被数据元素标签唯一限定的，一个数据集中的数据元素应当按递增方式排序，并且在一个数据集中一个数据元素只能出现一次。 468 | 469 | 注：数据元素标签可再次出现在内嵌数据集中。 470 | 471 | 这里定义两种数据元素： 472 | 473 | -标准数据元素拥有偶数组号，但不属于（0000，eeee),（0002，eeee),（0004，eeee)或（0006，eeee) 474 | 注：这些组是留作DIMSE命令及DICOM文件头使用的。 475 | -私有数据元素拥有奇数组号，但不属于（0001，eeee),（0003，eeee),（0005，eeee)，（0007，eeee)或（ffff，eeee)，私有数据元素将在7.8章中讨论。 476 | 注：通常相似或相关的数据元素都拥有相同的组号，从3.0开始数据组不传递任何语义信息。 477 | 478 | 一个数据元素会拥有3种数据结构中的一种，3 种结构中的2种都是显示VR的区别在于其长度是否出现，另外一种数据结构是隐式VR的。所有3种数据结构都包含数据标签，数据长度，及数据，如图7.1-1。 479 | 480 | [Figure7.1_1](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Figure 7.1_1.jpg) 481 | 482 | 隐式及显式VR数据应不同时出现在一个数据集及其内嵌数据集中，一个数据集使用隐式还是显式，在他们的物质中都取决于协商传输语法（见第10节与附录A）。 483 | 484 | **注**： 当使用DICOM默认传输语法（隐式VR小端）时，数据元素中将不包含VR信息。 485 | 486 | #7.1.1数据元素域 487 | 一个数据元素是由域组成的，三种数据结构都共有3个域，分别是：数据元素标签，值长度，及值域。第4个域，值表示法，只出现在2种显式VR结构中。数据元素结构定义在7.12.与7.1.3中，域定义如下： 488 | 489 | 数据元素标签：一对有序16位整形无符号数，表示一个组号后跟随一个元素号。 490 | 491 | 值表示法：一个双字节字符串包含数据元素的VR，指定数据元素的VR应当与3.6数据字典中所限定的VR相同。VR的两个字符应当用默认字符集进行编码。 492 | 493 | 数据长度： 任一个都可以： 494 | -一个16位或32位无符号整形包括值域的显式长度表示组成值域的字符数（偶数），它不包含标签，值表示法，数据长度域的长度。 495 | 496 | -一个32位设置为未指定长度（FFFFFFFFH）.未指定长度可以被使用给标签为项目组（SQ）和未知UN的数据元素。对于标签为OW或OB未指定长度将按照协商传输语法来使用（见第10节与附录A）。 497 | 498 | 注：解码方对VR为SQ及UN的数据集应即支持显式的也应支持未指定长度的，合适时对VRs：OW和OB也应当支持这些情况。 499 | 500 | 值域：包含数据元素值的偶数个字节。 501 | 502 | 存储在些值域中的数据类型由元素的VR指定，指定数据元素标签的VR已在3.6中的数据字典中指明，或使用此数据元素的VR域中的值，标准数据元素的VR应当与数据字典中指定的VR相同。 503 | 504 | 值的多重性描述了在此值域中可以放多少个此VR类型的数据。如果数据多重性大于1，那么多个数据应当按照前面6.4章节中描述的那个界定在值域中，标准数据元素的数据多重性都在3.6的数据字典中指明。 505 | 506 | 未定义长度的值域中数据的分界是由在后面7.5中描述的序列界定项及数据元素界定项界定的。 507 | 508 | #7.1.2显式VR的数据元素结构 509 | 510 | 当使用显式VR结构时，数据元素由4个连续域组成：数据元素标签，VR,数据长度,值域。按照数据元素的VR，数据元素的结构会有以下两种方式： 511 | 512 | -对于VR为OB, OW, OF, SQ 及 UN,在VR域中两个字符后余下的16位是预留给以后的DICOM标准使用的。这些预留字节应被设置为0000H并不能使用不能解码(Table 7.1-1).。数据长度是一个32位的无符号整形。如果值域有一个显式长度那长在长度域中应该有一个等于值域中字节总数的数值，否则值域的有一个未知长度，其值域未尾由序列界定项标记。 513 | 514 | [Table7.1_1](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.1_1.jpg) 515 | 516 | -对于VR是UT类型的，在VR域中两个字符后余下的16位是预留给以后的DICOM标准使用的。这些预留字节应被设置为0000H并不能使用不能解码。值域长度是一个无符号32位整形。值域需要有一个显式长度，在长度域中应该有一个等于值域中字节总数的数值。 517 | 注：VR是UT类型的，也可以有一个非未定义长度如：0xFFFFFFFFH. 518 | 519 | -对于其它的VRs值长度域是紧跟在两字节VR后面的16位无符号整形(Table 7.1-2)，其值应等于值域的总长度。 520 | [Table7.1_2](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.1_2.jpg) 521 | 522 | #7.1.3隐式VR的数据元素结构 523 | 524 | 当使用隐式VR的数据元素结构时，其由三个连续域组成：数据元素标签，值长度，值域（Table 7.1-3）。如果值域有一个显式长度，在长度域中应该有一个等于值域中字节总数的数值。否则值域的有一个未知长度，其值域未尾由序列界定项标记。 525 | [Table7.1_3](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.1_3.jpg) 526 | #7.2组长度 527 | 528 | 组长度标准数据元素(gggg,0000)应被隐匿的定义给所有VR为UL并且数据多重性为1的数据元素组。在DICOM3.0（见7.4节对数据元素类型的描述）中是一个可选数据元素（数据元素类型3），它提供了一个在局部数据集解码中可跨越整个数据元素组的最佳体制。应用程序可以选择把组长度显式的编码到数据集中也可以选择不使用。所有应用都应可以接受或忽略类似的元素。 529 | 530 | **注**：在组0，2，4，6中的元素都是非标准数据元素，在标准中的其它地方表明了组0和2是必需有组长度元素的。 531 | 532 | #7.3大端与小端字序 533 | 534 | 数据集编码的另一个元素就是在AE这间通信时协商的字序。 535 | 536 | 小端字序定义如下： 537 | 538 | -在一个多字节的二进制数中（如32位无符号整形值，组号，元素号等），最低有效位应最先被编码，其余有效字节按其递增序编码。 539 | 540 | -在一个由多个8位单字节码能成的字符串中，字符将按其在字符串的出现顺序来编码（从左到右）。 541 | 542 | 大端字序定义如下： 543 | 544 | -在一个多字节的二进制数中，最有吗有效位应最先被编码，其余有效字节按其递减序编码。 545 | 546 | -在一个由多个8位单字节码能成的字符串中，字符将按其在字符串的出现顺序来编码（从左到右）。 547 | 548 | **注**：对于VR为OW或OB的像素数据或图层数据，其值中数据位的打包将在第8部分详述。 549 | 550 | 字序是协商过的传输语法的一组件（见第10部分），所有AE都支持的默认传输语法，都使用小端编码详述在附录A.1中，可变传输语法及其它的一些使用大端字序的传输语法也在附录4.1中讲述。 551 | 552 | **注**：3.7章中的命令集结构使用小端字序隐式VR传输语法。 553 | 554 | 在使用小端编码的默认情况下，大端设备翻译数据集时要在解析或操作具体数据元素之前进行字节交换。所有带有多字节值VR以及不是由单个8字节码组成的字符串的数据元素都会受到此影响。VR类型表述由单个8字节码组成的字符串的是真正的由单个字节组成的字符串，并因此而不受字序影响。由多字节构成的非字符串VR类型如下: 555 | 556 | -2字节的US,SS,OW及AT类型中的每一个组件 557 | 558 | -4字节的OF,UL,SL及FL 559 | 560 | -8字节的FD 561 | 562 | **注**：对于以上的那些VR类型，在小端模式下多字节按其有效位增序出现，例：一个VR为FD的8字节数据元素，可写做16进制68AF4B2CH，但是在小端模式下应如：2C4BAF68H。 563 | 564 | #7.4数据元素类型 565 | 566 | 数据元素类型是一个属性，做为一个数据元素编码，对于一个数据集来说可要可不要，取决二数据元素类型的属性。 567 | 568 | 一个信息对象的属性或一个服务对象对的属性的数据元素类型是用来描述此属性是强制的还是可选的，同时也可表述一个属性是不是条件可选的（在某些条件下是强制的）。复合信息对象对属性的数据类型在3.3章中做详述 。常规信息对象对属性的数据类型是做为服务对象一个属性在3.4章中讲述。 569 | 570 | #7.4.1类型1必有数据元素 571 | 572 | 信息对象对及服务类中定义为类型1的是必须被引入的强制元素。值域中应包含如在3.6章中限定VR及VM限定的有效数据。值域长度不应为0，1类型的数据元素如果没有一个有效值是违背协议的。 573 | 574 | #7.4.2类型1C条件数据类型 575 | 576 | 信息对象对及服务类中定义的一些数据元素将在特定条件下应被引入。1C类型的数据元素都会有一个1类型的数据元素做为前提条件，如果特定条件已达到但是数据元素却没有出现是违背协议的。 577 | 578 | 同样的如果指定条件未达到，则1C类型数据元素不应出现。 579 | 580 | #7.4.3类型2必有数据元素 581 | 582 | 信息对象对及服务类中定义为类型1的是必须被引入的强制元素，然而一个类型2的元素值是未知的那么允许编码时是0长度并且不带任何值。如果值是未知的，那么在其值域中应包含如在3.6章中由其VR及VM描述的数据。这些元素应出现在数据集中，如不出现则违背协议。 583 | 584 | **注**：类型2的数据允许在操作者及应用都不知道其值的时候传递0长度数据或有特殊原因不表明其值，并且这里推荐设备是可以接受这种数据元素的。 585 | 586 | #7.4.4类型2C条件数据元素 587 | 588 | 信息对象对及服务类中定义为类型2C的元素在特定条件下有着与类型2相同的出现条件，如果特定条件已达到但是数据元素却没有出现是违背协议的。 589 | 590 | 同样的如果指定条件未达到，则2C类型数据元素不应出现。 591 | 592 | **注**：一个类型2C的例子反向时间(0018,0082)，在好多服务类的定义中，这种数据元素只有在扫描序列(0018,0020)的值是IR时需要。其它的出现情况请查看3.3章。 593 | 594 | #7.4.5类型3可选数据元素 595 | 596 | 信息对象对及服务类中定义为类型2C的元素是可选的。数据集中缺少类型3的数据不表述任何其它意义，也不违背协议，类型3的元素也可以编码为0长度0内容，类型3的0长度也就表示这个元素在数据集中不存在。 597 | 598 | #7.4.6序列中的数据元素类型 599 | 600 | 当一个信息对象对定义了一个序列数据元素，序列属性的类型表示了序列属性自身必须出现，这个属性描述了这个序列的属性如将出现多少项及其怎样包含这此项，序列中的数据集的属性类型在任何情况下都是描述在数据集内部的，例：序列中出现的每一项。 601 | 602 | **注**： 603 | 604 | 1、序列的属性及类型决定的项是否出现，数据元素上的一些条件限制使某一项不能强制出现。 605 | 606 | 2、历史中许多信息对象对中声明类型1及类型2的数据元素为类型1C及2C，这些元素各自分别视条件出现。这刚好就是类型及类型2的简单描述。 607 | 608 | 3、特殊情况下，当一个附属于序列属性为类型2或类型3的类型为1C或2C的数据元素限制条件为“如果序列被发送则需要”时，并不意味着这一项必须出现。这些条件等价于“一个序列项出现则需要”，并且此条件也不是严格需要的。任何属性为类型2或类型3的序列都可以以0长度发送。 609 | 610 | 4、特殊情况下，当一个附属于序列属性为类型2或类型3的类型为1C或2C的数据元素限制条件为“如果<父序列属性名>被发送则需要”时，并不意味着这一项必须出现。这些条件等价于“一个序列项出现则需要”，并且此条件也不是严格需要的。任何属性为类型2或类型3的序列都可以以0长度发送。 611 | 612 | #7.5内嵌数据集 613 | 614 | VR为SQ表明数据元素的值是由一个或多个项组成的序列，这些项又包含一系列数据元素。SQ类型提供了一个灵活的编码机制，可以在一些简单的数据集重复结构中使用，或编码一些更复杂的信息对象定义通称文件夹。SQ数据元素也可以用来递归包含多层的内嵌数据结构。 615 | 616 | 出现在SQ数据元素中的项应该是有序的一个序列，这样每一个项都可以用其位置序数引用到。每一个项都应被隐式的分配一个从1对应第一个元素开始的位置序数，并且其后项都以1递增。序列中的最后一个项的位置序数应该等于序列中项的总个数。 617 | 618 | **注**： 619 | 620 | 1、这条意味着在数据传输入存储中的项都暗含着顺序。 621 | 622 | 2、一个信息对象对或模块定义可以选择不使用VR为SQ的数据元素中的项顺序属性，这可以简单的通过对有序项的序数不使用任何特殊的语义，或不指定任何关于项位置序数的用法。 623 | 624 | 每一个项中打包的数据元素的定义都是由VR为SQ的数据元素的描述（或相关属性）提供。序列中的项可包含相同数据元素集也可包含不同的数据元素集，VR为SQ的数据元素通常都包含多个项，但是其数据多重性都通常应是1（如一个单序列）. 625 | 626 | 这里有三种VR为SQ的数据元素但其不受能过传输语法传递的VR编码规则的限制。它们要按照隐式VR方式编码。这此特殊的数据元素是：项(FFFE,E000)，界定项(FFFE,E00D),序列界定项(FFFE,E0DD)。然而在界定项(FFFE,E000)值域中的数据集编码方式应该以传输语法中传递的规则为准。 627 | 628 | #7.5.1项编码规则 629 | 630 | VR为SQ的数据元素的每一个项的都应被编码为以(FFFE,E000)为数据标签的DICOM标准数据元素。项标签后是4字节的项长度域，其编码方式为以下两种之一： 631 | 632 | a)显式长度：包含在序列项值域（紧接着但不包括项长度域）中的字符位数（偶数）是做为一个32位无符号整形值（见7.1章）来编码的。这个长度是这个项中传递的所有数据元素的总长度。如果项中没有数据集当被设置长度为00000000H。 633 | 634 | b)未定义长度：项长度域中的值应为FFFFFFFFH来表明此项长度未定义。它应当联合界定项一起使用，这个界定项的标签为(FFFE,E00D)随后数据为打包好的数据元素，项分界数据元素应该是无值的并且其数据长度为00000000H。 635 | 636 | 编码方可选择两种编码方式中的一种，数据集解码方应同时支持此两种编码方式，数据元素标签(FFFF,eeee)是此标准的预留项，并未使用。 637 | 638 | 每一个项的值都应包含一个由数据元素组成的数据集，在每一项的内容中，这些元素的都应按标签值的增序排序并只出现一次（按照7.1节数据集的描述）。一项中的有序数据元素间以及包含他们的VR为SQ的有序元素标签这间应该都是无相互关系的。拥有一个或多个数据元素的项都属于SQ值表示法，因此允许递归。 639 | 640 | 7.8节描述了把私有数据元素打包到序列项中的方法。 641 | 642 | #7.5.2序列中项的界定 643 | 644 | 封装在值表示法为SQ的数据元素值域中的序列项的最后一项的界定，可是以下两种模式中的一种： 645 | 646 | a)：显示长度：包含在数据元素值域（紧接着但不包括数据元素长度域）中的字符位数（偶数）是做为一个32位无符号整形值（见7.1章）来编码的。这一长度应包括由数据元素传递的由0或多个项组成的序列的总长。如果序列中包括0个项刚此长度应设置为00000000H。 647 | 648 | b)：未定义长度：项长度域中的值应为FFFFFFFFH来表明此项长度未定义。它应当联合序列界定项一起使用，这个序列界定项应被引入到序列中最后一项的后面，它的标签为(FFFE,E0DD)项长度为00000000H，无数据域。 649 | 650 | 序列项的编码方或选取以上两种方法中的一种，序列项的解码方应同时支持以上两种方式。 651 | 652 | **注**： 653 | 654 | 序列界定项(FFFE,E0DD)与界定项(FFFE,E00D)是不相同的，通过以上讲解可以看出序列的最后一项的长度是左边未定义的，如果一个未定义长度的项是未定义长度序列的最后一项，那么在序列界定标签后会紧跟着一个界定项标签。 655 | 656 | 如一个SQ类型的显示长度数据元素封装着显式长度的项见Table 7.5-1 657 | [Table7.5_1](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.5_1.jpg) 658 | 如一个SQ类型的未定义长度数据元素封装着显式长度的项见Table 7.5-2 659 | [Table7.5_2](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.5_2.jpg) 660 | 在Table 7.5-2中项的数据集中有显式VR出现。 661 | 如一个SQ类型的显示长度数据元素封装着既有显式长度的项也有未定义长度的项见Table 7.5-3 662 | [Table7.5_3](https://raw.githubusercontent.com/mnhwa/DICOM-Chinese/master/Figure/Part 5/PS3.5_Table 7.5_3.jpg) 663 | 664 | 665 | #7.5.3序列继承 666 | 667 | 一个封闭后的数据集应只包括特殊字符集(0008,0005)的数据元素如果这个项序列的信息对象定义中定义了特殊字符集这一属性。 668 | 669 | **注**： 670 | 671 | 一个封闭后的数据集不包括特殊字符集的数据元素只有在这个项序列的信息对象定义中部分定义了特殊字符集这一属性时可以出现。 672 | 673 | 如果一个封装后的数据集包括特殊字符集属性，应当只适用于此封装数据集。如果一个封装数据集中没有显式的包括特殊字符集，那么此封装数据集的特殊字符集值也适用。 674 | 675 | #7.6重复组 676 | 677 | 多图层位面与曲线经常会与一张图像关联起来（见3.3章）。拥有奇数组号（5000-501E,eeee）的标准数据元素代表曲线，同时拥有偶数组号(6000-601E,eeee)的数据元素代表图层，这两个组号区域内都是重复组，这些组号用法是该标准3.0版本以前的残留版本，它使语义与特殊组号关联起来。 678 | 679 | 在这些组号区间内，标准数据元素有着相同的元素号，并且在它们各自的组中有着相同的意义（并且有相同的VR,VM及数据元素类型）。当一个常规数据元素在交叉了几个组时就可在些数据元素的标签中使用符号(50xx,eeee)和(60xx,eeee)作为组号。组(50xx,eeee)和(60xx,eeee)正是因为这些性质也叫做重复组。 680 | 681 | 重复组只能出现在偶数组(6000-601E,eeee)和偶数组(5000-501E,eeee)这种情况下，以后VR为SQ的数据元素也将为相同的目标而服务。 682 | 683 | **注**：奇数组中的私有组(5001-501F,eeee)和(6001-601F,eeee)仍然会被用到，但是这里不会牵扯到重复语义，也不暗藏标准重复组。 684 | 685 | #7.7做废数据元素 686 | 687 | 从3.0开始有些数据元素已经不再被支持。这些作废数据元素被整理在3.6中的VR表中（RET）。应用仍可支持这些数据元素来达到对3.0以前版本的前后兼容，但是对当前版本标准已经没有必要。如果使用作废数据元素那么它必需要有一个符合3.0以前版本中规定的合法值。其它对作废数据元素的使用及其数据元素标签，都是此版本标准的保留内容。作废元素标签不应在以后版本中重复定义。 688 | 689 | #7.8私有数据元素 690 | 691 | 应用也许会用到一些不能包含到标准数据元素中的信息来进行通信，私有数据元素就是用来包含这些信息的。 692 | 693 | 私有数据元素具有与前面7.1节中讲述的标准数据元素相同的结构（例，数据标签，可选VR，数据长度，值域）。私有数据元素应使用奇数组号，也可以以数据元素标签增序的方式包含到数据集中，其VR类型应是标准中6.2中讲述的一种。 694 | 695 | 对于每一个信息对象定义及服务对象对类定义，一些数据元素如3.3章和3.4章讲述的那样(数据类型1, 1C, 2, or 2C)是必有的。私有数据元素不能替代强制性标准数据元素。 696 | 697 | #7.8.1私有数据元素标签 698 | 699 | 多个系统可能会定义相同奇数组号的私有元素，为避免冲突，私有元素的标签应按以下规则来设定： 700 | 701 | a)私有元素创造者编号(gggg,0010-00FF) (gggg奇数)可由一个独立系统来预留给一个组号为gggg的元素块使用，这个使用者应当在这个序列中的第一个未使用（未指派）的元素中嵌入一个识别码来预定一个私有数据块，私有识别码的VR可以是LO（长字符串），VM应该是1。 702 | 703 | b)私有数据元素创造者编号(gggg,0010)，是一个数据元素类型为1标识系统预留元素(gggg,1000-10FF),私有数据元素创造者编号(gggg,0011)标识系统预留元素(gggg,1100-11FF),如上，直到私有数据元素创造者编号(gggg,00FF)标识系统预留元素(gggg,FF00-FFFF)。 704 | 705 | c)私有元素的编码者应该能够动态的分配私有数据到私有组号中任何空闲（未预定）的块中去，并讲明此私有数据的创造者。私人数据的解码方应能接受在由预留块限定的私有组中任何位置有给定的私人创造者识别码对应的私有数据元素。 706 | 707 | 注： 708 | 1、3.0以前的版本都讲述的影组，这些组拥有的组号比标准组大1，消除私有数据元素标签冲突使得这些特性被淘汰了，同时这个术语也就作废了。 709 | 2、3.0以前的版本描述私有元素组号(gggg,10FF-7FFF)预留组制造商，以及私有元素组号(gggg, 8100-FFFF)预留给使用者，为了消除私有数据元素标签的冲已经使得这些特性被淘汰了，同时这个术语也就作废了。 710 | 711 | 自从序列中的每一项都是一个自我包含的数据集开始（见7.5节中讲述的通过项序列来内嵌数据集），任何包含私有数据元素的项都应有一个私有元素创造者专门为这些私有元素预留的元素块。 712 | 713 | 预留的有效范围仅在些项内。私有元素创造者在内嵌项的嵌入数据集中的预留属性并不能被项继承。 714 | 715 | **注**： 716 | 717 | 1、如果一个序列本身是一个私有数据元素其内部的项也包含私有数据元素，那么在这个序列外及其内都会有私有创建者元素。 718 | 719 | 2、对于不同的私有创建者来说，不同的项可能会预留有相同的私有数据元素块，此时允许内嵌数据集把来多处的数据打包成文件夹的形式就是很有必要的。 720 | 721 | #7.8.2私有数据元素的VR规则 722 | 723 | 私有数据元素的值表示法应与6.2节中对标准数据元素的值表示法的限定相同。 724 | 725 | --------------------------------------------------------------------------------