"nom" web pdf pour une meilleure sauvegarde par défaut du nom de fichier dans Acrobat?

Question

Mon application génère des fichiers Pdf pour l'utilisateur de la consommation. Le "Content-Disposition" en-tête http est défini comme mentionné ici. Il est réglé à "inline; filename=foo.pdf, ce qui devrait être suffisant pour Acrobat pour donner "foo.pdf" que le nom de fichier lors de l'enregistrement du pdf.

Mais, en cliquant sur le bouton "Enregistrer" dans le navigateur intégré Acrobat, le nom par défaut pour enregistrer n'est pas que le nom de fichier, mais au lieu de l'URL avec des barres obliques changé par des traits de soulignement. Énorme et laid. Est-il possible d'affecter cette valeur par défaut nom de fichier dans Adobe?

Il y a une chaîne de requête dans l'Url, et c'est non négociable. Cela peut être important, mais l'ajout d'un "&foo=/titre.pdf" à la fin de l'URL de ne pas modifier le nom de fichier par défaut.

Mise à jour 2: j'ai essayé les deux

content-disposition  inline; filename=foo.pdf
Content-Type         application/pdf; filename=foo.pdf

et

content-disposition  inline; filename=foo.pdf
Content-Type         application/pdf; name=foo.pdf

(vérifiée par le biais de Firebug) Malheureusement, ni travaillé.

Un exemple d'url est

/bar/sessions/958d8a22-0/vues/1493881172/export?format=application/pdf&non-attachement=true

ce qui se traduit par un défaut d'Acrobat enregistrer sous le nom de

http___localhost_bar_sessions_958d8a22-0_views_1493881172_export_format=application_pdf&no-attachment=true.pdf

Mise à jour 3: Julian Reschke apporte une réelle perspicacité et la rigueur de cette affaire. Veuillez upvote sa réponse. Cela semble être cassé en FF (https://bugzilla.mozilla.org/show_bug.cgi?id=433613) et IE mais le travail dans Opera, Safari et Chrome. http://greenbytes.de/tech/tc2231/#inlwithasciifilenamepdf

Answer 1

Une partie du problème est que la RFC 2183 n'a pas vraiment d'état quoi faire avec une disposition de type "inline" et un nom de fichier.

Aussi, autant que je puisse en dire, la seule UA qui utilise le nom de fichier du type=inline est Firefox (voir les cas de test).

Enfin, il n'est pas évident que l'API de plugin fait en fait que de l'information disponible (peut-être someboy familiariser avec l'API peut élaborée).

Cela étant dit, j'ai envoyé un pointeur sur cette question à un Adobe personne; peut-être le bon peuple aura un coup d'oeil.

Liés: voir la tentative de clarifier le Contenu-Disposition en HTTP dans le projet d'-reschke-rfc2183-en-http -- c'est au début des travaux en cours, des commentaires appréciés.

Mise à jour: j'ai ajouté un cas de test, ce qui semble indiquer que le plugin Acrobat reader n'est pas utiliser les en-têtes de réponse (dans Firefox), bien que l'API de plugin fournit un accès à eux.

Answer 2

Définissez également le nom du fichier dans ContentType . Cela devrait résoudre le problème.

 context.Response.ContentType = "application/pdf; name=" + fileName;
// the usual stuff
context.Response.AddHeader("content-disposition", "inline; filename=" + fileName);
 

Une fois que vous avez défini l'en-tête de disposition du contenu, ajoutez-en aussi un en-tête, puis utilisez binarywrite pour diffuser le fichier PDF.

 context.Response.AddHeader("Content-Length", fileBytes.Length.ToString());
context.Response.BinaryWrite(fileBytes);
 

Answer 3

Comme vous, j'ai essayé et essayé d'obtenir que cela fonctionne. Finalement j'ai renoncé à cette idée, et juste opté pour une solution de contournement.

Je suis à l'aide d'ASP.NET Framework MVC, j'ai donc modifié mes itinéraires pour que contrôleur/action pour s'assurer que l'servi fichier PDF est la dernière partie de l'emplacement de la partie de l'URI (avant la chaîne de requête), et passer tout le reste dans la chaîne de requête.

Par exemple:

Vieux URI:

http://server/app/report/showpdf?param1=foo&param2=bar&filename=myreport.pdf

Nouvel URI:

http://server/app/report/showpdf/myreport.pdf?param1=foo&param2=bar

L'résultant de l'en-tête ressemble exactement à ce que vous avez décrit (type de contenu application/pdf, la disposition est en ligne, le nom de fichier est inutilement une partie de l'en-tête). Acrobat affiche dans la fenêtre du navigateur (pas de boîte de dialogue enregistrer sous) et le nom de fichier est automatiquement renseignée si un utilisateur clique sur le Acrobat bouton "Enregistrer" est le rapport de nom de fichier.

Quelques considérations:

Pour les noms de fichiers à chercher décent, ils ne devraient avoir aucune des caractères d'échappement (c'est à dire, pas d'espaces, etc)... ce qui est un peu limite. Mes noms de fichiers sont générés automatiquement, dans ce cas, et avant il y avait des espaces, qui apparaissaient comme '%20 dans la boîte de dialogue d'enregistrement de nom de fichier. J'ai juste remplacé les espaces par des underscores, et ça a fonctionné.

Ce n'est pas les noms de la meilleure solution, mais il fonctionne. Cela signifie également que vous devez avoir le nom de fichier disponibles pour faire partie de l'URI originale, qui pourrait gâcher avec votre programme de flux de travail. Si c'est actuellement produites ou extraites à partir d'une base de données lors de l'appel côté serveur qui génère le PDF, vous devrez peut-être déplacer le code qui génère le nom du fichier à javascript dans le cadre de la soumission d'un formulaire ou si il s'agit d'une base de données en faire un rapide appel ajax pour obtenir le nom de fichier lors de la construction de l'URL que les résultats de l'inline PDF.

Si vous prenez le nom de fichier à partir d'une entrée de l'utilisateur dans un formulaire, alors que ce devrait être validé à ne pas contenir des caractères d'échappement, ce qui va gêner les utilisateurs.

Espérons que cela aide.

Answer 4

Dans ASP.NET 2.0, changez l’URL de

 http://www. server.com/DocServe.aspx?DocId=XXXXXXX
 

à

 http://www. server.com/DocServe.aspx/MySaveAsFileName?DocId=XXXXXXX
 

Cela fonctionne pour Acrobat 8 et le nom de fichier SaveAs par défaut est maintenant MySaveAsFileName.pdf .

Cependant, vous devez restreindre les caractères autorisés dans MySaveAsFileName (pas de points, etc.).

Answer 5

Apache's mod_rewrite peut résoudre ce problème.

J'ai un service Web avec un point de terminaison à /foo/getDoc.service . Bien entendu, Acrobat enregistrera les fichiers sous getDoc.pdf . J'ai ajouté les lignes suivantes en apache.conf :

 LoadModule     RewriteModule         modules/mod_rewrite.so
RewriteEngine  on
RewriteRule    ^/foo/getDoc/(.*)$    /foo/getDoc.service     [P,NE]
 

Désormais, lorsque je demande /foo/getDoc/filename.pdf?bar&qux , il est réécrit en interne sur /foo/getDoc.service?bar&qux , de sorte que j'atteins le bon terminal du service Web, mais Acrobat pense qu'il enregistrera mon fichier sous la forme filename.pdf .