Sin más contexto, diría que el número máximo de bytes para un carácter en UTF-8 es
respuesta: 6 bytes
El autor de la respuesta aceptada señaló correctamente esto como la "especificación original". Eso era válido a través de RFC-2279 1 . Como J. Cocoe señaló en los comentarios a continuación, esto cambió en 2003 con RFC-3629 2 , que limita UTF-8 a la codificación de 21 bits, que se puede manejar con el esquema de codificación usando cuatro bytes.
respuesta si cubre todo unicode: 4 bytes
Pero, en Java <= v7 , ¿hablan de un máximo de 3 bytes para representar unicode con UTF-8? Esto se debe a que la especificación Unicode original solo definía el plano multilingüe básico ( BMP ), es decir, es una versión anterior de Unicode o un subconjunto de Unicode moderno. Entonces
respuesta si representa solo unicode original, el BMP: 3 bytes
Pero, el OP habla de ir al revés. No de caracteres a bytes UTF-8, sino de bytes UTF-8 a una representación de "Cadena" de bytes. Quizás el autor de la respuesta aceptada obtuvo eso del contexto de la pregunta, pero esto no es necesariamente obvio, por lo que puede confundir al lector casual de esta pregunta.
Pasando de UTF-8 a la codificación nativa, tenemos que ver cómo se implementa la "Cadena". Algunos lenguajes, como Python> = 3, representarán cada carácter con puntos de código enteros, lo que permite 4 bytes por carácter = 32 bits para cubrir los 21 que necesitamos para Unicode, con algo de desperdicio. ¿Por qué no exactamente 21 bits? Porque las cosas son más rápidas cuando están alineadas por bytes. Algunos lenguajes como Python <= 2 y Java representan caracteres que utilizan una codificación UTF-16, lo que significa que tienen que utilizar pares sustitutos para representar unicode extendido (no BMP). De cualquier manera, sigue siendo un máximo de 4 bytes.
respuesta si va UTF-8 -> codificación nativa: 4 bytes
Entonces, conclusión final, 4 es la respuesta correcta más común, así que lo hicimos bien. Pero el kilometraje puede variar.