This PNG file can not be uploaded from my app to a 3d-party server. It always reports this error:
does multipart has image?
I'm sure multipart encoding is correct. Tens of thousands of images are uploaded from my app without this issue. It it the first time.
I guess there is something special about this PNG file and I proved it:
Dropbox iOS app can not display the image.
Tweetbot can not upload it. The error message is "media type unrecognized".
So this PNG file is indeed special and quite some apps and servers don't handle it properly. But I don't know what's so special about it and hope someone who know PNG better than me can help. Thanks.
It is a CgBI file, not a PNG, most likely made with Apple's rogue modified pngcrush.
Such files always contain "CgBI" in bytes 12-15, where "IHDR" belongs.
CgBI files can be converted to valid PNG files (except that the transparent areas are irreparably damaged) by several applications, including
Jongware's pngdefry
Apple's "pngcrush" (but not the real pngcrush)
others listed on the above-referenced CgBI wiki page
Here are the first few bytes in your file:
$ od -c test.png | head -4
0000000 211 P N G \r \n 032 \n \0 \0 \0 004 C g B I
0000020 P \0 002 + 325 263 177 \0 \0 \0 \r I H D R
0000040 \0 \0 \0 ` \0 \0 \0 ` \b 006 \0 \0 \0 342 230 w
0000060 8 \0 \0 \0 c H R M \0 \0 z % \0 \0 200
Those bytes represent the following:
PNG signature 0-7
CgBI length 8-11
"CgBI" 12-15
CgBI data 16-19
CgBI CRC 20-23
IHDR length 24-27 (should be in 8-11)
"IHDR" 28-31 (should be in 12-15)
width 32-35 (should be in 16-19)
height 36-39 (should be in 20-23)
bit depth 40 (should be in 24)
color type 41 (should be in 25)
compression 42 (should be in 26)
filter method 43 (should be in 27)
interlace method 44 (should be in 28)
IHDR CRC 45-48 (should be in 29-32)
...
Related
I know that printf(%08x) shows 4 octets of the stack (410484e4 for instance). Let's say that this value correspond to the begining of a char array (called tab), so what would be the value of tab[0], would it be 08 ('A' converted in ASCII) or e4 (ä) ?
Thank you
p.s: the executable I'm working on is an ELF 32 binary
I am trying to print to a ESC/POS compatible printer and am struggling to get my head around GS v 0. I have just connected from a Mac and sending commands is hex via CoolTerm.
The docs say ...
GS v 0 m xL xH yL yH d1....dk
-----------------------------------------------------
[Name] Print raster bit image
[Format] ASCII GS v 0 m xL xH yL yH d1....dk
Hex 1D 76 30 m xL xH yL yH d1....dk
Decimal 29 118 48 m xL xH yL yH d1....dk
[Range] 0≤xL≤48, xH=0; 0≤yL≤255, yH=0; 0≤d≤255
k=(xL+xH×256)×(yL+yH×256)(k≠0)
[Description] Selects Raster bit-image mode. The value of m selects the mode, as follows:
+------+------------+----------------------------+---------------------------+
| m | MODE | Vertical Dot Density | Horizontal Dot density |
+------+------------+----------------------------+---------------------------+
|0, 48 | Normal | 200 DPI | 200 DPI |
+------+------------+----------------------------+---------------------------+
|1, 49 |Double-width| 200 DPI | 100 DPI |
+------+-------------+---------------------------+---------------------------+
|2, 50 |Double-height| 100 DPI | 200 DPI |
+------+-------------+---------------------------+---------------------------+
|3, 51 | Quadruple | 100 DPI | 100 DPI |
+------+-------------+---------------------------+---------------------------+
• xL, xH, select the number of data bits ( xL+ xH × 256) in the horizontal direction for the bit image.
• yL, yH, select the number of data bits ( yL+ yH × 256) in the vertical direction for the bit image.
• This command has no effect in all print modes (character size, emphasized, double-strike, upside-down, underline, white/black reverse printing, etc.) for raster bit image.
• The part of bit image that exceeds the printable area will not be printed.
• d indicates the bit-image data. Set time a bit to 1 prints a dot and setting it to 0 does not print a dot.
So from this I deduce I need to send the following in HEX
1D 76 30 30 20 00 00 01
Does the image data now follow this, and do I have to send a message saying the image has ended?
I remember there is <ESC>K (not GS) command to print 8 lines of pixels. See ESC commands for details. After K must be sent 2 bytes - number of data bytes and the real data. But it is not guaranteed whether every printer will support this. What is the brand and model of your?
The docs say:
Hex 1D 76 30 m xL xH yL yH d1....dk
with m being 0x48..0x51, so you can't send
1D 76 30 30 20 00 00 01
but rather, for instance
1D 76 30 48 20 00 00 01
I don't think it makes much sense that xH and yL are 0.
I am trying to extract the text of page 5 in pdf.
The pdf have a font YLJAAA+CMSY10 which has no mappings (CMap) or even encodings (default encoding or /Differences). While extracting text, after string "tetex package" CGPDFScanner returns "\x15" character which is encountered many times. When this character is encountered current font is the above mentioned font which has nothing to extract the text from pdf string.
What is this \x15 character?
Thanks.
I found 2 (not "many") occurrences of this:
[ (\025) ] TJ
which is a number in octal – this is the number that is \x15 in hexadecimal.
The font definition for "YLJAA+CMSY10" in the PDF carries no special encoding, so it has the default encoding for "CMSY" ("Computer Modern Symbol"):
114 0 obj
<<
/Type /Font
/Subtype /Type1
/BaseFont 210 0 R % -> "/YLJAAA+CMSY10"
/FirstChar 0
/FontDescriptor 211 0 R
/LastChar 127
/Widths 204 0 R
>>
211 0 obj
<<
/Ascent 750
/CapHeight 683
/CharSet (/bullet/greaterequal/arrowright/arrowdblright/element/negationslash/backslash/radical)
/Descent 0
/Flags 4
/FontBBox [ -29 -960 1116 775 ]
/FontFile 205 0 R
/FontName 210 0 R % -> '/YLJAAA+CMSY10'
/ItalicAngle -14
/StemV 85
/XHeight 430
>>
endobj
In itself, this still says nothing definitive: a PDF producer may reorder glyphs and encodings at will, as long as it does the same with the embedded font). Assuming the font set is not reordered, checking a random list of CMxx encodings shows that the character code 0x1F could well be GREATER-THAN OR EQUAL TO (Unicode U+2265).
Acrobat agrees; inspecting the font in the PDF shows that character code 21 (decimal) is named 'GREATER-THAN OR EQUAL' and looks like it as well.
I'm having troubles decoding/encoding a base64 string because of the CRLF on it.
I've tried this lib Base64.h and this one NSData+Base64.h but both do not handle well the CRLF.
Anyone had this problem before?
Anyone has an advice on how to avoid these CRLF? I think Android's Java lib is replacing this with a '0', am I correct?
public static final int CRLF = 4;
Base64 encodes 64 characters, namely 'A-Za-z0-9+/' with a possible trailing '=' to indicate a non mod 3 length. CR+LF may be used as a line separator, generally decode each line separately.
See Wikipedia Base64 for more information on CR+LF variants.
"+vqbiP7s3oe7/puJ8v2a3fOYnf3vmpap"
decoded is:
"FA FA 9B 88 FE EC DE 87 BB FE 9B 89 F2 FD 9A DD F3 98 9D FD EF 9A 96 A9"
The last character is not 0.
I am confused as to how memory is stored when declaring variables in assembly language. I have this block of sample code:
val1 db 1,2
val2 dw 1,2
val3 db '12'
From my study guide, it says that the total number of bytes required in memory to store the data declared by these three data definitions is 8 bytes (in decimal). How do I go about calculating this?
It also says that the offset into the data segment of val3 is 6 bytes and the hex byte at offset 5 is 00. I'm lost as to how to calculate these bytes and offsets.
Also, reading val1 into memory will produce 0102 but reading val3 into memory produces 3132. Are apostrophes represented by the 3 or where does it come from? How would val2 be read into memory?
You have two bytes, 0x01 and 0x02. That's two bytes so far.
Then you have two words, 0x0001 and 0x0002. That's another four bytes, making six to date.
The you have two more bytes making up the characters of the string '12', which are 0x31 and 0x32 in ASCII (a). That's another two bytes bringing the grand total to eight.
In little-endian format (which is what you're looking at here based on the memory values your question states), they're stored as:
offset value
------ -----
0 0x01
1 0x02
2 0x01
3 0x00
4 0x02
5 0x00
6 0x31
7 0x32
(a) The character set you're using in this case is the ASCII one (you can follow that link for a table describing all the characters in that set).
The byte values 0x30 thru 0x39 are the digits 0 thru 9, just as the bytes 0x41 thru 0x5A represent the upper-case alpha characters. The pseudo-op:
db '12'
is saying to insert the bytes for the characters '1' and '2'.
Similarly:
db 'Pax is a really cool guy',0
would give you the hex-dump representation:
addr +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F +0123456789ABCDEF
0000 50 61 78 20 69 73 20 61 20 72 65 61 6C 6C 79 20 Pax is a really
0010 63 6F 6F 6C 20 67 75 79 00 cool guy.
val1 is two consecutive bytes, 1 and 2. db means "direct byte". val2 is two consecutive words, i.e. 4 bytes, again 1 and 2. in memory they will be 1, 0, 2, 0, assuming you're on a big endian machine. val3 is a two bytes string. 31 and 32 in are 49 and 50 in hexadecimal notation, they are ASCII codes for the characters "1" and "2".