Lisp: Нужна помощь в получении правильного поведения из SBCL при преобразовании потока октетов в EUC-JP с искаженными байтами - PullRequest
2 голосов
/ 07 января 2009

Следующее не работает в данном конкретном случае, жалуясь, что все, что вы даете, не является символом.

(handler-bind ((sb-int:character-coding-error
                 #'(lambda (c)
                      (invoke-restart 'use-value #\?))))
    (sb-ext:octets-to-string *euc-jp* :external-format :euc-jp))

Где *euc-jp* - переменная, содержащая двоичный код текста в кодировке EUC-JP.

Я тоже пробовал #\KATAKANA_LETTER_NI вместо # \? а также просто "". Пока ничего не получалось.

Любая помощь будет принята с благодарностью!

РЕДАКТИРОВАТЬ: Чтобы воспроизвести *EUC-JP*, выберите http://blogs.yahoo.co.jp/akira_w0325/27287392.html, используя drakma.

Ответы [ 2 ]

1 голос
/ 08 января 2009

В SBCL 1.0.18 есть выражение mb-util.lisp, которое выглядит следующим образом:

(if code
    (code-char code)
    (decoding-error array pos (+ pos bytes) ,format
                    ',malformed pos))

Я не очень знаком с внутренностями SBCL, но это похоже на ошибку. Последовательность возвращает символ, в то время как альтернатива возвращает строку (независимо от того, что вы даете ему через USE-VALUE, она всегда преобразуется в строку с помощью функции STRING; см. Определение DECODING-ERROR в octets.lisp).

0 голосов
/ 07 января 2009

у меня работает:

CL-USER> (handler-bind ((sb-int:character-coding-error
                         #'(lambda (c)
                             (declare (ignore c))
                             (invoke-restart 'use-value #\?))))
           (sb-ext:octets-to-string (make-array '(16)
                                                :element-type '(unsigned-byte 8)
                                                :initial-contents '#(181 65 217 66 164 67 181 217 164 223 164 222 164 185 161 163))
                                    :external-format :euc-jp))
"?A?B?C休みます。"

Может ли *euc-jp* быть чем-то отличным от (vector (unsigned-byte 8))?

...