Windows でテキスト ファイル (つまり、行末が CRLF のファイル) を読み取る関数があり、このファイルでread-lineを呼び出すと、CR で終わる文字列が取得され、これは SBCL または Clozure CL で終わります。MKCL では、CR と LF の両方が削除されます。
だから、どの実装が正しいのだろうか？
標準によると、主要な値である line は、読み取られる行であり、文字列として表されます (末尾の改行がない場合)。（ここを参照）。したがって、CR または LF が残っていないはずだと思いますが、私にはあまり明確ではありません。
もちろん、回避策はありますが、かなり面倒です。これがバグなのか、単に実装依存なのかを知りたいです。
CCL と SBCL は、Windows のサポートが比較的弱い CL 実装です。どちらも、CRLF が Windows の行末形式であることを認識していないようです。メンテナと議論することはできますが、これをサポートする必要はないと考える人もいるかもしれません。
正しいことは、行を読み取り、Windows で CRLF を適切に処理することです。Common Lisp には、行末文字が単一の NEWLINE 文字で表されるという考えがあります。NEWLINE は、Windows では CRLF にマップするのが最適です。いくつかの実装はそれを正しく行っています。
これを回避する 1 つの方法は、特別な外部形式でファイルを開くことです。CCL には次のようなものがあります。 http://ccl.clozure.com/manual/chapter4.5.htmlこれで、文字をトリミングする必要なく、通常どおりストリームを読むことができます。
SBCL と Clozure CL はUnicode Newline Guidelinesに違反していると言えます。
特定のプラットフォームで NLF を表す文字がわかっている場合でも、入力時および解釈時に、CR、LF、CRLF、および NEL を同じように扱ってください。出力時にのみ、それらを区別する必要があります。
ただし、戻り値をトリミングするのは間違った解決策だと思います。
正しい（Windows / CRLF）行終了モードでファイルに実装固有の:external-format引数を使用する必要があると思います。open