Mover un personaje entre apps es un problema distinto de sacar tus datos de una app. Las conversaciones, la memoria y los ajustes viven en la base de datos del servicio; el personaje suele ser un artefacto autónomo que puedes tener en la mano como archivo. Esa diferencia es lo que hace que valga la pena entender las cards: una card que es tuya es la parte de tu configuración que sobrevive a que una app cierre, cambie de precios o se convierta en algo que ya no quieres usar.
Qué es una character card como archivo
Según las especificaciones comunitarias, una card es un PNG (o APNG) corriente con la definición del personaje escrita en un bloque tEXt: un fragmento de texto etiquetado que los visores de imágenes ignoran y que las apps compatibles leen. El JSON se guarda en UTF-8 codificado en base64. Las cards de versión 1 y 2 usan un bloque llamado chara; las de versión 3 usan otro llamado ccv3. Algunas apps permiten exportar el mismo objeto como un .json plano, que lleva los mismos datos pero sin la imagen del avatar.
La especificación V3 añade un segundo contenedor, CHARX (extensión .charx): un archivo ZIP con card.json en la raíz y un directorio assets/ al lado, referenciado desde la card mediante URI embeded://. CHARX existe porque una card moderna puede incluir un juego de imágenes de expresiones, arte de fondo o audio, y nada de eso cabe en un bloque de texto con un tamaño razonable.
La consecuencia práctica de tener dos bloques es que una misma card puede estar completa y vacía a la vez, según quién la lea. Una app que solo conoce el bloque chara no ve nada en un archivo que sea únicamente V3. En la práctica, las herramientas que escriben V3 suelen escribir ambos bloques para que un mismo archivo se abra en clientes antiguos y nuevos, pero eso es una cortesía de la app que exporta, no algo que el formato garantice.
Las tres generaciones, campo por campo
Saber de qué generación es tu card te dice qué puede sobrevivir a una importación antes incluso de probar nada.
| Formato | Dónde vive | Qué lleva | Límite principal |
|---|---|---|---|
| V1 | bloque chara | Seis campos planos: nombre, descripción, personalidad, escenario, primer mensaje y diálogos de ejemplo | Sin lorebook, sin system prompt, sin variantes de saludo |
| V2 | bloque chara, con los campos anidados en data | Todos los campos V1 más notas del creador, system prompt, instrucciones posteriores al historial, saludos alternativos, un character book incrustado, etiquetas, creador, versión del personaje y un objeto libre extensions | Sin lista de assets; extensions es específico de cada app por diseño |
| V3 | bloque ccv3 | Todo lo de V2 más una lista de assets, apodo, notas del creador multilingües, lista de fuentes, saludos exclusivos de grupo y decoradores de lorebook como la profundidad de inserción y las reglas de activación | Invisible para quien solo mira chara |
| CHARX | ZIP con card.json + assets/ | Una card V3 más los archivos de imagen y audio que referencia | Solo sirve si la app receptora sabe descomprimirlo |
Dos detalles de las especificaciones importan más de lo que parece. Primero, V2 exige que los editores no destruyan pares clave-valor desconocidos: el objeto extensions debe conservarse incluso en apps que no lo entienden, con las claves en un espacio de nombres por app para evitar colisiones. Segundo, V3 es un superconjunto estricto de V2, así que existe un camino de bajada: una app puede rellenar un objeto V2 a partir de una card V3, pero los decoradores se eliminan en el proceso. Justo ahí es donde el comportamiento cambia sin que falte ningún campo a la vista. Para qué sirve cada campo se explica en Anatomía de una character card.
Qué sobrevive, qué se degrada y qué nunca viaja
Repartir el contenido de una card en tres grupos hace que el riesgo se vea concreto.
| Grupo | Contenido | Por qué |
|---|---|---|
| Viaja siempre | Nombre, descripción, personalidad, escenario, primer mensaje y diálogos de ejemplo | Son los campos V1; prácticamente cualquier app compatible los lee |
| Viaja si el lector es lo bastante nuevo | System prompt, instrucciones posteriores al historial, saludos alternativos, lorebook incrustado, etiquetas y metadatos del creador | Añadidos de V2: un importador que solo entiende V1 simplemente los ignora |
| Se degrada en silencio | Decoradores del lorebook, assets e ilustraciones de expresiones, saludos de grupo y extensions con espacio de nombres | Se pierden o se aplanan cuando una card V3 se lee como V2, o cuando un CHARX lo importa un cliente que solo entiende PNG |
| Nunca viaja | Historial de conversación, memoria generada por la app, elección de modelo, ajustes del sampler y estado de la suscripción | Nada de eso forma parte de la card; vive en el servicio |
La última fila es la que sorprende a mitad de una migración. Exportar un personaje no es hacer copia de seguridad de una relación: la transcripción y la memoria a largo plazo que la app construyó para ti son cosas aparte, normalmente más difíciles de obtener y a menudo no portables en un formato aprovechable. Ese lado del problema se trata en Exportar los datos de tu app de compañía, y las razones del comportamiento de la memoria están en Memoria y continuidad.
Hay dos cosas que cambian sin que nadie las toque. Las cards V3 guardan creation_date y modification_date como marcas de tiempo Unix, y la especificación indica a las apps que escriban la fecha de modificación al exportar: una card que solo moviste parecerá editada después, y la fecha de creación original queda como la única prueba fiable de procedencia. Si guardas un archivo de tus propias cards, anota la fecha antes de exportar, no después.
Que una importación sea rechazada tampoco significa siempre que la card esté dañada. La especificación permite que una app rechace de entrada un archivo CHARX si es demasiado grande, está corrupto, está cifrado sin una vía de descifrado compatible o simplemente no es un zip válido. Si una app rechaza un archivo que otra abrió sin problemas, pruébalo primero como zip antes de dar al personaje por perdido.
Por qué una card importada a la perfección se comporta distinto
Supongamos que el traslado fue sin pérdidas y que todos los campos llegaron intactos. El personaje puede seguir pareciendo otro, porque la card es solo una de varias entradas. La app receptora aporta su propio system prompt base, ejecuta un modelo distinto, aplica sus ajustes de sampler y reparte de otra forma la ventana de contexto entre el lorebook y la conversación en curso. Una card que presupuestaba mil tokens de detalle de mundo en una app puede ver cómo se recorta la mayor parte en otra.
Conviene decirlo con claridad, porque la reacción habitual es ponerse a editar la card, lo que acaba rompiéndola en la app de origen. Diagnostica primero la configuración. El método de comparación de Reescribir un personaje estancado funciona aquí sin cambios: mensajes de apertura fijos y una variable cada vez. Si tus entradas del lorebook han dejado de dispararse, la causa probable es una diferencia de disparador o de presupuesto de tokens, no un texto perdido: consulta Construcción de mundos para el rol con IA.
Las apps que directamente no tienen puerta
Todo lo anterior da por hecho que ambas apps hablan el formato card. Buena parte de las apps de compañía de consumo no lo hacen. El personaje existe como filas de una base de datos, el editor ofrece una casilla de descripción corta y no hay botón de exportar: no porque el dato sea complejo, sino porque la portabilidad no es un objetivo del producto. Juzgarlo con justicia importa: una app cerrada no es automáticamente peor, y mucha gente nunca quiere mudarse. Pero sí cambia a qué te estás comprometiendo cuando pasas semanas puliendo un personaje dentro de ella.
Comprueba si hay puerta antes de necesitarla, no después. Si una app ofrece exportación de cards, normalmente lo dirá en los ajustes o en la ayuda, y la exportación indicará un formato. Si la palabra "exportar" no aparece por ningún lado, da por hecho que el personaje no es recuperable y guarda tu propia copia del texto que escribiste: un documento simple con la descripción, la personalidad y el saludo es una copia de seguridad tosca pero eficaz que ningún cambio de formato puede romper. Cuánto control de edición te da cada app forma parte de lo que miramos en el ranking de apps, y la reseña de MusePick analiza una app centrada en el rol desde esta perspectiva.
Lista de comprobación antes de mudarte
- Exporta en el formato más completo disponible. Si te ofrecen PNG y JSON, llévate ambos: el JSON es más fácil de inspeccionar y reparar, el PNG conserva el avatar.
- Anota la generación. El diálogo de exportación suele indicar V2, V3 o CHARX. Si no lo dice, lo más seguro es suponer V2.
- Guarda el archivo original sin tocar. Volver a exportar desde la app receptora puede degradar en silencio una card V3 a V2, y los decoradores no se recuperan de una copia degradada.
- Importa y luego lee el editor campo por campo. Compara con la card de origen: descripción, personalidad, diálogos de ejemplo, saludos, número de entradas del lorebook. Lo que falte aparece aquí, no en el chat.
- Lanza tres mensajes de apertura fijos. Uno ligero, uno con carga emocional y uno que pida al personaje tomar la iniciativa; los mismos tres en ambas apps, para que una diferencia signifique algo.
- Reconstruye lo que el formato no pudo llevar. Avatar e imágenes de expresiones, variantes de saludo y las entradas del lorebook que no llegaron. Déjalo para el final, cuando ya sepas qué falta de verdad.
Hecho en ese orden, una migración lleva menos de una hora y te enseña algo duradero: qué partes de tu personaje estaban en el archivo y cuáles estaban en la app. Esa distinción es el contenido real de la portabilidad, y conviene conocerla antes de necesitarla. Si estás creando un personaje desde cero pensando en una futura mudanza, Crea tu primer personaje de rol y Cómo funcionan los creadores de personajes con IA cubren qué debe ir en la card y no en la app.
Relacionado en CompanionRank
Anatomía de una character card Exportar los datos de tu app de compañía Construcción de mundos para el rol con IAPreguntas frecuentes
¿Puedo mover una character card de una app a otra?
Solo si ambas apps hablan el mismo formato de card. Las apps construidas sobre las especificaciones comunitarias de character cards leen y escriben archivos PNG con el JSON de la card incrustado dentro, así que una card exportada desde una suele abrirse en otra. Muchas apps de compañía de consumo no exponen ningún archivo de card, y en ellas el personaje no puede sacarse por ninguna vía oficial.
¿Cuál es la diferencia entre una character card V2 y una V3?
V2 envuelve los seis campos originales de V1 dentro de un objeto data y añade system prompt, instrucciones posteriores al historial, saludos alternativos, un lorebook incrustado, etiquetas, metadatos del creador y un objeto extensions. V3 es un superconjunto de V2: conserva todos sus campos y añade una lista de assets, un apodo, notas del creador multilingües, una lista de fuentes, saludos exclusivos de grupo y decoradores de lorebook. V3 se guarda en un bloque distinto, así que una card solo V3 puede parecer vacía para un lector que solo entienda V2.
¿Por qué mi personaje importado se comporta distinto en la app nueva?
La card es solo una de varias entradas. La app nueva aporta su propio system prompt, modelo, ajustes de sampler y presupuesto de contexto, y puede recortar o ignorar campos que no implementa. Un personaje que se lee idéntico en ambos editores puede producir respuestas distintas, y eso es una diferencia de configuración, no una importación rota.