I receive this exception during parsing string containing JSON:
Newtonsoft.Json.JsonReaderException: Unterminated string. Expected delimiter: ". Path '[114].var2', line 1, position 431602.
So I went to exactly that (431602) position and found that it's here:
(...)lZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqK*jp*KWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW1(...)
So it's just simply "jp" chars which shouldn't be anything wrong.
What could be a reason for this exception?
EDIT
To be more specific I also put a whole string with few variables around it:
"var1":"946","var2":"\/9j\/4AAQSkZJRgABAQAAAQABAAD\/\/gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcgSlBFRyB2NjIpLCBxdWFsaXR5ID0gNjAK\/9sAQwANCQoLCggNCwoLDg4NDxMgFRMSEhMnHB4XIC4pMTAuKS0sMzpKPjM2RjcsLUBXQUZMTlJTUjI+WmFaUGBKUVJP\/9sAQwEODg4TERMmFRUmTzUtNU9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09P\/8AAEQgAeABHAwEiAAIRAQMRAf\/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC\/\/EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29\/j5+v\/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC\/\/EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29\/j5+v\/aAAwDAQACEQMRAD8A9OooooAKTNLTaAI7m5jtoWllYKqjOTXmniTxrqMt00elXflQDg4TB\/765P8AKtPxnqdxc67HokZEVuqB55O+OvH4Vz2qalbQCAWiQqpBwyRAuADjC5GAM5GepwT6Z5pVJqpY0UVy3LXh\/wAU65JGySqb0K3LLOfMH4ZyR+FbMXj0218kN5bs0R4f++h\/TP06+9cdZxWWqyyxo0qXuCyFpMlz+X+FQarMb6CByzedANkin7w\/Hrjg9elTG\/tLjaXKe32tzDd20dxbSLJFIMqw7iiuR8B6r51qtm5XfGigj1P+Qf0orohPmRm1Y7OiiirEFIRS0UAecfEbTJYro6tbSNuKKkir2UgjP8qwRbO+mXiwxxvP+6iw+Pkwoyee3J59q7vxaxt7uGaZN9q8ZjlX\/Zzz\/NT+BrkBJZRXzI8jQMmUVuAJY+wOeOnuCPeuKrKSk1Y2gkZmm2lrZ6haJPbOlwSHExlwu0dWwPboKuqqy+JYbmCNSk12UY5yGRdvzfmrnNYpihuL1ks7Se4cnasa5Kg\/zIq3dx30t+mm26CCWNNrFWwIUx8xJBOBj3\/U05Ru736AnpYteFUuJvFSRwybtxZ2Zc4A2HA\/L+dFdJ4PmtBrMOn6YhaCBGaSXH3jjGfzx+Aoram3JXtYzluegUUUVsSFFFFAFa\/tYby2MM65U9D6GvMfEeg32m5CwPc2n8EkQJaP29cV6fdSJDE0sjYVRkmuD1fxHqU8p\/s+wl8kHALxMS3vjtWU7XuUmznbO38S6lbFIL2SK16Zf5N35DJq9b+FobVDJe3ny9X28A\/UmmNe+J7kbUhkQH\/pkF\/nTU0K8um36ret\/uht5\/wFcbk1vJRXlqzVK\/S50\/guazbVZrfTYx5MURLuBwTkADPfvRWv4Q02HT9PdoI9okbgnknHcmiuyilyKxlPc36KKK1JCmuyopZ2CqoySTgAU6ue8TRXOpQfYLW5WCJj++bBJb\/ZHt61FSpGmryY1FvRFW+8V6O0m37aCq9AqMc\/pVCfxppUIIjiuJPooA\/U1Vj8D2xOZ72Vv91Qv+NWH8JaVFg7ZpSB\/G\/+GK8qpLDSlzSbZulO1kZVz4xspSfL0yTPr52P6VWSbWtXlSGxs3gWRgA+Mf8Ajx\/pW0H0XSG+Y2sJHpgt\/jXReG5YdQR9QhVvKyUiZlxu9SP5fnV0VGU1yQ07sJNpayNextUsrGG1jJKxIFyep9z9etFT0V6pzhRRUNzOtvEZH+gA6k+lJtJXYGP4o8RQ6FbqCplnk+6gbBA9T\/n+VcHP42vHYmC2hjz\/AHiWP9K67UNGsLqd7u\/Rpp5OTuc4HoAB2FUhDodgculnAR\/e27v8a82riaVR\/C2bxhJLexzaa\/r1\/wDLA8p9oYv\/AK2aVtN8QXn+uFwQevnS4A\/AmuifxTpFvlI5Hl9o0P8AXFY194xIJFrZ\/RpG\/oP8aIyqv+HTS\/r5A1Hqw0vwTJdXiJe3ACnlliGePqf8K9OtreK0to7e3QJFEoVVHYCuf8Epezaa2o6gQHuT+6QLgKg7\/j\/hXS13UVNR996mUmr6BRRRWpIyWRIYnklYIiAszE4AA6mvNtW8Q6rqmoNJpqzrbR8QqkeSf9o8dT+ldfrOrWkbtBJcwKkf+s3uBk9l\/qfwrFm8WaRCNrXW8+iKT\/8AWrjrV3fkjG5rGGl27HJyaf4m1FyZRdFT2kk2j8iafB4Ov2cefPDGPYlj\/n8a2LjxnZKD5FvPJ\/vYUf1rHn8Z3jt+4too\/wDeJY\/0rJSxL+GKRVqa3dzctfB9lHg3E80p9BhR\/X+dalloel\/bkt4LWLcBuct8zBfXmuPW58R6mm5Tc7D\/AHR5a\/nxXoXhHQjounE3BDXlwd0zZzj0XPt\/PNOFCpOXvzv5ITmktEboAVQqjAAwAKWiivQMQooooA8417wlc3OsX00U0McUkvmDOc8gE8Y9SazIfCUCNi5upH9kUL\/PNdZ411S60ia3e3ijdLhSpLg8Ffoff9K8+udc1i7lKwswz2hj\/wAmuKca7k7OyNouCWqOpt9A0mFMm3Lkd3cn\/wCtT2uNF0\/7rWkLDsoG79Oa5BNL1q95m8zB7zSf061p6d4OmnuESa5XJONsa5\/U1g6Uft1LlqT6RO18OXUWsXLSW6u1tbEZkYYDP2A+nX8q6qqek6bb6Tp0VlajCRjknqx7k1crvpUo0o2iYSk5O7CiiitSQooooAoavaLc26ExLI0ThgCufY\/zrEOi39xIf3ccMeeNx7fQUUVzzoRqTvIuM3FaFqLw1ggy3ZI7hEx+pP8AStOy0u2sm3xb2fGNznOKKKuNGnHVITnJ7su0UUVqSJRmiigAzRRRQB\/\/2Q==","var3":"77241"
I noticed that this seems to be a base64 encoded JPEG. In most cases it would be better & easier to have your server send back the jpeg rather than JSON.
public ActionResult ShowImage()
{
var file = Server.MapPath("~/App_Data/UserUpload/asd.png");
return File(file, "image/png", Path.GetFileName(file));
}
To see original source follow this link.
Troubleshooting advice:
If you are unable to put the whole string, you may want to make it smaller to isolate the error.
Try removing a a block characters at a time (I would use a binary left/right half experimentation method) until it stops breaking. Then look closer at the bad half. If you can get the bad half small enough and are unable to see the error, please post it.
I am guessing the column given by the error isn't counted the same way that you are counting them.
Related
Consider the following line of code:
string _decoded = System.Web.HttpUtility.UrlDecode(
"There%20should%20be%20text%20after%20this%0022help!");
The encoded line
"There%20should%20be%20text%20after%20this%0022help!"
when decoded via the website urldecoder.org produces
"There should be text after this22help!"
however the value of _decoded as displayed in the debugger is:
Figure 1: Debugger view of problem
What could be causing this problem? Is there a setting or special encoding that will circumvent this in all cases?
EDIT: Yes, I consider this behavior to be an error. I don't want URLDecode to introduce the \0 char to the resultant string, because it would result in an invalid file name (my code is moving around files).
There is a null byte (\0 = %00) after this so the debugger doesn't show the rest of the string.
So the decoded value is correct, it's just the limitation (or bug?) of the debugger.
You can take a look at here for more info about null byte from security perspective. And there is this question posted about it as well.
Somehow I'm getting a weird result from a GetString(). So, in my project I got this code:
byte[] arrayBytes = System.Convert.FromBase64String(n["spo_fdat"].InnerText);
string str = System.Text.Encoding.UTF8.GetString(arrayBytes);
The InnerText Value and the code is in: https://dotnetfiddle.net/mMUlti
So, my problem is that somehow I'm getting this result on my Visual Studio:
While in the online compiler that I post above the output is as expected.
This output is an output for a printer and this \0 are destroying the format.
Anyone have a clue of what is going on and what should I do/try?
It looks like for some reason every other byte in your input is null. If you strip those out you get something that looks much more plausible as printer commands (though I am no expert). Hopefully you can verify things...
To do this all I did was added this line in:
arrayBytes = arrayBytes.Where((x,i)=>i%2==0).ToArray();
The where command takes the value (x), and index (i) and if the index mode 2 is 0 (ie its even) then the where clause allows it - if its odd it throws it away.
The output I get from this starts:
CT~~CD,~CC^~CT~
^XA~TA000~JSN^LT0^MNW^MTT^PON^PMN^LH0,0^JMA^PR2,2~SD15^JUS^LRN^CI0^XZ
^XA
^MMT
^PW607
^LL0406
There are some non-printing character in there too that look like possible printing commands (eg 16 is the first character that is "data link escape" character.
Edited afterthought:
The problem you have here is obviously a problem with the specification. It seems to be that your input is wrong. You need to talk to whoever generated it find out the specification they are using to generate it, make sure their ode matches that spec and then right your code to accept that spec. With a solid specification you should both be writing compatible code.
Try inspecting the bytes instead. You'll see that what you have encoded in the base-64 string is much closer to what Visual Studio shows to you in comparison to the output from dotnetfiddle. Consoles usually don't escape non-printables (such as \0 - the null character) whereas Visual Studio string inspector does so in attempt to provide as much value to its user as possible.
Looking at your base-64 encoded data, it looks way more like UTF-16 than UTF-8. If you decode it like so, you'll perhaps get rid of the null characters in Visual Studio inspector as well.
Regardless of that, the base-64 data don't make much sense. More semantical context is required to figure out what the issue is.
According to inspection by Chris, it looks like the data is UTF-8 encoded in UTF-16.
You should be able to get proper results with the following:
var xml = //your base-64 input...
var arrayBytes = Convert.FromBase64String(xml);
var utf16 = Encoding.Unicode.GetString(arrayBytes);
var utf8Bytes = utf16.Select(c => (byte)c).ToArray();
var utf8 = Encoding.UTF8.GetString(utf8Bytes);
Console.WriteLine(utf8);
The opposite is probably how your input was created. However, you could also go for Chris' solution of ignoring every odd byte as it is basically the same with less weird encoding things going on (although this may be more explicit to what really goes on: UTF-8 inside UTF-16).
When I assign an html file to a WebBrowser's Url property, I get this Script err:
So, in an effort to determine what is causing the mayhem, I changed the extension of the file from .html to .txt and tried this code, starting from a spot just before what was flagged as bad:
int dangerZone = 95217560;
string path = #"C:\misc\mapcode_20160720_022208.txt";
string readText = File.ReadAllText(path);
string stuffNearAndPastTheProblem = readText.Substring(dangerZone);
MessageBox.Show(stuffNearAndPastTheProblem);
...but, instead of being enlightened with whatever html is malformed or otherwise problematic, I get a crash that tells me:
System.ArgumentOutOfRangeException was unhandled HResult=-2146233086
Message=startIndex cannot be larger than length of string.
How can there be a problem at character 95217563 when there are not even 95217560 characters in the file?
UPDATE
Okay, I tried this to check the length:
var chars = readText.ToCharArray();
MessageBox.Show(chars.Length.ToString());
...and it tells me 24131.
So the char position from the err msg is, indeed, the epitome of bogusness.
UPDATE 2
So I changed the "dangerZone" value to 2100, and the MessageBox displayed is bigger than King Kong on steroids. So obviously there are a lot more than 24131 chars...
Maybe what's happening is that these lines in the .html/.txt file:
sb.Append("<script src=\"http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js\"></script> ");
sb.Append("<script src=\"http://maps.google.com/maps/api/js?sensor=false\"></script> ");
sb.Append("<script src=\"gomap.js\"></script> ");
sb.Append("<!--[if IE]>");
sb.Append("<script src=\"http://html5shiv.googlecode.com/svn/trunk/html5.js\"></script>");
sb.Append("<![endif]-->");
...are including those referenced .js files in the err msg's character locating calculations. IOW, it may be inserting those referenced files "inline" like so:
part of my file
jquery.min.js
google maps api js
gomap.js
html5.js
...and then back to the rest of my file
...and then basing the problematic char location on all of that combined html and js, whereas only a relatively small subset is actually contained in the .text file.
If my hunch about the frankensteinization of the script's "working set" is correct, then yes, the "bad char" location provided in the Script err msg is pretty much useless (in my case, anyway).
Shouldn't that be cause readText.Substring(dangerZone) would be substituted with readText.Substring(95217560) which means you are specifying 95217560 as the start index of the substring operation. Do your file really have that length of characters?
You are using overload String.Substring Method (Int32)
public string Substring(
int startIndex
)
what number in error message HResult=-2146233086??? You are wrong. See MSDN ArgumentOutOfRangeException and as it says:
HResult Gets or sets HRESULT, a coded numerical value that is
assigned to a specific exception.(Inherited from Exception.)
That's not related to the number of characters in your file content.
I am trying to make a connection via HttpWebRequest. I am reading url links from a text file.
However, I am getting 'System.UriFormatException' error.
I have tried to add http:// in front of the url links in my text file. But the result is the same.
What can be the solution?
If the error only occurs when reading the values from a file, but not when assigned directly to a string variable, then I'm guessing that there are extra characters being read (quotes, escaped characters, carriage-return/line feeds, etc).
Try reading the first value into a string, and then comparing that to what you expect in the explicit string value. Any differences should be obvious after that.
Without seeing code it's impossible to tell what you're trying to do. But you can start by looking at the Message property of the UriFormatException class. Message is a string that explains the reason for the exception.
Getting a few different exceptions related to Base-64 strings in C#. Below are the exceptions along with sample string. I don't know too much about this topic but I believe I did confirm the lengths of the following strings are multiples of 4. I'm hoping these issues are all related but I'm not sure. Any help is appreciated.
"Invalid character in a Base-64 string."
DcxWhbe30oLrUI69U41gSnm7eU2c8qOx7k/eKnSaG3ZDlv8BIPHJKxl0DStVUtsjdxufrZd30K4IAl0XxBIKgKUlOt4k+nVPrfCnM4HHzw19GHnYlTr2DLhw6iD0goEnMk+bJG2xWQ4wRLLn8KOj6DdBxTes6sdpoeWKxcAHPZ2FFXqC3MfQ+SMMV7re9YiY9ZpudFFr1QVRMztzinK5YA==
"Length of the data to decrypt is invalid."
jq6xC0Dv+oeL0MXOei7wNIQgD+aon+S8N2ZfDyAO+5dlm/lIBYN+aCn2Xjnyi/XCzv7Liag5aaKXZ3b+7P7+R7lmarsT9ugnFrnvjInsvUxsbk4EAjIP55O9d7XXYnARW3yjW7klLyR0U9JjMVsISKThDtLe4rOJHgDvYahF454YOn5GlVXBoB+qNnLscGZ6
"Invalid length for a Base-64 char array."
C8MutyUPoTrmmnprFV3wqxMMVs7O5J4NA61jhZLaCSbwteklqGHFuuSlhf0mH8L5FLJ+jcrWuns2zz+Q/o5tA0DCDGnEAxDxKraR8Ip/iDUrTCS9ZAW0VrZpqUY4EPhyCbSpdU0OwfQ05eHXqwU6LIzz3gqavpi6AlMP9H5GYTaxsfQEByswjizWs5hO2ZmH
As I went to look at what I was using to decode the string in response to Andrey's question, I realized that I had been making an assumption that was blinding me from the real issue.
The data string is being passed through a querystring parameter and I was assuming that parameter as seen in the custom error message I was getting was the bad string when, in fact, a little debugging showed that the string I was actually attempting to decode had whitespaces. Posting the string through the querystring was causing all the plus (+) signs to get decoded into whitespace. I am able to resolve this issue from there.
Thank you to anyone who spent time reading this rather misguided question.