最近新写的 DigitalPlatform.Z3950 这个 Z39.50 函数库推出以后，编写一个 Z39.50 前端变成了比较容易的任务。由此我想到，可否开发一个 Web 界面的 Z39.50 编目前端，一来是提供给广大用户一种新的选择，另外也可以起到检验 DigitalPlatform.Z3950 函数库的作用。

以下是我对基本功能的一些设想，欢迎大家补充： 1) 需要建立一个 Z39.50 站点数据库，并提供 Web 界面进行维护管理。这样经过一段时间用户共同添加积累，包含了大部分常用的 Z39.50 服务器参数，选用的时候就很方便了。Z39.50 技术本身现在已经基本普及了，要做好的恰恰是易用性。 2) Web 界面上，每个注册的用户可以拥有一个自己的 Z39.50 站点列表，站点信息从上述 Z39.50 站点库中引用或者复制。这里要解决一个问题，就是通用的 Z39.50 站点配置信息里面的用户名和密码，可以被每个用户引用或者复制以后的信息，覆盖用户名和密码部分，从而实现不同用户用自己的密码访问同一 Z39.50 的效果。 3) 具备一定的 MARC 记录编辑功能。 4) 具备一个类似“购物篮”的设施，可以存储检索后选定的记录，最后统一下载为 ISO2709 文件到用户本地电脑。 5) 用 .NET Core 开发，系统可以部署在 Linux 服务器上。

Z39.50 站点数据库，dp2Capo 实现 Z39.50 检索的功能也需要它。这样可以令 dp2Capo 检索功能简单，检索请求里面直接引用站点数据库中的站点 ID 即可，dp2Capo 本身一定是具备访问 Internet 能力的，它可以主动用这个 ID 去获得站点的详细配置信息。

dp2Catalog 可以增强功能，用上述站点数据库来作为配置服务器参数时候的数据源，简化用户配置常用 Z39.50 服务器的操作，从而大大降低使用门槛。(配置 Z39.50 服务器参数是小白用户使用中的一个主要难点)

Z39.50站点数据库用MongoDB
站点数据库的字段定义 Z39.50服务器配置字段：服务器地址，端口号，数据库，用户名，密码其它字段：创建用户（如果是公共的可以为public），创建时间
创建ASP.NET Core MVC 应用，实现站点管理，用户注册等1楼提到的功能。
提示 Web API 供其它前端使用公共的Z39.50站点配置信息
项目名称WebZ

web marc 编辑器

2018-06-04 数字平台谢涛(2820725526) 11:29:17 我的设想是，主体是一个不可编辑的表格，当鼠标点到某个位置的时候，这个位置出现 textbox。

我昨天甚至想到，这个处于编辑状态的字段，外观上可以故意和其他字段区别开，也是一种很好的界面风格。

一般 MARC 字段，能编辑字段名，字段指示符，和字段内容，三个区域即可。而对于一些固定长的字段，比如头标区和 100$a 之类，还可以在选择它们的时刻，自动撑高变为一个编辑模板出现在原本的内容区域。这样就非常先进了。

WebMarcEditor 设计主要思路在浏览器端设定两种编辑模式可以随意切换。分为条目编辑器和MARC编辑器俩种；开设这俩种是针对倆种用户，一种为熟悉MARC数据结构格式的专业用户，另外一种为非专业用户。条目编辑器 OP 略

MARC编辑器。根据模板生成所需字段的前台显示。添加字段，删除字段，添加子字段，删除子字段。清空空字段，自动加PY字段（要根据模板），字段排序都为鼠标在表格右键实现。而且字段排序功能将在插入字段的时候自动排序到制定位置！

站点数据库的一些细节

1) 记录要有站点名字段。这是一个中文的名称字段，会被用来检索，显示在界面上，非常重要。在记录保存的时候，要检查数据库中所有记录，确保这个名称不会重复。

renyh回复：好的，增加站点中文名称字段，不重复。目前创建索引的有站点地址，这个中文名称也创建索引。

2) 记录要有 ID 字段。每个记录有个唯一性的 ID，可用 GUID 规则发生。当前端下载了一个站点记录，后来需要再次检查服务器上这个记录是否有变化的时候，要用这个 ID 字段来进行检索。为什么不用“站点名”字段承担这个连接的功能？因为站点名可能会改名，但这个 ID 字段一旦建立以后永远不会修改的。

renyh回复：id是用GUID，还是用mongodb自带的ObjectID类型，我觉得直接使用用自带的ObjectID就可以了。

3) 要有一个 URL 字段，指向提供 Z39.50 配置信息的页面。例如国会图书馆的 Z39.50 服务器配置参数页面。

renyh回复：好的，已增加此字段

4) 权限认证方式、用户名、密码这几个字段，在创建记录的 Web 界面填写的时候，应该还有一种办法指定这个信息是否保存在服务器上，让用户明确了解。如果用户不希望保存，可以有个 checkbox 或者按钮让这几个域发灰。

renyh回复：在创建通用站点配置信息时，不用填写这类帐户信息吧，当个人配置自己站点列表时，拷贝通用站点信息后，然后填写帐号信息，这个时候可以选择填还是不填 已根据谢老师的回复，改为创建站点信息时，输入帐号信息，用户也可以选择不保存

5) 密码字段，是否允许用户看到？看到也可以理解，因为上传到服务器以后这个密码就成为公共密码了，谁都能看到和使用。也可以做成用户看不到，但实际上存储在服务器里面，并且 API 可以获取到。不过这样就有点蒙事儿的意思了，概念不是那么顺。

renyh回复，~~帐户和密码信息，我理解是放在个人的站点信息里，个人的站点有个ID指向通用站点配置，但通用站点配置不包括帐户密码信息~~ 站点信息中包括帐号信息，密码显示时用mask

谢老师回复

在创建通用站点配置信息时，不用填写这类帐户信息吧，当个人配置自己站点列表时，拷贝通用站点信息后，然后填写帐号信息，这个时候可以选择填还是不填

最理想的情况，是从站点数据库拿到站点配置，直接就可以访问 Z39.50 服务器，不需要用户名和密码。这个最方便，例如国会图书馆的服务器就不要用户名和密码。稍微次之的情况，是站点记录里面有用户名和密码，比如用户名 public 密码 public，这明显是让大家公共使用的。如果你开发的创建记录界面不让输入用户名和密码，这种情况怎么办呢？难道每个人都要把这个缺乏密码的站点记录复制下来在本地填充密码？怎么填，还要加一个文字说明？因为用户基本都是无脑的小白用户，要考虑他的行为模式，一举一动。因为这一点做不好，这个应用就打了很大折扣了

而本地输入密码，每个不同的人拿到同一条站点记录，到本地都输入不同的、属于自己的密码，这是不得已的情况，并不是 Z39.50 服务器提倡的用法。Z39.50 服务器是很提倡开放的，无障碍访问的，大部分都是提供公共服务。

所以，优先给创建站点记录的人压力，让他尽可能填写好这些字段，然后一般用户直接用这个站点记录就能访问服务器。我们对创建站点记录的人要求可以高一些，这些人是懂 Z39.50 配置的。但用站点记录的人，可能是根本对电脑操作不熟练的小白用户。

我甚至设想，这种站点记录可以明确标出几个等级状态：第一等是直接用来访问；第二等是需要专门填写用户名和密码才能访问。 权限验证方式，和是否能直接访问没有关系。

考虑到将来我们可能开发自动根据每条站点记录，去访问服务器，检查服务器的可访问性，那么第二等的记录就无法用于自动访问，因为没有人提供密码么！

数字平台任延华(474381593) 18:59:00 好的，明白了，通用站点配置信息加上输入用户名帐户等信息。

站点配置信息

关键属性

字段名	中文名	示例/备注
name	服务器名称	例如：国图联编中心
addr	服务器地址	例如：60.245.28.23
port	端口号	例如：210
homepage	Web主页	可跳转
dbnames	数据库名	多个库名以逗号分隔，例如UCS01,UCS09
authmethod	权限验证方式	Open值为0，ID/Passw值为1
groupId	Group ID
userName	用户名
password	密码

服务器名：可读性文字，如“Library of Congress”，为国会图书馆的名称。地址：服务器的IP地址或域名，如“z3950.loc.gov”。端口号：这是Z39.50服务器的监听端口号，如“7090”。Z39.50协议的缺省监听端口号为210。 Web主页：可选参数，在这里可填写服务器的Web主页或有关技术交流网站的URL，如“http://www.loc.gov/z3950/lcserver.html”。在数据库名列表框中，可添加该服务器提供的访问数据库。可输入多个数据库名。注：虽然有些服务器提供了多个数据库访问，但不支持多库联合检索。在Z39.50检索窗中进行检索操作时，如果检索前选定了服务器节点，软件会自动联合检索该服务器节点下属的全部服务器。对于不支持多库联合检索的服务器，这种检索方式会报错。对于这类服务器，检索前选定具体的数据库节点，就可避免出现报错。

权限验证方式分Open和ID/Pass两类方式，Open支持匿名访问，ID/Pass需要输入用户名与密码。具体采用哪种权限验证方式，要咨询Z39.50服务器的系统管理员。如果服务器支持匿名登录，这里可以不填写用户名和密码。例如国会图书馆的Z39.50服务器就支持匿名登录，选Open权限验证方式并保持用户名和密码参数为空即可。 GroupID 是有用的。有些 Z39.50 服务器不填写group

检索/获取

字段名	中文名	示例/备注
recsperbatch	获取记录每批条数	例如20，这项属于通用信息，还是个性设置？
defaultMarcSyntaxOID	缺省数据格式OID	UNIMARC/MARC21/SUTRS/XML
defaultElementSetName	缺省元素集名	B/F/dc/mods/marcxml/opacxml
firstfull	在获取浏览记录阶段即获取全记录	这项还需要吗？作为通用站点配置信息，按统一的简要格式下载吗？因为有的服务器统计下载条数
detectmarcsyntax	自动探测MARC记录格式	on/off
ignorereferenceid	不检查Reference	on/off，功能是？
ISBN检索前，对检索词作如下预处理	规整为13位形态/规整为10位形态/加入横杠/去除横杠/野蛮匹配多选，是用一个字段表示，还是用多个字段表示。
isbn_force13	规整为13位形态	0/1

获取记录每批条数：Z39.50协议前端在获取检索结果的时候，是采用分批传送的方式进行的。需在此设置每一批所传送的记录条数。建议设定为20。这个参数如果太小，分批会变得细碎；如果太大，每批传送后显示的等待时间会变长。

缺省数据格式OID：Z39.50协议为不同的数据格式分配了特定对象标识(OID)参数值，前端将根据此处设定的数据格式OID向服务器提出获取数据的请求。对于国会图书馆的Z39.50服务器，这里需设定为1.2.840.10003.5.10，也就是USMARC格式的OID。

缺省元素集名：前端将根据此处的设定，装载相应的元素集。对于MARC格式的数据，可选择的元素集名一般有”B”和”F”两种，前者为简明格式，后者为详细格式。本参数和前一参数“缺省数据格式OID”有内在联系，需要一并设定。例如，某些数据类型并未有对应的元素集(比如MARCXML、DC等)，这里设定的元素集对检索结果没有任何影响。对于美国国会图书馆的Z39.50服务器，这里设定为“F”。

在获取浏览记录阶段即获得全记录：记录浏览信息与全信息字节量有较大差别，所以，先获取浏览记录可以提高数据传递效率。并且，很多服务器采用对浏览记录不收费而对全记录收费的授权访问策略，那么，不选择“获取浏览记录阶段即获得全记录”，则可以节省前端的数据获取成本。

自动探测MARC记录格式：Z39.50协议规定，在获取数据阶段，每条数据记录都携带了指明其具体MARC格式的信息。但是目前国内国外的某些Z39.50服务器并未遵守这一规定，例如在返回国内常见的 UNIMARC数据记录的时候，胡乱跟随以“USMARC”的格式信息，造成Z39.50前端显示记录概况的时候，抽取字段信息错位。对于这类不规矩的Z39.50服务器，dp2编目前端无奈设计了此选项。对于不规矩的Z39.50服务器，需要check on此参数，前端会根据所获取到的MARC数据内容，自动侦测其为UNIMARC还是USMARC并作后续处理。而对于规矩的Z39.50服务器，check off此参数即可。对于国会图书馆的Z39.50服务器，此参数设定为off。

字符集

字段名	中文名	示例/备注
queryTermEncoding	检索词缺省编码方式	gb2312/utf8等
defaultEncoding	数据记录缺省编码方式	gb2312/utf8等
recordSyntaxAndEncodingBinding	数据格式与字符集编码绑定关系	是一个数组
charNegoUtf8	启用字符集协商功能，优先为检索词选用UTF-8编码方式	on/off
charNego_recordsInSeletedCharsets	若启用了字符集协商功能，令数据记录也一同采用UTF-8编码试	on/off

检索词缺省编码方式：定义前端向服务器端提交的检索词的编码方式。一般情况下，对于国内目前大部分不支持Unicode的Z39.50服务器，这里需要设定为“gb2312”。对于国会图书馆的Z39.50服务器，此参数设定为”UTF-8”。

数据记录缺省编码方式：定义服务器传递到前端的数据记录所采用的缺省编码方式。一般情况下，对于国内目前大部分不支持Unicode的Z39.50服务器，这里需要设定为“gb2312”。对于国会图书馆的Z39.50服务器，此参数设定为“MARC-8”。

数据格式和字符集编码方式绑定关系：当上一参数“数据记录的缺省编码方式”不足以指定复杂的编码方式约定时，本参数给出了一种根据具体数据格式对应不同编码方式的定一办法，以更好地切合实际情况。如果服务器仅支持一种数据格式，编码方式也是固定的，就没有必要设定本参数(将本参数保持为空即可)。对于国会图书馆的Z39.50服务器，建议设定为：数据格式1.2.840.10003.5.10(USMARC)对应编码方式MARC-8；数据格式1.2.840.10003.5.109.10(XML)对应编码方式UTF-8。

启用字符集协商功能，优先为检索词选用UTF-8编码方式：对于某些支持字符集协商功能的Z39.50服务器，当dp2编目前端这类也支持字符集协商功能的前端访问它们的时候，若启用字符集协商功能，就可以选定最佳的字符集在通讯中使用。本参数为on时，第一启用了字符集协商功能，第二会在协商中自动优先选用UTF-8编码方式。若Z39.50服务器不具备字符集协商功能，则设定本参数为off即可。对于美国国会图书馆的Z39.50服务器，本参数设定为off。 (注：数字平台的dp2ZServer，即Z39.50服务器产品支持字符集协商功能。)

若启用了字符集协商功能，令数据记录也一同采用UTF-8编码方式：本参数生效的前题是前一项参数“启用了字符集协商功能”为on。本参数的意思已经很明了，就是当前一项参数为on的情况下，决定传输数据记录是否也一并采用UTF-8编码方式。如果Z39.50服务器有此能力，本参数当然应设定为on，以便应用Unicode字符集。对于美国国会图书馆的服务器，因前一参数设定为off，因此本参数处于不可设定状态，缺省为off。注：1) 检索词编码方式设定不正确，将导致服务器无法正确理解检索词，检索的结果就会不正确；2) 对于不支持字符集协商功能的服务器，如果在此启用了字符集协商功能，可能无法正常联接服务器。如遇此情况，请清除启用字符集协商功能选择框即可。

暂时不使用的字段

字段名	中文名	示例/备注
~~excludeNames~~	全选中不参于检索的数据库名	dp2catalog用法，先不加

全选时不参与检索的数据库名。这个属于 dp2catalog 非常特别的用法。因为在 dp2catalog 里面，可以在目标树上选定服务器节点(表示用全部数据库检索)，和选定某个数据库节点(是服务器节点的下级节点)。有的 Z39.50 服务器比较不灵活，如果你列出多个数据库在数据库名参数中访问，它会报错；如果你列出一个数据库名，它就不会报错。诸如此类。所以这是 dp2catalog 特有的问题、和解决办法。可以先不考虑这个参数，后期有必要再加入也不迟。并不是所有 Z39.50 前端都像 dp2catalog 那样设计一棵树。当然，后面比如 WebZ 我们怎么设计界面，还需要专门研究一下。每次重新设计都是一次新的机会，可以尝试一些新的做法。平时我们也可以多了解别的软件的做法。

创建站点时，用户可选择是否设置帐号信息

数字平台谢涛(2820725526) 20:02:10

这些字段是否需要，要一个一个讨论。基本上是两个方法：一个是现在都做到；一个是先做一些核心的，以后需要增加再慢慢增加。不过慢慢增加，会反复去重新修改 Form 界面，也比较烦

还有你设计 Web 编辑记录界面的时候，最好第一画面是一些必要字段，然后点个什么出现扩展的字段，避免一上来出现一个很庞大的 Form 吓着使用者。

这些都是 Web 界面的烦恼。不过 Web API 没有这个烦恼，比如要提交保存记录，获得记录，可以用 XML 格式。里面用不到的字段自然不会出现，XML 记录看起来会很小。而且有弹性

对于第三方来说，他们可能会觉得我们有些字段没用，他们不看。他们获得了也不看。也是可以的

所以你可以评级一下，看看核心的是哪些，扩展的是哪些字段

我觉得先弄出个样子，后面再扩展也是一个做法，符合互联网精神。别没事给自己找事

数字平台任延华(474381593) 20:13:08 最简单的，有一般信息、数据库、账号 就可以了

数字平台谢涛(2820725526) 20:13:51 恐怕还要有编码方式。不过编码方式有很多种一种是检索词编码方式；一种是获得记录时候记录的编码方式。而且同一个 Z39.50 服务器这两个参数可以扭曲

    public class ZServerItem
    {
        //[BsonId]
        //[BsonRepresentation(BsonType.ObjectId)]
        //这里没用ObjectId，OjbectID检索起来不方便，必须是16进制数，会报BsonNull is not a valid 24 digit hex string
        [BsonId]    // 允许 GUID
        public string id { get;  set; } 

        //==========
        //Z39.50服务器基本配置信息
        //==========
        public string name { get; set; } // 服务器名称
        public string addr { get; set; } // 服务器地址
        public string port { get; set; }  // 端口
        public string homepage { get; set; } //主页

        public string dbnames { get; set; } // 数据库名

        public int authmethod { get; set; }    // 权限验证方式 open:0,ID/PASS:1
        public string groupid { get; set; } // groud id
        public string username { get; set; }  // 用户名  
        public string password { get; set; } // 密码  //加密todo

        //===
        // Z39.50服务器高级配置项
        public int recsperbatch { get; set; }
        public string defaultMarcSyntaxOID { get; set; }
        public string defaultElementSetName { get; set; }
        public int firstfull { get; set; }
        public int detectmarcsyntax { get; set; }
        public int ignorereferenceid { get; set; }

        public int isbn_force13 { get; set; }
        public int isbn_force10 { get; set; }
        public int isbn_addhyphen { get; set; }
        public int isbn_removehyphen { get; set; }
        public int isbn_wild { get; set; }

        public string queryTermEncoding { get; set; }
        public string defaultEncoding { get; set; }
        public string recordSyntaxAndEncodingBinding { get; set; } //先不加
        public int charNegoUtf8 { get; set; }
        public int charNego_recordsInSeletedCharsets { get; set; }

        // 分类号与主题词 放在一个字段 20180621
        public string[] subjects { get; set; }

        //converteacc  //0/1   dp2catalog界面上隐藏了该字段

        //==========
        //其它辅助字段：创建用户，创建时间，状态，审核人，审核时间
        //==========
        public string creatorPhone { get; set; } //创建者手机号
        public string creatorIP { get; set; } //前期无帐户时，存IP地址
        public string createTime { get; set; }
        public int state { get; set; }//状态，0 未审核，1审核通过，2审核不通过
        public string verifier { get; set; } //审核人帐号
        public string lastModifyTime { get; set; } //最后修改时间
        public string remark { get; set; } //备注
}

关于API安全与性能

数字平台谢涛-20180608留言

站点数据库在设计 API 的时候，要注意考虑安全防范。比如一个 API，同一个 IP 地址过来的请求，每一段时间以内的峰值数量不应该超过多少。超过了就限流。

检索的 API 也可以考虑限流。比如某段时间内不应该超过多少次。让服务器处在正常的状态，不会被搞得很繁忙。

另外，重复的 API 也可以考虑用 cache 机制，不用访问数据库就快速响应。

在不太增加开发成本的情况下，可以在页面上显示一下基本统计信息。比如今天被访问了多少次，新创建了多少条记录。一共有多少条记录，等等

关于站点数据库服务

谢老师20180607留言

我们这个站点数据库，可以理解为一种公众的 Service，包括一套 API 和一个长期稳定运行的服务器。这样第三方开发者直接用我们的 API 就可以了， 不用再去开发一套这样的功能，也不必维护这样一个站点。我们公司的产品也全部都用这个站点库。

类似的设施，以前还有拼音 Servcie，汉语著者号码表 Service 等等。

数字平台任延华(474381593) 17:01:39 明白，太好了，提供公共通用信息

数字平台谢涛(2820725526) 17:02:32 我们公司名字叫做“数字平台”。本身就是这个目标

以前的一些 API，采用了 WCF 方式开发，没有明确是 Restful 方式。这样虽然我们自己自得其乐，但对于第三方门槛有些高，很多开发人员搞不定这种接口开发，好端端的 Service 他们用不了。虽然其实 dp2library 也有 Restful 协议方式，但因为它是“其中之一”，不是唯一的，所以我们也不特别重视它，比如有时候忘了绑定这个协议啊什么的。我们忘了，内务又不敏感。所以长期以来就造成了一种不是太“好用”的局面。

后面我们可以用一个阶段做一些整理工作，一方面确保这些 API 都是用 Restful 开放了，另外也可以专门用 Web API 再专门包装一次，确保第三方能方便调用。这些工作很重要。

关于创建站点时使用手机验证码功能

数字平台任延华(474381593) 18:25:41 谢老师，创建站点功能目前的设计是：创建站点信息不需要登录，为了防止故意捣乱提交不合理信息，准备在新增站点信息时，需要输入手机号，然后获取短信验证码，输入验证码后再提交。

Z39.50 的下一代协议SRW 和 SRU

这里也顺便提一下，Z39.50 服务器本来可以提供一种 Explain 机制，前端可以主动请求 Explain，那么就可以得到诸如这个服务器含有什么数据库名，怎么访问，等等参数，比我们现在制定的站点参数还详细。但可惜实现了这个机制的 Z39.50 服务器不多。也就是说这是个可选的机制。所以没办法我们只好搞一个站点属性数据库了

SRW 和 SRU 是 Z39.50 的下一代协议。目前国际上已经有一些例子。它保留了 Explain 机制，很有意思，以后我们可以研究一下。dp3 争取要提供 SRW 和 SRU 协议。这两个协议有一点点差异，W 是指 WebService，即它可以提供 WSDL 文件，类似 dp2library 的 WCF 机制；U 是指直接用 Web API 的 URL 请求访问，非常简单廉价。

可以适当考虑一下，让目前这个站点数据库具有一定弹性，比如可以存储 SRU/SRW 站点信息。

站点管理最近做的一些功能。http://dp2003.com/webz 1）批量创建站点记录，清空数据库，这个功能主要用于检索和分页测试时需要大量数据。

2）实现了检索api，目前主要有这4个检索途径，目前采用的是实时从库里检索，再取出指定范围的记录，没有使用结果集，这种方式在某些情况下第一次检索与后面批取记录的结果会有差别。 3）目前的界面风格是一个站点显示为一块信息，感觉这样主界面上每个站点太占地方了，后面想改为一行，点开后再看详细信息，类似公众号书目查询的界面。 4）编辑时，一些高级选项，需要点下按钮再看到，避免一下子事项太多。显示界面还没来得及加高级选项的显示。 5) 关于字段类型修改，之前在mongodb中站点集合的id使用的objectid类型，后来检索时发现objectid必须要满足16进制格式，不满足会报 *** is not a valid 24 digit hex string，后来改为guid了。

6）另外站点信息可能还需要做一个分类这样的字段，例如中国的，外国的谢：分类和主题都要。建议做成一个字段，string [] 类型即可。罗列分类号和主题词 分类和主题做成一个字段？有点没明白，是把分类和主题词看作同一种信息吗？比如如果检索时，是一个检索途径。谢：对，分类和主题都是一个意思。可以把分类号和主题词罗列在一个字段内。没有必要弄两个字段 字段名叫做主题词，或者 tag ，或者 category(分类)都是可以的 人才能分类和主题放在一起的做法，是很实用的方法任：是人工分的类别吗？Z39.50站点信息好像没有分类号信息呀谢：这个问题留待以后解决。你现在开发时候不用考虑这么多后面我们找一些图书馆老师来定这个分类和主题的规矩。

Windows Form 程序里面如何实现选择 Z39.50 服务器的对话框？

设想可以用一个对话框内嵌 IE 浏览器控件，控件里面直接显示来自 dp2003.com/webz 的某个选择服务器节点的页面，当选择完成后，点对话框的 OK 按钮，对话框能得到所选的这个服务器节点的 XML 格式的配置数据。

对话框如何得到 IE 控件里面选定节点的数据，这是个技术难点。可以在 HTML 页面里面准备一个具有特定 id 的 hidden input 元素，对话框用操纵 HTML DOM 的方法去搜索和定位这个元素，从而获得数据。也就是说，页面在选择的时候，要负责把 XML 数据放到这个 input 元素里面。

这样，对话框开发起来相对简单，主要靠 dp2003.com/webz 的页面来实现选择节点功能。这是合理的，因为，如果站点管理模块发生变化，这些页面肯定是第一时间会修改升级匹配的，靠页面解决这个问题比对话框自己用 Web API 去获取要简单靠谱。(如果对话框要用 Web API 去实现这些功能，一共要实现检索、浏览、选择的功能，代码编写量还是不小的，而这些功能原本 webz 的页面就有)

这也是 hybird 混合模式的一种应用。很简单实用。后面考虑跨平台界面开发，应该会逐步更多地用到这种模式。

当然这种用法也不是排斥 Web API 的作用和意义。只是适用的场合不同。Web API 还是要有的。

DigitalPlatform / chord

Web 界面 Z39.50 编目前端的设想 #166

web marc 编辑器

站点数据库的一些细节

1) 记录要有站点名字段。这是一个中文的名称字段，会被用来检索，显示在界面上，非常重要。在记录保存的时候，要检查数据库中所有记录，确保这个名称不会重复。

3) 要有一个 URL 字段，指向提供 Z39.50 配置信息的页面。例如国会图书馆的 Z39.50 服务器配置参数页面。

4) 权限认证方式、用户名、密码这几个字段，在创建记录的 Web 界面填写的时候，应该还有一种办法指定这个信息是否保存在服务器上，让用户明确了解。如果用户不希望保存，可以有个 checkbox 或者按钮让这几个域发灰。

站点配置信息

关键属性

检索/获取

字符集

暂时不使用的字段

关于API安全与性能

关于站点数据库服务

关于创建站点时使用手机验证码功能

Z39.50 的下一代协议SRW 和 SRU

Windows Form 程序里面如何实现选择 Z39.50 服务器的对话框？

DigitalPlatform / chord

Web 界面 Z39.50 编目前端的设想 #166

web marc 编辑器

站点数据库的一些细节

1) 记录要有站点名字段。这是一个中文的名称字段，会被用来检索，显示在界面上，非常重要。在记录保存的时候，要检查数据库中所有记录，确保这个名称不会重复。

3) 要有一个 URL 字段，指向提供 Z39.50 配置信息的页面。例如国会图书馆的 Z39.50 服务器配置参数页面。

4) 权限认证方式、用户名、密码这几个字段，在创建记录的 Web 界面填写的时候，应该还有一种办法指定这个信息是否保存在服务器上，让用户明确了解。如果用户不希望保存，可以有个 checkbox 或者按钮让这几个域发灰。

站点配置信息

关键属性

检索/获取

字符集

暂时不使用的字段

关于API安全与性能

关于站点数据库服务

关于 创建站点时使用手机验证码功能

Z39.50 的下一代协议SRW 和 SRU

Windows Form 程序里面如何实现选择 Z39.50 服务器的对话框？

关于创建站点时使用手机验证码功能