<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">I assume people who put “true” binary data into their QByteArrays and<br class="">convert that to JSON would have pre-base64-encoded it manually already, to<br class="">avoid the data loss, so this is a surprising change for those that just use<br class="">it as a poor man’s string. <br class=""></blockquote><br class="">Agreed, anyone who needed to send binaries in the past would have encoded <br class="">somehow (base16, base64 or base64url), but they might have also already moved <br class="">it to QString because that's what's documented. If they haven't -- and <br class="">QByteArray::toBase64 returns QByteArray -- then we get double encoding, which <br class="">is wore.<br class=""></div></div></blockquote><div class="">Thats what is happening here</div><div class=""><a href="https://github.com/open-eid/chrome-token-signing/issues/168" class="">https://github.com/open-eid/chrome-token-signing/issues/168</a></div><div class="">Maybe QByteArray::toHex/Base64 should then return QString instead?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">In a green field scenario, the new behaviour is quite useful. You don't need <br class="">to pre-encode, the converter will do it for you.<br class=""></div></div></blockquote><div>We need then specify how it will then encoded (hex or base64) then.</div><div><br class=""></div><div>Raul Metsma</div><div><br class=""></div><div><br class=""></div></div></body></html>