Использовать эту функцию.
private String leftPadding(String word, int length, char ch) {
return (length > word.length()) ? leftPadding(ch + word, length, ch) : word;
}
как использовать?
leftPadding(month, 2, '0');
выход: 01 02 03 04 .. 11 12
Часть проблемы - то, что соответствующее RFC 2183 действительно не указывает, что сделать с типом расположения "встроенных" и имени файла.
кроме того, насколько я могу сказать, единственный UA, который на самом деле использует имя файла для type=inline, является Firefox (см. тестовый сценарий ).
Наконец, не очевидно, что сменный API на самом деле делает ту информацию доступной (возможно, someboy знакомый с API, может уточнить).
Однако я отправил указатель на этот вопрос человеку Adobe; возможно, правильные люди взглянут.
Связанный: посмотрите попытку разъяснить Довольное Расположение в HTTP в draft-reschke-rfc2183-in-http - это - ранняя происходящая работа, ценившая обратная связь.
Обновление: Я добавил тестовый сценарий , который, кажется, указывает, что плагин Acrobat Reader не использует заголовки ответа (в Firefox), хотя сменный API предоставляет доступ им.
У Вас могло всегда быть две ссылки. Тот, который открывает документ в браузере и другом для загрузки его (использование неправильного типа контента). Это - то, что делает Gmail.
Установите имя файла в ContentType также. Это должно решить проблему.
context.Response.ContentType = "application/pdf; name=" + fileName;
// the usual stuff
context.Response.AddHeader("content-disposition", "inline; filename=" + fileName);
после установки заголовка довольного расположения, также добавьте заголовок довольной длины, затем используйте binarywrite для потоковой передачи PDF.
context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.BinaryWrite(fileBytes);
Вместо вложения можно попробовать встроенный:
Response.AddHeader("content-disposition", "inline;filename=MyFile.pdf");
я использовал встроенный в предыдущем веб-приложении, которое генерировало вывод Crystal Reports в PDF и отправило это в браузере пользователю.
Я был перенаправлен здесь, потому что у меня есть та же проблема. Я также попробовал обходное решение Troy Howard, но это, кажется, не работает.
подход я сделал на этом, больше не должен использовать объект ответа записать файл на лету. Так как PDF является уже существующим на сервере, что я сделал должен был перенаправить мою страницу, указывающую на тот файл PDF. Работает отлично.
http://forums.asp.net/t/143631.aspx
я надеюсь, что мое неопределенное объяснение дало Вам общее представление.
Как Вы, я попробовал и попытался заставить это работать. Наконец я разочаровался в этой идее, и просто выбрал обходное решение.
я использую ASP.NET Платформа MVC, таким образом, я изменил свои маршруты для того контроллера/действия, чтобы удостовериться, что поданный файл PDF является последней частью части местоположения URI (перед строкой запроса), и передайте все остальное в строке запроса.
, Например:
Старый URI:
http://server/app/report/showpdf?param1=foo¶m2=bar&filename=myreport.pdf
Новый URI:
http://server/app/report/showpdf/myreport.pdf?param1=foo¶m2=bar
получающийся заголовок смотрит точно как то, что Вы описали (тип контента является приложением/PDF, расположение встроено, имя файла является бесполезно частью заголовка). Acrobat показывает его в окне браузера (никакие не сохраняют как диалоговое окно), и имя файла, которое автозаполняется, если пользователь нажимает кнопку Acrobat Save, имя файла отчета.
Несколько соображений:
Для имен файлов для взгляда достойными у них не должно быть завершенных символов (т.е., никакие пробелы, и т.д.)..., который немного ограничивает. Мои имена файлов автоматически генерируются в этом случае, и прежде чем имел пробелы в них, которые обнаруживались как '%20 в получающемся диалоговом имени файла сохранения. Я просто заменил пробелы подчеркиваниями, и это удалось.
Это не именами лучшее решение, но оно действительно работает. Это также означает, что необходимо иметь имя файла в наличии для создания его частью исходного URI, который мог бы смешать с рабочим процессом программы. Если это в настоящее время сгенерировано или получается от базы данных во время вызова серверной стороны, который генерирует PDF, Вы, возможно, должны были бы переместить код, который генерирует имя файла к JavaScript как часть представления формы или если это прибывает из базы данных, делают его, быстрый ajax звонит для получения имени файла при создании URL, который приводит к встроенному PDF.
при взятии имени файла от ввода данных пользователем на форме, тогда это должно быть проверено для не содержания оставленных символов, которые будут раздражать пользователей.
Hope, которая помогает.
Попробуйте это, если Ваш исполняемый файл является "get.cgi"
http://server,org/get.cgi/filename.pdf?file=filename.pdf
Да, это абсолютно безумно. Нет никакого файла под названием "filename.pdf" на сервере, существует каталог вообще под исполняемым файлом get.cgi.
Но это, кажется, работает. Сервер игнорирует filename.pdf, и читатель PDF игнорирует "get.cgi"
Dan
Я полагаю, что об этом уже упоминалось в том или ином виде, но я попытаюсь изложить это своими словами.
Вместо этого:
/bar/sessions/958d8a22-0/views/1493881172/export?format=application/pdf&no-attachment=true
Я использую это:
/bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf?GeneratePDF=1
Вместо того, чтобы «экспорт» обрабатывать запрос, когда он приходит, я ищу в URL-адресе GeneratePDF = 1. Если обнаружено, я запускаю любой код, который выполнялся в режиме «экспорт», вместо того, чтобы позволять моей системе пытаться искать и обслуживать PDF-файл в местоположении /bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf
. Если GeneratePDF не найден в URL-адресе, я просто передаю запрошенный файл. (обратите внимание, что я не могу просто перенаправить на запрошенный файл - иначе я бы зациклился)
Если вы используете asp.net, вы можете управлять именем файла pdf через имя файла страницы (url). Как писали другие пользователи, Acrobat ... когда он выбирает имя файла pdf при нажатии кнопки «сохранить»: он берет имя страницы, удаляет расширение и добавляет «.pdf». Итак, /foo/bar/GetMyPdf.aspx дает GetMyPdf.pdf.
Единственное решение, которое я нашел, - управлять "динамическими" именами страниц с помощью обработчика asp.net:
Mapping1: все страницы имеют общую систему счисления (MyDocument _):
<httpHandlers>
<add verb="*" path="MyDocument_*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>
Mapping2: полностью свободное имя файла (требуется папка в пути):
<add verb="*" path="/CustomName/*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>
Некоторые советы здесь ( pdf динамически создается с использованием iTextSharp):
http://fhtino.blogspot.com/2006/11/how-to-show-or-download-pdf-file-from.html
Я решил эту проблему (с помощью PHP) следующим образом:
Предположим, ваш URL-адрес SomeScript.php? Id = ID & data = DATA
и нужный файл для использования - TEST.pdf
.
Измените URL-адрес на SomeScript.php / id / ID / data / DATA / EXT / TEST.pdf
.
Важно, чтобы последний параметр - это имя файла, которое вы хотите использовать в Adobe («EXT» может означать что угодно). Убедитесь, что в приведенной выше строке нет специальных символов, BTW.
Теперь в верхней части SomeScript.php
добавьте:
$_REQUEST = MakeFriendlyURI( $_SERVER['PHP\_SELF'], $_SERVER['SCRIPT_FILENAME']);
Затем добавьте эту функцию в SomeScript.php
(или ваша библиотека функций):
function MakeFriendlyURI($URI, $ScriptName) {
/* Need to remove everything up to the script name */
$MyName = '/^.*'.preg_quote(basename($ScriptName)."/", '/').'/';
$Str = preg_replace($MyName,'',$URI);
$RequestArray = array();
/* Breaks down like this
0 1 2 3 4 5
PARAM1/VAL1/PARAM2/VAL2/PARAM3/VAL3
*/
$tmp = explode('/',$Str);
/* Ok so build an associative array with Key->value
This way it can be returned back to $_REQUEST or $_GET
*/
for ($i=0;$i < count($tmp); $i = $i+2){
$RequestArray[$tmp[$i]] = $tmp[$i+1];
}
return $RequestArray;
}//EO MakeFriendlyURI
Теперь $ _ REQUEST
(или $ _ GET
, если хотите) доступны как обычно $ _ REQUEST ['id']
, $ _ REQUEST ['data']
и т. Д.
] Для тех, кто все еще смотрит на это, я использовал решение, найденное [] здесь [], и оно отлично работало. Спасибо Фабрицио! [
]