When downloading a file with Response.Write spaces in the file name are replaced with underscores, and when the associated application opens, a number in square brackets is appended:
Response.AppendHeader("Content-disposition", "attachment; filename=this is the file.xml");
Response.Write(dr["InfopathDoc"]);
This results in this file name in the associated application:
this_is_the_file[1].xml
How can I get rid of the underscores and why do I get the [1] ?
Thanks
Found the solution for this problem here
http://dotnetslackers.com/Community/blogs/kaushalparik/archive/2009/05/06/file-download-problem-filename-with-spaces-truncated-in-ff-and-replaced-by-underscore-in-ie.aspx
To solve problem for FF, add quotes around the filename as
Response.AddHeader("Content-Disposition",
"attachment; filename=\"" + filename +
"\"");
And for IE, replace spaces with '%20'
filename = toDownload.Name.Replace(" ", "%20");
On the net there are some solutions suggested to this kind of problem. Not all solutions work everywhere and for all browsers, but some solutions at least guarantee "save results" although they cannot keep the originally "suggested" filename for all clients:
First sight:
Content-Disposition: attachment; filename=My New Document.pdf;
FF36: Presents for download the file "My" :-(
IE6: Presents "My New Document.pdf", but on opening it may appear as "My New Document[1].pdf".
IE8: Presents "My_New_Document.pdf", but may also append "[1]" as IE6.
ATTN: On saving the document, IE keeps the presented name, regardless of what it hands out to the selected application on direct opening!
First improvement:
Content-Disposition: attachment; filename="My New Document.pdf";
FF36: Works as supposed, i. e. presents "My New Document.pdf".
IE6+IE8: No change, just as before.
Second change:
Content-Disposition: attachment; filename="My%20New%20Document.pdf";
(replace blanks by %20, as in URL encoding, and keep double quotes.)
FF36: Presents what was sent back, which is "My%20New%20Document.pdf". Not nice.
IE6+IE8: Presents "My New Document.pdf", but hands out "My%20New%20Document.pdf".
Third variation:
Content-Disposition: attachment; filename=My%20New%20Document.pdf;
(Remove double quotes, but keep %20.)
FF36: As above -- not nice.
IE6+IE8: As above -- not that nice also.
Conclusion:
It seems that at least the presented methods do not solve the problem all and forever: Neither do they cover all situations for 1 browser, nor do they cover all browsers for the any same one selected situation.
For me, the best result seems to be possible with surrounding double quotes: For FF36 and IE6 that works, and for IE8 (and probably for IE7) it is at least stable with the underscores, i. e. download & save render the same file name as download & open, except the "[1]" which we cannot prevent anyway.
Final remarks
Some people go with the little king of Saint-Exupérys "The Little Prince" which said that an emperor cannot really expect that his people follows when he demands what is simply not possible, causing him to command the sun to rise and set just when it naturally happens to do so. Like this king gets in trouble when his small planet accelerates its rotation more and more, these people have given up and simply add underscores on the server side already. :-)
But the RFCs on this topic and what browser implementors offer is quite hard to overcome sometimes.
If anyone is still interested:
This kind of file name rewriting is done by the browser only as you can see when inspecting the received HTTP response with an appropriate tool, independent of the browser used. IE first downloads the requested file into its "Temporary Internet Files" folder system (which is not just one, but this is another topic), and for this purpose the file receives a new name, making best match to the "Content-Disposition" suggestion from the HTTP response. But if an equally named file is already present in the actual "Temporary Internet Files" folder actually used for this file, its name is extended by a sequenced number in brackets, like "[2]". Because every new HTTP request causes the IE cache mechanism to newly compute the actual cache folder, and the next cache folder chosen may not yet contain a file with that name, the number may seem to vanish at the next download of a file or resource with the same name.
If a downloaded file is stored somewhere, the originally suggested file name is used again usually, depending on the IE version. Some versions and patch levels seem to use the cache folder file name instead :-(
The problem starts to become annoying when the browser hands out a downloaded file to a chosen or automatically selected application. In this case the application is called to open the file directly from the cache, which is bad for at least 2 reasons:
(1) The file name will be the name of the file in the cache folder, not the suggested name. This may even strip the extension, which will confuse some applications even if they have been chosen for handling the file correctly.
(2) If an internet newbie user downloads and opens a file for editing and then simply presses the "Save" button of the application, the file is simply saved into the IE cache folder, and no user of this kind will ever find this file again. These are things which can turn people really angry and desperate...
Shouldn't you be using Response.Output.Write() instead, after HTMLEncoding the output? :
Response.Output.Write(Server.HtmlEncode(Convert.ToString(dr["InfopathDoc"])));
Edit: The underscores and the [1] appended to the filename suggest that it is being loaded from the Temporary internet files folder. There is insufficient information to deduce why this may be happening, but maybe this information will provide you a clue.
Did you try replacing spaces with "%20" (without double qoutes) like in urls?
But you should consider to avoid spaces in filenames (in urls).
Apparently this is an issue with IE7 and requires a hotfix:
http://support.microsoft.com/kb/952730/en-us
Still don't know about the number being appended though - I thought maybe it is because a file of the same name already exists in the IE temporary download folder, but that's not the case.
Related
In searching to resolve this issue I have found several lists of codes that appear to be the same special character, but give different codes from each other. And since I can't seem to type them, I can't verify if any of them is the correct code for a domain name.
The domain name URL for purposes of this inquiry is the http://sǝx.com IDN. If you paste that in, it goes to a landing page; but how would you TYPE it in?
In comparison, £.com (symbol for the British Pound) is pretty straight forward: you just hold down the Alt key, tap 0, tap 1, tap 6, and tap 3 — all on the numpad — and then release the Alt key and press enter. Bam! You just created the £ needed to go to the £.com website (which resolves and redirects to poundsymbol.com).
But how do you do this for the "ǝ" in sǝx.com? The domain name converts to "xn--sx-73a.com" in your browser once you press enter, so I thought that might give me a clue to typing in the character. But if so I missed it.
However, in researching the "ǝ" symbol I ran across this URL:
http://easycaptures.com/fs/uploaded/1110/6435628828.jpg
(That's an image of it, since when I paste it in this editor it ends up like this instead: ?text=%C7%9D)
Anyway, that URL implies that there are many different versions of the letter available in several different character sets. If so, would they all work the same in a browser for resolving to the same domain name? If so, is any particular character set easier to work with on a standard US keyboard?
There are also other URLs that seem to give different information about the actual code for the letter, such as wikipedia:
https://en.wikipedia.org/wiki/%C6%8F
(and others, but I'm at my link limit)
While they all look similar, I am wondering if the distinction between them is enough to prevent the URL from resolving properly based on which exact character from which exact character set is deployed.
And again, I am only unable to test this more as I cannot ascertain how to type most of them into the browser - particularly if the code has a letter, as that seems to start triggering shortcuts on the browser instead of considering it as URL input.
Please help me decipher the mystery (to me) of the "ǝ" (apparently also called schwa) and how I would find and type the correct code to get to "sǝx.com" or "pǝt.com" or any website that included "ǝ" in its name.
Thanks in advance!
I need to quickly write a simple GUI over a command line application. Two steps are required:
Specify an input file path,
Specify an output file path (non existing)
I found out a previous post, however trying to get the above (1) to work seems like an insane task.
Indeed BrowseForFolder seems to only work in some weird cases, you can use BIF_BROWSEINCLUDEFILES for only *.pdf and/or *.txt (trial and errors). I can get an error if I select a *.dll and/or a *.jpg (don't ask).
So instead, I gave up this approach and followed another one, in this case (objIE.Document.all.FileSelect), only the name of the selected file is returned the path seems to be always set to "c:/fakepath" for some reason. So again I am missing the full path to be able to pass that to the command line app.
Is there any sane way (<10 lines of codes) to get (1) and (2) working on Win7/64bits (VBS, HTA...)?
Don't know if people are still interested in the BrowseForFolder file selection issue, but here's what I've found.
I had the same issue selecting files with BrowseForFolder using &H4000 / BIF_BROWSEINCLUDEFILES. I could get a return with .docx but not .doc files and as you say .pdf files.
For me .txt wouldn't return anything, as didn't WMI Backup .rec files that I needed for a script I'm writing, resulting in this error information:-
Error: Unspecified error
Code: 80004005
Source: (null)
After looking at other solutions I came back to this one as my preferred choice, plus it was doing my head in that it didn't want to work. So at the bitter end it seems to be this easy.
To get my .rec files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\.rec]
#="WMI.Backup"
[HKEY_CLASSES_ROOT\WMI.Backup]
#="WMI Backup"
"BrowseInPlace"="1"
To get .txt files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\txtfile]
"BrowseInPlace"="1"
So "BrowseInPlace"="1" seems to be the nugget.
Seems so unbelievably easy that I'm sure this solution is out there somewhere but I never came across it so thought I'd put it online.
I would be interested to find that it works for others as I fear that this issue may of sent me mad, still can't believe it seems to work.
Hope this helps.
Here are 3 different ways to do what you want:
http://www.robvanderwoude.com/vbstech_ui_fileopen.php
Did a MediaWiki upgrade from 1.15.1 to 1.20.2 by following the simple update instructions (basically a new installation, copying over the old LocalSettings.php, update script and copying over images). Weird thing now is that all of the File: prefixes don't work. Instead the internal links to images is a "file:name of image" URL rather than "http://mediawiki address/index.php/File:name of image".
Anybody else getting this. Assuming it is something wrong with the old LocalSettings.php.
Ran the refreshLinks and refreshImageMetadata maintenance scripts without fixing the problem.
In the comments, you wrote that you have file: added to $wgUrlProtocols. This is very likely what's triggering the problem.
It looks like something has changed in the parser between MW 1.15 and 1.20 so that it's now parsing file:whatever as an external link (since it matches the file: prefix you've defined in $wgUrlProtocols) even if it's inside square brackets.
The obvious workaround would be to change the $wgUrlProtocols entry from file: to file:// so that it will only match if the slashes are there (as they should be, according to standard file: URL syntax). Since your on-wiki filenames are, presumably, very unlikely to begin with double slashes, they should not match this more specific prefix.
That said, this could still be considered a bug in MediaWiki. You may want to file a bug report about it, if there isn't one yet.
(Edit: Looks like Mark A. Hershberger filed one already.)
I am currently developing some functionality that implements some complex calculations. The calculations themselves are explained and defined in Word documents.
What I would like to do is create a hyperlink in each code file that references the assocciated Word document - just as you can in Word itself. Ideally this link would be placed in or near the XML comments for each class.
The files reside on a network share and there are no permissions to worry about.
So far I have the following but it always comes up with a file not found error.
file:///\\165.195.209.3\engdisk1\My Tool\Calculations\111-07 MyToolCalcOne.docx
I've worked out the problem is due to the spaces in the folder and filenames.
My Tool
111-07 MyToolCalcOne.docx
I tried replacing the spaces with %20, thus:
file:///\\165.195.209.3\engdisk1\My%20Tool\Calculations\111-07%20MyToolCalcOne.docx
but with no success.
So the question is; what can I use in place of the spaces?
Or, is there a better way?
One way that works beautifully is to write your own URL handler. It's absolutely trivial to do, but so very powerful and useful.
A registry key can be set to make the OS execute a program of your choice when the registered URL is launched, with the URL text being passed in as a command-line argument. It just takes a few trivial lines of code to will parse the URL in any way you see fit in order to locate and launch the documentation.
The advantages of this:
You can use a much more compact and readable form, e.g. mydocs://MyToolCalcOne.docx
A simplified format means no trouble trying to encode tricky file paths
Your program can search anywhere you like for the file, making the document storage totally portable and relocatable (e.g. you could move your docs into source control or onto a website and just tweak your URL handler to locate the files)
Your URL is unique, so you can differentiate files, web URLs, and documentation URLs
You can register many URLs, so can use different ones for specs, designs, API documentation, etc.
You have complete control over how the document is presented (does it launch Word, an Internet Explorer, or a custom viewer to display the docs, for example?)
I would advise against using spaces in filenames and URLs - spaces have never worked properly under Windows, and always cause problems (or require ugliness like %20) sooner or later. The easiest and cleanest solution is simply to remove the spaces or replace them with something like underscores, dashes or periods.
I have an IzPack installer that takes in a lot of User Inputs and substitutes them in an XML file. This XML file is actually the configuration file for my application.
There is a major problem that I have hit and I cant move on from it.
In the Input fields (in the installer) user can enter any text and also special characters like & # % ' etc. These special characters messes up my XML file as they are no allowed in the XML syntax and needs to be escaped. for example for & one would need &
So far I have been asking the user to do this, as in escape the special characters themselves, but thats now working either.
Is there a way to have this done automatically? I really need a solution fast.
I am using IzPack V 4.1
You should use a proper XML Api (SAX, DOM) to generate the XML file, this will apply the correct encoding automatically. This may look more complicated first but guarantees that a well formed, syntactically correct file is written.
Searching for JAXP should give you a proper starting point.