When I use HxD to modify a part of a file, it warns me about changing the size of the binary. What happens when you change the size of the exe file or other hex file that causes it to break?
Related
I open a pdf file "test.pdf" with Vim and copy its content to another text buffer that I save as "copy.pdf". I don't understand why "copy.pdf" is different, can be opened as a pdf (the title shows) but the page is empty.
The same happens when I read the file in Javascript with FileReader.readAsBinaryString and rewrite it to disk, so it is not related to how I copy in Vim.
Even more strange, the Finder says that the copy is actually 30KB bigger.
Where are the hidden bytes?
Usually when I see this sort of behavior and resulting blank pages, it is the result of using a program or process that is treating the binary information of a PDF as text in some form or another - for example, doing CR/LF conversion, tab to space conversion or interpreting the data as UTF-8 instead of binary. Doing any sort of transformation will ruin the binary streams within a PDF and will cause the offset bytes in the cross-reference table to become incorrect, causing the PDF to be unreadable.
Perhaps your process of writing back to disk doing CR/LF conversion or otherwise treating your binary blob as non-binary?
I've set the Default encoding for properties files to "ISO-8859-1" in my Intellij IDEA 2016.3, then I create properties files, but the file encoding is still UTF-8:
Any idea? Or should this be an issue?
Updates:
After changed the project and system default encoding to ISO-8859-1 and then create new properties file, it is still applied with UTF-8 encoding, and I can't manually change the properties file encoding while I do be able to change encoding for other files.
Updates:
I've created an issue on youtrack:
https://youtrack.jetbrains.com/issue/IDEA-165440
Today I faced exactly the same problem. I found a workaround to fix the affected properties files:
rename the file to txt; make sure the checkbox 'Rename bound resource bundle' is unchecked (e.g. locale-en.properties -> locale_en.txt)
go to -> File -> Settings -> File Encodings -> chose the renamed file in the file tree to the right
You are now able to chose the new encoding from the drop-down list (e.g. ISO-8859-1)
Choose 'OK' and then 'Convert' (confirm also the warning about characters that can't be converted, if a dialog shows up)
Rename the file back to it's original name (e.g. locale-en.properties)
If the dialog in step 4 showed up, make sure that you fix the characters which were not converted properly (in my case some of the German umlaut showed up as ? and had to be fixed manually)
Textmate does not allow open a file with characters in unknown encoding. For example, when a wrong encoding is selected, the Open button is disabled:
When a proper encoding is selected, the Open button is enabled:
Is there a c or Objective-C library for reporting characters encoded outside current encoding?
create .tm_properties file in your home dir, then put this code in it:
[ attr.file.unknown-encoding ]
encoding=gbk
this will set default encoding to gbk when Textmate 2 don't know file encoding.
also you can put this .tm_properties file in project root to use this setting within project only.
The usual approach is to load the text assuming a certain default encoding (like UTF-8/16 or latin 1). If there's a BOM at the start of the text then this is very good indication that the text is some form of Unicode. The BOM also helps to find what transformation format is used (UTF-8 etc.).
If loading the text still fails then it's time to ask the user for a hint (charset selection), because it's difficult to guess what the used encoding is.
I went to upload my ipa as I normaly do and after upload it via itunes I got this email
The binary being analyzed must be an executable: /tmp/mz_3482061619165087240dir/conbop-1377470196-1.ipa/Payload/device-ios.app/Forge
The file 'device-ios.app/Default-568h#2x~iphone.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default-568h#2x~iphone.png: JPEG image data, EXIF standard '
The file 'device-ios.app/Default-Landscape#2x~ipad.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default-Landscape#2x~ipad.png: JPEG image data, EXIF standard '
The file 'device-ios.app/Default-Portrait#2x~ipad.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default-Portrait#2x~ipad.png: JPEG image data, EXIF standard '
The file 'device-ios.app/Default-Portrait~ipad.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default-Portrait~ipad.png: JPEG image data, EXIF standard '
The file 'device-ios.app/Default#2x~iphone.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default#2x~iphone.png: JPEG image data, EXIF standard '
The file 'device-ios.app/Default~iphone.png' is labeled as a PNG file, but is not valid to that format; file command reports: './device-ios.app/Default~iphone.png: JPEG image data, EXIF standard '
Any help would be appreciated as to why itunes is kicking this back.
Thanks!
The image errors are because Apple require all the images are png files rather than jpgs, they appear to have recently become more strict about enforcing this which might be why you haven't had these problems before, you should be able to resave the files as png with an image editor.
I've not seen the binary is not an executable error before, I'd recommend trying again once you fix the image issues, if you still see that error it would be great if you could send your ipa file to support#trigger.io and we'll take a look at it.
I did have to change the images as well as do some other things with permissions. Connorhd explained in this post how to change the permissions for the time being.
The binary being analyzed must be an executable trigger.io
I'm working on an app that handles text files.
On the open dialog accessory view, when the user choses a file I want to display on a NSPopUpButton the supported encodings for the selected file, but so far the only way I could find to test if a file can be opened with a certain encoding is to actually trying to load it to a NSString.
Right now I'm doing this for each encoding:
NSString *fileContents = [NSString stringWithContentsOfURL:selectedURL encoding:encoding error:nil];
if (fileContents)
{
/* Add encoding to the list of supported encodings */
}
This loads the whole file to the fileContents object.
Is it possible possible to only test if the file can be loaded without actually loading it?
This is not possible to predict with 100% accuracy unless you read everything. For instance many encodings are supersets of ASCII and you'd be fooled if you stopped reading partway through a file; maybe the first paragraph just happens to contain nothing but ASCII and then 4 paragraphs later the file suddenly contains a bunch of mathematical equations.
A good middle ground is to support the conventions for specifying encodings that already exist. For instance text editors like vim and emacs specify a certain syntax for embedding encoding hints in the first few lines of a file, and HTML and XML files can contain <meta> tags with encoding information. If you can read those, it's fairly safe to assume they're correct and not read the entire file; otherwise, you do have to read the whole file to know for sure.
(An exception: certain Unicode encodings start with byte-order marks that are not used by any other encoding so you can assume those are what they say they are.)