http - online - "Nombre" web pdf para un mejor nombre de archivo de guardar por defecto en Acrobat?
descargar adobe reader para windows 10 (16)
Mi aplicación genera archivos PDF para el consumo del usuario. El encabezado http "Content-Disposition" se configura como se menciona here . Esto se establece en "inline; filename = foo.pdf", que debería ser suficiente para que Acrobat proporcione "foo.pdf" como nombre de archivo al guardar el pdf.
Sin embargo, al hacer clic en el botón "Guardar" en Acrobat incrustado en el navegador, el nombre predeterminado para guardar no es ese nombre de archivo, sino que la URL con barras cambia a guiones bajos. Enorme y feo. ¿Hay alguna forma de afectar este nombre de archivo predeterminado en Adobe?
Hay una cadena de consulta en las URL, y esto no es negociable. Esto puede ser significativo, pero agregar un "& foo = / title.pdf" al final de la URL no afecta el nombre de archivo predeterminado.
Actualización 2: He intentado ambos
content-disposition inline; filename=foo.pdf
Content-Type application/pdf; filename=foo.pdf
y
content-disposition inline; filename=foo.pdf
Content-Type application/pdf; name=foo.pdf
(como se verificó a través de Firebug) Lamentablemente, ninguno funcionó.
Una URL de muestra es
/bar/sessions/958d8a22-0/views/1493881172/export?format=application/pdf&no-attachment=true
que se traduce en un guardado Acrobat predeterminado como nombre de archivo de
http___localhost_bar_sessions_958d8a22-0_views_1493881172_export_format=application_pdf&no-attachment=true.pdf
Actualización 3: Julian Reschke aporta información y rigor real a este caso. Por favor, vote su respuesta. Esto parece estar roto en FF ( https://bugzilla.mozilla.org/show_bug.cgi?id=433613 ) e IE, pero funciona en Opera, Safari y Chrome. http://greenbytes.de/tech/tc2231/#inlwithasciifilenamepdf
Al igual que usted, intenté e intenté hacer que esto funcionara. Finalmente abandoné esta idea y simplemente opté por una solución alternativa.
Estoy usando ASP.NET MVC Framework, así que modifiqué mis rutas para ese controlador / acción para asegurarme de que el archivo PDF servido sea la última parte de la porción de ubicación del URI (antes de la cadena de consulta) y pase todo else en la cadena de consulta.
P.ej:
URI antiguo:
http://server/app/report/showpdf?param1=foo¶m2=bar&filename=myreport.pdf
Nuevo URI:
http://server/app/report/showpdf/myreport.pdf?param1=foo¶m2=bar
El encabezado resultante se ve exactamente como lo que ha descrito (el tipo de contenido es application / pdf, la disposición está en línea, el nombre de archivo es inútilmente parte del encabezado). Acrobat lo muestra en la ventana del navegador (no se guarda como diálogo) y el nombre de archivo que se completa automáticamente si un usuario hace clic en el botón Guardar de Acrobat es el nombre de archivo del informe.
Algunas consideraciones:
Para que los nombres de los archivos se vean decentes, no deberían tener ningún carácter escapado (es decir, sin espacios, etc.) ... lo cual es un poco limitante. Mis nombres de archivo se generan automáticamente en este caso, y antes tenían espacios en ellos, que aparecían como ''% 20 en el nombre del archivo de diálogo de guardar resultante. Acabo de reemplazar los espacios con guiones bajos, y funcionó.
Esto de ninguna manera es la mejor solución, pero funciona. También significa que debe tener el nombre de archivo disponible para que forme parte del URI original, lo que podría interferir con el flujo de trabajo de su programa. Si actualmente se está generando o recuperando de una base de datos durante la llamada del servidor que genera el PDF, es posible que deba mover el código que genera el nombre de archivo a javascript como parte de un envío de formulario o si proviene de una base de datos hacerlo un llamada rápida ajax para obtener el nombre de archivo al construir la URL que da como resultado el PDF en línea.
Si toma el nombre de archivo de una entrada de usuario en un formulario, entonces debe validarse para que no contenga caracteres escapados, lo que molestará a los usuarios.
Espero que ayude.
Créditos a .
Nginx
location /file.pdf
{
# more_set_headers "Content-Type: application/pdf; name=save_as_file.pdf";
add_header Content-Disposition "inline; filename=save_as_file.pdf";
alias /var/www/file.pdf;
}
Comprobar con
curl -I https://example.com/file.pdf
Firefox 62.0b5 (64 bits): OK.
Chrome 67.0.3396.99 (64 bits): OK.
IE 11: Sin comentarios.
Creo que esto ya se ha mencionado en uno u otro sabor, pero intentaré expresarlo con mis propias palabras.
En vez de esto:
/bar/sessions/958d8a22-0/views/1493881172/export?format=application/pdf&no-attachment=true
Yo uso esto:
/bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf?GeneratePDF=1
En lugar de tener que "exportar" procesar la solicitud, cuando aparece una solicitud, busco en la URL de GeneratePDF = 1. Si se encuentra, ejecuto el código que se estaba ejecutando en "exportar" en lugar de permitir que mi sistema intente buscar y /bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf
un PDF en la ubicación /bar/sessions/958d8a22-0/views/1493881172/NameThatIWantPDFToBe.pdf
. Si GeneratePDF no se encuentra en la URL, simplemente transmito el archivo solicitado. (Tenga en cuenta que no puedo simplemente redireccionar al archivo solicitado, sino terminaría en un ciclo infinito)
Diálogo de descarga de archivos (PDF) con opción de guardar y abrir
Puntos para recordar:
- Return Stream con el tamaño correcto de la matriz del servicio
- Lea el byte de la secuencia con la longitud correcta de bytes en función de la longitud de la secuencia.
- establecer el tipo de contenido correcto
Aquí está el código para leer la secuencia y abrir el diálogo de descarga de archivo para el archivo PDF
private void DownloadSharePointDocument()
{
Uri uriAddress = new Uri("http://hyddlf5187:900/SharePointDownloadService/FulfillmentDownload.svc/GetDocumentByID/1/drmfree/");
HttpWebRequest req = WebRequest.Create(uriAddress) as HttpWebRequest;
// Get response
using (HttpWebResponse httpWebResponse = req.GetResponse() as HttpWebResponse)
{
Stream stream = httpWebResponse.GetResponseStream();
int byteCount = Convert.ToInt32(httpWebResponse.ContentLength);
byte[] Buffer1 = new byte[byteCount];
using (BinaryReader reader = new BinaryReader(stream))
{
Buffer1 = reader.ReadBytes(byteCount);
}
Response.Clear();
Response.ClearHeaders();
// set the content type to PDF
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Disposition", "attachment;filename=Filename.pdf");
Response.Buffer = true;
Response.BinaryWrite(Buffer1);
Response.Flush();
// Response.End();
}
}
El mod_rewrite
de Apache puede resolver esto.
Tengo un servicio web con un punto final en /foo/getDoc.service
. Por supuesto, Acrobat guardará los archivos como getDoc.pdf
. Agregué las siguientes líneas en apache.conf
:
LoadModule RewriteModule modules/mod_rewrite.so
RewriteEngine on
RewriteRule ^/foo/getDoc/(.*)$ /foo/getDoc.service [P,NE]
Ahora cuando solicito /foo/getDoc/filename.pdf?bar&qux
, se reescribe internamente en /foo/getDoc.service?bar&qux
, por lo que estoy llegando al punto final correcto del servicio web, pero Acrobat cree que guardará mi archivo como filename.pdf
.
En ASP.NET 2.0, cambie la URL de
http://www. server.com/DocServe.aspx?DocId=XXXXXXX
a
http://www. server.com/DocServe.aspx/MySaveAsFileName?DocId=XXXXXXX
Esto funciona para Acrobat 8 y el nombre de archivo SaveAs predeterminado ahora es MySaveAsFileName.pdf
.
Sin embargo, debe restringir los caracteres permitidos en MySaveAsFileName
(sin puntos, etc.).
En lugar de adjunto, puedes probar en línea:
Response.AddHeader("content-disposition", "inline;filename=MyFile.pdf");
Utilicé en línea en una aplicación web anterior que generó la salida de Crystal Reports en PDF y la envié en el navegador al usuario.
Establezca el nombre del archivo en ContentType también. Esto deberia resolver el problema.
context.Response.ContentType = "application/pdf; name=" + fileName;
// the usual stuff
context.Response.AddHeader("content-disposition", "inline; filename=" + fileName);
Después de configurar el encabezado content-disposition, también agregue el encabezado content-length, luego use binarywrite para transmitir el PDF.
context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.BinaryWrite(fileBytes);
Fui redirigido aquí porque tengo el mismo problema. También probé la solución provisional de Troy Howard, pero parece que no funciona.
El enfoque que hice en este caso es NO usar más el objeto de respuesta para escribir el archivo sobre la marcha. Como el PDF ya existe en el servidor, lo que hice fue redireccionar mi página apuntando a ese archivo PDF. Funciona genial.
http://forums.asp.net/t/143631.aspx
Espero que mi vaga explicación te haya dado una idea.
Intenta esto, si tu ejecutable es "get.cgi"
http://server,org/get.cgi/filename.pdf?file=filename.pdf
Sí, es completamente loco. No hay un archivo llamado "nombredearchivo.pdf" en el servidor, hay un directorio bajo el ejecutable get.cgi.
Pero parece funcionar. El servidor ignora el nombre de archivo.pdf y el lector de PDF ignora el "get.cgi"
Dan
Intente ubicar el nombre del archivo al final de la URL, antes que cualquier otro parámetro. Esto funcionó para mí. http://www.setasign.de/support/tips-and-tricks/filename-in-browser-plugin/
La forma en que resolví esto (con PHP) es la siguiente:
Supongamos que su URL es SomeScript.php?id=ID&data=DATA
y que el archivo que desea usar es TEST.pdf
.
Cambie la URL a SomeScript.php/id/ID/data/DATA/EXT/TEST.pdf
.
Es importante que el último parámetro sea el nombre de archivo que desea que use Adobe (el ''EXT'' puede ser sobre cualquier cosa). Asegúrese de que no haya caracteres especiales en la cadena anterior, por cierto.
Ahora, en la parte superior de SomeScript.php
, agregue:
$_REQUEST = MakeFriendlyURI( $_SERVER[''PHP/_SELF''], $_SERVER[''SCRIPT_FILENAME'']);
A continuación, agregue esta función a SomeScript.php
(o su biblioteca de funciones):
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
Ahora se $_REQUEST
(o $_GET
si lo prefiere) como normalmente $_REQUEST[''id'']
, $_REQUEST[''data'']
, etc.
Y Adobe usará su nombre de archivo deseado como la información predeterminada para guardar o como correo electrónico cuando lo envíe en línea.
Para cualquiera que todavía esté mirando esto, utilicé la solución que se encuentra here y funcionó maravillosamente. Gracias Fabrizio!
Parte del problema es que el RFC 2183 relevante en realidad no indica qué hacer con un tipo de disposición de "en línea" y un nombre de archivo.
Además, hasta donde puedo decir, el único UA que realmente usa el nombre de archivo para type = inline es Firefox (ver caso de prueba ).
Finalmente, no es obvio que la API de complemento realmente hace que la información esté disponible (tal vez alguien familiarizado con la API pueda explicarlo).
Dicho esto, he enviado un puntero a esta pregunta a una persona de Adobe; tal vez las personas correctas echarán un vistazo.
Relacionado: vea el intento de aclarar Contenido-Disposición en HTTP en draft-reschke-rfc2183-in-http : este es el trabajo inicial en progreso, los comentarios son apreciados.
Actualización: He agregado un http://greenbytes.de/tech/tc2231/#inlwithasciifilenamepdf , que parece indicar que el complemento de Acrobat Reader no usa los encabezados de respuesta (en Firefox), aunque la API de complemento les proporciona acceso.
Si usa asp.net, puede controlar el nombre del archivo pdf a través del nombre del archivo de la página (url). Como escribieron otros usuarios, Acrobat está un poco s ... cuando elige el nombre del archivo pdf cuando presiona el botón "guardar": toma el nombre de la página, elimina la extensión y agrega ".pdf". Entonces /foo/bar/GetMyPdf.aspx da GetMyPdf.pdf.
La única solución que encontré es administrar nombres de página "dinámicos" a través de un manejador asp.net:
- crear una clase que implemente IHttpHandler
- asignar un controlador en web.config limitado a la clase
Mapping1: todas las páginas tienen una raíz común (MyDocument_):
<httpHandlers>
<add verb="*" path="MyDocument_*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>
Mapping2: nombre de archivo completamente libre (necesita una carpeta en la ruta):
<add verb="*" path="/CustomName/*.ashx" type="ITextMiscWeb.MyDocumentHandler"/>
Algunos consejos aquí (el pdf se crea dinámicamente usando iTextSharp):
http://fhtino.blogspot.com/2006/11/how-to-show-or-download-pdf-file-from.html
Siempre puedes tener dos enlaces. Uno que abre el documento dentro del navegador y otro para descargarlo (usando un tipo de contenido incorrecto). Esto es lo que hace Gmail.