带有 Like-Stream 的 Marc21 二进制解码器
Marc21 Binary Decoder with Akka-Stream
我正在尝试解码 Marc21 二进制数据记录，这些记录具有以下关于提供记录长度的字段的规范。
A Computer-generated, five-character number equal to the length of the
entire record, including itself and the record terminator. The number
is right justified and unused positions contain zeros.
我正在尝试使用
Akka Stream Framing.lengthField，但我只是不知道如何指定该字段的大小。我想一个字符是 8 位，一个数字可能是 16 位，我不确定，我想知道这是否取决于平台或语言。简而言之，问题是是否可以说知道我在 Scala/Java 中的那个字段的大小是多少？
还有什么意思：
The number is right justified and unused positions contain zeros"
如果收集得当，这对人们如何读取值有影响吗？
如果有人对此有任何了解，请分享。
编辑1
上下文：
我正在尝试构建一个流处理图，其中第一阶段将针对 symphony（供应商编目系统）服务器处理 sys 命令 运行 的结果，这是一个非结构化字节块流它作为一个整体代表了所有请求的 Marc21 记录（完整转储或部分转储）。
我的意思是，通过处理，将非结构化字节流分块为帧流，其中帧是记录。
换句话说，同时为一个记录准备字节，并将其单独发送到下一阶段。
下一阶段将包括将该记录（字节）发送到 apache Kafka。
显然发射阶段将完全并行化以加速该过程。
Symphony 服务器无法在请求时通过流式传输转储，尤其是通过网络。因此，这种基于 Akka 流的图形处理可以执行该工作，以便在我们的整体快速数据基础设施中对我们的转储进行快速 ingestion/production 和整体流处理。
编辑2
根据@badcook 的输入，我想知道这里是否可以使用 ComputeFramesize。不确定我对该函数及其参数的含义感到有些困惑。
不胜感激。
您似乎正在尝试解析 MARC 21 records。
在这种情况下，我建议您只看一下 MARC4J 并使用它。
如果您想将它与 Akka 流集成，或者即使您想以自己的方式解析 MARC 记录，我建议您使用 MARC 21 记录终止符（ASCII）将字节流与 Framing.delimiter 分开控制字符 1D) 转换为完整的 MARC 记录，而不是尝试流式处理和处理 MARC 记录的片段。会容易很多。
关于您的具体问题：MARC 21 规范在谈论其结构时使用字符而不是原始字节。它指定了两种字符编码为原始字节，UTF-8 和 MARC 8，它们都是可变宽度编码。因此，不，每个字符都是一个字节是不正确的。一个字符占用多少字节没有单一的答案。
“[R]右对齐和未使用的位置包含零”是另一种说法，数字从左边开始用 0 填充。在这种情况下，这一行来自一个更大的引用，即数字字符串必须是 5 个字符长。这意味着如果您要表示数字 1，则必须将其表示为 00001.
我正在尝试解码 Marc21 二进制数据记录，这些记录具有以下关于提供记录长度的字段的规范。
A Computer-generated, five-character number equal to the length of the entire record, including itself and the record terminator. The number is right justified and unused positions contain zeros.
我正在尝试使用
Akka Stream Framing.lengthField，但我只是不知道如何指定该字段的大小。我想一个字符是 8 位，一个数字可能是 16 位，我不确定，我想知道这是否取决于平台或语言。简而言之，问题是是否可以说知道我在 Scala/Java 中的那个字段的大小是多少？
还有什么意思：
The number is right justified and unused positions contain zeros"
如果收集得当，这对人们如何读取值有影响吗？
如果有人对此有任何了解，请分享。
编辑1
上下文：
我正在尝试构建一个流处理图，其中第一阶段将针对 symphony（供应商编目系统）服务器处理 sys 命令 运行 的结果，这是一个非结构化字节块流它作为一个整体代表了所有请求的 Marc21 记录（完整转储或部分转储）。
我的意思是，通过处理，将非结构化字节流分块为帧流，其中帧是记录。
换句话说，同时为一个记录准备字节，并将其单独发送到下一阶段。
下一阶段将包括将该记录（字节）发送到 apache Kafka。
显然发射阶段将完全并行化以加速该过程。
Symphony 服务器无法在请求时通过流式传输转储，尤其是通过网络。因此，这种基于 Akka 流的图形处理可以执行该工作，以便在我们的整体快速数据基础设施中对我们的转储进行快速 ingestion/production 和整体流处理。
编辑2
根据@badcook 的输入，我想知道这里是否可以使用 ComputeFramesize。不确定我对该函数及其参数的含义感到有些困惑。
不胜感激。
您似乎正在尝试解析 MARC 21 records。
在这种情况下，我建议您只看一下 MARC4J 并使用它。
如果您想将它与 Akka 流集成，或者即使您想以自己的方式解析 MARC 记录，我建议您使用 MARC 21 记录终止符（ASCII）将字节流与 Framing.delimiter 分开控制字符 1D) 转换为完整的 MARC 记录，而不是尝试流式处理和处理 MARC 记录的片段。会容易很多。
关于您的具体问题：MARC 21 规范在谈论其结构时使用字符而不是原始字节。它指定了两种字符编码为原始字节，UTF-8 和 MARC 8，它们都是可变宽度编码。因此，不，每个字符都是一个字节是不正确的。一个字符占用多少字节没有单一的答案。
“[R]右对齐和未使用的位置包含零”是另一种说法，数字从左边开始用 0 填充。在这种情况下，这一行来自一个更大的引用，即数字字符串必须是 5 个字符长。这意味着如果您要表示数字 1，则必须将其表示为 00001.