procmail 키릴 문자 변환

Question

에 대해 이야기하고 있는 것 같습니다.RFC 2047: 이메일 헤더의 MIME 인코딩. 그 이후로 이 RFC는 추가 RFC에 의해 확장되어 추가 문자 집합을 허용하고 선택적으로 언어 사양을 포함합니다.

원래 이메일 및 MIME 사양에는 헤더에 엄격한 US-ASCII만 포함되어 있다는 가정이 포함되어 있었기 때문에 헤더 인코딩은 메시지 본문의 MIME 인코딩과 완전히 별개의 문제입니다.

형식은 다음과 같습니다.

=? <character-set> [*language] ? <encoding-letter> ? <text> ?=

<encoding-letter>Q(인쇄 가능한 인용문의 경우) 또는 B(base64 인코딩의 경우)입니다. 메시지가 완전히 의미 없는 것처럼 보인다면 base64가 표시되고 있는 것입니다. 문자 세트 이름이나 인코딩 문자 모두 대소문자를 구분하지 않습니다.

따라서 다음을 볼 수 있습니다.

Subject: =?utf-8?b?SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=?=

또는 언어 ID를 추가하세요.

Subject: =?utf-8*en?b?SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=?=

수동 디코딩 예:

$ echo "SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSB1bmRlcnN0b29kIHRoZSBleGFtcGxlLgo=" | base64 -d
If you can read this, you understood the example.

기존 Procmail 스크립트에 강제 태그 문자 세트 인코딩이 포함되어 있다는 사실은 iso-8859-1실제 문제가 잘못 태그된 문자 인코딩일 수 있음을 나타 US-ASCII냅니다 UNKNOWN-8BIT. windows-1251다시 말해서:

이전 이메일 클라이언트는 windows-1251키릴 문자를 내보내지만 헤더에 키릴 문자로 표시하지 않습니다.
그 과정에서 이메일은 8비트 메일 인코딩을 깔끔하게 처리할 수 있다고 제대로 선언하지 않거나 일반 US-ASCII 이외의 모든 문자 집합에 대해 태그를 적용하려는 메일 서버를 통과합니다.

이 경우 MTA는 메시지를 전달하기 위해 8비트 문자를 인코딩하고 태그를 지정해야 합니다. 그러나 8비트 문자에 태그가 지정되지 않은 경우 원래 메일 클라이언트만 문자 집합이 실제로 무엇인지 확인할 수 있습니다.

사실 이후에 문자 세트에 레이블을 지정하는 문제는 문자 세트를 식별하려면 콘텐츠가 특정 문자 세트로 해석되는 것이 적합한지 알기 위해 인간 수준의 이해가 필요할 수 있다는 것입니다. 그래서 때로는 잘못된 경험적 방법을 사용하게 됩니다.

예를 들어, 실제로 로 올바르게 인코딩된 이메일을 받은 경우 iso-8859-1스크립트는 이를 로 잘못 표시 windows-1251하여 북유럽/서유럽 악센트 문자가 임의의 의미 없는 키릴 문자로 표시되도록 합니다. 그러나 windows-1251잘못 표시된 인코딩된 메시지를 받는 것보다 더 드문 경우 iso-8859-1라면 위험을 감수하기로 선택할 수도 있습니다. 괜찮습니다.

헤더가 실제로 어떻게 인코딩되었는지 알아보려면 문제의 메시지를 조사해야 할 것 같습니다 Subject:. 그들은:

라벨이 없는 일반 windows-1251?
base64실제로 유효한 UTF-8 인코딩 입니까 ?
아니면 인코딩되어 UTF-8로 잘못 태그가 지정 windows-1251되었나요 ?base64

안타깝게도 procmail해당 컴패니언만으로는 인코딩되지 않은 형식의 헤더를 formail얻기에 충분하지 않을 수 있습니다 . Subject:그들은 가지고 있다2001년 이후로 유지되지 않음, 그리고심지어 저자조차도 이제 다른 것으로 전환할 것을 권장합니다.. 하지만 procmail지금 계속 사용하려면 다음 스크립트와 같은 것이 필요합니다.

https://github.com/akkana/scripts/blob/master/decodemail.py

저는 약 10년 동안 중요한 스크립팅을 수행하지 않았기 procmail때문에 아래 예가 틀렸을 수도 있고, 이를 수행하는 더 좋은 방법이 있을 수도 있습니다. 하지만 문제 해결 방법을 설명하는 데 도움이 될 수도 있습니다.

먼저 Subject:헤더의 내용을 디코딩하여 변수에 저장해야 합니다.

:0 h
SUBJDECODED=| decodemail.py Subject:

:0 h
SUBJWASRAW=| formail -xSubject: | recode windows-1251..UTF-8

잘못 표시된 인코딩을 수정하려면 실제 문자 세트의 문자 세트를 시스템에서 사용하는 UTF-8로 다시 인코딩해야 할 수도 있습니다.

SUBJWASWIN1251=`echo "$SUBJDECODED" | recode windows-1251..UTF-8`

가능한 인코딩이 여러 개 있는 경우 이러한 변수를 여러 개 만들어야 할 수도 있습니다.

그런 다음 테마의 모든 버전과 일치시킬 수 있습니다.

:0
* SUBJWASRAW ?? your-subject-regexp-here
{
    # Here the subject was raw windows-1251 without any encoding at all.
    # The variable has it converted to valid UTF-8 used by this system,
    # so now the header can be rewritten in an useful form.
    # (This example leaves the subject as raw unlabelled UTF-8 which 
    # may or may not be acceptable to whatever you use to view your email with.
    # But on modern RFC 6532 compliant mail clients 
    # in a system that uses UTF-8 throughout it may actually be OK.)

    :0 f
    | formail -i "Subject: $SUBJWASRAW"
}

:0
* SUBJWASWIN1251 ?? your-subject-regexp-here
{
    # regexp matched, so we know the subject was windows-1251 
    # mislabeled as UTF-8. Fix it.
    :0 f
    | formail -i "Subject: $SUBJWASWIN1251"
}

:0
* SUBJDECODED ?? your-subject-regexp-here
{
    # regexp matched to subject decoded according to existing label
    # so we know that it was validly labelled. But it still needs to
    # be rewritten as it may have been something other than UTF-8.
    :0 f
    | formail -i "Subject: $SUBJDECODED"
}

# Any further rules should be able to match on the subject as usual.

참고: 변수에는 접두사만 your-subject-regexp-here포함되므로 정규식에는 접두사가 포함되어서는 안 됩니다.^Subject:.*값제목 Subject:.

Answer 1