LIUMIN2024

本次会议讨论了关于快捷键的问题，总结如下： 1、快捷键功能需求与实现 用户希望所有中文库都能使用类似CALIS的快捷键功能，目前nlc库无法使用，其他库可以使用，这是因为该库未定义角色（NLC或CALIS），目前只有calis快捷键已完成实现，nlc快捷键涉及到业务需求层面，需要跟用户进行进一步沟通，确定需求后，再开展后续工作。另外西文书目库不涉及快捷键功能，因为西文字段名与中文不同，不存在类似需求。 2、文档规范与用户沟通 需求文档需明确区分CALIS和NLC的快捷键功能，即使功能相似也需分开描述，需求文档需清晰标注功能适用标准（CALIS/NLC），避免后续争议。 3、细节知识点 记录格式通过998字段或数据库角色（CALIS/NLC）标识，优先级为998字段记录的格式高于设定的角色，例如一条数据在998字段中规定了这条Marc数据为calis格式，该数据存储的书目库角色为nlc，这条Marc数据依旧为calis格式。 4、快捷键方案设计 1）根据这条数据格式进行区分，nlc格式输入快捷键后只弹出nlc格式的快捷键，calis同理 2）不进行格式区分，输入对应的快捷键后，全部弹出可使用的快捷键nlc生成什么数据，calis生成什么数据 3）依旧根据数据格式进行区分，输入对应的快捷键后，全部弹出可使用的快捷键，如果该数据为calis格式，针对nlc生成的数据弹框就发灰，无法选择，calis同理。

本次会议主要讨论了数据记录和字符集处理的技术细节，包括中文和英文的Mark记录格式、字符集的定义和重要性，以及在导出数据时如何处理字符集和编码方式。会议强调了字符集在数据传输中的作用，以及在不同编码方式（如GB2312和UTF-8）下字符集的处理差异。同时，讨论了自动规整功能的使用和潜在问题，以及如何在培训中向用户解释这些技术细节。 在内务前端书目查询窗中，检索并调取一条书目记录到种册窗界面。中文和西文的记录长度信息记录在头标区中，由五位数字组成，记录长度对于程序员来说非常重要，因为它帮助程序员确定每条记录的长度，从而正确处理数据。注意记录长度不计算Marc数据实际长度，它类似于文件中的一个标识符，确保数据不会被错误地处理或合并。中文和西文的字符集信息存储的地方不同，西文格式的字符集信息存储在头标区第九位，仅用一个字符表示，中文格式的字符集信息则存储在Marc数据的100字段中，使用4位字符表示,这是不合理的，字符集信息应该统一存储在头标区中，但是伊芙拉设计unimarc小组把字符集信息设计存储到100字段中了，所以导致了这种现象的发生。 光标移动到100字段上，使用快捷键CTRL + M打开一个模板，该模板能看到100字段的内容到底是怎么构成的，26/4存储的是字符集信息，还有补充字符集，在这里先不赘述补充字符集。举个例子，有条Marc数据的100字段信息为：100 ǂa20090713d2009 em y0chiy0120 ea，“0120”就是这条数据的字符集信息，当记录导出到ISO2709的时候，这个字符集是应该发生变化的。为了便于观察，我们将“0120”改为“xxxx”，在书目查询窗中选择这条书目数据，点击右键，选择导出，选择导出到Marc（ISO2709）数据，在导出Marc窗，选择编码方式为UTF-8，不勾选自动规整100字段，不勾选删除997/998字段，不勾选任何选项，不选择脚本，导出Marc文件后，使用批处理-从Marc文件中导入，重新输入导出的ISO文件名，可以观察到100字段，第26个字符，字符集信息未发生改变，依旧是“xxxx”。当导出的Marc数据编码方式不变，勾选上自动规整100字段时候，“xxxx”会变为50##，系统在导出数据时，自动规整了100字段的字符集信息。如果选择的编码方式为GB2312，不勾选与勾选自动规整100字段时，第26个字符，字符集信息都不会发生改变，因为国际上未能统一标准，对于字符集必备信息是0110还是0120存在争论，所以未开发GB2312自动规整100字段必备字段信息功能。 另外，需要提醒用户在导出ISO2709文件时，尽量选择编码方式为UTF-8进行导出，因为导出GB2312编码方式时，会出现丢字符的情况，例如：欧洲法文语言里边，出现一个字母O上面打了两个点，导出GB2312编码方式的时候，这两个点会丢失，后续完善dp2系统，在导出GB2312编码方式时，出现丢失数据的情况会警告提示。以上为本次字符集培训内容知识。

刘敏常见问题库

2

1.西文时间freetime 2.z39.50服务器 3.批校验册条码 4.册统计窗 5.dp2mini阅读分析模块 6.自动规整问题