字节数组的最短字符串编码

Question

I have this code that generates UBJSON byte array

UBObject obj = UBValueFactory.createObject();
obj.put("appId", UBValueFactory.createString("70cce8adb93c4c968a7b1483f2edf5c1"));
obj.put("apiKey", UBValueFactory.createString("a65d8f147fa741b0a6d7fc43e18363c9"));
obj.put("entityType", UBValueFactory.createString("Todo"));
obj.put("entityId", UBValueFactory.createString("2-0"));
obj.put("blobName", UBValueFactory.createString("blobName"));

ByteArrayOutputStream out = new ByteArrayOutputStream();
UBWriter writer = new UBWriter(out);
try {
    writer.write(obj);
    writer.close();
} catch (IOException e) {
    e.printStackTrace();
}

// Byte array of UBJSON
byte[] ubjsonBytes = out.toByteArray();

The question is, what is the shortest String encoding that can be done for the byte array here, that can be used and transmitted over HTTP URL? Using Base64 works perfect as URL path or query parameter but yields quite long String.

Answer 1

Depending on the input length and other properties you might want to try compressing the input with gzip before encoding the byte[] with Base64. Often a URL friendly variant of Base64 is used:

For this reason, modified Base64 for URL variants exist (such as base64url in RFC 4648), where the + and / characters of standard Base64 are respectively replaced by - and _ , so that using URL encoders/decoders is no longer necessary and have no impact on the length of the encoded value, leaving the same encoded form intact for use in relational databases, web forms, and object identifiers in general.

Some variants allow or require omitting the padding = signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries will encode = to . , potentially exposing applications to relative path attacks when a folder name is encoded from user data.

You could attempt to use Base85 however it encodes with characters that can change the meaning of URL eg & . This might or might not work with your setup and might depend stuff like reverse proxy configuration. Because of that it's often better to use a safe encoding like Base64.

All in all, long data should go into request body and not URL.