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.
Related
While writing some property-based tests in F#, I have discovered a very strange behavior of the constructor of System.IO.DirectoryInfo. Based on the documentation, I would expect an ArgumentException to be thrown any time I try to construct a DirectoryInfo with an invalid path character; and I would expect Path.GetInvalidPathChars() to be a reliable source for these. Its documentation says, "The array returned from this method is not guaranteed to contain the complete set of characters that are invalid in file and directory names"; but it says nothing about the method returning characters that are not invalid! Form feed ('\012') is one of these invalid characters, as you might expect; I would expect any kind of control character to be invalid in a path name. And indeed, if I try to construct a DirectoryInfo with one in the middle or the beginning, it doesn't work. However, it does work if I put it at the end:
The absolute path produced does not have the form feed in it though, confirming that this is indeed and invalid path character. I confirmed that the directory I created in that REPL session was there, with no control characters in the name. However, to make it even odder, when I convert the DirectoryInfo back to a string, the garbage character is maintained:
Then same behavior is exhibited for horizontal tab '\009', line feed '\010', and vertical tab '\011', and carriage return '\013', but all other control characters are rejected. One would think they would at least be trimmed if they were going to be accepted.
What's going on here? Is this a bug in DirectoryInfo, or is there some rational/consistent explanation of this behavior in .NET? (And what other such potholes might I have to look for!)
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.
I have a large url that I am encoding using System.Web.HttpUtility.UrlEncode. When I encode it its not encoding it like the working example I have. I am not sure what the problem is, maybe different character type or something, I put an example of what suppose to be created and what actually being created. thanks for any help, i am lost on this one.
Working exmaple (look how this one has Did%252Citag%252 and the other doesnt)
22%7Chttp%3A%2F%2Fv17.nonxt1.googlevideo.com%2Fvideoplayback%3Fid%3D0b608733ae5257c3%26itag%3D22%26source%3Dpicasa%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1333533157%26sparams%3Did%252Citag%252Csource%252Cip%252Cipbits%252Cexpire%26signature%3D8AD67D74F34FBAFBBA87616C0AED4A336DF0982A.129E2B5E648F8A2F35A34F312AC5C3C957A1C40A%26key%3Dlh1%2C35%7Chttp%3A%2F%2Fv18.nonxt3.googlevideo.com%2Fvideoplayback%3Fid%3D0b608733ae5257c3%26itag%3D35%26source%3Dpicasa%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1333533157%26sparams%3Did%252Citag%252Csource%252Cip%252Cipbits%252Cexpire%26signature%3D7A58A11994C710872E945D0EAA6E43B6BFB8A648.B9C1D9FB377E1A49EBF3DC6C166C0B6E3E94EC24%26key%3Dlh1%2C34%7Chttp%3A%2F%2Fv6.nonxt1.googlevideo.com%2Fvideoplayback%3Fid%3D0b608733ae5257c3%26itag%3D34%26source%3Dpicasa%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1333533157%26sparams%3Did%252Citag%252Csource%252Cip%252Cipbits%252Cexpire%26signature%3D260B10850A3448C849B8B8F1F2AF5E31244E71BC.6D7420FD66B85D40982BFB2C847EDB46021C63AE%26key%3Dlh1%2C5%7Chttp%3A%2F%2Fv23.nonxt7.googlevideo.com%2Fvideoplayback%3Fid%3D0b608733ae5257c3%26itag%3D5%26source%3Dpicasa%26ip%3D0.0.0.0%26ipbits%3D0%26expire%3D1333533157%26sparams%3Did%252Citag%252Csource%252Cip%252Cipbits%252Cexpire%26signature%3D9894DCDA7D2634EE0006CE0F6E0E29ABF7A8F253.18765D7CD7BDE80ED1A47DC8EC559C3E05C92F56%26key%3Dlh1
Here is an example of the one I am creating (see this one encodes as did%2citag%2)
5%7chttp%3a%2f%2fv23.nonxt7.googlevideo.com%2fvideoplayback%3fid%3d0b608733ae5257c3%26itag%3d5%26source%3dpicasa%26ip%3d0.0.0.0%26ipbits%3d0%26expire%3d1333562840%26sparams%3did%2citag%2csource%2cip%2cipbits%2cexpire%26signature%3dC0E2993011931D9F5FCAFAF54E821415F6042DDD.477CD23B021563A6DE30E858E35C21046E0B0BA6%26key%3dlh1%2c18%7chttp%3a%2f%2fv11.nonxt4.googlevideo.com%2fvideoplayback%3fid%3d0b608733ae5257c3%26itag%3d18%26source%3dpicasa%26ip%3d0.0.0.0%26ipbits%3d0%26expire%3d1333562840%26sparams%3did%2citag%2csource%2cip%2cipbits%2cexpire%26signature%3d696501A8ACBA0E1246173B040E0FB81DA8EBCDC7.944BA6C08C630EFFC2456D66BAD12376D7E377B2%26key%3dlh1%2c34%7chttp%3a%2f%2fv6.nonxt1.googlevideo.com%2fvideoplayback%3fid%3d0b608733ae5257c3%26itag%3d34%26source%3dpicasa%26ip%3d0.0.0.0%26ipbits%3d0%26expire%3d1333562840%26sparams%3did%2citag%2csource%2cip%2cipbits%2cexpire%26signature%3dDDD3D9081F7F2FF462D17CFAE6CAB72AEB86DEA9.3275E0EE8921EF728132035FC94BEF5926A0B7C1%26key%3dlh1%2c35%7chttp%3a%2f%2fv18.nonxt3.googlevideo.com%2fvideoplayback%3fid%3d0b608733ae5257c3%26itag%3d35%26source%3dpicasa%26ip%3d0.0.0.0%26ipbits%3d0%26expire%3d1333562840%26sparams%3did%2citag%2csource%2cip%2cipbits%2cexpire%26signature%3d7826E7470450F9F473BC7A845967EF3AC655CFB.3850F952F5D68151D325CD754C581CD66B0BC4D7%26key%3dlh1%2c22%7chttp%3a%2f%2fv17.nonxt1.googlevideo.com%2fvideoplayback%3fid%3d0b608733ae5257c3%26itag%3d22%26source%3dpicasa%26ip%3d0.0.0.0%26ipbits%3d0%26expire%3d1333562840%26sparams%3did%2citag%2csource%2cip%2cipbits%2cexpire%26signature%3d32FAAE6AE74B22BFB3DBD4300CEEDBC1A12A9ED4.8014678ABB1AEE93FB4B1C36E2C74C89102DC112%26key%3dlh1
Looks like in the first example the URL is double encoded. Meaning if you look at decoded sparams parameter it is represented as
sparams=id%2Citag%2Csource%2Cip%2Cipbits%2Cexpire
In your second example
sparams=id,itag,source,ip,ipbits,expire
So, what is happening in the first example is that, they are doing a UrlEncode on the value first. Using this value Construct the URL and then do UrlEncode on the constructed URL.
UPDATE : This is a general practice to be followed if the value of your querystring contains values which needs to be UrlEncoded (eg. , & space ? etc)
According to w3c standards, your example is fine. There is no %252 symbol.
I'm not sure exactly what you are expecting, but when you fire these strings into a URL Decoder, this is what you get:
String 1
22|http://v17.nonxt1.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=22&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333533157&sparams=id%2Citag%2Csource%2Cip%2Cipbits%2Cexpire&signature=8AD67D74F34FBAFBBA87616C0AED4A336DF0982A.129E2B5E648F8A2F35A34F312AC5C3C957A1C40A&key=lh1,35|http://v18.nonxt3.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=35&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333533157&sparams=id%2Citag%2Csource%2Cip%2Cipbits%2Cexpire&signature=7A58A11994C710872E945D0EAA6E43B6BFB8A648.B9C1D9FB377E1A49EBF3DC6C166C0B6E3E94EC24&key=lh1,34|http://v6.nonxt1.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=34&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333533157&sparams=id%2Citag%2Csource%2Cip%2Cipbits%2Cexpire&signature=260B10850A3448C849B8B8F1F2AF5E31244E71BC.6D7420FD66B85D40982BFB2C847EDB46021C63AE&key=lh1,5|http://v23.nonxt7.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=5&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333533157&sparams=id%2Citag%2Csource%2Cip%2Cipbits%2Cexpire&signature=9894DCDA7D2634EE0006CE0F6E0E29ABF7A8F253.18765D7CD7BDE80ED1A47DC8EC559C3E05C92F56&key=lh1
String 2
5|http://v23.nonxt7.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=5&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333562840&sparams=id,itag,source,ip,ipbits,expire&signature=C0E2993011931D9F5FCAFAF54E821415F6042DDD.477CD23B021563A6DE30E858E35C21046E0B0BA6&key=lh1,18|http://v11.nonxt4.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=18&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333562840&sparams=id,itag,source,ip,ipbits,expire&signature=696501A8ACBA0E1246173B040E0FB81DA8EBCDC7.944BA6C08C630EFFC2456D66BAD12376D7E377B2&key=lh1,34|http://v6.nonxt1.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=34&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333562840&sparams=id,itag,source,ip,ipbits,expire&signature=DDD3D9081F7F2FF462D17CFAE6CAB72AEB86DEA9.3275E0EE8921EF728132035FC94BEF5926A0B7C1&key=lh1,35|http://v18.nonxt3.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=35&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333562840&sparams=id,itag,source,ip,ipbits,expire&signature=7826E7470450F9F473BC7A845967EF3AC655CFB.3850F952F5D68151D325CD754C581CD66B0BC4D7&key=lh1,22|http://v17.nonxt1.googlevideo.com/videoplayback?id=0b608733ae5257c3&itag=22&source=picasa&ip=0.0.0.0&ipbits=0&expire=1333562840&sparams=id,itag,source,ip,ipbits,expire&signature=32FAAE6AE74B22BFB3DBD4300CEEDBC1A12A9ED4.8014678ABB1AEE93FB4B1C36E2C74C89102DC112&key=lh1
You URLS are quite different, and they also have a leading chars that I'm not sure you are wanting.
I have a WP7 project where I am using the below code. It normally works ok, but I am getting a strange result with some particular strings being passed through.
Service = "3q%23L3t41tGfXQDTaZMbn%23w%3D%3D?f"
NavigationService.Navigate(new Uri("/Details.xaml?service=" + Service, UriKind.Relative));
Next Page:
NavigationContext.QueryString.TryGetValue("service", out Service1);
Service1 now = 3q#L3t41tGfXQDTaZMbn#w==?f
Why has the string changed?
The string hasn't changed, but you're looking at it in two different ways.
The way to encode 3q#L3t41tGfXQDTaZMbn#w==?f for as URI content is as 3q%23L3t41tGfXQDTaZMbn%23w%3D%3D?f. (Actually, it's 3q%23L3t41tGfXQDTaZMbn%23w%3D%3D%3Ff but you get away with the ? near the end not being properly escaped to %3F in this context).
Your means of writing the string, expects to receive it escaped.
Your means of reading the string, returns it unescaped.
Things are working pretty much perfectly, really.
When you need to write the string again, then just escape it again:
Service = Uri.EscapeDataString(Service1);
In your first code snippet the string is URL Encoded.
In the 2nd code snippet, the string is URL Decoded.
They are essentially the same strings, just with encoding applied/removed.
For example: urlencoding # you get %23
For further reading check out this wikipedia article on encoding.
Since HttpUtility isn't part of WP7 Silverlight stack, I'd recommend using Uri.EscapeUriString to escape any URI's that have not been escaped.
You should probably URL encode the string if you want it to pass through unscathed.
I am writing a crawler for a website.
Its response is gzip encoded.
I am not able to parse correctly a particular field, though the decompression is successful.
I am also using htmlagilitypack to parse it,
the parsed value of the field is only a part of the original value
as an example :
I am getting only /wEWAwKc04vTCQKb86mzBwKln/PuCg==
whereas the firebug shows the actual value as much longer:
/wEWBgKj7IuJCgKb86mzBwKln/PuCgLT250qAtC0+8cMAvimiNYD
what does the '==' at the end means?
I am assuming it that its a error on decompressors behalf?
The character = is added by the Base64 encoding.
Encoding the following sentence
Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.
you would get
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
The = character can only be present at the end of the Base64 string. If you obtain it, it means you are probably getting all the characters; vice versa is not true, as that character is used as padding character, and it is not always mandatory in all the Base64 implementations.
You don't have a problem with decompression. The page has obviously been correctly decompressed. Otherwise your software would likely throw an error or you'd see just a bunch of strange characters.
However, what you get is an ASCII string that's obviously in Base 64 encoding. The equal signs at the end appear if the original binary data is not a multiple of 3 bytes. So that's all perfect Base 64 data.
As to why your crawler gets different data than Firefox with Firebug: I don't know but can image many reasons. These are two separate browsing sessions and the web site might just assign them different session IDs or somehow record some history of the session.
Anyhow, at the end of the day I don't understand your problem. What exactly are you unable to parse? Do you get some kind of error? What do you mean by field? Are you talking about a field of an HTML form?