2015-04-28 38 views
5

Sto scrivendo il mio codificatore/decodificatore BASE64 per alcuni ambienti vincolati.Perché Base64 di JDK8 utilizza ISO-8859-1?

E ho trovato che Base64.Encoder#encodeString dice che usa ISO-8859-1 per costruire una stringa da quei byte codificati.

Suppongo perfettamente che il set di caratteri ISO-8859-1 copra anche tutti gli alfabeti di base64.

C'è qualche ragione possibile per non utilizzare US-ASCII?

risposta

7

ho il sospetto è più efficiente: la conversione da ISO-8859-1 torna al testo è solo tratta di promuovere ogni byte direttamente a un char, mentre per ASCII avresti bisogno di controllare che il byte è ASCII valida . Il risultato per base64 sarà sempre lo stesso, ovviamente.

(Questo è solo un'ipotesi, ma un educato. Si può sempre eseguire benchmark se si desidera convalidare esso ...)

+1

Il codice che dà ragione. [Implementazione] (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/Base64.java#Base64.Encoder.encodeToString%28byte%5B % 5D% 29) delega direttamente a ['String (byte [] ascii, int hibyte, int offset, int count)'] (http://docs.oracle.com/javase/8/docs/api/java/lang /String.html#String-byte:A-int-int-int-), un costruttore che è deprecato perché è utile solo per l'utilizzo di 'hibyte == 0' (leggi iso-latin-1), per il quale è presente un ciclo di copia ottimizzato. Quindi è un uso giustificato e ottimizzato in questo caso specifico. – Holger

+1

Anche se funzionerebbe bene se la * documentazione * dicesse che stava usando US-ASCII mentre si utilizzava la stessa implementazione. Ma dire "ISO-8859-1" nella documentazione è un buon indicatore per i potenziali implementatori, suggerendo che usare iso-latin-1 è preferibile rispetto all'utilizzo di ASCII qui ... – Holger

+1

@Holger: E sarebbe stato molto confuso per chiunque * stesse guardando * all'attuazione e ai documenti insieme :) –