imap kodowanie Opcje

[nospor]

Cześć, mam pewien problemi. Odbieram imapem wiadomości z gmaila.
Patrzę jaki ma encoding, na tej podstawie decoduje tekst.
Patrzę jakie ma kodowanie i na tej podstawie koduje na utf8, czyli np. z iso-8859-2 zamieniam na utf8

Do tej pory wszystko było ok. Ale dziś natrafiłem na maile, które zachowywałe się bardzo dziwnie.

Może przedstawię pseudokod jak do tej pory robiłem i było dobrze:

Kod

$body = 'Tutaj wiadomosc pobrana z imap';
jesli encoding = 1 to przepuszczaj wiadomosc przez imap_8bit()
jesli jest charset, to zamieniaj z danego charset na utf8

I to jak pisałem działało do dzisiaj.

Dziś trafiłem na wiadomość o treści: Cze?? czyli po poprawnym przekonwertowaniu ma wyjść Cześć.
Niestety, po przekonwertowaniu wychodzi: Cze=B6=E6
Wiadomośc jest w kodowaniu iso-8859-2 wiec te krzaczki to są odpowiedniki w iso polskich liter.
Jak się okazało, jeśli pominę krok:
"jesli encoding = 1 to przepuszczaj wiadomosc przez imap_8bit()"
to wiadomość jest poprawnie przekonwertowana.

No i teraz mam zagwostkę, bo niektóre maile wymagają by konwertować je w zależności od encoding, a inne jak ten okazało się że nie. Nie jestem w stanie znaleźć zależności, która mi powie, które konwertować a które nie.

Podam jeszcze atrybuty jakie zwraca imap dla tej wiadomosci:

[type] => 0
[encoding] => 1
[ifsubtype] => 1
[subtype] => PLAIN
[ifdescription] => 0
[ifid] => 0
[lines] => 19
[bytes] => 525
[ifdisposition] => 0
[ifdparameters] => 0
[ifparameters] => 1
[parameters] => Array
(
[0] => stdClass Object
(
[attribute] => CHARSET
[value] => ISO-8859-2
)

[1] => stdClass Object
(
[attribute] => FORMAT
[value] => flowed
)

)

)

[Bags_Bunny]

Otworzyłem właśnie email, który zawiera wiadomość w HTML oraz alternatywną w czystym tekście i wygląda na to, że obie części są zakodowane w inny sposób.
Konkretniej: część w text/plain (Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes) jest "czysta", natomiast część w text/html (Content-Type: text/html; charset=ISO-8859-1; Content-Transfer-Encoding: quoted-printable) zawiera dodatkowe znaki:

<td width=3D"626" valign=3D"top" style=3D"background-color: #FFFFFF;"><t=
able style=3D"border-spacing: 0px; font-family:Calibri, Verdana, Arial; fon=...

Spróbuj zwrócić uwagę na nagłówki Content-*.

[nospor]

Ależ ja właśnie patrze na Content dla każdej wiadomosci i dla czystego tekstu i dla html.
U ciebie dla html jest quoted-printable
U mnie przykładowo wiadomość ma encoding imap8. I jak zdekoduje ją przez imap8 tą nieporządany wynik. Gdy oleję imap8 to wszystko jest ok. Sęk w tym, że inne wiadomosci jak mają ustawione imap8 to należy przez imap8 przepuścić bo wtedy są one złe. I nie widzę tu żadnej zależnosci kiedy przepuszczać a kiedy nie skoro każda ma ustawione imap8

edit:
wstępna zależność jaką udało mi się ustalić jest taka, ze jak jest encoding imap8 to olewać to i nic nie dekodować. Jak jest inne encoding, to wówczas dekodować

Jak ktoś może coś do tego dodać to zapraszam

[abort]

@Bags_Bunny: Quoted-printable (QP) wstawia zakodowany znak za pomocą sekwencji: anak równości ("=") z następującym zaraz za tym znakiem kodem heksadecymalnym tego znaku. Przypadkiem się składa, że znak równości ma kod ASCII 61, czyli heksadecymalnie 3D. I kodowanie QP zamienia znak "=" na "=3D", POZORNIE dodając niepotrzebne znaki. Jedyny taki przypadek, ale dość charakterystyczny. I bardzo widoczny przy przesyłaniu HTMLi

@nospor: Ale, ale... Z manuala:
imap_8bit — Convert an 8bit string to a quoted-printable string
Czyli dekoduje Ci "Cześć" na "Cze=B6=E6" - i robi to zgodnie z założeniami i całkiem poprawnie. Pytanie jest inne: po co to dekodujesz do QP, skoro masz:

Kod

[0] => stdClass Object
(
[attribute] => CHARSET
[value] => ISO-8859-2
)

IMHO wiadomość jest "imap/8it", ale ta akurat część ma ściśle zdefiniowany format - wystarczy go odczytać i się do niego zastosować.

Na marginesie: na pierwszy rzut oka podejrzewałem jakiś "broken" mailer. Lata temu (za czasów wprowadzania ISO-8859-2) była taka sytuacja, że mailery (tudzież czytniki news) wysyłały znaki kodowane w ISO-8859-2, ale w nagłówku wstawiały na bezczelnego iso-8859-1 (albo wręcz us-ascii).

P.S.
@nospor: niepożądany

Ten post edytował abort 23.12.2011, 00:19:52

[nospor]

Pytanie jest inne: po co to dekodujesz

Jest podane encoding to decoduje tak jak jest podane. Tak jak napisałem wcześniej:

wstępna zależność jaką udało mi się ustalić jest taka, ze jak jest encoding imap8 to olewać to i nic nie dekodować. Jak jest inne encoding, to wówczas dekodować

czyli raz jest imap8 a raz inne. Jak jest inne to się okazało że trzeba decodować a jak imap8 to już nie trzeba. Być może to przez te święta się odmużdżam i nie widzę oczywistej jakiejś rzeczy