Osoba podpisana jako Grzegorz Niemirowski <gnthexfiles@poczta.onet.pl> w
artykule <news:l5qc6k$due$1@node1.news.atman.pl> pisze:
Andrzej P. Wozniak <uszer@poczta.onet.pl.invalid> napisał(a):
Wiem, co zrobiłem, ale szybciej bym doszedł, gdybym popełnił błąd przy
odpowiadaniu komuś, kto nie korzysta z OEPT, bo ten, jak wiadomo,
ingeruje w referencje, co skierowało moje podejrzenia w złą stronę.
Na szczęście ingeruje tylko w ich długość, nie w kodowanie. Choć
z drugiej strony pewnie miałby problem z długimi referencjami
zakodowanymi w UTF-7.
Jeśli mnie pamięć nie myli, niektóre programy w referencjach walą kolejne
identyfikatory bez spacji, więc połapanie się w plusach i minusach może być
istotnym problemem. W związku z tym masz nowe zadanie - dodać do OEPT
naprawę pól nagłówków zakodowanych w UTF-7. Zwróć uwagę, że tylko pole
Subject jest poprawnie zakodowane, w pozostałych polach mamy sposób
kodowania właściwy dla treści, a nie dla nagłówka.
…i w ten sposób przez przypadek po tylu latach odkryłem kolejny błąd w
OE. Sprawdziłem – referencje koduje sam OE bez OEPT, oprócz tego
koduje też inne pola (Newsgroups, FUT, Keywords)
[...]
OE w UTF-7 koduje też pole Reply-to, ale to trafia jako pole "To: " do
oddzielnego emaila
[...]
Ciekawostka, prawda?
UTF-7 jest tak rzadko używane, że najwidoczniej nikomu w MS nie przyszło
do głowy wykonać testów OE z tym kodowaniem.
Nie wydaje mi się. Musieli coś sprawdzać dawno temu, bo UTF-7 w Outlook
Expressie jest do tej pory domyślnym kodowaniem Unikodowym (dla czytania).
Załóż nową tożsamość w OE i sprawdź.
--
Andrzej P. Woźniak uszer@pochta.onet.pl (zamień miejscami z<->h w adresie)
|