Download File From Byte Array C .net Core WORK
Mitsue Cialella
I get 415 Unsupported Media Type error when testing from fiddler.Is this even possible in .net core webapi? I have searched for a while and there are no solutions for .net core. There are examples of BinaryMediaTypeFormatter which would not work with .net core webapi. If this is not possible with webapi then what is the best solution to accept a byte array in .net core web applications?
Update: I believe the client-side Byte[] retrieval can be accomplished via "HttpContent.ReadAsByteArrayAsync()" as shown here: Convert HttpContent into byte[]. I still am unsure as to how to send the raw (unserialized) Byte[] from the ASP.NET Core Web API side however.
As it can be noticed, "FileName", "FileExtension" and "File" (which is the forementioned byte array) are stored in a database. The attachment can be any kind of file, save for banned extensions in the Upload method (not shown). Then in my controller I have:
This is very important as the utility that this file eventually goes to is expecting the file in this format. What I've had to do is change this struct to a class in C#, but I cannot find a way to easily initialize each of these byte arrays to all space characters.
This works fine, but I'm sure there must be a simpler way to do this. When the array is set to UserCode = new byte[6] in the constructor the byte array gets automatically initialized to the default null values. Is there no way that I can make it become all spaces upon declaration, so that when I call my class' constructor that it is initialized straight away like this? Or some memset-like function?
Also, the array Length property is already passed as the parameter so it doesn't need to be retrieved from the array properties. It should also be pre-calculated and assigned to a local variable.Loop bounds calculations that involve a property accessor will re-compute the value of the bounds before each iteration of the loop.
using a pointer to a buffer, the length to write, and the encoded byte. I think the fastest way to do it in managed code (much slower), is to create a small block of initialized bytes, then use Buffer.Blockcopy to write them to the byte array in a loop. I threw this together but haven't tested it, but you get the idea:
The following example demonstrates the ToBase64String method. The input is divided into groups of three bytes (24 bits) each. Consequently, each group consists of four 6-bit numbers where each number ranges from decimal 0 to 63. In this example, there are 85 3-byte groups with one byte remaining. The first group consists of the hexadecimal values 00, 01, and 02, which yield four 6-bit values equal to decimal 0, 0, 4, and 2. Those four values correspond to the base-64 digits "A", "A", "E", and "C" at the beginning of the output.
The ToBase64String method is designed to process a single byte array that contains all the data to be encoded. To encode data from a stream, use the System.Security.Cryptography.ToBase64Transform class.
The following example uses the ToBase64String(Byte[]) method to convert a byte array to a UUencoded (base-64) string, and then calls the FromBase64String(String) method to restore the original byte array.
The following is a more complex example that creates a 20-element array of 32-bit integers. It then uses the BitConverter.GetBytes(Int32) method to convert each element into a byte array, which it stores in the appropriate position in a buffer by calling the Array.Copy(Array, Int32, Array, Int32, Int32) method. This buffer is then passed to the ToBase64String(Byte[]) method to create a UUencoded (base-64) string. It then calls the FromBase64String(String) method to decode the UUencoded string, and calls the BitConverter.ToInt32 method to convert each set of four bytes (the size of a 32-bit integer) to an integer. The output from the example shows that the original array has been successfully restored.
Ordinarily, the ToBase64String method is not used to round-trip a UUEncoded (base-64 encoded) string. That is, if you decode a string by calling the FromBase64String method, then encode the returned byte array by calling the ToBase64String method, the resulting string will not necessarily be identical to the original string. The string will round-trip only if the original string is a valid base-64 encoded string.
The following example calls the Convert.ToBase64String(Byte[], Base64FormattingOptions) with a Base64FormattingOptions.InsertLineBreaks argument to insert line breaks in the string that is produced by encoding a 100-element byte array.
If the options parameter is set to InsertLineBreaks and the output of the conversion is longer than 76 characters, a line break is inserted every 76 characters. A line break is defined as a carriage return character (U+000D) followed by a line feed character (U+000A). Because line breaks are considered white-space characters in a base-64 encoding, they are ignored when converting a base-64 encoded string back to a byte array. The line breaks are simply convenient when displaying the encoded string to a control or a device such as a console window. For more information, see RFC 2045, "Multipurpose Internet Mail Extensions", at -editor.org/.
I am working on a .net core application (case management system) which triggers a mailing service. The mailing service is not part of the application itself, it is a .net core API that connects to the application (by sending a json object).
So I am saving the PDF document to a memory stream, rather than a physical file location. I can then use the ToArray() function on the memory stream to give me my byte array. I personally then save this to my database as a VARBINARY.
UPDATE: Recent additions include support for GZIP and Deflate compression and decompression. This is based on byte arrays instead of strings to make it more versatile. Also, the string encoding is preserved inside a byte array.
This brings up an interesting problem, which stems from the frame size. The frame size appears in the structure before the actual payload does, which makes sense because we need the consumers of the protocol to know how many bytes are in the payload they are about to read. But, since our payload can contain all sorts of data as well as header properties, and data types are serialized differently, it's hard for us to know the size of the serialized payload before we have actually serialized all the data in the message.
So, what I decided to do, was to simply calculate how big each frame would need be at minimum when serialized, utilize System.Buffers.MemoryPool from the System.Memory NuGet packages to fetch a pooled byte array of the minimum size, and then serialize the data directly to that pooled array, write it to the network socket and eventually return the array to the pool to be reused later. This would allow the client to eliminate any memory churn when serializing the data since data would be serialized to reusable byte arrays.
One of the first things I noticed was that when strings were being serialized, they were converted directly to a UTF8 byte array. Obviously, this will create a new array to contain the UTF8 bytes. However, strings can also be serialized to an existing array and given an offset to where to start to write the bytes and we'll also know how many bytes are eventually written. This of course fit in extremely well with the pooled array idea.
As we have seen, the benefits of pooling and reusing arrays on code hot paths can be quite dramatic. This is mostly the result of freeing up our precious CPU cycles from being used by the Garbage Collector, cleaning up all our temporary objects. Having a garbage collector is one of the benefits of a managed language such as C#, but not having to use the Garbage Collector is even better.
After thinking about it for a while, I realized the the message payloads were being sent and received as byte arrays (byte[]). After talking it over the the RabbitMQ client maintainers, we decided that we'd make the change to have the message payloads represented as Memory instead. That allows us to use pooled arrays for messages received, copy the payload into another pooled array before being sent to the message event handlers, and then we could return them to the pool once the consumers had processed the messages!
I'm using a JavaScript image cropping plugin to provide the end-users the ability to crop images they upload on a Web App built on top of ASP.NET Core. The JavaScript cropping plugin is returning the image as base64 text, this is fine as in Html we can bind an image to a base64 string by setting the "src" attribute. However, in my case I need to convert this base64 image to byte array to save the binary in the SQL database then create the physical file of the cropped image.
df19127ead