As stated in the topic, I am deflating data in my iOS and Android app respectively. The result generated happens to be mostly identical, except that the headers are different.
In iOS, the header is
1f8b0800000000000003
while on Android, the header is
1f8b0800000000000000
Other than this, the remaining parts are identical, I tried to search with both header string but only found results that stating both of them are gzip headers. What are their differences and what would be the possible reason causing them?
Thanks!
GZIP format spec (RFC 1952) says that GZIP member header stores the OS on which the conversion took place, with the intent of describing the filesystem. That's field OS here
http://www.zlib.org/rfc-gzip.html#header-trailer
+---+---+---+---+---+---+---+---+---+---+
|ID1|ID2|CM |FLG| MTIME |XFL|OS | (more-->)
+---+---+---+---+---+---+---+---+---+---+
which matches the position in which you observe the difference.
0 stands for OS with FAT filesystem, 3 stands for Unix.
Granted, trying to identify filesystem through identifying OS does not sound like a good idea today, but that's the way it was originally designed.
Related
Please tell me the differences with/without header files during the cppcheck's analysis.
Actually i am integrating cppcheck's report with sonar, will sonar's dashboard will contain any differences?
After including header files, it took 5 days(approx) complete the analysis, even though i used -j 4 and max-config to 2 options.
And confused that, the LOC has reduced after including header files for analysis. and i could see the functions , classes are reduced to few numbers.
Does cppcheck errors on header files? if yes, what rules are applied on it? where can i find this info, thw rules that are associated with header files?
Please help.
thanks,
Dinesh
I am a Cppcheck developer.
It's not a technically trivial question if you should include headers or not. There are both benefits and drawbacks with headers for the analysis. Better type information is a good thing. Expanding macros might be a bad thing.
In case you wonder; the same checkers will be used no matter if headers are included or not. It's just that the input data is not always better when all headers are included.
I certainly recommend that you don't include any standard headers. stdio,string,stl,etc.
I personally normally don't include various system headers. I would prefer to create a cfg file instead if I use a library. That will give Cppcheck better information about the library than the headers.
I normally try to include local headers in the project. Use -I to add good paths in the project.
We're using Amazon S3 to store and serve images, videos, etc. When uploading this content we also always set the correct content-type (image/jpeg, etc.).
My question is this: Is a file extension required (or recommended) with this sort of setup? In other words, will I potentially run into any problems by naming an image "example" versus "example.jpg"?
I haven't seen any issues with doing this in my tests, but wanted to make sure there are any exceptions that I may be missing.
Extensions are just a means by which OS decides the operating program. As far as your scenario is concerned, as long as the content-type specifies the type, the extension doesn't matter. But why in the world, would you name a jpg file as .txt right ?
Regards
I'm creating an app based on a API server. The server is currently in UTF-8 encoding.
Rather than write a line of code every time the API is accessed to re-encode text, I thought I may as well just set the server API to have the same text encoding as the app.
Only problem is I can't find out the default encoding!
Where would I find this information, and can I change the default encoding on the app?
Cheers!
There is no default encoding. NSString can have various encodings internally.
I know that on Mac OS X, ASCII, UTF-8 and UTF-16 w/ host byte order are always among possible internal representations, iOS shouldn't be different, though I'm not totally sure. I think it's safe to assume that stringWithUTF8String: will not cause any extra re-encoding.
NSString's static method will do the job
+ (NSStringEncoding)defaultCStringEncoding;
We are building a REST API and we want to return the same object, but one call is a 'light' version (without all the field)
what is the best practice ?
1st case
full version: http://api.domain.com/myobject/{objectId}
light version: http://api.domain.com/myobject/{objectId}?filter=light
2nd case
full version: http://api.domain.com/myobject/{objectId}/details
light version: http://api.domain.com/myobject/{objectId}
3rd case
full version: http://api.domain.com/myobject/{objectId}?full=true
light version: http://api.domain.com/myobject/{objectId}
4th case ?
Any link to a documented resource of a REST API is welcome !
Thanks.
This should be handled through content negotiation, that's what its for. Content negotiation is how a client can request which representation of the resource it wants to see. Consider the case of a picture: image/x-canon-cr2, image/jpeg, image/png.
Ostensibly all the same image, but in different formats.
So, this is the mechanism you really want to use for a "lite" version of your resource. For example you could use:
"application/xhtml+xml" for the main version
"application/xhtml+xml; lite" for the for the light weight version
So, for a full resource:
GET /resource
Accept: application/xhtml+xml
For a light version
GET /resource
Accept: application/xhtml+xml; lite
For either, but preferring the lite version:
GET /resource
Accept: application/xhtml+xml;lite, application/xhtml+xml
(the more specific specifier, i.e. the one with ;lite, has higher priority over the normal applciation/xhtml+xml.)
If you will take either, but prefer the full version:
GET /resource
Accept: application/xhtml+xml;lite;q=0.1, application/xhtml+xml
Those without a quality factor default to 1.0, so 0.1 is less than 1.0 and you will get the full version if available over the lite version.
Addenda:
The q factor on Accept is effectively used to show the preferences of the client. It is used to prioritize the list of media types that the client accepts. It says "I can handle these media types, but I prefer a over and b over c".
A JPEG vs a PNG is no different than the lite vs full version. The fact that a JPEG looks anything like the original PNG is an optical illusion, the data is far different, and they have different uses. A JPEG is not "lower quality", it's different data. It's "missing fields". If I want, say, the image size, the JPEG will give me that information just as well as a PNG would. In that case, it's quality is adequate for the task. If it wasn't adequate, then I shouldn't be requesting it.
I can guarantee that if I have a client that can only process PNG and ask for a JPEG, then that program will not "work equally well" with it. If my son wants Chicken Fingers and I give him Cream of Spinach, there are going to be issues, even though both of those are representations of the the resource /dinner.
The "application/xhtml+xml;lite" representation is just that -- a representation, it is NOT the resource itself. That's why the word representation is used. The representations are all simply projections from the actual resource, which is some virtual entity on the server realized internally in some undefined way.
Some representations are normative, some are not.
Representations are manifested through media types, and media types are handled via Con-neg and the ACCEPT header. If you can't handle a representation, then don't ask for it.
This is a con-neg problem.
I don't know what a "media player" has to do with this discussion.
The 1st case and 3rd case have the advantage that one url is used for a single resource and the query string is used to request a particular view of that resource. Choosing between them is a matter of taste, but I tend to prefer a default of getting all the data and saving the options for viewing subsets.
I need to rewrite a QuickTime reference movie, making it point to another set of files.
I'm working in Windows environment, so I don't have acces to the QuickTime API, and being the referenced files unaccesible, I can't also use the COM interface to load the movie because it can't resolve the referenced paths.
The documentation in the "QuickTime File Format Specification" says that the 'dref' atom can have a list of 'alis', 'url ' and 'rsrc' data references. In this case I need to parse the 'alis' elements. According to the reference, "Data reference is a Macintosh alias".
So long, I have not been able to see a declaration of the structure or any related information. Do you know the structure of an alias record? Where can I find detailed information about it's structure?
Thank you a lot for your help!
The format is very similar to the sort of alias that you could generate in the Finder by right-clicking an item, and creating an alias to it.
Aside: When the QuickTime format was originally specified, Apple intelligently chose to incorporate a number of other standards and paradigms that were extensively already being used elsewhere in the OS. This is one of the reasons why QT is (or was) able to do really clever things like reference movies. Unfortunately, there's also now a lot of cruft leftover from OS features that are no longer relevant (ie. AppleShare). Back in its heyday, QuickTime was slick, especially compared to its competitors; today, it's vastly underappreciated due to the buggy Windows port, and the relatively low processing power of the desktop systems of its time.
Back ontopic, unfortunately, the format for alias files is not an open/published standard, and there is precious little documentation on the topic on the 'net. There's one really old doc that deconstructs the alias format used in Mac OS Classic. Although the structure used in OS X is very similar, the alias files themselves tend to be much larger, as they contain numerous extra data strings at the end of the file that are not documented in the above-linked documentation.
Also, aliases created in the finder do look a bit different from the ones contained within the dref atom, although I've never run through them bit-by-bit to deduce the actual differences. If you want to take a peek at what those files, and have the OS X Developer Tools installed, you can run
setfile -a a [filename]
on a Finder-generated alias to strip the file of its alias-ness so that you can look at its contents in a hex editor (otherwise, the OS will just redirect you to the linked file - doh!). You can re-set the file's alias attribute, or arbitrarily designate any file as an alias by running
setfile -a A [filename]
Unfortunately, during my experiments, dumping the alis portion of a QT movie's dref atom has never seemed to generate an alias that Mac OS was able to interpret.
Fortunately (or not, as it was in my case), the functions that Mac OS allegedly uses to create/handle aliases are part of a public API called the Alias Manager, which is part of the very-low-level CoreServices framework. If you've got time to delve into this further, you can write some code to experiment with Mac OS's built-in alias-generating and interpreting capabilities.
Unfortunately, if you're dealing with an old/buggy file, you have no way of knowing if the file was actually generated by CoreServices' Alias Manager, or if that framework has changed/evolved/regressed since then. Because it's a closed format, 3rd-party developers who opt to not use the Alias Manager can only take guesses as to the format's "legal" structure.
You can use this Java program to see what is in the header, and extract data (it's a bit old, but may still work). What is more useful, though, is the thorough discussion by the author about the Quicktime header.
But I think you may just be looking for the Apple documentation, currently found here.