Немного не понял фразу:

Цитата:

Esil
у меня только на просмотр,скачивание я убрал

Опера "по дефолту" не открывает файлы (имеется ввыду внешними програмами ассоциированными с разрешением файлов) указаные в 951.

Проблема как я полнял в том, что во время формирования ссылки на скачивание скрипт выдает на совсем коректную ссылку. IE "проглатывает" ошибку, а Опера - нет.

Провел эксперимент.
Файл указанный в 951 поле называеться 102.doc (ссылка на пример на пост выше).
Опера предлагает скачать файл 102.exe. Если просле загрузки его снова переименовать в док, то он нормально откроется вордом.

Вопрос, почему опера меняет расширение?
Я понимаю что вопросы не к ИРБИСу а Опере, но все же может в формируемой ссылке нарушены стандарты?

Ребята попробуйте открыть у себя.

P.S. Если в ссылке вида /cgi-bin/irbis64r_opak72/cgiirbis_64.exe?C21COM=2&I21DBN=NMC&P21DBN=NMC&Z21ID=&Image_file_name=%5CFullText%5C102.doc&IMAGE_FILE_DOWNLOAD=1

убрать выделенный фрагмент, то опера открывает файл корректно, правда теперь меняет имя файла, но открывается именно загружаемый файл



Редактировано 2 раз. Последний раз 21.11.2009 22:18 пользователем Konstantinus.

Опера не корректно открывает файлы и не корректно распознает его тип, поскольку при передаче файла не установлены все необходимые заголовки HTTP-запроса.
Вот так выглядит процедура на PHP, которая выдает файл клиенту.

	function get_file($filename){
		if (file_exists($filename))
		{
			$name = basename($filename);
			header("Pragma: private",true);
			header("Content-type:application/octet-stream",true);
			header("Content-Disposition: attachment; filename=$name",true);
			header("Content-Description: Response to catalog archive request",true);
			print file_get_contents($filename);
		}
		else
		{
			header("HTTP/1.1 404 Not Found",true,404);
		}
	}

Я не претендую на последнюю инстанцию, но для моих задач этого достаточно. Возможно нужно еще что-то передать (типа размера и расширения файла), не помню уже. Думаю, что проблема именно в этом.



Редактировано 1 раз. Последний раз 21.11.2009 23:29 пользователем Панев Максим.

Тогда разработчиков надо попросить включить это исправление в очередной патч.

я имел ввиду что я убрал IMAGE_FILE_DOWNLOAD=1,мне сказали чтобы док-и выставленные в инэт должны быть только на просмотр,а до этого предлагалось открыть или сохранить.
Теперь на счет Дежеву почему он у меня не открывается,скриншот есть

Вопрос об открытии файла или выводе диалога сохранения браузер решает исходя из содержания HTTP заголовка Content-type. И только IE обращает внимание на содержание и расширение файла.

HTTP заголовок формируется в последних версиях(9.1, 8.1) WEB ИРБИС исходя из расширения файла. Если расширение файла не учтено в WEB ИРБИС, будет выводиться заголовок, провоцирующий открытие файла в браузере. В новой версии не учтён конкретно формат DJVU, но я подготовлю соответствующее обновление.

Esil написал(а):
-------------------------------------------------------
> я имел ввиду что я убрал IMAGE_FILE_DOWNLOAD=1,мне
> сказали чтобы док-и выставленные в инэт должны
> быть только на просмотр,а до этого предлагалось
> открыть или сохранить.

А что написано сейчас, что такой док есть, но посмотреть его нельзя? (:P)

Нет,почему,все открывается,только вот когда документ WORDвский в Опере просит вот так:скрин
а в эхплорере ничего ни просит автоматом открывает.Скажи а Djvu файлы у тебя открывается?



Редактировано 3 раз. Последний раз 25.11.2009 06:52 пользователем Esil.

Повторю:

Если в ссылке убрать &IMAGE_FILE_DOWNLOAD=1, то опера открывает файл корректно, правда теперь меняет имя файла, но открывается именно загружаемый файл.

А хочется что и файл не переименовывался, и расширение не пропадало. Проблема сугубо в Веб-Ирбисе. Здесь предлагалось решение, поэтому прошу разработчиков учесть это в следующем наборе исправлений.

>Опера открывает файл корректно, правда теперь меняет имя файла

В следующем обновлении эта проблема будет устранена.

> Нет,почему,все открывается,только вот когда документ WORDвский в Опере
> просит а в эхплорере ничего ни просит автоматом открывает.

Acrobat, Word, Dejavu интегрируются в IE и Firefox. В этом случае все документы независимо от HTTP заголовков, о которых я писал выше, открываются в браузере. От WEB ИРБИС при этом ничего не зависит.



Редактировано 1 раз. Последний раз 26.11.2009 13:13 пользователем Кирилл Соколинский (СЗТУ).

Добрый день!

Помогите, пожааааааааалуйста, новичку разобраться !

У нас версия 2009.1. Ссылка на файл хранится в поле 951^i в следующем формате "text/.../.../*.pdf". При этом ссылки работают и файлы открываются. НО папка text находится в htdocs на диске С:, на котором неумолимо исчезает место (файлы то прибывают).

Вопрос: Возможно ли настроить работу сервера так, что бы он открывал файлы с полными текстами, которые находятся вне папки htdocs?

Я так понимаю у вас стоит XAMPP
я у себя такого рода папку разместил даже на другом разделе, указав в файле httpd-vhosts.conf таку строку:

Alias /library d:/document
<Directory d:/document>

при описании соотв. виртуального хоста

и в дальнейшем при необходимости обращения к папке d:/document в html указываю в пути папку library.
Но это у меня касается именно сайта.

Может это Вам поможет в решении указанной проблемы

sch-nina написал(а):
-------------------------------------------------------
> Вопрос: Возможно ли настроить работу сервера так,
> что бы он открывал файлы с полными текстами,
> которые находятся вне папки htdocs?

Вариант решения, описанный ssa_admin, является оптимальным. Но существует и внутреннее решение для WEB ИРБИС.

При указании пути в подполе ^A Вы можете указывать прямые пути файлов на дисках. При этом обязательна защита от несанкционированного доступа. Она подробно описана в инструкции.



Редактировано 1 раз. Последний раз 19.11.2010 14:04 пользователем Кирилл Соколинский (СЗТУ).

Здравствуйте, помогите разобраться, пожалуйста!

Суть: есть заполненное 951 поле (Фото Link2). И эта самая ссылка работает из АРМ Каталогизатор (выделена красным на фото Link2).

Вопрос: как сделать, чтобы ссылка на документ отображалась в Web-ирбис?

В данный момент, прописав ссылку на файл вижу в веб-ирбисе картинку Link1. Версия WEB-ирбис 01 (видимо, самая последняя). На версии 9.1 ссылка отображалась без проблем. Где ошибка?

Спасибо!



Редактировано 1 раз. Последний раз 05.05.2011 11:39 пользователем StDemian.

Прошу поделиться опытом, бывают ли проблемы если пути к полным текстам содержат русские/украинские символы?

Продолжаю ветку.
Имеем несколько полнотекстовых БД. В БД с ссылкой на конечный файл все работает.
А в полнотекстовой БД с использованием фреймовой структуры (ссылка на index.html) есть ошибка. Результат работы ссылки во вложении.
Подскажите, что нужно учесть для ликвидации ошибки?
Спасибо.

Юлия Главчева написал(а):
-------------------------------------------------------
> Продолжаю ветку.
> Имеем несколько полнотекстовых БД. В БД с ссылкой
> на конечный файл все работает.
> А в полнотекстовой БД с использованием фреймовой
> структуры (ссылка на index.html) есть ошибка.

Судя по ссылке на скриншоте, файл имеет собственный URL, т.е. не пропускается через шлюз. В таком случае проблемы могут быть только в неверной(абсолютной, вероятно) адресации фреймов. Её нужно заменить на относительную. С WEB ИРБИС эта задача никак не связана.

Konstantinus написал(а):
-------------------------------------------------------
> Прошу поделиться опытом, бывают ли проблемы если
> пути к полным текстам содержат русские/украинские
> символы?

Рекомендую использовать в адресах исключительно латинские символы.

StDemian написал(а):
-------------------------------------------------------
> Вопрос: как сделать, чтобы ссылка на документ
> отображалась в Web-ирбис?

1. Убедитесь, что у Вас установлено последнее обновление (http://irbis.gpntb.ru/read.php?21,44277);

2. Убедитесь, что в INI файле WEB ИРБИС параметр show_ed имеет нужное значение (0 -- показывать ссылки всем пользователям, 1 --только авторизованным, 2 -- не показывать вообще)



Редактировано 1 раз. Последний раз 05.05.2011 13:07 пользователем Кирилл Соколинский (СЗТУ).

Кирилл, спасибо, после обновления все заработало адекватно!

Подскажите, пожалуйста, как глобально откорректировать поле 851_I. Не очень хорошо ориентируюсь в языке форматирования, переставили программу на новый сервер, нужно полностью поменять ссылки на полнотекстовые ресурсы (851_І). Может вопрос для "чайников", но мы такие пока и есть жду подсказок.

Возвращаясь к полю 951...
Наши внешние объекты находятся на том компьютере, где стоит сервер IRBIS64. На диске D в папке FullText. Т. е. полный путь будет D:\FullText
В этом случае нобходимо все-таки заполнять подполе a или i? Ведь это же относительный путь, но файл размещается на "сервере".
Запутался напрочь. Ранее в версии irbis32 2005.1, ссылка на внешний объект (объекты размещались в папке FullText директории БД) прописывалась почти всегда через поле 951^a (кроме URL) посредством FullText\NameOfFile.ext. Все прекрасно работало. Теперь согласно рекомендациям нужно прописывать как /FullText/NameOfFile.ext?
Также не очень ясно прописывать пути в файле irbis_server.ini для защиты.
Конструкция типа C:\IRBIS64\Datai\DataBase\FullText не работает. Слеши менял, добавлял слеш в конец - без результатно. Какой все-таки формат представления каталога? Если нужно дописать несколько путей к каталогу, какой символ используется для разделения?

woodyfon написал(а):
-------------------------------------------------------
> Возвращаясь к полю 951...
> Наши внешние объекты находятся на том компьютере,
> где стоит сервер IRBIS64. На диске D в папке
> FullText. Т. е. полный путь будет D:\FullText
> В этом случае нобходимо все-таки заполнять подполе
> a или i? Ведь это же относительный путь, но файл
> размещается на "сервере".
> Запутался напрочь. Ранее в версии irbis32 2005.1,
> ссылка на внешний объект (объекты размещались в
> папке FullText директории БД) прописывалась почти
> всегда через поле 951^a (кроме URL) посредством
> FullText\NameOfFile.ext. Все прекрасно работало.
> Теперь согласно рекомендациям нужно прописывать
> как /FullText/NameOfFile.ext?
> Также не очень ясно прописывать пути в файле
> irbis_server.ini для защиты.
> Конструкция типа
> C:\IRBIS64\Datai\DataBase\FullText не работает.
> Слеши менял, добавлял слеш в конец - без
> результатно. Какой все-таки формат представления
> каталога? Если нужно дописать несколько путей к
> каталогу, какой символ используется для
> разделения?

Ознакомьтесь с материалом: [irbis.gpntb.ru]

Самый простой и эффективный способ:

1. В INI файле:
Safe_File_Paths=C:\IRBIS64\Datai\DataBase\FullText\;
Safe_File_Download=1

2. В подполе ^A
NameOfFile.ext

Ну я не знаю, какой-то не фарт: перестало показывать размер файла. Какой файлик pft отвечает за показ размер файла?

woodyfon написал(а):
-------------------------------------------------------
> Ну я не знаю, какой-то не фарт:
> перестало показывать размер файла. Какой файлик
> pft отвечает за показ размер файла?

Чтобы обеспечить вывод размера файла нужно давать полные ссылки C:\IRBIS64\Datai\DataBase\FullText\NameOfFile.ext

Эту задачу выполняет UNIFOR в формате ed_reference.pft, которому ничего не известно о параметре Safe_File_Paths в INI файле WEB ИРБИС.

Похоже, за вывод размера файла отвечает строка:
&uf('+9E',&uf('+9A',if v951^a <> '' then v951^a fi))
Где можно почитать подробно про uf('+9...')? В документации к ИРБИС такие значения функции не документированы.
+
В файле ed_reference.pft ошибка. Функция &uf('+9a',внешний объект) возвращает число размера в байтах. При округление до кб, мб. Кило равно не 1024, а 1000. Хотя технически это верно, но пользователи привыкли килобайт считать 1024 байт. Читают именно килобайт, а не кибибайт.
+
Переписал файлик ed_reference.pft, чтобы размер показывал в реальных цифрах. Конечно, код не оптимизирован, но работает.
+
Заработала ссылка в поле 951^a. когда прописал следующее в ini-файле
Safe_File_Paths=C:\IRBIS64\Datai\DataBase\FullText\..;
Safe_File_Download=1
В поле 951^a путь указал как /FullText/FileName.ext. Т. е. в отличии от старых вирсий в новых версиях ирбиса слеш обратный, хотя в АРМ-Каталогизатор работает вне зависимости какой слеш, но чтобы работало в WI нужен именно такой (походу связано с форматами).
+
На тестовой версии (Windows 7 + Apache 2.2) все работает. Но на рабочей (Windows Server 2008 SP2 + Apache 2.2) не хочет? хотя сделал все в точности. Показывает все время ошибку FILE NOT EXISTS. Смоделировать то, что произошло на рабочей, на тестовой просто не могу. Какой порт используется при передаче внешнего файла?
P.S. Почему так детально все описываю, чтобы не забыть.



Редактировано 4 раз. Последний раз 25.07.2011 16:10 пользователем woodyfon.

woodyfon написал(а):
-------------------------------------------------------
> Где можно почитать подробно про uf('+9...')? В
> документации к ИРБИС такие значения функции не
> документированы.

Действительно, на +9A описания не было. Другие функции были описаны в релизах. Самый полный(хотя что-то упущено, конечно) на сегодняшний день перечень UNIFOR здесь: [wiki.elnit.org]


> /FullText/FileName.ext. Т. е. в отличии от старых
> вирсий в новых версиях ирбиса слеш обратный, хотя
> в АРМ-Каталогизатор работает вне зависимости какой
> слеш, но чтобы работало в WI нужен именно такой
> (походу связано с форматами).

В интернет-адресах обратный слэш -- это норма.


> +
> На тестовой версии (Windows 7 + Apache 2.2) все
> работает. Но на рабочей (Windows Server 2008 SP2 +
> Apache 2.2) не хочет? хотя сделал все в точности.
> Показывает все время ошибку FILE NOT EXISTS.

Такое возможно, если файл располагается на сетевых дисках.

> Какой порт используется
> при передаче внешнего файла?

Тот же, что и при передаче страниц -- 80.

> В файле ed_reference.pft ошибка.

Это не ошибка, а грубое округление. Следует учитывать, что увеличение объёма формата сильно замедляет время расформатирования записей.

Поскольку размер выгружаемого файла нужен пользователю лишь для определения целесообразности выгрузки, точность цифры не имеет существенного значения.



Редактировано 1 раз. Последний раз 25.07.2011 23:14 пользователем Кирилл Соколинский (СЗТУ).

Цитата:

В интернет-адресах обратный слэш -- это норма.

Теперь понятно почему в WI не работает путь с обратными слешами. В ссылке на файл берется из поля 951^a.

Цитата:

Такое возможно, если файл располагается на сетевых дисках.

В том и дело, что файлы размещаются в папке FullText в директории БД.

Цитата:

Тот же, что и при передаче страниц -- 80.

Значит неправильную настройку системы и Apache можно исключить.

Цитата:

Это не ошибка, а грубое округление. Следует учитывать, что увеличение размеров формата сильно замедляет время расформатирования записей.
Поскольку размер нужен пользователю лишь для определения целесообразности выгрузки, точность цифры не имеет существенного значения.

Все-таки если показывать пользователям размер файла, он должен быть соответствующим. Тогда у пользователей не будут вопросов. Не заметил существенного увеличения времени расформатирования записей. Быть может, все зависит от производителности сервера.
+
Заметил странную вещь:
Ссылка на внешний файл имеет вид

[localhost]

Соответственно ошибка FILE NOT EXISTS
Если ссылку вручную подправить

[localhost]

ТО шлюз разрешает его скачать.
Как убрать из имени файла в URL слова "color" или "font" не знаю.
+
Если в ссылке есть термин из запроса, то термин обрамляется в тэги раскраски из значений. Я бы уже не стал эту ситуацию называть ошибкой, скорее не учтена.

EXTPREF=<b><font color=red>
EXTPOST=</font></b>

Из инструкции Директивы отмены раскраски найденных терминов необходимо применять директиву <!>. Как правильно обрамить в тег <!> ссылку (файл ed_reference.pft), которая формирует путь скачки внешнего объекта.
+
Решено.
Код из файла ed_reference.pft, который относится к формированию ссылки заключил с двух сторон тегом '<!>' без запятых спереди и сзади.
Целесообразно в последующих версиях подправить файл pft, чтобы в дальнейшем не возникало недоразумений.



Редактировано 7 раз. Последний раз 26.07.2011 17:14 пользователем woodyfon.

woodyfon написал(а):
-------------------------------------------------------

> Код из файла ed_reference.pft, который относится к
> формированию ссылки заключил с двух сторон тегом
> '<!>' без запятых спереди и сзади.
> Целесообразно в последующих версиях подправить
> файл pft, чтобы в дальнейшем не возникало
> недоразумений.

Да, действительно, описанная Вами ситуация вероятна при поиске по имени файла. Поэтму я добавлю теги запрета раскраски. Но возможно ли в стандартной поставке WEB ИРБИС осуществить такой поиск?

Цитата:

Но возможно ли в стандартной поставке WEB ИРБИС осуществить такой поиск?

Поиск по имени файла в стандартной поставке WI невозможен. Но данная ситуация у нас сложилась не при поиске имени файла - новую область я не делал. Ситуация возникла при просмотре новых поступлений за определенный период, поскольку у нас способ наименования внешних объектов такой: ДатаПоступления_Автор(Составитель)_Характер документа.pdf. У других же пользователей ситуация может возникнуть если файл называют кириллицей, в наименовании которого имеются термины из заглавия или(и) фамилий авторов, а поиск происходит при по автору/заглавию. Конечно. лучше в именах файлов не использовать кириллицу, но не все об этом знают.



Редактировано 1 раз. Последний раз 27.07.2011 12:47 пользователем woodyfon.

Кирилл Соколинский (СЗТУ) написал(а):

Re: ССЫЛКА-ВНЕШНИЙ ОБЪЕКТ (поле 951)
Пользователь: Кирилл Соколинский (СЗТУ) (IP-адрес скрыт)
Дата: 23, October, 2009 01:10
-------------------------------------------------------
> Предполагается, что в подполе ^I должен находиться
> URL документа. Т.е. его адрес в Интернете, а не на
> Вашем диске.
>
> Если Вы хотите изменить это правило, требуется
> редактировать файл datai\deposit_XX\ofinal_W.pft
> Замените там все метки 951^A на 951^I и наоборот.

Здраствуйте! После переустановки пропали мои настройки, хочу заново настроить чтобы ссылки на файлы открывались, С тех пор изменении не было никаких? В папке C:\IRBIS64\Datai\Deposit\ никак не найду ofinal_W.pft. И будет ли показывать размер файлов по умолчанию или же его тоже надо настраивать?
В БД пути указаны в 951^I.
WI 2010.1



Редактировано 1 раз. Последний раз 19.04.2012 16:21 пользователем Esil.