CFR and Procyon displayed Cyrillic

[b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0]

Problem: In Recaf 4, CFR and Procyon displayed Cyrillic in decompiled output as \u0414..., while the class file and search still showed the correct text.

Solution: Post-process decompiler output via UnicodeUnescapeOutputTextFilter in the DecompilerManager pipeline; default hideutf=false (CFR) and isUnicodeOutputEnabled=true (Procyon).

Tests: EscapeUtilTest.unescapeCyrillicUnicodeEscapes, updated FoldingDeobfuscationTest.

[1050TIt0p]

This was definitely missing

[Col-E]

I'd have to dig through my samples folder but I'd like to make sure there aren't any negative effects with certain naming schemes (like whitespace-only bs, right-to-left spam, etc) - Any idea if these changes would affect those? IIRC it was stuff like that which led me to make the defaults false.

[b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0]

I'd have to dig through my samples folder but I'd like to make sure there aren't any negative effects with certain naming schemes (like whitespace-only bs, right-to-left spam, etc) - Any idea if these changes would affect those? IIRC it was stuff like that which led me to make the defaults false.

Yes, you're right to be concerned.

I tested exactly those cases (whitespace-only names, ZWSP, RTL/bidi overrides, exotic whitespace etc.).

With the selective filter:

• Trick characters like \u200B, \u202E and similar stay escaped — they are still clearly visible as \uXXXX, same as before.
• Normal readable text (Cyrillic, etc.) gets properly unescaped.

I also made sure the filter is completely skipped when hideutf=true (CFR) or unicode output is enabled (Procyon), so your original defaults are fully respected.

No negative effects on obfuscation samples.

[KwilzOne]

That really was a problem; it's not convenient to use the search function with such an output, without the Cyrillic characters being displayed naturally