While moving a website - that I did not build - I have run into the use of %3F.
%3F is the percent-encoded version of ?.
It seems to be used like this a lot:
Example
when linking to a file named example_lang=1.html.
So, I replaced %3F with _, and all works again.
I am missing something here. The old website worked. After being moved, it no longer worked. After the replacement of %3F to _, the links worked again. Why?
First, you should elaborate your question to understand it better after all If I understood it correctly then this might be the answer.
"_" is not a reserved URI character.
As you said that %3F is reserved for "?" then you are absolutely right but if you read the documentation written on wiki states that "_"(underscore) is not a reserved URI character.
So that for example if the URL for a web page is "example_test.html" then its encoded URL must be "example_test.html" if there is not any mechanism applied on that URL. Now I will take an another example of PHP based web page that may answer your question.
In PHP there is a function "str_replace" that is used to replace the string by programmer defined characters or string.
Let assume that I have a page named "example_test.html" and for some xyz reasons I want to change it to "example%3Ftest.html" then I can use
str_replace("%3F","_","<a href='example%3Ftest.html'>Example Test</a>");
This function will search for all occurences of "%3F" and replace it with "_" in provided string(here "href=example%3Ftest.html") and output as "href='example_test.html" which is the actual link for my file.
Related
I've got a rather odd situation happening, that I'm having difficulty tracking down in an existing Django application. One of the views, which inherits from APIView, returns with a file when a user makes a POST call. The endpoint works fine, but there's something odd happening when the downloaded file reaches the client machine. By the time the browser receives the file, the file extension has been renamed with a trailing underscore. (So suppose the file was originally "test.txt", the version that the client receives would be "test.txt_").
As near as I can figure, just before the response object is returned in the APIView, the content-type and content-disposition headers look correct. E.g.:
Content-Type: application/octet-stream
Content-Disposition: attachment;filename="test.txt"
That same file, when it shows up in Chrome downloads, is named "test.txt_" - with the trailing underscore. I've tried the same thing out in Firefox, and it seems to download correctly. Unfortunately, telling the majority of our users to switch browsers isn't going to fly.
I have tried:
Forcing a different content type (e.g.: instead of "application/octet-stream", try "application/text", just to see what happens). This had no effect.
Formatting the content disposition slightly different (e.g.: space between the semicolon and filename). This also had no effect.
Removed the double quotes around the filename in the content-disposition header. No effect.
Dropping breakpoints within the Rest Framework itself, but Visual Studio Code doesn't seem to trigger on these. (I'm not super-familiar with debugging through Visual Studio Code, so this may be my fault).
Stripped out any custom middleware, so the only remaining middleware are as follows:
corsheaders.middleware.CorsMiddleware
django.contrib.sessions.middleware.SessionMiddleware
django.middleware.locale.LocaleMiddleware
django.middleware.common.CommonMiddleware
django.middleware.csrf.CsrfViewMiddleware
django.contrib.auth.middleware.AuthenticationMiddleware
django.contrib.messages.middleware.MessageMiddleware
So far, any similar issues that other people have experienced seem to be slightly different (i.e.: Internet Explorer removing the period in the extension and replacing it with an underscore).
Any guesses on what might be happening here? I'm a bit stumped.
You have to remove "" from your file name
Change attachment; filename="filename.txt" to attachment; filename=filename.txt
Although seems like you won't be able to have spacing in file name
I finally figured out what was going on here. The UI that was used to trigger the download was doing so through creating a temporary anchor tag (see the second answer here: Download data url file ). When it was doing so, it had two different cases. In one case, if downloading multiple files, it would change the file extension to .zip. In another case, if downloading a single file, it was still trying to append an extension, but the way the UI code was written, it was setting the extension to be an empty string. So the end result is a period being added, but no extension after that. For example, if the file being downloaded was "test.txt", it would end up as "test.txt.", which was then converted by Chrome to "test.txt_", on Windows, to make it a valid file extension.
Our environment has a document storage system that contains documents with the attributes DocumentName and ContentType. In some cases, the content type would return with spaces appended to the end of the string like "pdf ".
In Internet Explorer the output would truncate the end of the string while Chrome would convert the extra spaces to underscores giving me this filename: "file.pdf______________"
To resolve I simply truncate the string.
public string getFileName(string docName, string contentType) {
string fileName = docName + "." + contentType.Trim();
return fileName;
}
I encountered the same problem.
Let's say your download file name is "my_report.csv"
Then before doing the download operations get rid of " characters
fileName = fileName.replace('"','') // replacing one " charcter
fileName = fileName.replace('"','') // replacing second " character
This will resolve your issue.
My solution in ASP.NET core
[HttpGet("pdf/{fileId}")]
public IActionResult GetPdfFile([FromRoute]int fileId)
{
var result = Repo.GetFile(fileId);
Response.Headers.Add("Content-Disposition", $"inline; filename={result.FileName}");
return File(result.Data, "application/pdf");
}
I resolved this issue with replace white space in file name by a character like -.
This was happening for me when the filename included a comma.
lastname,MD.pdf
browser would download filestream as
_lastname,MD.pdf_
Adding code to remove a potential comma from the filename resolved the issue and made it download as expected.
filename = filename.Replace(",", ""); // replace comma characters with blank
now downloads as
lastnameMD.pdf
In my case there was a space as a first character, and it was replaced to underscore. So I simply removed the space :-)
function test(){
var log=(typeof Logger=='undefined')?console:Logger;
log.log(" ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ".length);
}
The code prints 127.0 in Google Apps Script, but returns 128 in Chrome browser and Nodejs!
This is a known bug in Rhino, the JS engine that Google Apps Script uses. It doesn't correctly process "soft hyphen" character 0xAD when it's entered directly in a string; the character just gets lost. Your string contains it within "¨". To simplify the example,
"ab".length
(with a soft hyphen between a and b) returns 3 in browsers but 2 in GAS.
A workaround, if you must use soft hyphen in strings, is to escape it like "a\u00ADb"
"a\u00ADb" === "ab"
evaluates to true in browsers, and to false in GAS.
This discussion, currently offline but available from Google cache, refers to this bug. I quote it below
Subject: Re: Rhino eats strange characters
Hi Richard,
for me this clearly looks like a bug in Rhino where I'm able to
reproduce it. I'll try to prepare a patch for Rhino for this problem.
Please open an issue in HtmlUnit to be sure that it doesn't get lost
(and to be sure that I've correctly identified the root cause).
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com
Richard Eggert wrote:
I recently attempted to use HtmlUnit to load pages that have been
"compressed" using HTMLZip (http://www.htmlzip.com/) and found that
HtmlUnit horribly mangles the output. Since HTMLZip claims to work
properly in every major browser (and I'll take their word for it), I
figure this is a bug in HtmlUnit, since it is supposed to mimic the
behavior of "normal" browsers.
Examining the source code of a page generated by HTMLZip, I found that
HTMLZip uses JavaScript strings that contain unprintable characters
without escaping them. When I replaced all the unprintable characters
with their corresponding \x escape sequences, HtmlUnit was able to
process the page. However, HtmlUnit was not able to process pages in
which multiple layers of HTMLZip compression had been applied.
I then did an experiment in which I created a very simple ISO-8859-1
HTML document that contained just a SCRIPT tag that declared a variable
"x" that was assigned a string containing the characters 0 through 255,
escaping only the white space and quotation characters (to avoid syntax
errors). I ran it through HtmlUnit and examined the value of the "x"
variable. I found that every character was preserved intact EXCEPT for
the 0xAD character, which corresponds to the Unicode SHY "soft hyphen"
character in ISO-8859-1. The character was just plain missing from the
string!
In order to narrow down where the 0xAD was getting dropped, I used a
ScriptPreProcessor to capture the script before it was passed to Rhino.
I examined the captured script and found that the 0xAD was still present
in the text, which indicates to me that the character is being dropped
by Rhino and not by the HTML parser.
Should I submit a bug report for this? Also, can anyone think of a
quick workaround? Off the top of my head, all I can think of would be
to write a ScriptPreProcessor that automatically converts the SHY
character to an escape sequence, but without actually parsing the
script, I could end up escaping characters that appear outside of string
literals.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
This seems like it ought to be a trivial question, but I'm having a hell of a time finding an answer for this so far...
I have an access database that stores hyperlinks to files on a shared network drive. The link targets are specified as simple file paths (e.g. "G:\directoryname\filename.ext") rather than proper URL's ("http://domain.ext/link").
This works fine in general, but I've recently run into a problem involving file names that contain the "#" character. (It is not an option to change the file names to remove the # characters)
If I try to set up a link to something like "G:\directoryname\ExampleFile#24.pdf", then Access parses the # in the filename as it would generally do when it defines a hyperlink. The resulting target is just ""G:\directoryname\ExampleFile", with the portion of the link following the offending "#" simply being truncated.
Now, obviously if the link target were a regular URL, I would just replace the "#" in the text of the link with "%23" and there would be no issue.
The problem is that, if I do that here, my network file action fails, because unlike when opening a regular URL through a browser, the network doesn't recognize %23 as equivalent to # ( I get an error saying "Unable to open G:\directoryname\ExampleFile %23 24.pdf. Cannot open the specified file.")
Is there a more direct way to have ms-access record the link target with a literal # character included?
Well this certainly doesn't help you but here is your answer:
"You cannot use a pound character in a file name for a hyperlink in an Office program"
https://support.microsoft.com/en-us/kb/202261
I am using POEdit for translations in a web application.
However, when I start POEdit I can't find any sources when I run 'Catalog > Update from Sources'. I only have .CSHTML-Files where the texts need to be translated.
What I've already tried:
Set the source path in Catalog > Properties and the charset to
'UTF-8'.
Added additional keyword ("[[[w+]]]") for matching words in my files (the words to translate always have the following form: [[[wordToTranslate]]]
Added a cshtml-extractor (In File > Settings > Extractor). When I did this, the following error message appeared: "warning: unterminated string constant". Warning: ')' found where '}' was expected.
Browsing the web without finding any clue of how to include cshtml-files.
Any hints are appreciated.
Any solutions are MUCH appreciated. :-)
Added additional keyword ("[[[w+]]]") for matching words in my files
I don’t know why you assume the keyword values are regexes of all things; they are not. The GNU gettext manual makes it clear what “keyword” is in the gettext context: name of the function used to call gettext with translatable string literals as the argument.
Added a cshtml-extractor
You get errors coming from this, it would be reasonable to assume that’s the problem. Because you gloss over this crucial step and don’t reveal the details of how you configured it, it’s impossible to give you a concrete answer (not without a crystal ball, anyway).
So I can only make an educated guess: if you didn’t actually add a proper extractor that understands the syntax of the template language you use, and used some gross hack like using the Python parser, then that’s the cause of your errors, together with the use of keyword value that can’t possibly be valid.
I'm using SSRS Action -> Go To Url like this:
="javascript:void(window.open('http://xxx/xxx/Pages/ReportViewer.aspx?%2fDevelopment%2fReport&rs:Command=Render&Parameter="& Parameters!Parameter.Value &"'))"
generated link should be:
http://xxx/xx/Pages/ReportViewer.aspx?/Development/Report&rs:Command=Render&Parameter=Úxxx
I need to somehow escape special characters with diacritics like character 'Ú' in example above. Without escaping this character the above link is broken.
Thanks for you help.
You need to URL encode your parameter, however referencing System.Web (as many suggest) is problematic, since later versions of the Reporting Services designer seem to run in a partial trust context, and System.Web does not have APTCA.
Instead, in later framework versions you have the choice of using System.Uri.EscapeDataString or System.Net.WebUtility
See SO question How do you UrlEncode without using System.Web? for examples of both, neither of which require full trust
You need to add Url encoding to your outgoing parameters. This article explains how to reference the library in the report and user UrlEncode() to process your parameters.