hex/

Depende da codificação escolhida. Em UTF-8, um caractere chinês comum ocupa 3 bytes; por exemplo, 中 é e4 b8 ad. Em GBK e GB2312, ocupa 2 bytes, e 中 é d6 d0. Um emoji ocupa 4 bytes em UTF-8. Letras sem acento e dígitos ocupam 1 byte em UTF-8 e em GBK, então o resultado é o mesmo. Quando o resultado difere de outra ferramenta, confira qual codificação ela usa. Esta página usa UTF-8 por padrão.

Significa que os bytes não foram codificados com a codificação atual; tente outra. Para texto em chinês, as mais comuns são UTF-8 e GBK (softwares antigos e exportações de bancos de dados costumam usar GBK); o hex em UTF-16 geralmente tem muitos bytes 00. Esta ferramenta nunca exibe bytes indecodificáveis como lixo. A única exceção é o ISO-8859-1: cada byte corresponde a algum caractere, então nunca dá erro, mas texto em chinês vira caracteres embaralhados. GBK e GB2312 são decodificados com o decodificador GB18030 embutido no navegador, que é mais tolerante que o do Python ou do Java, então o GB2312 também decodifica caracteres que só existem no GBK. Se os bytes nunca foram texto (uma imagem, dados criptografados, um hash), nenhuma codificação vai decodificá-los.

Maiúsculas e minúsculas funcionam. Os bytes podem ser separados por espaços, quebras de linha, tabulações, dois-pontos, vírgulas ou hifens, ou vir sem nenhum separador, e cada byte pode começar com 0x ou \x; portanto, 0x48,0x65 e \x48\x65 são decodificados do jeito que estão. Cada grupo entre dois separadores precisa ter um número par de dígitos, então escreva 0x01 em vez de 0x1. Qualquer caractere diferente de 0-9 e a-f também gera erro. Os dois erros indicam a posição do caractere. Formatos como U+4E2D e %E4%B8%AD não são reconhecidos; para codificação de URL, use a ferramenta de URL deste site.

Defina o separador como "," e o prefixo como "0x" para obter 0x48,0x65, que você pode colocar em um array de bytes em C ou Java. Defina o separador como "Nenhum" e o prefixo como "\x" para obter \x48\x65, a notação de bytes usada em strings de Python e C. O prefixo é adicionado antes de cada byte, então "Nenhum" com 0x resulta em 0x480x65, o que raramente é útil. "Maiúsculas" afeta apenas a-f; o x de 0x continua minúsculo.

O UTF-16 segue o padrão do Java: começa com FE FF (a marca de ordem de bytes) e é big-endian, então 中 vira fe ff 4e 2d. O UTF-16BE sem a marca é 4e 2d; copie o resultado e apague os dois primeiros bytes. O UTF-32 é big-endian e não tem marca, então 中 é 00 00 4e 2d. Ao decodificar, o UTF-16 aceita FE FF (big-endian) ou FF FE (little-endian) no início e assume big-endian quando não há marca.

O ASCII cobre apenas de 0 a 127, e o ISO-8859-1 vai só até U+00FF (letras da Europa Ocidental com acento, sem caracteres chineses). Qualquer caractere fora dessa faixa gera um erro como “O caractere "中" não pode ser codificado em ASCII”, em vez de ser trocado em silêncio por ?, como faz o getBytes do Java. O GBK e o GB2312 se comportam do mesmo jeito: emojis e caracteres raros que não estão na tabela geram erro. Mude para UTF-8 ou GB18030 para convertê-los.

Na conversão de texto para hex, sim. Todo caractere da caixa de entrada é convertido, inclusive espaços e quebras de linha no início e no fim: o espaço é 20 e a quebra de linha é 0a. A caixa de texto do navegador normaliza as quebras de linha para \n, então uma quebra de linha em um texto de várias linhas vira 0a, e não 0d 0a; edite o resultado por conta própria se precisar de quebras de linha do Windows. Na conversão de hex para texto, os espaços em branco do hex são ignorados e só os bytes contam, e um 0d 0a no resultado também aparece como uma única quebra de linha.

Não. A conversão é feita no seu navegador, sem fazer nenhuma requisição de rede e sem salvar nada.