The process name of an internal UTM service appears garbled (mojibake) on macOS in a Japanese locale.

[kkdd]

Hello,
The process name of an internal UTM service appears garbled (mojibake) on macOS in a Japanese locale.

Expected process name:

• UTMの標準マシンサービス (= “UTM Standard Machine Service”)

Actual displayed process name:

• UTMの莉ｮ諠ｳ繝槭す繝ｳ繧ｵ繝ｼ繝薙せ

Configuration

• UTM Version: 4.7.5
• macOS Version: 15.7.3 macOS Sequoia
• Mac Chip : M4 Max

Environment
• OS: macOS (Japanese language environment)
• Locale: ja_JP
• System encoding: UTF-8
• Application: UTM for macOS
• Observed in:
• Activity Monitor
• Other process list tools (GUI or CLI such as ps, top)

Observed Behavior
• The display name of an internal UTM helper / service process is garbled.
• The process itself functions normally; only the displayed name is corrupted.
• The issue likely does not appear in English locales.

Expected Behavior
• The process name should be displayed correctly as UTF-8 in Japanese environments.
• Alternatively, it should fall back to a safe ASCII / English name rather than showing mojibake.

Technical Analysis (Suspected Root Cause)

This mojibake matches a well-known UTF-8 ⇄ Shift_JIS (CP932) misinterpretation pattern.

Likely transformation path:
1. The process display name is originally generated as UTF-8
2. At some point, it is misinterpreted as Shift_JIS (CP932)
3. The corrupted byte sequence is then rendered again as UTF-8

As a result:
標準 → 莉ｮ諠ｳ
マシン → 繝槭す繝ｳ
サービス → 繧ｵ繝ｼ繝薙せ

This is a classic Japanese mojibake signature.

Why This Likely Happens in UTM

UTM internally combines multiple technology layers with different string and locale models:
• Swift / Objective-C (UTF-16 / UTF-8)
• Rust (UTF-8)
• QEMU (C, locale-dependent)
• macOS launchd / LaunchServices

Potentially problematic areas:
• Process name generation via char * (C APIs)
• Missing or implicit setlocale() usage
• Assumptions of non-UTF-8 encodings in helper / QEMU-related code paths
• Multiple sources for process names (argv[0], CFBundleName, CFBundleDisplayName)

This kind of mixed stack makes encoding boundary issues more likely.

Impact
• No functional or security impact observed.
• However:
• Process monitoring becomes confusing for Japanese users
• Reduces readability and usability
• Indicates an internationalization (i18n) robustness issue

Suggestions / Possible Fixes
• Ensure that all process display names are:
• Explicitly handled as UTF-8 end-to-end, or
• Normalized to ASCII / English names
• Review C / QEMU code paths for locale and encoding assumptions
• Add test coverage or QA checks for ja_JP.UTF-8 environments

Notes

This appears to be an application-side internationalization issue, not a macOS OS bug.

If needed, I can also provide:
• A shorter issue template version
• A minimal UTF-8 ⇄ Shift_JIS reproduction example
• Code-level hints for where to apply fixes

This should be suitable for submitting directly to the UTM project.