Develop Reference

How to convert a base64 String to a ZPL label for print on a Zebra ZQ630 printer

For context, our application is an Android WebView that loads a url (web app written in React) with a print feature. The flow of the app is that once the print button is clicked, it triggers a print method on the Android side through an #Javascript Interface bringing with it a payload - A base 64 String, that we convert in the Android side of code to print. Note -- ( The printer is connected to the android device )
Issue is that the conversion is coming out like instead of like .
To further complicate the issue, on base64decode.net using google chrome, the conversion presents no issues, but if you try the same payload on the same site using Safari, it ends up scrambled as in our app as also shown above.
I have tried using Zebra SDK Base64 API and none seems to help thus far.
I've tried to convert the Base64 String on the React side of my app using atob but even when it successfully converts and displays this code. On Labelary.com it wouldn't generate any image and throws error.
I guess my question would be if anyone has experienced this before and does anyone know a way around it. --A good say to generate a ZPL string that would work on Labelary.com either on Java or Javascript
// This code is the result of atob conversion that wouldn't generate a ZPL on labelary.com
^XA
^PW812
^CI13
^FT0,510^GB809,0,2^FS
^FT0,423^GB809,0,20^FS
^FT244,402^GB0,215,2^FS
^FT0,187^GB809,0,2^FS
^FT20,20^A0N,18,22^FDJCPENNEY.COM^FS
^FT20,43^A0N,18,22^FD5555 SCARBOROUGH BLVD^FS
^FT20,65^A0N,18,22^FDCOLUMBUS OH 43232^FS
^FT447,30^A0N,23,29^FD1 LBS^FS
^FT630,30^A0N,23,29^FD1 OF 1^FS
^FT20,122^A0N,28,35^FDSHIP^FS
^FT20,150^A0N,28,35^FD TO:^FS
^FT122,118^A0N,23,29^FDUSPS 48182^FS
^FT122,144^A0N,23,29^FD8149 LEWIS AVE^FS
^FT122,177^A0N,28,35^FH^FDTEMPERANCE MI 48182_F09998^FS
^FT20,396^BD2^FH^FD988840481829998[)>_1E01_1D961Z00316075_1DUPSN_1DW2A813_1E07L$4Y29L'_1D+_1DH:ZGX/,ZX2&O#( *XZ6F+XD1A/*_0D:+GDI_0D_1E_04^FS
^FT284,252^A0N,65,81^FH^FD MI 482 0_F001 X^FS
^BY4,,102^FT330,382^BCN,,N^FD>;420481829998^FS
^FT20,467^A0N,42,52^FDUPS SUREPOST^FS
^FT20,500^A0N,23,29^FDTRACKING #: 1Z W2A 813 YW 0031 6075^FS
^FT687,508^GB122,0,85^FS
^BY3,,142^FT106,664^BCN,,N^FD>:1ZW2A813YW>500316075^FS
^FT0,695^GB809,0,14^FS
^FT20,721^A0N,28,35^FDUSPS DELIVER TO:^FS
^FT20,743^A0N,18,22^FDMARCIA SMOTHERMAN^FS
^FT20,765^A0N,18,22^FD268 HIGHLANDS^FS
^FT20,787^A0N,18,22^FH^FDTEMPERANCE MI 48182_F01189^FS
^FT356,721^A0N,18,22^FH^FDCarrier_F0Leave^FS
^FT356,746^A0N,18,22^FDIf No Response^FS
^FT569,813^GB213,112,2^FS
^FT603,723^A0N,18,22^FH^FDPARCEL SELECT^FS
^FT586,747^A0N,18,22^FH^FDU.S. POSTAGE PAID^FS
^FT658,771^A0N,18,22^FH^FDUPS^FS
^FT659,795^A0N,18,22^FH^FDeVS^FS
^FT0,839^GB809,0,14^FS
^FT221,883^A0N,32,40^FDUSPS TRACKING # eVS^FS
^BY3,,156^FT40,1079^BCN,,N^FD>;>842048182>892612909859896551001000113^FS
^FT156,1135^A0N,28,35^FD9261 2909 8598 9655 1001 0001 13^FS
^FT0,1148^GB809,0,8^FS
^FT508,1193^A0N,23,29^FDREF1: 2020066410165651^FS
^FT508,1215^A0N,23,29^FDContainer ID: 307497242^FS
^BY2,,30^FT20,1189^BCN,,N^FD>;257977480900^FS
^FT20,1215^A0N,23,29^FD257977480900^FS
^XZ
Note: I've had some other base64 String conversion that worked well but not all of them. Below is the same code - converted on Base64decode.net on Chrome but it works well on Labelary.com
^XA
^PW812
^CI13
^FT0,510^GB809,0,2^FS
^FT0,423^GB809,0,20^FS
^FT244,402^GB0,215,2^FS
^FT0,187^GB809,0,2^FS
^FT20,20^A0N,18,22^FDJCPENNEY.COM^FS
^FT20,43^A0N,18,22^FD5555 SCARBOROUGH BLVD^FS
^FT20,65^A0N,18,22^FDCOLUMBUS OH 43232^FS
^FT447,30^A0N,23,29^FD1 LBS^FS
^FT630,30^A0N,23,29^FD1 OF 1^FS
^FT20,122^A0N,28,35^FDSHIP^FS
^FT20,150^A0N,28,35^FD TO:^FS
^FT122,118^A0N,23,29^FDUSPS 48182^FS
^FT122,144^A0N,23,29^FD8149 LEWIS AVE^FS
^FT122,177^A0N,28,35^FH^FDTEMPERANCE MI 48182_F09998^FS
^FT20,396^BD2^FH^FD988840481829998[)>_1E01_1D961Z00316075_1DUPSN_1DW2A813_1E07L$4Y29L'_1D+_1DH:ZGX/,ZX2&O#( *XZ6F+XD1A/*_0D:+GDI_0D_1E_04^FS
^FT284,252^A0N,65,81^FH^FD MI 482 0_F001 X^FS
^BY4,,102^FT330,382^BCN,,N^FD>;420481829998^FS
^FT20,467^A0N,42,52^FDUPS SUREPOST^FS
^FT20,500^A0N,23,29^FDTRACKING #: 1Z W2A 813 YW 0031 6075^FS
^FT687,508^GB122,0,85^FS
^BY3,,142^FT106,664^BCN,,N^FD>:1ZW2A813YW>500316075^FS
^FT0,695^GB809,0,14^FS
^FT20,721^A0N,28,35^FDUSPS DELIVER TO:^FS
^FT20,743^A0N,18,22^FDMARCIA SMOTHERMAN^FS
^FT20,765^A0N,18,22^FD268 HIGHLANDS^FS
^FT20,787^A0N,18,22^FH^FDTEMPERANCE MI 48182_F01189^FS
^FT356,721^A0N,18,22^FH^FDCarrier_F0Leave^FS
^FT356,746^A0N,18,22^FDIf No Response^FS
^FT569,813^GB213,112,2^FS
^FT603,723^A0N,18,22^FH^FDPARCEL SELECT^FS
^FT586,747^A0N,18,22^FH^FDU.S. POSTAGE PAID^FS
^FT658,771^A0N,18,22^FH^FDUPS^FS
^FT659,795^A0N,18,22^FH^FDeVS^FS
^FT0,839^GB809,0,14^FS
^FT221,883^A0N,32,40^FDUSPS TRACKING # eVS^FS
^BY3,,156^FT40,1079^BCN,,N^FD>;>842048182>892612909859896551001000113^FS
^FT156,1135^A0N,28,35^FD9261 2909 8598 9655 1001 0001 13^FS
^FT0,1148^GB809,0,8^FS
^FT508,1193^A0N,23,29^FDREF1: 2020066410165651^FS
^FT508,1215^A0N,23,29^FDContainer ID: 307497242^FS
^BY2,,30^FT20,1189^BCN,,N^FD>;257977480900^FS
^FT20,1215^A0N,23,29^FD257977480900^FS
^XZ
Finally, this is the base64 String in question:
XgBYAEEADQBeAFAAVwA4ADEAMgANAF4AQwBJADEAMwANAF4ARgBUADAALAA1ADEAMABeAEcAQgA4ADAAOQAsADAALAAyAF4ARgBTAA0AXgBGAFQAMAAsADQAMgAzAF4ARwBCADgAMAA5ACwAMAAsADIAMABeAEYAUwANAF4ARgBUADIANAA0ACwANAAwADIAXgBHAEIAMAAsADIAMQA1ACwAMgBeAEYAUwANAF4ARgBUADAALAAxADgANwBeAEcAQgA4ADAAOQAsADAALAAyAF4ARgBTAA0AXgBGAFQAMgAwACwAMgAwAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQASgBDAFAARQBOAE4ARQBZAC4AQwBPAE0AXgBGAFMADQBeAEYAVAAyADAALAA0ADMAXgBBADAATgAsADEAOAAsADIAMgBeAEYARAA1ADUANQA1ACAAUwBDAEEAUgBCAE8AUgBPAFUARwBIACAAQgBMAFYARABeAEYAUwANAF4ARgBUADIAMAAsADYANQBeAEEAMABOACwAMQA4ACwAMgAyAF4ARgBEAEMATwBMAFUATQBCAFUAUwAgAE8ASAAgADQAMwAyADMAMgBeAEYAUwANAF4ARgBUADQANAA3ACwAMwAwAF4AQQAwAE4ALAAyADMALAAyADkAXgBGAEQAMQAgAEwAQgBTAF4ARgBTAA0AXgBGAFQANgAzADAALAAzADAAXgBBADAATgAsADIAMwAsADIAOQBeAEYARAAxACAATwBGACAAMQBeAEYAUwANAF4ARgBUADIAMAAsADEAMgAyAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAUwBIAEkAUABeAEYAUwANAF4ARgBUADIAMAAsADEANQAwAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAIABUAE8AOgBeAEYAUwANAF4ARgBUADEAMgAyACwAMQAxADgAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABVAFMAUABTACAANAA4ADEAOAAyAF4ARgBTAA0AXgBGAFQAMQAyADIALAAxADQANABeAEEAMABOACwAMgAzACwAMgA5AF4ARgBEADgAMQA0ADkAIABMAEUAVwBJAFMAIABBAFYARQBeAEYAUwANAF4ARgBUADEAMgAyACwAMQA3ADcAXgBBADAATgAsADIAOAAsADMANQBeAEYASABeAEYARABUAEUATQBQAEUAUgBBAE4AQwBFACAATQBJACAANAA4ADEAOAAyAF8ARgAwADkAOQA5ADgAXgBGAFMADQBeAEYAVAAyADAALAAzADkANgBeAEIARAAyAF4ARgBIAF4ARgBEADkAOAA4ADgANAAwADQAOAAxADgAMgA5ADkAOQA4AFsAKQA+AF8AMQBFADAAMQBfADEARAA5ADYAMQBaADAAMAAzADEANgAwADcANQBfADEARABVAFAAUwBOAF8AMQBEAFcAMgBBADgAMQAzAF8AMQBFADAANwBMACQANABZADIAOQBMACcAXwAxAEQAKwBfADEARABIADoAWgBHAFgALwAsAFoAWAAyACYATwAjACgAIAAqAFgAWgA2AEYAKwBYAEQAMQBBAC8AKgBfADAARAA6ACsARwBEAEkAXwAwAEQAXwAxAEUAXwAwADQAXgBGAFMADQBeAEYAVAAyADgANAAsADIANQAyAF4AQQAwAE4ALAA2ADUALAA4ADEAXgBGAEgAXgBGAEQAIABNAEkAIAA0ADgAMgAgADAAXwBGADAAMAAxACAAWABeAEYAUwANAF4AQgBZADQALAAsADEAMAAyAF4ARgBUADMAMwAwACwAMwA4ADIAXgBCAEMATgAsACwATgBeAEYARAA+ADsANAAyADAANAA4ADEAOAAyADkAOQA5ADgAXgBGAFMADQBeAEYAVAAyADAALAA0ADYANwBeAEEAMABOACwANAAyACwANQAyAF4ARgBEAFUAUABTACAAUwBVAFIARQBQAE8AUwBUAF4ARgBTAA0AXgBGAFQAMgAwACwANQAwADAAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABUAFIAQQBDAEsASQBOAEcAIAAjADoAIAAxAFoAIABXADIAQQAgADgAMQAzACAAWQBXACAAMAAwADMAMQAgADYAMAA3ADUAXgBGAFMADQBeAEYAVAA2ADgANwAsADUAMAA4AF4ARwBCADEAMgAyACwAMAAsADgANQBeAEYAUwANAF4AQgBZADMALAAsADEANAAyAF4ARgBUADEAMAA2ACwANgA2ADQAXgBCAEMATgAsACwATgBeAEYARAA+ADoAMQBaAFcAMgBBADgAMQAzAFkAVwA+ADUAMAAwADMAMQA2ADAANwA1AF4ARgBTAA0AXgBGAFQAMAAsADYAOQA1AF4ARwBCADgAMAA5ACwAMAAsADEANABeAEYAUwANAF4ARgBUADIAMAAsADcAMgAxAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAVQBTAFAAUwAgAEQARQBMAEkAVgBFAFIAIABUAE8AOgBeAEYAUwANAF4ARgBUADIAMAAsADcANAAzAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQATQBBAFIAQwBJAEEAIABTAE0ATwBUAEgARQBSAE0AQQBOAF4ARgBTAA0AXgBGAFQAMgAwACwANwA2ADUAXgBBADAATgAsADEAOAAsADIAMgBeAEYARAAyADYAOAAgAEgASQBHAEgATABBAE4ARABTAF4ARgBTAA0AXgBGAFQAMgAwACwANwA4ADcAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABUAEUATQBQAEUAUgBBAE4AQwBFACAATQBJACAANAA4ADEAOAAyAF8ARgAwADEAMQA4ADkAXgBGAFMADQBeAEYAVAAzADUANgAsADcAMgAxAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEgAXgBGAEQAQwBhAHIAcgBpAGUAcgBfAEYAMABMAGUAYQB2AGUAXgBGAFMADQBeAEYAVAAzADUANgAsADcANAA2AF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQASQBmACAATgBvACAAUgBlAHMAcABvAG4AcwBlAF4ARgBTAA0AXgBGAFQANQA2ADkALAA4ADEAMwBeAEcAQgAyADEAMwAsADEAMQAyACwAMgBeAEYAUwANAF4ARgBUADYAMAAzACwANwAyADMAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABQAEEAUgBDAEUATAAgAFMARQBMAEUAQwBUAF4ARgBTAA0AXgBGAFQANQA4ADYALAA3ADQANwBeAEEAMABOACwAMQA4ACwAMgAyAF4ARgBIAF4ARgBEAFUALgBTAC4AIABQAE8AUwBUAEEARwBFACAAUABBAEkARABeAEYAUwANAF4ARgBUADYANQA4ACwANwA3ADEAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABVAFAAUwBeAEYAUwANAF4ARgBUADYANQA5ACwANwA5ADUAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABlAFYAUwBeAEYAUwANAF4ARgBUADAALAA4ADMAOQBeAEcAQgA4ADAAOQAsADAALAAxADQAXgBGAFMADQBeAEYAVAAyADIAMQAsADgAOAAzAF4AQQAwAE4ALAAzADIALAA0ADAAXgBGAEQAVQBTAFAAUwAgAFQAUgBBAEMASwBJAE4ARwAgACMAIABlAFYAUwBeAEYAUwANAF4AQgBZADMALAAsADEANQA2AF4ARgBUADQAMAAsADEAMAA3ADkAXgBCAEMATgAsACwATgBeAEYARAA+ADsAPgA4ADQAMgAwADQAOAAxADgAMgA+ADgAOQAyADYAMQAyADkAMAA5ADgANQA5ADgAOQA2ADUANQAxADAAMAAxADAAMAAwADEAMQAzAF4ARgBTAA0AXgBGAFQAMQA1ADYALAAxADEAMwA1AF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAOQAyADYAMQAgADIAOQAwADkAIAA4ADUAOQA4ACAAOQA2ADUANQAgADEAMAAwADEAIAAwADAAMAAxACAAMQAzAF4ARgBTAA0AXgBGAFQAMAAsADEAMQA0ADgAXgBHAEIAOAAwADkALAAwACwAOABeAEYAUwANAF4ARgBUADUAMAA4ACwAMQAxADkAMwBeAEEAMABOACwAMgAzACwAMgA5AF4ARgBEAFIARQBGADEAOgAgADIAMAAyADAAMAA2ADYANAAxADAAMQA2ADUANgA1ADEAXgBGAFMADQBeAEYAVAA1ADAAOAAsADEAMgAxADUAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABDAG8AbgB0AGEAaQBuAGUAcgAgAEkARAA6ACAAMwAwADcANAA5ADcAMgA0ADIAXgBGAFMADQBeAEIAWQAyACwALAAzADAAXgBGAFQAMgAwACwAMQAxADgAOQBeAEIAQwBOACwALABOAF4ARgBEAD4AOwAyADUANwA5ADcANwA0ADgAMAA5ADAAMABeAEYAUwANAF4ARgBUADIAMAAsADEAMgAxADUAXgBBADAATgAsADIAMwAsADIAOQBeAEYARAAyADUANwA5ADcANwA0ADgAMAA5ADAAMABeAEYAUwANAF4AWABaAA==

Convert your base64 String to UTF-8 using this code:
String Mybase64 = "dGVjaFBhC3M=";
//1- Convert to byte
byte[] X = Base64.decode(Mybase64);
//2- Convert to UTF-8
String ZPL_Result = new String(X, "UTF-8");
Update*
string b64 = "XgBYAEEADQBeAFAAVwA4ADEAMgANAF4AQwBJADEAMwANAF4ARgBUADAALAA1ADEAMABeAEcAQgA4ADAAOQAsADAALAAyAF4ARgBTAA0AXgBGAFQAMAAsADQAMgAzAF4ARwBCADgAMAA5ACwAMAAsADIAMABeAEYAUwANAF4ARgBUADIANAA0ACwANAAwADIAXgBHAEIAMAAsADIAMQA1ACwAMgBeAEYAUwANAF4ARgBUADAALAAxADgANwBeAEcAQgA4ADAAOQAsADAALAAyAF4ARgBTAA0AXgBGAFQAMgAwACwAMgAwAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQASgBDAFAARQBOAE4ARQBZAC4AQwBPAE0AXgBGAFMADQBeAEYAVAAyADAALAA0ADMAXgBBADAATgAsADEAOAAsADIAMgBeAEYARAA1ADUANQA1ACAAUwBDAEEAUgBCAE8AUgBPAFUARwBIACAAQgBMAFYARABeAEYAUwANAF4ARgBUADIAMAAsADYANQBeAEEAMABOACwAMQA4ACwAMgAyAF4ARgBEAEMATwBMAFUATQBCAFUAUwAgAE8ASAAgADQAMwAyADMAMgBeAEYAUwANAF4ARgBUADQANAA3ACwAMwAwAF4AQQAwAE4ALAAyADMALAAyADkAXgBGAEQAMQAgAEwAQgBTAF4ARgBTAA0AXgBGAFQANgAzADAALAAzADAAXgBBADAATgAsADIAMwAsADIAOQBeAEYARAAxACAATwBGACAAMQBeAEYAUwANAF4ARgBUADIAMAAsADEAMgAyAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAUwBIAEkAUABeAEYAUwANAF4ARgBUADIAMAAsADEANQAwAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAIABUAE8AOgBeAEYAUwANAF4ARgBUADEAMgAyACwAMQAxADgAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABVAFMAUABTACAANAA4ADEAOAAyAF4ARgBTAA0AXgBGAFQAMQAyADIALAAxADQANABeAEEAMABOACwAMgAzACwAMgA5AF4ARgBEADgAMQA0ADkAIABMAEUAVwBJAFMAIABBAFYARQBeAEYAUwANAF4ARgBUADEAMgAyACwAMQA3ADcAXgBBADAATgAsADIAOAAsADMANQBeAEYASABeAEYARABUAEUATQBQAEUAUgBBAE4AQwBFACAATQBJACAANAA4ADEAOAAyAF8ARgAwADkAOQA5ADgAXgBGAFMADQBeAEYAVAAyADAALAAzADkANgBeAEIARAAyAF4ARgBIAF4ARgBEADkAOAA4ADgANAAwADQAOAAxADgAMgA5ADkAOQA4AFsAKQA+AF8AMQBFADAAMQBfADEARAA5ADYAMQBaADAAMAAzADEANgAwADcANQBfADEARABVAFAAUwBOAF8AMQBEAFcAMgBBADgAMQAzAF8AMQBFADAANwBMACQANABZADIAOQBMACcAXwAxAEQAKwBfADEARABIADoAWgBHAFgALwAsAFoAWAAyACYATwAjACgAIAAqAFgAWgA2AEYAKwBYAEQAMQBBAC8AKgBfADAARAA6ACsARwBEAEkAXwAwAEQAXwAxAEUAXwAwADQAXgBGAFMADQBeAEYAVAAyADgANAAsADIANQAyAF4AQQAwAE4ALAA2ADUALAA4ADEAXgBGAEgAXgBGAEQAIABNAEkAIAA0ADgAMgAgADAAXwBGADAAMAAxACAAWABeAEYAUwANAF4AQgBZADQALAAsADEAMAAyAF4ARgBUADMAMwAwACwAMwA4ADIAXgBCAEMATgAsACwATgBeAEYARAA+ADsANAAyADAANAA4ADEAOAAyADkAOQA5ADgAXgBGAFMADQBeAEYAVAAyADAALAA0ADYANwBeAEEAMABOACwANAAyACwANQAyAF4ARgBEAFUAUABTACAAUwBVAFIARQBQAE8AUwBUAF4ARgBTAA0AXgBGAFQAMgAwACwANQAwADAAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABUAFIAQQBDAEsASQBOAEcAIAAjADoAIAAxAFoAIABXADIAQQAgADgAMQAzACAAWQBXACAAMAAwADMAMQAgADYAMAA3ADUAXgBGAFMADQBeAEYAVAA2ADgANwAsADUAMAA4AF4ARwBCADEAMgAyACwAMAAsADgANQBeAEYAUwANAF4AQgBZADMALAAsADEANAAyAF4ARgBUADEAMAA2ACwANgA2ADQAXgBCAEMATgAsACwATgBeAEYARAA+ADoAMQBaAFcAMgBBADgAMQAzAFkAVwA+ADUAMAAwADMAMQA2ADAANwA1AF4ARgBTAA0AXgBGAFQAMAAsADYAOQA1AF4ARwBCADgAMAA5ACwAMAAsADEANABeAEYAUwANAF4ARgBUADIAMAAsADcAMgAxAF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAVQBTAFAAUwAgAEQARQBMAEkAVgBFAFIAIABUAE8AOgBeAEYAUwANAF4ARgBUADIAMAAsADcANAAzAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQATQBBAFIAQwBJAEEAIABTAE0ATwBUAEgARQBSAE0AQQBOAF4ARgBTAA0AXgBGAFQAMgAwACwANwA2ADUAXgBBADAATgAsADEAOAAsADIAMgBeAEYARAAyADYAOAAgAEgASQBHAEgATABBAE4ARABTAF4ARgBTAA0AXgBGAFQAMgAwACwANwA4ADcAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABUAEUATQBQAEUAUgBBAE4AQwBFACAATQBJACAANAA4ADEAOAAyAF8ARgAwADEAMQA4ADkAXgBGAFMADQBeAEYAVAAzADUANgAsADcAMgAxAF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEgAXgBGAEQAQwBhAHIAcgBpAGUAcgBfAEYAMABMAGUAYQB2AGUAXgBGAFMADQBeAEYAVAAzADUANgAsADcANAA2AF4AQQAwAE4ALAAxADgALAAyADIAXgBGAEQASQBmACAATgBvACAAUgBlAHMAcABvAG4AcwBlAF4ARgBTAA0AXgBGAFQANQA2ADkALAA4ADEAMwBeAEcAQgAyADEAMwAsADEAMQAyACwAMgBeAEYAUwANAF4ARgBUADYAMAAzACwANwAyADMAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABQAEEAUgBDAEUATAAgAFMARQBMAEUAQwBUAF4ARgBTAA0AXgBGAFQANQA4ADYALAA3ADQANwBeAEEAMABOACwAMQA4ACwAMgAyAF4ARgBIAF4ARgBEAFUALgBTAC4AIABQAE8AUwBUAEEARwBFACAAUABBAEkARABeAEYAUwANAF4ARgBUADYANQA4ACwANwA3ADEAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABVAFAAUwBeAEYAUwANAF4ARgBUADYANQA5ACwANwA5ADUAXgBBADAATgAsADEAOAAsADIAMgBeAEYASABeAEYARABlAFYAUwBeAEYAUwANAF4ARgBUADAALAA4ADMAOQBeAEcAQgA4ADAAOQAsADAALAAxADQAXgBGAFMADQBeAEYAVAAyADIAMQAsADgAOAAzAF4AQQAwAE4ALAAzADIALAA0ADAAXgBGAEQAVQBTAFAAUwAgAFQAUgBBAEMASwBJAE4ARwAgACMAIABlAFYAUwBeAEYAUwANAF4AQgBZADMALAAsADEANQA2AF4ARgBUADQAMAAsADEAMAA3ADkAXgBCAEMATgAsACwATgBeAEYARAA+ADsAPgA4ADQAMgAwADQAOAAxADgAMgA+ADgAOQAyADYAMQAyADkAMAA5ADgANQA5ADgAOQA2ADUANQAxADAAMAAxADAAMAAwADEAMQAzAF4ARgBTAA0AXgBGAFQAMQA1ADYALAAxADEAMwA1AF4AQQAwAE4ALAAyADgALAAzADUAXgBGAEQAOQAyADYAMQAgADIAOQAwADkAIAA4ADUAOQA4ACAAOQA2ADUANQAgADEAMAAwADEAIAAwADAAMAAxACAAMQAzAF4ARgBTAA0AXgBGAFQAMAAsADEAMQA0ADgAXgBHAEIAOAAwADkALAAwACwAOABeAEYAUwANAF4ARgBUADUAMAA4ACwAMQAxADkAMwBeAEEAMABOACwAMgAzACwAMgA5AF4ARgBEAFIARQBGADEAOgAgADIAMAAyADAAMAA2ADYANAAxADAAMQA2ADUANgA1ADEAXgBGAFMADQBeAEYAVAA1ADAAOAAsADEAMgAxADUAXgBBADAATgAsADIAMwAsADIAOQBeAEYARABDAG8AbgB0AGEAaQBuAGUAcgAgAEkARAA6ACAAMwAwADcANAA5ADcAMgA0ADIAXgBGAFMADQBeAEIAWQAyACwALAAzADAAXgBGAFQAMgAwACwAMQAxADgAOQBeAEIAQwBOACwALABOAF4ARgBEAD4AOwAyADUANwA5ADcANwA0ADgAMAA5ADAAMABeAEYAUwANAF4ARgBUADIAMAAsADEAMgAxADUAXgBBADAATgAsADIAMwAsADIAOQBeAEYARAAyADUANwA5ADcANwA0ADgAMAA5ADAAMABeAEYAUwANAF4AWABaAA==";
byte[] data = Base64.decode(b64, Base64.DEFAULT);
String ZPL_Result = new String(data, StandardCharsets.UTF_8);

Figured I leave an answer here on the approach I employed. I resorted to creating a regex expression to filter out the unicode characters that was appearing in the conversion. That way I had a clean String to print.
The precise unicode character is "u + FFFD"

SMS body text for html with % for percent sign crashes android app

Whenever I put a % in the body of my sms html link like:
sms (? or & separating depending on ios android) :
a href="sms:555555555?body=Hello123 % testing!"target="_parent">
Click /a
It crashes my messaging app on android, but on iOS it's fine. I tried to encode it as well, but that didn't seem to work. Any clue on how to escape this?
EDIT: This only happens with Google Messages, Samsung Messages is ok

try to write with symbol like ©<p>Copyright ©</p>

Try to encode percent like
a href="sms:555555555?body=Hello123 %25 testing!"target="_parent">

I had the same issue and spent a lot of time but solution was pretty simple.
Need to replace '%' with one of these:
percent sign variations
SMS body encoding function:
function encodeSMSText(text) {
const updatedText = text.replace(/%/g, String.fromCharCode(0xFF05));
return encodeURIComponent(updatedText)
.replace(/[!'()*]/g, function(c) {
return '%' + c.charCodeAt(0).toString(16);
});
}

Regular expression to match all phone numbers

I have tried matching Phone numbers with the regular expressions provided by Android in Patterns.Phone,this matches a lot of things that are not phone numbers.I have also tried using:
(?:(?:\+?1\s*(?:[.-]\s*)?)?(?:\(\s*([2-9]1[02-9]|[2-9][02-8]1|[2-9][02-8][02-9])\s*\)|([2-9]1[02-9]|[2-9][02-8]1|[2-9][02-8][02-9]))\s*(?:[.-]\s*)?)?([2-9]1[02-9]|[2-9][02-9]1|[2-9][02-9]{2})\s*(?:[.-]\s*)?([0-9]{4})(?:\s*(?:#|x\.?|ext\.?|extension)\s*(\d+))?
However,I found that the Test was not successfull for all the inputs.I would like to validate the following inputs using a regular expression:
67450450
+9144-27444444
27444444
27470570
+12142261347
+61406366180
0891 2577456
2577456
+91 9550461668
9550461668
03-1234567
1860 425 3330
Basically any nymber format supported here:WTND

you can use the following code to check phone #:
private boolean validPhone(String phone) {
Pattern pattern = Patterns.PHONE;
return pattern.matcher(phone).matches();
}
if(validPhone("67450450")){
Toast.makeText(this,"The phone number is valid");
}
else
{
Toast.makeText(this,"The phone number is not valid");
}

This isn't clean/efficient, just thrown together to match your sample data:
\b\d{7,10}|\+\d{4}-\d{8}|\+\d{11}|\d{4}\s\d{7}|\+\d{2}\s\d{10}|\d{2}-\d{7}|\d{4}\s\d{3}\s\d{4}\b

Propper way to handle dumping and reloading of JSON data containing special characters on android?

Not sure if this has been answered already but a quick search didn't turn up a satisfying result..
I'm stuck with the following scenario:
web service with REST API and JSON formatted data blobs
android client app talking to this service and locally caching / processing the data
The we service is run by a German company so some of the strings in the result data contain special characters like German umlauts:
// example resonse
[
{
"title" : "reward 1",
"description" : "Ein gro\u00dfer Kaffee f\u00fcr dich!"
},
{
"title" : "reward 2",
"description" : "Eine Pizza f\u00fcr dich!"
},
...
]
Locally the app is parsing the data using a set of classes which mirror the response objects (e.g. Reward and RewardResponse classes for the upper example). Each of these classes can read and dump itself from / to JSON - however this is where things get ugly.
Taking the example above org.json will correctly parse the data and the resulting strings will contain proper Unicode versions of the special characters 'ß' (\u00df) and 'ü' (\u00fc).
final RewardResponse response = new RewardResponse(jsonData);
final Reward reward = response.get(0);
// this will print "Ein großer Kaffee für dich!"
Log.d("dump server data", reward.getDescription());
final Reward reward2 = new Reward(reward.toJSON());
// this will print "Ein gro�er Kaffee f�r dich!"
Log.d("dump reloaded data", reward2.getDescription());
As you can see there is a problem with loading the data generated by JSONObject.toString().
Mainly whats happening is that JSONObject will parse escapes in the form of "\uXXXX" but it will dump them as plain UTF-8 text.
In turn, when parsing it won't properly read the unicode and instead insert a replacement character in the result string (� above \uffff as code point).
My current workaround consists of a look-up table containing the Unicode Latin1 supplement characters and their respective escaped versions (\u00a0 up to \u00ff). But this also means I have to go over each and every dumped JSON text and replace the characters with their escaped versions each time I dump something.
Please tell me there is a better way for this!
(Note: there is this question however he had problems with local file encoding on disk.
My problem above, as you can see, is reproducible without ever writing to disk)
EDIT: As requested in the comments here's the toJSON() method:
public final String toJSON() {
JSONObject obj = new JSONObject();
// mTitle and mDescription contain the unmodified
// strings received from parsing.
obj.put("title", mTitle);
obj.put("description", mDescription);
return obj.toString();
}
As a side note it makes no difference if I use JSONObject.toString() or a JSONStringer.
(The documentation advises to use .toString())
EDIT: just to remove Reward from the equation, this reproduces the problem:
final JSONObject inputData = new JSONObject("{\"description\":\"Ein gro\\u00dfer Kaffee\"}");
final JSONObject parsedData = new JSONObject(inputData.toString());
Log.d("inputData", inputData.getString("description"));
Log.d("parsedData", parsedData.getString("description"));

[Note: posted as an answer for better formatting]
I just tried the example
final JSONObject inputData = new JSONObject("{\"description\":\"Ein gro\\u00dfer Kaffee\"}");
final JSONObject parsedData = new JSONObject(inputData.toString());
Log.d("inputData", inputData.getString("description"));
Log.d("parsedData", parsedData.getString("description"));
on my Nexus 7 running Android 4.2.1, and on Nexus S running 4.1.2, and it works as intended:
D/inputData(17281): Ein großer Kaffee
D/parsedData(17281): Ein großer Kaffee
In which Android version did you see the problem?

Different encoding using "android.util.Base64" and "org.apache.commons.codec.binary.Base64;"

I am programming an authentication service in Android and this one includes a server part written in java.
I do the same operations in both parts executing these two pieces of codes in Android and Server:
ANDROID:
String genChallengeResponse(String challenge, String message) {
String Hmac_ALG = "HmacSHA256";
SecretKey key = new SecretKeySpec(challenge.getBytes(), Hmac_ALG);
Mac m = Mac.getInstance(Hmac_ALG);
m.init(key);
m.update(password.getBytes());
byte[] mac = m.doFinal();
return new String(Base64.encode(mac, Base64.DEFAULT));
}
SERVER:
String genChallengeResponse(String challenge, String message) {
String Hmac_ALG = "HmacSHA256";
SecretKey key = new SecretKeySpec(challenge.getBytes(), Hmac_ALG);
Mac m = Mac.getInstance(Hmac_ALG);
m.init(key);
m.update(password.getBytes());
byte[] mac = m.doFinal();
return new String(Base64.encodeBase64(mac));
}
Starting from the same challenge and message these are the results:
Android: n2EaLpQr0uKgkZKhCQzwuIFeeLjzZKerZcETVNcfla4=
Server: n2EaLpQr0uKgkZKhCQzwuD9eeLjzZKerZcETVNcfla4=
^^
These are different just for TWO CHARACTERS.
The problem is that this strange behaviour does not appear in every pair of String passed to the functions...
I tried to use the UTF-8 in each system, but nothing changes...
Do someone knows what is the problem? If this is a known problem...
(is important to say that the problem is the same using Android 2.2 or also 4.0, then the problem is not the operating system, I think).

Can't comment yet therefore as answer:
I found out a few weeks ago that Android's Base64 uses different settings for the Linefeeds (check here: http://developer.android.com/reference/android/util/Base64.html )
I think in my case it was NO_WRAP missing.Perhaps one of the other options (NO_PADDING or URL-Safe, does the tested password contain + or - ?) could change your results...