I used twitter4j to post tweet include image and text in android. My text has been truncate to less than 140. But I wonder why the server response over 140 characters exception.
Here is my try:
message = trimTweet(message); // guaranteed max length is less than 140
StatusUpdate status = new StatusUpdate(message);
if(bitmapUri != null){
status.setMedia(new File(getRealPathFromURI(getApplicationContext(), bitmapUri)));
}
twitter.updateStatus(status);
The server response:
10-23 19:18:00.842: E//NewsActivity.java:280(25288):
TwitterException{exceptionCode=[b2b52c28-11aaaacd], statusCode=403,
message=Status is over 140 characters., code=186, retryAfter=-1,
rateLimitStatus=null, version=3.0.4}
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:162)
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
10-23 19:18:00.842: E//NewsDetailActivity.java:280(25288): at twitter4j.internal.http.HttpClientWrapper.post(HttpClientWrapper.java:98)
From debug, I can see my tweet message less than 140 characters (sometime is 138 or 139). But when I try to send only 108 or 110 characters, it sent success. Then I wonder twitter4j add my image to tweet text. Is that right?
How can I send image and text with only 140 characters?
Finally I figured out my problem. When adding URL or image, Twitter limit characters down to 118. That 's sound stupid, I think. From this link: http://mediacause.org/10-nonprofit-twitter-tips-140-characters/
We all get tripped up by just how limiting 140 characters can be (it
sounds like a lot until you start typing). Add in a link or a photo,
and your character count for accompanying text is cut down to 118.
Keep this in mind when crafting tweets and include text that gets
straight to the point
Update: Thanks to #Aggressor, now twitter updated limit link depend on the URL that gets t.co wrapped.
The https steals away 23 characters(it was 21), so you have only 117 characters for text.
For non https url, you have 118 characters (wrapped url is 22).
Https:
Http:
I found from the twitter documentation that while Tweets are still limited to 140 characters, the character counting model has evolved over time. Tweets are UTF-8 string content and any UTF-8 character counts as a single character. Strings that are understood as links, such as "http://twitter.com", "twitter.com", "twitter.com/twitterapi" will be automatically converted to t.co. t.co links represent a variant character count (currently "22" for HTTP-based links and "23" for HTTPS-based links). See How Twitter wraps URLs with t.co for more information on how t.co plays a role in character counting. Counting Characters provides more details on character counting strategies.
Use GET help/configuration to programmatically keep track of t.co wrapping lengths. The fields "short_url_length" and "short_url_length_https" will indicate the current lengths.
Related
I'm using Sabre/vobject (Documentation GitHub) using php to create vCard version 3.0.
As stated in the format of vCard
Content lines SHOULD be folded to a maximum width of 75 octets
The Sabre library handle it correctly and fold the lines in the right place. When adding the vCard to iPhone contacts app, all works as expected. On Android when the address is less than 75 bytes all works well, but once the address is longer and the content folds into multiple lines, the address doesn't appear on the contact. At least when using the default contact app on Pixel 3, Android 10.
If I change the vCard manually, and keep the whole address in one line of more than 75 bytes, not as expected by the format, then the contacts app is adding the address well.
Is it just a bug on the Android contacts app? I didn't find anything about this issue. Am I doing something wrong? Any solution?
The following vCard, doesn't add the address to the contact on Android
BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 3.4.5//EN
FN;CHARSET=utf-8:vCard test 3
N;CHARSET=utf-8:test 3;vCard;;;
ADR;TYPE=work;CHARSET=utf-8:;;336 Rue Saint-Honoré;Paris;Île-de-France;75
001;France
GEO:48.865928, 2.330285
EMAIL;TYPE=work;CHARSET=utf-8:abcdef#gmail.com
TEL;TYPE=mobile:+1 212 1234 5678
TEL;TYPE=landline:+1 977 1234 5678
TITLE;CHARSET=utf-8:CEO
END:VCARD
The following vCard add the address to the contact. Please note, the format is wrong the address line has more than 75 bytes.
BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 3.4.5//EN
FN;CHARSET=utf-8:vCard test 3
N;CHARSET=utf-8:test 3;vCard;;;
ADR;TYPE=work;CHARSET=utf-8:;;336 Rue Saint-Honoré;Paris;Île-de-France;75001;France
GEO:48.865928, 2.330285
EMAIL;TYPE=work;CHARSET=utf-8:abcdef#gmail.com
TEL;TYPE=mobile:+1 212 1234 5678
TEL;TYPE=landline:+1 977 1234 5678
TITLE;CHARSET=utf-8:CEO
END:VCARD
How to print strings on Apex3 using printer command language or SDK?
I created a library for android application to print Bitmap images on mobile thermal printers:
Apex3, 3nStar, PR3, Bixolon, Sewoo LK P30 using appropriate SDKs.
It works fine but pretty slow, every ticket of 30 cm length takes 20-40 secs to print (it depends on type of printer).
For 3nStar and Apex3 I started to do improvements to speed up a printing.
For 3nStar I developed a class which prints a header logo and formatted text with spanish characters.
(different alignments and different fonts for different parts of a ticket)
so, the ticket looks very similar as Bitmap image but a printing time is only 6 secs.
Now I have to do the same but with Apex3. And here I got stuck.
How I do it on 3nStar for strings:
I send in outputStream bytes which are commands for printer what to do.
outputStream.write(some_bytes)
First command always is
{0x1b, 0x74, 40} //Esc t ( -- [ISO8859-15 (Latin9)]
to print spanish characters.
Then, in a loop, for n strings:
I choose a font
{0x1B, 0x21, 0x00}//Esc ! 0 -- 0 is normal, 8 is bold etc.
where changing last byte I print different fonts: normal, bold, two height, two width and combined fonts.
Next I choose an alignment
{0x1b, 0x61, 48} //Esc a 48 for left, 49 for center, 50 for right
Then I convert a string in bytes using ISO_8859_1 to print spanish characters and also write in outputStream.
outputStream.write(messageString.getBytes(StandardCharsets.ISO_8859_1))
And last byte to send is
{0x0a} // Move on next line
And the above approach doesn't work with Apex3, also I failed using
http://www.old.adtech.pl/upload/Extech_Printer_Command_Language%20Rev_H_05062009.pdf
even though on page 1 of that book is written that is fit for Apex3.
I think I miss something, I start to see how to do it using some SDK feature of Android_SDK_ESC_V1.01.17.01PRO.jar
but I would prefer to do that using direct writing of bytes.
Answers I found from this
manual
Shortly differences with the approach that I described for 3nStar are:
1)Before printing set a char set
ESC F 1 //Esc t - for 3nStar
2)Set a font for text, for example
ESC K 1 3 CR //ESC F 1 - for 3nStar
3)Send a line of text with alignment
For 3nStar I can use an alignment command before sending a text, like
ESC 1 49 //Centering
But for Apex3 I have to know a line length which depends on type of font, also a length of printing string,
then I get
freeSpace = (lineLength - printingString)
and set spaces at the begining of a line (right alignment),
at the end (left alignment) or devide them (centering).
So, for both types of printers I use the same logic which differs only in 3 places.
It is simplified explanation as a real code includes several classes with hundreds lines of code.
Running the following code seems to generate the wrong values:
byte[] data = "\u00a5".getBytes("Shift_JIS");
It produces [ -4, -4 ], but I expect [ 0x5c ]
I've tried various alternative names, "Shift-JIS", "shift_jis", "cp932" and all produce the same result.
When I feed the resulting data into the Shift-JIS decoder, I get an exception: java.nio.charset.UnmappableCharacterException: Length: 2
That is, with the decoder configured as follows:
Charset charset = Charset.forName("Shift_JIS);
CharsetDecoder decoder = charset.newDecoder()
.onMalformedInput(CodingErrorAction.REPORT)
.onUnmappableCharacter(CodingErrorAction.REPORT);
But given the output of the encoder looks wrong, my guess is that the decoder is irrelevant. My point is that regardless of the actual bytes, the encoder generates data that it can't decode.
The full width Yen (U+FFE5) encodes to [ -127 (0x81), -113 (0x8F) ], and decodes correctly.
Strangely, if I try to decode [ 92 (0x5C) ] which is what I think the Shift-JIS encoding of the single width Yen is, the Android/Java decoder produces a back slash, leaving the character as 92.
If the encoder didn't support a given character, I would expect a replacement character such as '?'. But -4 (0xFC) doesn't even seem to be valid Shift-JIS. It's not even the Unicode replacement character U+FFFD.
Using the following line I can see that the encoder seems to be configured to use [-4, -4]:
Charset.forName("Shift_JIS").newEncoder().replacement()
So why isn't the single width Yen mapped in Shift-JIS?
Is [-4, -4] a sensible encoder replacement?
Why doesn't the decoder support 0x5C mapping to Yen (U+00A5)?
If 0x5C is not the correct encoding, what is?
A partial answer: back when Microsoft created its east-Asian code pages for Windows, like the Japanese code page 932 and Korean 949, they made the byte 0x5C render as a currency symbol (either a Yen sign or Won sign respectively) while still syntactically acting as a backslash character in file paths (so that a file path on a Japanese system might look like
C:¥Documents¥something.doc
). Thus the byte was in a sense a Yen sign, but also in a sense a backslash; the same byte was even rendered as a different one of these symbols depending upon the font when on a Japanese system, according to http://archives.miloush.net/michkap/archive/2005/09/17/469941.html.
The lack of a consistent meaning of the symbol within the encoding means that while a Shift-JIS encoder can sensibly map both \ and ¥ to the byte 0x5C, a decoder trying to map a Shift-JIS-encoded string to a sequence of unicode code points has no way of knowing whether to convert the byte 0x5C to a backslash or to a yen sign; Japanese users used to make that choice via their font selection (if they were able to make it at all).
In the face of this unfixable ambiguity, all decoders seem to choose to decode 0x5C to a backslash. (At least, Python does this, and the WhatWG have a spec that dictates it.)
As for the details of what Java/Android in particular are doing when asked to encode a Yen sign in shift_jis, I'm afraid I don't know.
When I try to analyse CDN download, some logs looks like below:
GET http://1234.apk?track=mmmmmmm range:bytes-sent=[500-500], content-length:1500 ...
In my understanding, range:bytes-sent represents continue download after break and it should have different number in bytes-sent, the followings are reasonable:
bytes-sent=[500-600]
bytes-sent=[500-]
bytes-sent=[-500]
but what meaning of range start = range end like [500-500]? It seems no data should be downloaded but generates http response.
Thanks first~
The bytes mentioned in the range are also sent. Hence if the server wants to only send the 500th byte, the server would send [500-500] as the bytes range. Have a look at https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p5-range-26 which has an example of how the first and last byte are sent :
o The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1
I have written a program to decode a CDMA 3GPP2 point-to-point SMS message. I tested it on a couple CDMA PDU hex strings I found on the internet, and it works perfectly. However, when I try to implement it on all incoming text messages on the Android platform, it always fails.
I took a look at the incoming PDU, and it doesn't seem to follow the same pattern I have been used to seeing. Can anyone explain what format this PDU is in, or what I am missing to correctly decode this PDU? Is there additional header or fields I am not taking into account?
Example PDU pulled from a incoming text message on my phone:
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
All of the CDMA pdus I found and tested my parser on look more like:
00000210020207028CE95DCC65800601FC08150003168D3001061024183060800306101004044847
Carrier: Verizon
Phone: Samsung Galaxy S Fascinate running Android 2.3.3
See the javadoc from $SDK/sources/android-16/com/android/internal/telephony/cdma/SmsMessage:
/**
* Creates byte array (pseudo pdu) from SMS object.
* Note: Do not call this method more than once per object!
*/
...so it's not following any particular CDMA standard. You can decode it however; so in fine ASCII art:-
000000000000100200000000000000000A36373839313031363734000000000000000000001B000310864D000306120624205611010B104C2CF9F3F5EBD73E7000
--------messageType --digitMode --------bearerReply ------------------------------------------------------bearer data
--------teleService --ton --------------------src --replySeqNo --messageID --msts --userdata
--------serviceCategory --errorClass --len --XX--len --len
--numberMode --causeCode ------ ------------2012/06/24 20:56:11
--npi --------bearerDataLength ----------------------userdata
--len
Note that I think you made a cut/paste error in your message - the 00 byte marked 'XX' I think shouldn't be there - luckily it's easy to spot the date and work backwards. So this is a message from 6789101674 with userdata:
104C2CF9F3F5EBD73E7000, the first five bits of which show that it's 7-bit encoded (0x02). Having shifted the remainder of the userdata 5 bits to the left, we're left with:
09859f3e7ebd7ae7ce00
--len(septets) 9 septets == 63 bits, so we expect 8 bytes of body
----------------7bit-body
So your 7bit-body decoded is "Bggguuugg".