Fórumok
Sziasztok! Érdekes hibát produkál a Thunderbird. A levelezésben XML fájlt csatolok egy új levélhez. Elküldés után az xml fájl módosul egy rövid, 20-30 karakter hosszú sorral (-------------- dXZxX3pvjmlmbzg880ZXQOez--) a végén. XML fájl: <?xml version="1.0" encoding="Windows-1250"?> <...> akármi </> -------------- dXZxX3pvjmlmbzg880ZXQOez-- A legújabb verziót használom. 91.1.0 Az xml-t egy program generálja, eddig nem volt gond. Az elküldésnél egy automata olvasná be csak mivel megjelenik a végén a beszúrt kód ezért hibás a beolvasás. Ezek a karakterek minden alkalommal megváltoznak, amikor e-mailt küldök. Letiltottam az összes bővítményt, és víruskeresést végeztem, de a hiba továbbra is fennáll. Miért van ez a kód a fájl végén? Miért ír bele a levelező az XML melléklethez küldéskor. Más fájltípusoknál nem találtunk ilyen hibát. Köszönöm a segítséget
Hozzászólások
Küldöd a mellékletet tartalmazó levelet vagy továbbítod?
Küldöm, új levelet nyitok felcsatolom mellékletbe azt mehet. A felcsatolás után még jó az xml. Az elküldés után már belekerül az xml végére a változó kód. Ugyanezt a fájlt másik három gépről küldve rendben befogadják. Nincs hiba. A levelezőt már kitöröltem, újratelepítettem.
ez a karaktersorozat a mime kontenetizaciobol adodik, ez jelzi a kontenerek hatarat
ha az elkuldott fajlt a cimzett tb-el menti le, akkor van benne/akkor is benne van ez a karaktersorozat? mert akkor tb hibanak tunik.
neked aztan fura humorod van...
Ez az új sor nem más, mint a MIME multipart Content-Type határolója, ez mondja meg, hogy mikor kezdődik és meddig tart egy MIME multipart csatolmány tagja.
Lásd: https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1
A beolvasód rossz, nem kezeli a MIME határokat multipart Content-Type esetén.
Ezen kívül szeintem illene lezárnod az XML utolsó sorát egy újsor karakterrel.
Köszönöm a segítséget, az xml részt lehet hogy valóban, rosszul írtam az eredeti fájlban jól van generálva, a végén lévő a sor a kérdés, hogy kerül oda. Az email program hibás? Már újratelepítettem.
A végén lévő sor a MIME multipart boundary. Az teljesen jó helyen van ott, ott KELL lennie, az jelzi a többi kliens számára, hogy a MIME csatolmány hol ér véget. Mondom, olvasd el a MIME szabványt, nagyon jól leírja, hogy hogyan kezelik a rendszerek a multipart MIME üzeneteket.
Ez a levelformatum szabvanya, az elvalaszto mime "tag" kerul bele a csatolmanyba. Ha akarsz debuggolni, akkor megprobalhatod txt fajllal, xml-lel de mas kiterjesztest adsz neki, 20 karakteres xml-lel, lassuk mit ront el. Megoldast a thunderbird dev csapat tud adni, ha csinalsz egy issue-t naluk.
Szerk: kuldd zippelve, azt nem rontja el vagy a zip megoldja.
Szerk2: most latom hogy egy automata olvassa be. A thunderbird-hez semmi koze, az automata (az mi?) kezeli rosszul a levelet.
Az automata a címzett rendszerében lévő feldolgozó szoftver ami beolvassa a rendszerébe érkező xml fájlokat. Mivel a levélküldés során az xml fájlban megjelenik a fenti hiba nem tudja értelmezni szabványos xml-ként a fogadó rendszer. Az a furcsa ha másik 3 gépről hasonló rendszerből ( levelező ugyanaz, oprendszer ugyanaz, minden ugyanaz ) küldöm a levelet ezzel az xml melléklettel nincs hiba. 1 gépnél van gond. A rendszert nem akarom újratelepíteni ezért :D - de lehet ez lesz már amennyi időt elvisz már :D
Lathato a felado oldal formátuma, a fogado oldal kodjanak ismereteben orvosolhato a problema. Sok levelezo szepen dolgozza fel a thunderbird "hibajat", ez az automata nem ezt teszi. Az automatan konnyebb lehet modositani, javitani.
Még egyszer: az XML file nem módosul. Az szépen ott marad a helyén.
Amit te látsz, az az úgynevezett MIME boundary, a multipart üzeneteknél ez a határoló, ami megmondja, hogy az adott csatolmány meddig tart.
Ha megnézed a leveledet, fentebb lesz benne egy olyan rész, hogy
Ez alapján tudja bármelyik helyesen működő kliens, hogy az XML csatolmány mikor kezdődik, és meddig tart.
A te feldolgozód nem ilyen, nem képes kezelni helyesen a MIME multipart üzeneteket.
A Thunderbuird szabványosan jár el, jól kezeli a dolgokat, NEM módosítja az XML-t. Csak éppen a feldolgozó oldal fos, nem szabványkövető, emiatt a szabványos e-mailekkel nem tud mit kezdeni.
Valószínűleg a probléma az, hogy a feldolgozód soronként dolgozza fel a MIME üzenetet, és leszarja a MIME multipart boundary-t. És azt hiszi, hogy az XML file kezdeze a <?xml> kezdetű sorban van, a vége pedig a </> sorban, és az adott sorban nincs más. Ez csak akkor igaz, ha az XML file-od újsor karakterrel záródik. Ugyanis ekkor a MIME boundary a következő sor elejére kerül. Ha nem újsor karakter a vége az XML állománynak, akkor a MIME boundary (nagyon helyesen) nem kerül új sorba.
Azt nézd meg, ha már ilyen balfasz a feldolgozó programod, hogy miért áll elő olyan XML, aminek a legutolsó sora nem újsor karakterrel ér véget. Itt van a problémád (a fostartyál feldolgozóprogramon kívül), az XML előállításában, nem a Thunderbirdben.
Köszönöm a hozzászólásokat.
Az elküldés után megnyitom az elküldött levél mellékletében lévő xml-t és belekerül a határolókód a végébe. Van még 10 gépem hasonló paraméterekkel oprendszerrel, levelezővel, víruskeresővel azokról küldve az xml fájt, minden ok.
Például van olyan a levelezőprogramban (most ne a Kitekintő Gyorsvonatra gondoljunk), hogy Nézet/Forrás, abban kellene összehasonlítani a jó meg rossz emaileket.
Nem az email a rossz, hanem az összetákolt program, amivel beolvasná.
Valószínűleg. Biztos akkor lesz, ha sikerül rendesen kielemezni a hibát.
Pl. végeztem egy tesztet Thunderbird-del (Win, 78.14), egy sorvége nélkül meg egy sorvégés xml-fájllal, itt látható a különbség. Vagyis nem látható, mert nincs különbség:
Üdv!
Pontosan ebbe a hibába futottunk bele mi is! Ez szerintem Thunderbird bug! Nálunk is XML-t csatolunk és ebben az esetben a TBird küldés után rosszul kódol valamit, mert az elküldött levél forráskódja már hibás. A túloldal is ezt a mime-elválasztót az XML fájl végének látja. Találtál-e rá esetleg megoldást azóta?
Fura, hogy nemzetközi fórumokon még nem találtam nyomát ennek a hibának. Lehet, hogy a magyar karakterkódolással lesz kapcsolatban a dolog?
Üdv,
TG
Nem tudtok publikalni egy levelet itt? Tehat azt es abban a formatumban ahogy a postaladaban elhelyezkedik, pl a szerveren? Szerintem itt "csak" annyi a bibi, hogy a fogado oldalon, hibasan feltetelezik, hogy a mime boundary uj sorban kezdodik.
Itt sajnos nem fogadó oldalon van a gond. Pl. sima gmail-re küldve is látszik az XML csatolmány, letöltöd gmailből az XML-t és benne van a mime elválasztó. TBird hibásan rakja össze a levél forrását (szerintem tuti valami kódolási probléma lesz az XML miatt) és a címzetti oldal a szabány alapján ezt a hibás mellékletet hámozza ki belőle.
Részletek az elküldött levél forrásából:
Fejlécben:
...
Content-Type: multipart/mixed; boundary="------------qa7n0aFegbP9XXTAkEFRpi6b"
...
aztán később a szöveges üzenetrész vége és az XML kezdete így néz ki, ez is ok:
...
Fax.: + ***
Mobil.: + ***
Web.: www.***.hu
--------------qa7n0aFegbP9XXTAkEFRpi6b
Content-Type: text/xml; charset=windows-1250; name="mpefj_0020145658_210922121803_N001.xml"
Content-Disposition: attachment; filename="mpefj_0020145658_210922121803_N001.xml"
Content-Transfer-Encoding: 8bit
...
És itt a gond, mert a levél forrásának a vége pedig ez:
...
</mpl_csomag>
</nyilvantartott_tetelek>
</tomeges_adatok>
</jegyzek_adat>--------------qa7n0aFegbP9XXTAkEFRpi6b--
--------------qa7n0aFegbP9XXTAkEFRpi6b--
Tehát KÉTSZER szerepel benne a boundary!
Szerintem ez egyértelmű TBird bug.