文本比较丨匹配
Three string equality checks in one node, and the empty-string trap inside it
- 结果1
- 结果2
- 结果3
A workflow that asks an LLM to make a decision usually ends with a string: "yes", "no", "style A", "style B". To turn that verdict into an actual branch, you need an equality check - and TextCompare gives you three of them in one node. Feed it up to three (text, compare) pairs and it hands back three independent booleans you can route on.
Display name: "文本比较丨匹配" ("text compare / match").
How it works
For each of the three pairs, the node does a plain string equality test. The single toggle, case_sensitive (default false), decides the flavor: with it off, both sides are lowercased before comparing, so "Hello" matches "hello". With it on, it's exact byte-for-byte.
The three pairs are fully independent. Pair 1's result doesn't influence pair 2 or 3. If you only need one comparison, leave the other two unwired - which brings us to the trap.
The empty-string trap
Here's the footgun nobody mentions on the tin: an unwired pair compares empty to empty, and "" == "" is True. Both text_2 and compare_2 default to empty strings, so if you leave pair 2 disconnected, 结果2 comes out True. Not "unused" - true. If you wire one of your booleans into a router expecting it to mean "match," a phantom True from an unused pair can silently take a branch you never asked for.
The fix is simple: only read the output indexes you actually wired, or connect both sides of every pair you want live. It's the kind of thing that bites once, mysteriously, then you remember it forever.
Inputs and outputs
case_sensitive(required) - the only required input. Off by default.text_1/compare_1…text_3/compare_3(optional) - three comparison pairs.结果1/结果2/结果3(outputs, BOOLEAN) - the three results, independent of each other.
It's an output node, so it always runs - good for a workflow where this check is the decision point.
What to wire it into
The natural downstream is the pack's condition-routing family: take a boolean from TextCompare, feed it to a router or switch, and let it choose between branches. It's the same "graph as a small program" pattern that the whole logic-node layer is built on (comfyui-node-plumbing.md). A concrete chain: LLM node says "yes"/"no" → TextCompare checks against "yes" → boolean gates your sampler choice. For string→boolean specifically, the pack's StringToBool node is the more general sibling - TextCompare is for when the comparison is the logic.
Installing it
TextCompare ships in ComfyUI-QING:
cd ComfyUI/custom_nodes
git clone https://github.com/GAO-SHIQING/ComfyUI-QING
cd ComfyUI-QING
python install_dependencies.py
Restart ComfyUI. Or install "ComfyUI-QING" via ComfyUI Manager.
Troubleshooting
- Result is True when you expected a mismatch. Check for an unwired pair - the empty-string trap above. Also remember the default is case-insensitive, so
"Red"vs"red"is a match unless you flipped the toggle. - Result is False when it should match. With
case_sensitiveon, whitespace matters - a trailing newline from a multiline source breaks exact equality. There's nostrip()here like there is on the StringToBool node.
Three comparisons, three booleans, one toggle. Just don't leave empty pairs dangling and expect them to be inert.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| case_sensitive | BOOLEAN | false | — |
| text_1opt | STRING | — | |
| compare_1opt | STRING | — | |
| text_2opt | STRING | — | |
| compare_2opt | STRING | — | |
| text_3opt | STRING | — | |
| compare_3opt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| 结果1 | BOOLEAN | — |
| 结果2 | BOOLEAN | — |
| 结果3 | BOOLEAN | — |