Sorry for the Noob Question.
I have a library - RFM69 - https://github.com/LowPowerLab/RFM69
This provides the output as .DATA this appears to be a built in type?
Second I am trying send .DATA as a byte array but don't know what type it is in the first place. How can I find out.
Open the repository on GitHub. https://github.com/LowPowerLab/RFM69
Use the search field in the upper right ( with the in repository option) and search for ".DATA"
This will give you any file that contains it. Within seconds you'll find out that DATA is a member of the class RFM69 which is defined in the file RFM69.h
You got the full source code. All you have to do is search, read and understand parts of it to get any answer you need.
https://github.com/LowPowerLab/RFM69/blob/master/RFM69.h
static volatile uint8_t DATA[RF69_MAX_DATA_LEN]; // recv/xmit buf, including header & crc bytes
I'll leave the rest to you.
Related
I'm trying to decode the TCAP GSM messages and wanted to undertand few things on the ASN.1 struct for few of the elements.
Wanted to understand what does the values in the rectangle brace [] indicate? (shown highlighted in the image above).
Here is the link to the ETS standard which I'm using to extract this info.
look page at 773 for more details.
Any help in making me understand the same is aprreciated.
It's a TAG number. You can read more about encoding of a TAG value here.
If you look at the insertSubscriberData structure you have imsi, msisdn and category of the same type (OCTET STRING) and all are optional. TAG number is necessary tool to distinguish what value was encoded because sender will not encode the value if it is null. When the decoder gets binary data and has to reconstruct the insertSubscriberData structure it needs to know if it is reading imsi, msisdn or category. Based on the tag number it knows what part of the structure it is.
While decoding the arguments of MAP sequence, you access the child elements of sequence using the tag values but bear in the mind that they do not have to be sequential, optional tags might not have been set by encoded party.
e.g. sample code using bounty castle
DLSequence sequence = (DLSequence)derTaggedObject.getObject();
for(int i =0; i < sequence.size(); i++){
DERTaggedObject seqElement = (DERTaggedObject)sequence.getObjectAt(i);
switch (seqElement.getTagNo()) {
case MSCRecordType:
TCAP and MAP ASN.1 module definitions can be found on this github page.
I would like to know how to read arrayBuffer data (DICOM arrayBuffer) by using XTK library. I have already tried lots methods, but do not work.
I have found a solution.
http://jsfiddle.net/73av5041/3/
shows that volume.file can be a array of name files. Then put the arrayBuffer data into volume.filedata directly. Keep the number of files and the length of arrayBuffer same.
I have a stream (hooked to an azure blob) which contains strings and integers. The same stream is consumed by a .net process also.
In C# the writing and reading is done through the type specific methods of BinaryWriter and BinaryReader classes e,g., BinaryWriter.Write("path1;path2") and BinaryReader.ReadString().
In Java, I couldn't find the relevant libraries to achieve the same. Most of the InputStream methods are capable of reading the whole line of the string.
If there are such libraries in Java, please share with me.
Most of the InputStream methods are capable of reading the whole line of the string.
None of the InputStream methods is capable of doing that.
What you're looking for is DataInputStreamand DataOutputStream.
If you are trying to read in data generated from BinaryWriter in C# you are going to have to mess with this on the bit level. The data you actually want is prefixed with an integer to show the length of the data. You can read about how the prefix is generated here:
C# BinaryWriter length prefix - UTF7 encoding
It's worth mentioning that from what I tested the length is written backwards. In my case the first two bytes of the file were 0xA0 0x54 convert this to binary to get 10100000 01010100. The first byte here starts with a 1 so it is not the last byte. The second byte starts with a 0 however so it is the last (or in this case first byte) for the length. So the resulting length prefix is 1010100 (taken from the last byte removing the indicator that it is the last byte) Then all previous bytes 0100000 which gives us the result of 10101000100000 or 10784 bytes. The file I was dealing with was 10786 bytes so with the two byte prefix indicating the length this is correct.
I tried on Flex 3, facing issue with uploading JPG/PNG image, trace readUTFBytes would return correct bytes length but tmpFileContent is trucated, it would only appear to have upload just 3 characters of data to the server through PHP script which made image unusable. I have no issue for non-images format. What is wrong here?
var tmpFileContent:String = fileRef.data.readUTFBytes(fileRef.data.length);
Is String capable of handle bytes?
I'm not sure what you're looking to do with the image, but you might want to read this:
http://livedocs.adobe.com/flex/3/html/help.html?content=Filesystem_15.html
You may also need a image encoder such as the JPEGEncoder: http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/mx/graphics/codec/JPEGEncoder.html
You could always encode using base64:
var enc:Base64Encoder = new Base64Encoder();
enc.encodeBytes(fileRef.data);
var base64data:String = enc.drain();
The method used in the tutorial is not going to work safely for anything but text files. An arbitrary binary format is likely to contain zeros. A zero (a byte whose value is 0) is generally considered a string terminator in many languages / platforms. This is also the case in Actionscript as this code shows:
var str:String = "abc\x00def";
trace(str);
The string will be truncated to "abc", since 0x00 is considered to mark the end of a string.
I think your best bet is to encode the content to base 64 as maclema suggested. From the php side, decode it back before writting the file with something like:
file_put_contents($myFilePath, base64_decode($fileData["filedata"]));
Also, I can't remember if file_put_contents is binary safe (I think it's not). If that's the case, you should use fopen('you_path',"wb"), fwrite() and fclose() to write the file. Notice the "b" in "wb", which stands for binary. If you don't pass that flag you'll probably have problems with some characters (newline and carriage return, for example).
Added:
Perhaps, following davr suggestion, you could try sending the data ByteArray to see if AMFPHP handles it correctly.
Php does allow embbeded Nuls in strings as this code shows:
$str = "a\x00b";
var_dump(ord($str{0})); // 97
var_dump(ord($str{1})); // 0
var_dump(ord($str{2})); // 98
So, if AMFPHP converts the bytearray to a string and does not mangle it in the process, this could actually work.
// method saves files on the server
function uploadFiles($fileData) {
// new file path an name
// to not overwrite the files we add the microtime before the file name
$myFilePath = '../../_uploads/'.
preg_replace("/[^0-9]+/","_",microtime()).'_'.$fileData["filename"];
// writing on the disk
$fp = fopen($myFilePath,"wb");
if($fp) {
fwrite($fp,$fileData["filedata"]);
fclose($fp);
}
// returning response - is not used anywhere
return true;
}
Otherwise, try echoing var_dump($fileData['filedata']) to see what the actual type AMFPHP is converting the data to (perhaps it uses an array, not sure; given how strings work in php (much like a buffer of single byte characters, though, I think it could be just using strings).
How do you go about verifying the type of an uploaded file reliably without using the extension? I'm guessing that you have to examine the header / read some of the bytes, but I really have no idea how to go about it. Im using c# and asp.net.
Thanks for any advice.
ok, so from the above links I now know that I am looking for 'ff d8 ff e0' to positively identify a .jpg file for example.
In my code I can read the first twenty bytes no problem:
FileStream fs = File.Open(filePath, FileMode.Open);
Byte[] b = new byte[20];
fs.Read(b, 0, 20);
so (and please excuse my total inexperience here) but how do I check whether the byte array contains 'ff d8 ff e0'?
Here's a quick-and-dirty response to the followup question you posted:
byte[] jpg = new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 };
bool match = true;
for (int i = 0; i < jpg.Length; i++)
{
if (jpg[i] != b[i])
{
match = false;
break;
}
}
That indeed is what the Unix file program does, with greater or lesser degrees of reliability. In part, it depends on whether the programs whose files you are trying to detect emits a file header; the program tar is notorious for not doing so. It depends on how many types of files you plan to try and recognize, but it might well be simplest to use an implementation of file; it recognizes many file types, and modern versions are extensible via a file of extra file type definitions that can handle a multitude of scenarios.
Wotsit is a good resource for finding out the magic numbers for various file types.
Edit: link is broken. Here’s a better resource that is still being updated
https://www.garykessler.net/library/file_sigs.html
The first few bytes of a file will often tell you the file type. See, for example,
http://www.garykessler.net/library/file_sigs.html
http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Use System.IO to read the byes as binary after the upload.
I'm curious, though, why you can't rely on on the ContentType header?
Reading the contents of the file is the fool proof way. Since you are building it in .Net, you could probably check the MIME Type of the uploaded file.
You can DllImport urlmon.dll to help. Please refer a post at:
http://coding-passion.blogspot.com/2008/11/validating-file-type.html
And to clarify regarding Content-type, it invariably is driven by the extension of the file. So even a .zip file got its extension renamed to .txt, the content type will still say Text only.