我正在学习计算机科学课程，当我阅读这些定义时，我明白了。但我不知道两个演示文稿有什么不同的目的以及为什么。这里对我的书所说的目的进行了一些简短的解释：
Zone decimal : hightly compatible with text data.
Packed decimal : faster computing speed.
我想知道的是：
1）在区域十进制表示中，有一个重复每个数字的区域部分。为什么 ？我认为这是没有目的的:(
2）为什么他们说区域十进制与文本数据兼容以及为什么压缩十进制更快。
谢谢 ：）
首先-您在哪里学习CS？这些术语来自 1960 年代，更常见的名称是 BCD（二进制编码十进制）
区域十进制对每个数字使用整个字节。这意味着您可以像打印文本一样打印一个数字（每个“字符”存储一个数字 0-9），但由于只有 10 个数字，一个字节可以保存 256 个不同的值，这有点浪费。
压缩十进制使用 4 位可以存储 16 个不同值的事实。因此，您可以在一个字节中存储两个数字（前 4 位和后 4 位）。这仍然有点浪费，因为您只使用了一半的容量。但是只需移位和掩码操作即可轻松提取两位数。
如今，您几乎唯一能看到 BCD 的地方是在一些低级硬件中，您想在根本不使用微处理器的情况下读取/x-mit 一个数字。仅在晶体管中制作 BCD 计数器很容易
但是，如果您想做任何数学运算，则必须像在纸上一样对每个数字进行长乘法-或者转换为常规整数并再次返回
这两种表示形式都失宠了，可能是因为它们没有直接得到 C 的支持，因此所有的系统都是 Unix 的后代。
压缩十进制在两个方面具有优势：由于占用的空间更少，它可以更快地脱离总线并进入处理器，并且许多 CISC 指令集都有专门的算术指令。引用http://en.wikipedia.org/wiki/Packed_decimal#Packed_BCD：
压缩 BCD [二进制编码的十进制] 在 COBOL 编程语言中支持为“COMPUTATIONAL-3”（许多其他编译器供应商采用的 IBM 扩展）或“PACKED-DECIMAL”（1985 COBOL 标准的一部分）数据类型。除了 IBM System/360 和更高版本的兼容大型机之外，压缩 BCD 是在 Digital Equipment Corporation 的原始 VAX 处理器的本机指令集中实现的，并且是 Burroughs Corporation 中型系统系列大型机的本机格式（源自 1950 年代 Electrodata 200系列）。
分区十进制 (http://en.wikipedia.org/wiki/Zoned_decimal#Zoned_decimal) 在穿孔卡片上的字符和它们在内存中的表示之间有一个简单的映射，这也许可以解释你的教科书声称它“与文本数据高度兼容。 " 正如 Wikipedia 文章所暗示的，它是 IBM 大型机圈子中更多使用的术语。在 minis 上，我们倾向于将其称为普通的旧十进制数据，即 PIC 9 数据。
自然环境中的“分区十进制”旨在与 EBCDIC 字符集兼容。
ASCII 将数字表示为 x'3x' -- x'39' 显示为字符“0”到“9”。
EBCDIC 字符集（起源于Hollerith 穿孔卡片）使用类似但不同的方案，其中 x'F0' 显示为字符“0”，而 x'F9' 显示为字符 '9'。
穿孔卡片的固定长度为 80 个字符，在许多情况下，其中 10 或 12 个字符被记录类型标识符和序列号吃掉（如果您将一堆卡片掉在地板上，这非常重要！）。所以空间非常宝贵。不是在每个数字旁边输入“+”或“-”字符，而是在卡的顶部附近使用“打孔”额外的孔来表示正数或负数，从而节省一个字节。
这些打孔字符在 EBCDIC 中被编码为 x"D0' 到 x'D9" 用于 -0 到 -9 和 x'C0' 到 x'C9' 用于 +0 到 +9，通常在数字的最后一位。
因此，“分区十进制”格式。每个字节的前四位是区域，后四位“数字”到 -42 被编码为 x'F4D2'。这更像是一种约定，因为计算机无法使用这种格式做任何事情。因此，在进行任何计算之前，需要将其编码为“打包”格式。这很简单 'X'F4D2' -> x'042D' 主要是抓取最后一个区域，然后从每个字节中提取“数字”四位，然后可以将其转换为二进制。
在设计 IBM 大型机时，最大的用户群是银行、保险公司和公用事业公司。那里的大部分处理都遵循这种模式。
大多数计算涉及货币金额，并且大部分结果会立即显示。很明显，如果机器可以直接对压缩十进制值进行算术运算，您就可以避免几个昂贵的“转换为二进制”和“转换为十进制”指令。作为奖励，它可以轻松地将小数点放在正确的位置并执行任何小数四舍五入。因此，大量工作用于实现本机压缩十进制指令（零、加、减、乘、除、移位和舍入等）。
This has been the preferred currency format for IBM mainframes ever since.
For many years developers on other platforms poured scorn on the mainframers for using such an archaic format, and, only recently began to realize how difficult it was to do fixed point decimal arithmetic to the standards accountants and tax collectors expect. Thanks to the efforts of Mike_Cowlishaw and others the rest of the world has caught up with the venerable IBM 360 and Java programmers can now calculate sales tax correctly using the BigDecimal library which is based on a variation on the old packed decimal format.