Short answer
There is no confirmed, documented answer here. The Dyalog APL documentation available for your environment does not state whether ⎕LOGFILE writes UTF‑8 independently of the host console code page, and no system variable or option is documented for overriding log encoding. Any claim that the log is “always UTF‑8” would be an assumption, not a verified fact, so the practical path is to determine the encoding empirically on your own installation before relying on the log for diagnostics.
Likely explanation vs. confirmed facts
Confirmed: Dyalog APL represents character data internally as Unicode in its Unicode editions, and the console code page on the host (for example, Windows code page 1252 vs. 65001) affects how byte content is displayed, not necessarily how it is written.
Likely but unverified: A logging mechanism tied to the interpreter’s internal Unicode strings would plausibly emit UTF‑8, since that is the natural lossless serialization. However, some tools on Windows historically write text files in the system ANSI code page, and older interpreter releases may behave differently from current ones. Without a documentation statement or a byte-level check on your version, treat the encoding as unknown.
Answering the three sub-questions
- Does ⎕LOGFILE always encode in UTF‑8 regardless of the console code page? Not established. Assume it might follow the host code page until you verify otherwise.
- Can the encoding be overridden? No documented system variable or option is known for this. If you need guaranteed UTF‑8, the safe workaround is to write critical diagnostics yourself with
⎕NPUT, which does take an explicit encoding option, rather than depending on the deployment log.
- Will already-logged entries appear garbled, and can they be corrected? Garbling is almost always a display-side misinterpretation, not corruption. If the bytes on disk are valid UTF‑8 but a viewer applies the console code page, re-opening the file with UTF‑8 explicitly selected fixes the display. If the file was genuinely written in an ANSI code page, the bytes are still recoverable by re-interpreting them with that code page — true data loss only occurs if characters were unrepresentable at write time.
How to determine the actual encoding on your system
- Force a log entry containing a distinctive non‑ASCII character, e.g. the check mark “✓” (U+2713), in a deployment failure message.
- Open the resulting log file in a hex editor. If you see the three-byte sequence
E2 9C 93, the file is UTF‑8. A single byte such as 0x9C or a replacement character would indicate an ANSI code page write instead.
- Optionally, change the console code page (
chcp 1252 vs. chcp 65001 on Windows) and repeat the test to see whether the written bytes change with the console setting.
Caveats
Behavior may differ between Dyalog versions and platforms, and release notes for your specific version are the authoritative source — this answer reflects general reasoning, not version-specific documentation. If you can share your Dyalog version and operating system, the recommendation (rely on ⎕LOGFILE vs. mirror diagnostics via ⎕NPUT) can be made more definite.
dyalog