On my IIS7 I have ASP.NET WebForms site, and I use cyrillic values in the query string. I use HttpUtility.UrlEncode for params when do redirect, in the end I have url like:
http://mysite.com/Search.aspx?SearchText=текст
When I try to read param SearchText value (include HttpUtility.Decode() function) it returns me a wrong value of ÑекÑÑ, but should return текст
It works on localhost on ASP.NET developer server, but doesn't on IIS7 (include local IIS7)
In my web.config I set up line
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
but it still doesn't work.
Appreciate any help,
Thanks a lot!
Problem actually was in UrlRewriting.net that I use in my web-application.
I solved the same problem by converting the value to ToBase64String:
Before redirecting to a target page I encoded the value:
Dim Data() As Byte 'For the data to be encoded
'Convert the string into a byte array
Dim encoding As New System.Text.UTF8Encoding
Data = encoding.GetBytes(ParamToPass)
'Converting to ToBase64String
Dim EncodedStringToPass as string = Convert.ToBase64String(Data)
Page.Response.Redirect("TargetPage.aspx?Param=" & EncodedStringToPass, False)
At the target page:
Dim Data() As Byte 'For the data to be decoded
Data = Convert.FromBase64String(Page.Request.Params("Param"))
Dim encoding As New System.Text.UTF8Encoding
Dim ParamToPass As String = encoding.GetString(Data)
P.S. The only disadvantage of the method is that one cannot see the real value of the parameters in url string of browsers. But in my case this made no problem
If you use the redirect function, yes inside it there is this call
url = UrlEncodeRedirect(url);
thats break the Cyrilic, Greece characters and probably others. If I remember well, (I say remember because this issue is from my experience some months ago) the break to the characters is after the ? symbol. In any case I have the same issue.
Possible solutions:
Make your custom redirect, maybe not so good as the original, but you can by pass this issue.
Find some alternative way to your redirect logic.
Make your custom text encode that use only valid url characters that are not change by the redirect, and then decodes them again back. The minous on that is that will be like hidden text and not visible readable search word.
This is the very basic of the redirect.
public static void RedirectSimple(string url, bool endResponse)
{
HttpResponse MyResponse = HttpContext.Current.Response;
MyResponse.Clear();
MyResponse.TrySkipIisCustomErrors = true;
MyResponse.StatusCode = 302;
MyResponse.Status = "302 Temporarily Moved";
MyResponse.RedirectLocation = url;
MyResponse.Write("<html><head><title>Object moved</title></head><body>\r\n");
MyResponse.Write("<h2>Object moved to here.</h2>\r\n");
MyResponse.Write("</body></html>\r\n");
if (endResponse){
MyResponse.End();
}
}
You can make it a function and try it to see if works correctly.
Related
The following code:
var text = (new WebClient()).DownloadString("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20"));
results in a variable text that contains, among many other things, the string
"$κ$-Minkowski space, scalar field, and the issue of Lorentz invariance"
However, when I visit that URL in Firefox, I get
$κ$-Minkowski space, scalar field, and the issue of Lorentz invariance
which is actually correct. I also tried
var data = (new WebClient()).DownloadData("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20");
var text = System.Text.UTF8Encoding.Default.GetString(data);
but this gave the same problem.
I'm not sure where the fault lies here. Is the feed lying about being UTF8-encoded, and the browser is smart enough to figure that out, but not WebClient? Is the feed properly UTF8-encoded, but WebClient is failing in some other way? What can I do to mitigate this?
It's not lying. You should set the webclient's encoding first before calling DownloadString.
using(WebClient webClient = new WebClient())
{
webClient.Encoding = Encoding.UTF8;
string s = webClient.DownloadString("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20");
}
As for why your alternative isn't working, it's because the usage is incorrect. Its should be:
System.Text.Encoding.UTF8.GetString()
I am trying to use the FileReader to obtain the base-64 representation of an image and submit that to a .net WebApi service for image uploading.
My problem is that the contents of fileReader.result are not valid as a base-64 encoded image, at least according to .net.
I am just using a very simple method, and testing with fiddler to post to the service. If I post the complete result string from filereader.result, I get an error "Invalid length for a Base-64 char array or string" when I try and read the string using FromBase64String.
public void Post([FromBody]string imgString)
{
var myString = imgString.Split(new char[]{','});
byte[] bytes = Convert.FromBase64String(myString[1]);
using (MemoryStream ms = new MemoryStream(bytes))
{
Image image = Image.FromStream(ms);
image.Save("myBlargyImage.jpg");
}
}
Is cut+paste into fiddler doing something to the string that I need to account for here, or is there something else I am not doing correctly? This seems like it should be straightforward: Encode the image as a string, send the string, decode the string, save the image.
For example, using filereader to display a preview of the image on the client, I get the following in filereader.result:
src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAgEAyADIAAD/...oBUA00AqYL/AMCg3//Z"
I have tried both sending the entire string ("data...Z"), and just the Base64 string. Currently, I am splitting the string server side to get the Base64 string. Doing this, I always get the invalid length error.
Alternatively, I have tried sending just the base64 string. Not knowing if the leading / was actually part of the string or not, I deleted it in the post body. Doing THIS, I can actually read the value into a byte array, but then I get an error using Image.FromStream that the array is not a valid image.
So, either I get an error that the entire string as provided by filereader is an invalid length, or, I hack it up and get an error that even if it is a valid length, it is not a valid image (when reading the bytearray). That is what makes me wonder if there is some issue of translation or formatting between the filereader.read, dev tools in chrome, then cutting and pasting into fiddler.
UPDATE:
I tried a more realistic implementation by just taking the filereader.result and putting it in a $.post() call, and it works as expected.
It appears I was right, that I, or notepad++, or fiddler, are doing something to the data when I touch it to cut and paste filereader.result into a service call.
If someone knows exactly what that might be, or how one can verify they are sending a valid base-64 encoding of an image to a service, it might help others who are attempting the same thing in the future.
Again, if in the browser filereader.result yielded 'data:image/jpeg;base64,somestring', I was simply copying that string from the developer tools panel, creating a fiddler call and in the request body including the copied string: "=data:image/jpeg;base64,somestring". Somehow, the base-64 'somestring' was getting munched in the cut+paste.
function readURL(input) {
if (input.files && input.files[0]) {
reader = new FileReader();
reader.onload = function (e) {
$('#imgPreview').attr('src', e.target.result);
$.post('/api/testy/t/4',
{'':e.target.result}
);
};
reader.readAsDataURL(input.files[0]);
reader.onloadend = function (e) {
console.log(e.target.result);
};
}
}
$("#imgUpload").change(function () {
readURL(this);
});
Don't forget to remove the 'noise' from a dataUrl,
For example in
data:image/png;base64,B64_DATA_HERE
you have to remove the data:image/png;base64, part before, so you process only the base 64 portion.
With js, it would be
var b64 = dataUrl.split("base64,")[1];
Hope this helps. Cheers
A data uri is not a base64 encode string, it may contain a base64 encoded string at the end of it. In this case it does, so you need to only send the base64 encoded string part.
var imagestr = datauri.split(',')[1];
sendToWebService(imagestr);
Make sure fiddler is not truncating the Base 64 String
on a web page there is following string
"Qualcomm Snapdragon™ S4"
when i get this string in my .net code the string convert to "Qualcomm Snapdragonâ„¢ S4"
the character "TM" change to â„¢
how can i decode "â„¢" back to "TM"
Update
follwoing is the code for downloaded string using webproxy
wc is webproxy
wc.Headers.Add("Accept-Charset", "ISO-8859-1,utf-8");
string html = Server.HtmlEncode(wc.DownloadString(url));
You should read the webpage in its proper encoding in the first place. In this case it seems you are reading with Encoding.Default (i.e. probably CP1252) and the page is really in UTF-8. This should be apparent either by reading the Content-Type header of the response or by looking for a <meta http-equiv="Content-Type" content='text/html; charset=utf-8'> in the content.
If you still need to do this after the fact, then use
var bytes = Encoding.Default.GetBytes(myString);
var correctString = Encoding.UTF8.GetString(bytes);
In any case you would need to know the exact encodings that were used on the page and for reading the malformed string in the first place. Furthermore I'd generally advise explicitly against using Encoding.Default because its value isn't fixed. It's just the legacy encoding on a Windows system for use in non-Unicode applications and also gets used as the default non-Unicode text file encoding. It should have no place whatsoever in handling external resources.
The following code:
var text = (new WebClient()).DownloadString("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20"));
results in a variable text that contains, among many other things, the string
"$κ$-Minkowski space, scalar field, and the issue of Lorentz invariance"
However, when I visit that URL in Firefox, I get
$κ$-Minkowski space, scalar field, and the issue of Lorentz invariance
which is actually correct. I also tried
var data = (new WebClient()).DownloadData("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20");
var text = System.Text.UTF8Encoding.Default.GetString(data);
but this gave the same problem.
I'm not sure where the fault lies here. Is the feed lying about being UTF8-encoded, and the browser is smart enough to figure that out, but not WebClient? Is the feed properly UTF8-encoded, but WebClient is failing in some other way? What can I do to mitigate this?
It's not lying. You should set the webclient's encoding first before calling DownloadString.
using(WebClient webClient = new WebClient())
{
webClient.Encoding = Encoding.UTF8;
string s = webClient.DownloadString("http://export.arxiv.org/api/query?search_query=au:Freidel_L*&start=0&max_results=20");
}
As for why your alternative isn't working, it's because the usage is incorrect. Its should be:
System.Text.Encoding.UTF8.GetString()
I am getting "Internet Explorer cannot display the webpage" error while trying to redirect ot another page.
string targetURL = "~/AnotherForm.aspx?Xresult=" + HttpUtility.UrlEncode(res);
Response.Redirect(targetURL);
Thanks
BB
ResolveURL() which is used by Response.Redirect(), doesn't work nicely with UrlEncode, try this:
string targetURL = "~/AnotherForm.aspx?Xresult=" + HttpUtility.UrlEncode(res);
Also check this related SO answer: Response.Redirect using ~ Path
You're miscalling HttpUtility.UrlEncode.
You should only Encode the parameter value.
By Encodeing the entire URL, you are escaping the / characters, messing up your URL.