Premise: The company interfaces with other companies need to use byte[] data stream transfer data
The original idea is as follows: Direct IO raw achievement OK
- Using System;
- Using System.IO;
- Using System.Text;
- Namespace StreamReader
- {
- Class Program
- {
- public static void Main (byte[] buffer)
- {
- System.IO.File.WriteAllBytes (@ "d:\ contract document Demo.pdf", buffer);
- }
- }
- }
But the resulting PDF won't open .....
In a way that is always more difficult than the idea that the IO generation may be problematic, the specific problem arises where no consideration is directly on the second method
Stream stream = new MemoryStream (buffer);
BinaryReader br = new BinaryReader (stream);
FileStream fs = File.create (@ "d:\ contract file Demo.pdf");
Fs. Write (buffer, 0, buffer. Length);
Br. Close ();
Fs. Close ();
The result is also a cool cool send yourself.
After thinking also didn't come up with a result. Generate byte[] data streams with your own PDF and then use both of these methods to generate a PDF that can be opened. Starting to wonder if the data stream is correct.
The original file to which the data flow was generated by the other party generates the byte[] data stream before and after a pair of data that has -8,-9 with '-' in the data stream found in Java is not generated by C #:
Baidu a wave of discovery Java's range of byte in [ -128,127] signed bit in C # byte range in [0,255] unsigned bit
The problem is that it was meant to be solved directly with a stupid method. And then continue to turn over a few articles found in C # sbyte range and the scope of Java is consistent haha
The result is that the HTTP request comes back with a sbyte receive using both of the above methods to generate a normal PDF file
Hole encountered in interface development--java Byte and C # byte data conversion problem