A revised version of ASDF replacing the system definition :encoding support with support for reading the encoding from file options is now available at: http://www.scieneer.com/files/asdf.lisp
Changes:
* Can read the file options in a wider range of files. Also supports C, Python, XML, and probably others. It's more robust and may be of some utility in other code.
* EBCDIC support removed to save on the line count. Can add this back at a cost of about 40 lines.
* UTF-8 detection removed to save on the line count. Still detects a UTF-8 BOM, and reads a UTF-8 encoding file option. Adding a UTF-8 encoding file option will help other tools too anyway.
* Removed the lengthy external-format translation table to save on the line count. It should be easy for CL implementations to include more aliases so move the burden of maintaining the aliases to the CL implementation. CLISP and the Scieneer CL already support an extensive range of codes and aliases, and an update set of aliases has been sent for CMUCL. SBCL, ECL, and CCL all have a useful set of aliases, but could consider adding a few more. A hook is include for translating the external-formats just in case it is needed, and it is a list of functions to call in turn so multiple projects could add hooks.
* Changed the asdf.lisp coding file option to us-ascii from utf-8 - it's a highly portable tool and this should be adequate.
* This version is now down to just 114 lines more than the standard version, and the bulk of the code is just one function.
* Tested on CCL, CLISP, CMUCL, ECL, SBCL, and Scieneer CL,
* Added a large set of test files that exercise the reading of the encoding file option and try to include enough characters from each character set to check that the encoding option has been successful mapped to an appropriate external-format. This includes all the encoding in linux 'iconv -l' that include support for the characters needed by CL, but excludes the EBCDIC codes. All 629 tests pass on the Scieneer CL, 628 on CLISP, and a much smaller but useful sent on CCL, CMUCL, ECL, and SBCL due to their limited aliases and limited encoding support. See: http://www.scieneer.com/files/coding-tests.tar.bz2
Keep in mind that even if a library author chooses an encoding that your CL implementation does not support, if they have added the encoding file option then the files can be reliably and automatically converted to something supported such as UTF-8. There may be a tool out there already in the Emacs or Python community to do this, or something can be written and could run on CLISP which is free and has extensive coding support.
Regards Douglas Crosher