Text Encoder/Decoder

A text-encoding Swiss Army knife: Base64, URL percent-encoding, hex, ROT13, JSON string escaping, and character-set conversion, each in encode or decode direction. TextEncoderDecoder exists because the metadata you scrape out of images is rarely plain text - SillyTavern character cards are base64-encoded JSON, URLs hide percent-escapes, A1111 parameter blocks occasionally come with character-set mangling, and somewhere in a workflow you always end up staring at a string that needs un-wrapping before it means anything.

The controls, in the order you'll touch them:

• text - the input string (multiline).
• operation - 解码 (Decode) or 编码 (Encode). The UI labels are Chinese; they mean decode/encode.
• encoding_format - the format, six options: Base64, URL (Percent-Encoding), Hex, ROT13, JSON String Escape, 字符集转换 (Character Set).
• post_decode_unicode (default on) - a decode-mode extra that additionally runs the result through a latin-1 → unicode-escape pass to recover Unicode characters that a prior decode mangled. Sounds clever; it's also the single biggest source of confusion (see below).
• source_encoding / target_encoding (optional) - used only by the Character Set mode. Defaults are gbk → utf-8, which makes sense for this pack's audience: the author's ecosystem is Chinese-language, where GBK-encoded files are a daily reality.

The intended flow, from the pack's own examples: ImageMetadataReader pulls a chara field (a base64 blob of a JSON character card) → TextEncoderDecoder in Decode + Base64 unwraps it into readable JSON. One node, and a bunch of otherwise unreadable SillyTavern cards become usable text.

Now the trap, and it's a real one: post_decode_unicode will happily double-mangle already-correct output. Base64-decode of a UTF-8 string produces valid UTF-8 - and then the post-decoding pass re-interprets it as latin-1 and un-escapes it, which can corrupt CJK characters. The pack's own example workflow hits exactly this: the decode output is visibly broken until you realize the setting is fighting you. The rule of thumb: leave post_decode_unicode off for clean base64/URL/hex decode of modern UTF-8 data, and only flip it on when the source was genuinely double-encoded. When in doubt, run it both ways and compare.

Errors don't crash the node - a bad base64 string returns 处理错误: ... (processing error) as the output string, and Character Set conversion replaces unmappable characters rather than failing. It's robust, just not always right.

Install

ComfyUI Manager → search comfyui-spawner-nodes → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-spawner-nodes

Deps: piexif, pypng, xmltodict, all light and pure Python. No models. README is a stub; author spawner1145 is a Chinese-speaking dev known for a Wan2.1 SD extension.

Troubleshooting

• Decoded Chinese text comes out as garbage (\u escapes or mojibake) - post_decode_unicode is on and fighting you. Turn it off for UTF-8 base64.
• "Invalid base64-encoded string" - the input isn't valid base64 (wrong field, truncated data, or you're decoding a plain string by accident). Check what you wired in.
• Character Set output is full of ? - the source text isn't actually in source_encoding. gbk is a common guess that's often wrong for non-Chinese content; try utf-8 or latin-1.
• ROT13 "decodes" to the same thing twice - that's what ROT13 does. Encode and decode are the same operation. Not a bug.