How can I make my fstream read online .txt file in my file server? I always get an error opening the file, can it not be read online?
Here's my sample code for this:
if stream infile;
infile.open("https://script-autopot.000webhostapp.com/license.txt");
if (infile.fail()) {
cout << "Error Opening File";
system("pause");
}
Basically, it's not possible in the way you think. In C++, fstream is a file stream. It's used for working with files. What you probably were thinking of is a "stream" for "data from the network", and that could be achieved with the base i/o stream classes, but not with the fstream. However, if you wrote it, or found a library that does it this way, the 'stream' would only be the final last object you'd interact with, and there'd be more factory classes before that, because setting up network/passwords/headers/certificates/younameit for all the HTTP/S/1/2/3 can get pretty complex. Much more complex than simple "here's the URL".
So.. maybe take a look at good old https://curl.haxx.se/libcurl/c/example.html?
Or newer things like https://github.com/yhirose/cpp-httplib?
I suppose you could find a few like this by googling "C++ https client".
Finally, if you're really bound to use fstream, then yes, there's a "everything is a file" saying in linux/unix terminology. You could technically open a wget-like process, bind its inputs/outputs to a file-based named-pipe, then open that file with a fstream and read/write from it like from a file.
Related
Diagrams.net, previously and still more widely known as draw.io, is a popular tool for drawing diagrams of various kinds. It stores diagrams in an XML-based format that uses the file ending .drawio. The file content has the structure:
<mxfile {...}>
<diagram {...}>
{the-actual-diagram-content}
</diagram>
</mxfile>`
According to the documentation page Extracting the XML from mxfiles, the string {the-actual-diagram-content} contains the actual diagram data in compressed format, "compressed with the standard deflate process". I'd like to decompress this data in my node.js app to parse and modify it.
I have found an older, similar question on StackOverflow, which wants the same, but uses the libraries "atob", and later "pako". I'd like to achieve the same with the more standard "zlib" node.js module, which - if this is really "the standard deflate process" - should be possible.
However, all my attempts to "inflate" the compressed string fail. I have mostly tried variations of the following code, with different encodings ('base64', 'utf8') and methods ('inflateSync', 'unzipSync', 'gunzipSync'):
zlib.inflateSync(Buffer.from(string, 'base64')).toString();
All attempts fail with the error "Error: incorrect header check". I read this as "dude, seriously, you're using the wrong unzip algorithm for this". However, I cannot figure out what the right algorithm or settings are.
The sample string I'd like to decode is the following. Using the jgraph inflate/deflate tool, this uncompresses perfectly fine. However, the settings done there, "URL Encode", "Deflate", "Base64" sound to me exactly like what I am trying.
zVdbk6I6EP41Vp3z4BYXL/Ao3nV0VEYZfQsQITOBIEQu/voNAgrqrHtOzVbti5X+0t0kX/eXxJrYdeKhDzx7RkyIawJnxjWxVxOEZktmvymQZIAoNzLA8pGZQfwVUNEJ5iCXo0dkwqDiSAnBFHlV0CCuCw1awYDvk6jqtie4+lUPWPAOUA2A71ENmdTOUKnJXfERRJZdfJnn8hkHFM45ENjAJFEJEvs1sesTQrORE3chTrkreMniBl/MXhbmQ5f+TkCXT0gX48NHW1CSsVHXjta0nmcJAT7mG+7kq6VJQYFPjq4J0yxcTVQiG1GoesBIZyNWc4bZ1MHM4tkwoD75vFDFNqnkX4A+hfGXS+cvhLBGgsSB1E+YSxHQyjlMbuzoWhK+4NkulaPwA3kXWJfUV6LYIOfqP/Am3PGm/IW8ia3mX8abeMebSdIYesceNJkOcxNinUT9K6CcATaRsoOYWM8EAp92UsUz3CXu2c01b5AS42xygNLVn8sDMLJcNjYYtdBnAAY6xAowPq1zHbsEE/+ap1pbFuMn72Vjmxo/moXZi8uTvaSwYkTfi+WwcSmKWdeg1ChiMqJSdn7dFIxMcvQN+Fz8jDgL0mfN/mWT1bkfXFNqVxqtXjSVDzGgKKyu9VFX5ekXBLFdXHIL0o3wpZvGzPaYR5UPv5tEolhNJIg3iTISfpGocCT7fQArPmchXHj5/9po3GnjXhQYs4sPPj9OQOBlt+EexWmbPjhffEIBBfo5ddpY+Q1aQthVDsv2b51IX8v+voNKx9CjU+ibmqjOV2t/sf98SZvPS8qeBV46DCh0DYT/CTfzlR7MrF5PmC8SIz5MdfnN4UVrzlmdlql4q46i66/m3uq7mtdTvZ3jrFQ0Zp9S4EjXoqUgK+uX5cTtbS3TmDV36a4E5bhgxA0mW3u1w5PpSRuph+6SIW9HNIC0cewe9e0cxsJyA4VOe8v2qyznChq33wP8Ee3DE97iYWvIqXY74k/4oIKDGQta/LnmY9WBRjsaAaN90jSwWrNYHIZr5vGxZt8eeMTHLyCQArwGfZ2OY3Uh0tZouLKlYLya0FVfjjZyM3ZM5VVDn6d4ISvcECB5rYSOOEpCJA90I54dtp0X7Mubo77bACKoZiNgz0vFOxmKLr3tk7QLlNZorbYnQ6HhBtPe20Hy2QJUcR8vwlktvaUHvPc+VDYn1yFm0kY4lJfSXBxN9d3rsKmpO3VuyWa4kLr/PpfZQ9kAjEnUKd6e3I3U+MJGJL1v6vL5hDdROQOMPeAWl8udlP+kDMUHMhS/S4bVx0i98Q0yZOb1BZ25X/+GiP2f
What am I doing wrong?
Use zlib.inflateRawSync(). What you have there is a raw deflate stream, not a zlib stream.
I have just started to get back into c++ after years using Perl, php and assembler and I am trying to create a simple MFC program using Visual Studio 2017 and c++ to open binary files for viewing. I am trying to work within the code created by the wizard and I have gotten stumped. I know this is probably not the best way of doing what I want to do but I am learning.
Anyways the code I am working on is:
void CAdamImageManagerDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
// TODO: add storing code here
}
else
{
// TODO: add loading code here
char documentBuffer[1000];
ar.Read(documentBuffer, 1000);
AfxMessageBox((LPCTSTR)documentBuffer);
}
}
This is called after you select a file using the standard mfc file open dialog box OnFileOpen. What I am trying to figure out is:
how can I know what the size is of the file that was referenced in the call?
how can I find out what the name of the file referenced is?
This is my first question on here in almost 10 years so please be gentle and not tell me how I didn't format the question properly or other things.
Use ar.GetFile()->GetFilePath() to get the complete file path to the file (reference)
Use ar.GetFile()->GetLength() to get the file size. (reference)
In general you decode the stream of a CArchive in the reverse ways like you write it.
So in most cases there is no need to know the size of the file. Serializing n elements is mostly done using CObList or CObArray or you just write the size of a data block into the archive followed by the BYTEs. The same way you may decode the stream.
if (ar.IsStoring())
{
DWORD dwSize = m_lenData;
ar << dwSize;
ar.Write(documentBuffer, dwSize);
}
else
{
DWORD dwSize;
ar >> dwSize;
ar.Read(documentBuffer, dwSize);
}
If you look at the MFC code how a CString is serialized or how a CObArray is serialized you find the same way.
Note that in this case the file turns into a binary file. And is no longer just "text".
So I have a use case where the client uploads a small TSV file, the file is opened and parsed on the server, and results are written to a new file on the server.
Since the TSV file will be tiny (under 1 MB), I am wondering if it is even necessary to upload the file to the server (writing it to disk) before parsing it. Instead, could the file contents be captured when the user clicks "upload file"? I could then store the file contents in an array, each item representing a line in the file.
Thoughts?
You don't need to stream the file to disk, but be aware that you should set clear and concise limits so that a person could not, say, upload a 5GB file and make your service crash from memory exhaustion. You just need to be aware that you're limited to your available amount of memory(likely less) when you process something completely in memory. It's also possible to stream parse it, so that you don't need to save it to disk before parsing it. In your case it sounds easiest to just upload it into memory, and make certain that you put a limit(maybe like 5mb limit) on the upload file size.
Are you asking whether this option is feasible or whether it's a good idea?
Regarding feasibility, it is entirely possible using the FileReader API to parse the content and then a simple Meteor.call onto whatever method is appending to the file on disk. The code would like like follows:
function onSubmit(event, template) {
var file = template.$('.your-file-input-elemt').files[0];
var filereader = new FileReader();
filereader.onload = function(fileevent) {
Meteor.call('processTSV', filereader.readAsText(file));
};
}
If you're talking about whether it's a good idea, then it comes down to browser support. Are you okay with users without the FileReader API not getting support from your application? If so it's considerably easier to deal with than handling uploads with something like CollectionFS.
Dear Stack Overflow users,
I would appreciate you kind help with the following problem:
We have an Apache server functioning as a forward proxy, with ext_filter configured: whenever the response is of MIME type PDF, the filter is called (a perl script), and the PDF's content may be read from the STDIN. We read the PDF from STDIN, write it to a file and that's all. This almost always work well, but on one specific website, the PDF is malformed when written in the following way:
my $input_file = shift;
binmode STDIN;
open(OUT, ">" . $input_file);
binmode OUT;
foreach my $line (<STDIN>){
print OUT $line;
}
close OUT;
If we instead call 'tee' (set the filter to use 'tee')- the file is written correctly. Analyzing the malformed PDF shows that the xref table is malformed in the PDF we write and Adobe Reader fails to open it. We have already tried using sysopen,sysread etc. , using ":raw", and several other ways to write a binary file properly, and nothing worked (cut&paste code from documnetation for writing binary files). Only when using the 'tee' utility in linux as the filter, it was written correctly. This doesn't help us- we need to be able to write it to a file from stdin as part of the perl script. Any suggestions? If there could be a way to somehow call 'tee' with a system call, and give it STDIN of the perl program- it might could work. Many thanks in advance.
Well, although the code was basiclly correct, putting it inside "eval" somehow ruined thd PDF.
I still don't understand why, but deleting the eval solved the problem.
The perl is called from a context of ext_filter module of Apache.
I'll farther investigate this and update when I'll find an explanation for this.
Thanks for everyone.
I hope my Q was clear ... I am curious about the typical way to code for someone clicking File|Open, and selecting a file that is inappropriate for the program--like someone using a word processing program and trying to open a binary file.
In my case, my files have multiple streams streamed together. I'm unsure how to have the code validate whether an improper file was selected before the app throws a stream read exception. (Or is the way to handle the situation to just write code to catch a stream read exception?)
Thanks, as always.
I think it's quite usual that you have code that just tries to open the file, and if it fails, an error is shown to the user. Most file formats has some kind of header with a "magic number", so that the reader can tell if it's not the right file very quickly after reading the first few bytes of the file.
Magic number at the start of the file generally helps -- if you have control of the file format.
Otherwise, yeah -- catch the exception and put up a dialog.