|
240 | 240 | "Detail.format/eml.attachment_size": { "hash": "sha256-c6ca8985e21d", "other": "Jak duży jest każdy załączony plik. Wiadomość rośnie o mniej więcej jedną trzecią więcej, bo załączone pliki są przesyłane w base64." }, |
241 | 241 | "Detail.format/eml.attachments": { "hash": "sha256-43c96b5ef075", "other": "Ile plików niesie wiadomość. Gdy pliki nie są jednakowe, użyj zamiast tego contains. mailparser odmawia wiadomości z więcej niż 1000 encji MIME, a manifest podaje ich liczbę dla tej wiadomości jako mime_entities." }, |
242 | 242 | "Detail.format/eml.body": { "hash": "sha256-5dc479375b75", "other": "Jaki tekst niesie wiadomość. zwykły tekst to jedna część tekstowa, a html jedna część HTML. tekst i html niesie obie z tymi samymi słowami, a program pocztowy pokazuje jedną z nich." }, |
243 | | - "Detail.format/eml.charset": { "hash": "sha256-5bc40079d024", "other": "Zestaw znaków tekstu, gdy kodowanie tekstu nie jest 7bit. iso-8859-2 i windows-1250 mają polski i nie mają japońskiego, a litery ą, ś i ź zapisują innymi bajtami, więc program, który bierze jeden za drugi, pokazuje złe litery. MimeKit czyta oba jako Latin-1, dopóki nie zarejestruje się dostawcy stron kodowych, a poprawnie, gdy jest zarejestrowany. Biblioteka standardowa Go nie przekształca żadnego zestawu znaków. Przy 7bit tekst jest czystym ASCII i mówi us-ascii, bez względu na to ustawienie." }, |
| 243 | + "Detail.format/eml.charset": { "hash": "sha256-636bf249f436", "other": "Zestaw znaków tekstu, gdy kodowanie tekstu nie jest 7bit. iso-8859-2 i windows-1250 mają polski i nie mają japońskiego, a litery ą, ś i ź zapisują innymi bajtami, więc program, który bierze jeden za drugi, pokazuje złe litery. MimeKit bez zarejestrowanego dostawcy stron kodowych próbuje UTF-8, a potem Latin-1, więc w obu pokazuje polskie litery źle, a poprawnie, gdy dostawca jest zarejestrowany. Biblioteka standardowa Go nie przekształca żadnego zestawu znaków. Przy 7bit tekst jest czystym ASCII i mówi us-ascii, bez względu na to ustawienie." }, |
244 | 244 | "Detail.format/eml.filename_style": { "hash": "sha256-adf72ea5fcb6", "other": "Jak zapisane są nazwy załączonych plików i obrazków. rfc2231 to sposób standardowy. rfc2047 to forma kodowana, której RFC 2047 zabrania wewnątrz nazwy, a wiele czytników i tak ją dekoduje. oba zapisuje obie, a content-type umieszcza nazwę tylko tam, gdzie szukały jej stare programy pocztowe. brak nie zapisuje nazwy wcale, a program, który jej potrzebuje, musi ją wymyślić - Thunderbird 157 nazywa je Part 1.2, Part 1.3 i tak dalej. Biblioteka standardowa Go nie czyta nazwy z content-type, a z rfc2047 oddaje sam zakodowany tekst. Gdy headers nie jest ustawione na kodowane, nazwa jest zapisana tak, jak jest, i zmienia się tylko jej miejsce, więc rfc2047 i oba zapisują te same bajty." }, |
245 | 245 | "Detail.format/eml.headers": { "hash": "sha256-5002e2b42e63", "other": "Czy temat, nazwy nadawcy i odbiorcy oraz nazwy załączonych plików mają litery spoza ASCII, i jak są zapisane. kodowane zapisuje je tak, jak każą RFC 2047 i RFC 2231. utf8 zapisuje je tak, jak są (RFC 6532), a pakiet email Pythona czyta to i zgłasza defekt w liniach From i To." }, |
246 | 246 | "Detail.format/eml.inline": { "hash": "sha256-65d689f88414", "other": "Ile obrazków pokazuje tekst. Przy html oraz tekst i html każdy leży obok HTML-a, a HTML wskazuje go przez cid:. Przy zwykłym tekście nie ma HTML-a, z którego można by wskazać, więc obrazki idą za tekstem jako obrazki do pokazania w treści. mailparser wpisuje je na listę załączników, pakiet email Pythona robi to, gdy HTML jest sam, a MimeKit nigdy." }, |
|
0 commit comments