Importar fichas de personagem: o que realmente vai junto na mudança

Mover um personagem entre apps é um problema diferente de tirar os seus dados de um app. As conversas, a memória e as configurações ficam no banco de dados do serviço; o personagem costuma ser um artefato autônomo que você consegue segurar como arquivo. Essa diferença é o que torna as fichas dignas de atenção — uma ficha que é sua é a parte da sua configuração que sobrevive a um app encerrar as atividades, mudar de preço ou virar algo que você não quer mais usar.

O que é uma ficha de personagem como arquivo

Segundo as especificações da comunidade, uma ficha é um PNG (ou APNG) comum com a definição do personagem escrita em um bloco tEXt — um trecho de texto rotulado que visualizadores de imagem ignoram e que apps compatíveis leem. O JSON fica guardado em UTF-8 codificado em base64. Fichas de versão 1 e 2 usam um bloco chamado chara; as de versão 3 usam outro, chamado ccv3. Alguns apps também permitem exportar o mesmo objeto como um .json simples, que leva os mesmos dados sem a imagem de avatar.

A especificação V3 acrescenta um segundo contêiner, o CHARX (extensão .charx): um arquivo ZIP com card.json na raiz e um diretório assets/ ao lado, referenciado a partir da ficha por URIs embeded://. O CHARX existe porque uma ficha moderna pode trazer um conjunto de imagens de expressão, arte de fundo ou áudio, e nada disso cabe em um bloco de texto num tamanho razoável.

A consequência prática do desenho com dois blocos é que uma ficha pode estar completa e vazia ao mesmo tempo, dependendo de quem a lê. Um app que só conhece o bloco chara não enxerga nada em um arquivo somente V3. Na prática, ferramentas que gravam V3 costumam gravar os dois blocos, para que um único arquivo abra em clientes antigos e novos — mas isso é gentileza do app que exporta, não uma garantia do formato.

As três gerações, campo a campo

Saber de qual geração é a sua ficha já revela o que pode sobreviver a uma importação, antes mesmo de qualquer teste.

Dois detalhes das especificações pesam mais do que parecem. Primeiro, a V2 exige que editores não destruam pares chave-valor desconhecidos — o objeto extensions deve ser preservado mesmo por apps que não o entendem, com as chaves em espaços de nome por app para evitar colisões. Segundo, a V3 é um superconjunto estrito da V2, então existe um caminho de rebaixamento: um app pode preencher um objeto V2 a partir de uma ficha V3, mas os decoradores precisam ser removidos no processo. É exatamente aí que o comportamento muda sem que nenhum campo visível suma. Para que serve cada campo está em Anatomia da Ficha de Personagem.

O que sobrevive, o que degrada e o que nunca viaja

Separar o conteúdo de uma ficha em três grupos torna o risco concreto.

A última linha é a que surpreende no meio de uma migração. Exportar um personagem não é fazer backup de uma relação — a transcrição e qualquer memória de longo prazo que o app construiu para você são coisas à parte, geralmente mais difíceis de obter e muitas vezes não portáveis de forma aproveitável. Esse lado do problema está em Exportação de dados do app de companhia, e as razões do comportamento da memória estão em Memória e Continuidade.

Duas coisas mudam sem que ninguém mexa nelas. As fichas V3 trazem creation_date e modification_date como timestamps Unix, e a especificação manda os apps gravarem a data de modificação na exportação — então uma ficha que você só transferiu vai parecer editada depois, e a data de criação original passa a ser a única prova confiável de procedência. Se você mantém um arquivo das suas próprias fichas, anote a data antes de exportar, não depois.

Uma importação recusada também nem sempre significa ficha danificada. A especificação permite que um app rejeite de cara um arquivo CHARX por ser grande demais, estar corrompido, estar criptografado sem um meio de descriptografia compatível ou simplesmente não ser um zip válido. Se um app recusa um arquivo que outro abriu sem problema, teste-o primeiro como zip antes de dar o personagem como perdido.

Por que uma ficha importada com perfeição ainda se comporta diferente

Suponha que a transferência tenha sido sem perdas e que todos os campos chegaram intactos. O personagem ainda pode parecer outra pessoa, porque a ficha é apenas uma entre várias entradas. O app receptor fornece o próprio system prompt base, roda um modelo diferente, aplica os próprios ajustes de sampler e distribui de outro jeito a janela de contexto entre o lorebook e a conversa em andamento. Uma ficha que reservava mil tokens de detalhe de mundo em um app pode ver a maior parte disso cortada em outro.

Vale dizer isso com todas as letras, porque a reação comum é começar a editar a ficha — o que acaba quebrando-a no app de origem. Diagnostique a configuração primeiro. O método de comparação de Reescrevendo um personagem parado funciona aqui sem mudanças: mensagens de abertura fixas, uma variável por vez. Se as suas entradas de lorebook pararam de disparar, a causa provável é diferença de gatilho ou de orçamento de tokens, e não texto perdido — veja Construção de Mundo para Roleplay com IA.

Os apps que simplesmente não têm porta

Tudo acima pressupõe que os dois apps falam o formato de ficha. Boa parte dos apps de companhia voltados ao consumidor não fala. O personagem existe como linhas em um banco de dados, o editor mostra uma caixinha de descrição e não há botão de exportar — não porque o dado seja complexo, mas porque portabilidade não é um objetivo do produto. Julgar isso com justiça importa: um app fechado não é automaticamente pior, e muita gente nunca quer mudar de app. Mas isso muda o que você está assumindo ao passar semanas lapidando uma persona lá dentro.

Verifique a porta antes de precisar dela, não depois. Se um app oferece exportação de fichas, isso normalmente aparece nas configurações ou nas páginas de ajuda, e a exportação vai citar um formato. Se a palavra "exportar" não aparece em lugar nenhum, presuma que o personagem não é recuperável e guarde a sua própria cópia do texto que escreveu — um documento simples com descrição, personalidade e saudação é um backup tosco, mas eficaz, que nenhuma mudança de formato quebra. Quanto controle de edição cada app oferece já faz parte do que olhamos no ranking de apps, e a análise do MusePick examina um app focado em roleplay sob esse aspecto.

Checklist antes de migrar

1. Exporte no formato mais completo oferecido. Se houver PNG e JSON, leve os dois — o JSON é mais fácil de inspecionar e consertar, o PNG carrega o avatar.
2. Anote a geração. A janela de exportação costuma indicar V2, V3 ou CHARX. Se não indicar, o mais seguro é presumir V2.
3. Mantenha o arquivo original intocado. Reexportar pelo app receptor pode rebaixar em silêncio uma ficha V3 para V2, e não dá para recuperar decoradores a partir de uma cópia rebaixada.
4. Importe e leia o editor campo a campo. Compare com a ficha de origem: descrição, personalidade, diálogos de exemplo, saudações, número de entradas do lorebook. O que faltar aparece aqui, não no chat.
5. Rode três mensagens de abertura fixas. Uma leve, uma emocionalmente carregada e uma que peça iniciativa ao personagem — as mesmas três nos dois apps, para que uma diferença signifique algo.
6. Reconstrua o que o formato não conseguiu levar. Avatar e imagens de expressão, variações de saudação e as entradas de lorebook que não chegaram. Deixe por último, quando já souber o que realmente falta.

Feita nessa ordem, uma migração leva menos de uma hora e ensina algo duradouro: quais partes do seu personagem estavam no arquivo e quais estavam no app. Essa distinção é o conteúdo real da portabilidade, e vale conhecê-la antes de precisar. Se você está criando um personagem do zero já pensando em uma mudança futura, Criando o Seu Primeiro Personagem de Roleplay e Como Funcionam os Criadores de Personagem com IA tratam do que pertence à ficha, e não ao app.

Perguntas frequentes