Unless a source file starts with a UTF-8 BOM, engines read it in a system-dependent encoding: MacRoman for BricsCAD on macOS, the locale’s ANSI code page on Windows (cp1252 in Western Europe), and clautolisp reads UTF-8. Accented characters in string constants therefore change meaning from one machine to another — unless the encoding is declared and handled.
Declare the encoding of your sources once for the whole system, and per file for exceptions:
(alpm-define-system 1
'(name "geometry"
encoding "utf-8"
files ("points"
"lines"
(file "legacy" encoding "cp1252"))))
Canonical names: ‘"ascii"’ (the default — reads identically everywhere), ‘"utf-8"’, ‘"utf-8-bom"’, ‘"cp1252"’, ‘"cp1250"’, ‘"cp1251"’, ‘"mac-roman"’ (also accepted as ‘"macroman"’, ‘"mac_roman"’, ‘"macintosh"’, ‘"x-mac-roman"’, ‘"cp10000"’).
When loading, ALPM compares each file’s declared encoding with what the running engine expects, and does what the situation requires: nothing when they match (or the file is ASCII), setting the load encoding where the engine supports that (clautolisp’s ‘*AUTOLISP-FILE-ENCODING*’), or converting the file to the engine’s expected encoding in a scratch directory and loading the converted copy. A declared encoding ALPM cannot honor on the current engine is a plan-time error — never silently corrupted characters.
To audit a system, run:
(alpm-check-encodings "geometry")
It flags files inconsistent with their declaration — in particular files declared (or defaulted to) ‘"ascii"’ that actually contain non-ASCII bytes, which is exactly the situation the declaration exists to prevent.
Note: generated loader files (Generating a Loader File) do no conversion; if your system needs conversion for the target engine, use ‘alpm-generate-distribution’ (a tree of pre-converted sources with the loader inside) or keep the sources in the engine’s native encoding.