+
+ if ($ok) {
+ foreach my $opt (qw(search present delSet resourceReport
+ triggerResourceCtrl resourceCtrl
+ accessCtrl scan sort extendedServices
+ level_1Segmentation level_2Segmentation
+ concurrentOperations namedResultSets
+ encapsulation resultCount negotiationModel
+ duplicationDetection queryType104
+ pQESCorrection stringSchema)) {
+ #print STDERR "\$conn->option('init_opt_$opt') = '", $conn->option("init_opt_$opt"), "'\n";
+ $conn->record()->store_result('init_opt', option => $opt)
+ if $conn->option("init_opt_$opt");
+ }
+
+ foreach my $opt (qw(serverImplementationId
+ serverImplementationName
+ serverImplementationVersion)) {
+ # There doesn't seem to be a reliable way to tell what
+ # character set the server uses for these. At least one
+ # server (z3950.bcl.jcyl.es:210/AbsysCCFL) returns an ISO
+ # 8859-1 string containing an o-acute, which breaks the
+ # XML parser if we just insert it naively. It seems
+ # reasonable, though, to guess that the great majority of
+ # servers will use ASCII, Latin-1 or Unicode. The first
+ # of these is a subset of the second, so that brings it to
+ # down to two. The strategy is simply this: assume it's
+ # ASCII-Latin-1, and try to convert to UTF-8. If that
+ # conversion works, fine; if not, assume it's because the
+ # string was already UTF-8, so use it as is.
+ my $val = $conn->option($opt);
+ Text::Iconv->raise_error(1);
+ my $maybe;
+ eval {
+ $maybe = $conv->convert($val);
+ }; if (!$@ && $maybe ne $val) {
+ $conn->log("irspy", "converted '$val' from Latin-1 to UTF-8");
+ $val = $maybe;
+ }
+ $conn->record()->store_result($opt, value => $val);
+ }
+ }
+
+
+ return $ok ? ZOOM::IRSpy::Status::TEST_GOOD :
+ ZOOM::IRSpy::Status::TEST_BAD;