Ich erlebe es immer wieder: nach dem Download z.B. eines .tar.gz-Archivs öffnet sich der Texteditor und mault, er könnte mit dem Format nichts anfangen. Allerdings sind die Fälle häufiger, in denen sich das passende Programm nach dem Download öffnet. Was ist der Unterschied?
Meine Glaskugel sagt: Der Webserver sendet den falschen MimeType.
Meine Glaskugel stimmt dem zu.
Meine auch. @Uhu: Auf der Festplatte entscheidet sich die SW anhand der Dateiendung. Nun sind ".tar.gz" aber keine Dateiendung, das sind nur die letzten Zeichen der URL. Daher schaut der Browser auf den MimeType im HTTP-Response-Header. Die letzten Zeichen der URL könnten auch …oller.net sein. Da kommt dann z.B. der MimeType HTML onhne *.html-Endung. Das ist nicht nur bei Linux (siehe Betreff) so, sondern immer. Probiere es mit Windows aus, dann wissen wir, ob unsere Glaskugeln Recht hatten.
:
Bearbeitet durch User
Die Datei war ein Update für LibreOffice - die sollten doch eigentlich wissen, wie man das richtig macht? Windos hab ich keins.
:
Bearbeitet durch User
Hast du mal einen Link? Dann könnte man sich den http-Header mal anschauen.
https://www.libreoffice.org/download/download/?lang=de&version=5.3.7 Dort die 64-Bit deb-Version auswählen.
Hmm, da ist es etwas schwierig, sich das anzuschauen. Der erste Link macht eine Webseite auf, auf der dann ein weiterer Download-Link automatisch geöffnet wird: http://download.documentfoundation.org/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz Der wiederum verweist auf mehrere Mirrors. Die geben dann unterschiedliche Mimetypes zurück. Bei https://mirror1.hs-esslingen.de/pub/Mirrors/tdf/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz ist es z.B.:
1 | HTTP/1.1 200 OK |
2 | Date: Thu, 11 Jan 2018 20:41:33 GMT |
3 | Server: Apache/2.4.29 (Fedora) |
4 | Last-Modified: Wed, 13 Dec 2017 20:44:43 GMT |
5 | ETag: "10b7e664-5603ed64d40d5" |
6 | Accept-Ranges: bytes |
7 | Content-Length: 280487524 |
8 | Keep-Alive: timeout=10, max=500 |
9 | Connection: Keep-Alive |
10 | Content-Type: application/x-gzip |
Bei https://mirror.kumi.systems/tdf/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz dagegen ist es:
1 | HTTP/1.1 200 OK |
2 | Server: nginx |
3 | Date: Thu, 11 Jan 2018 20:44:32 GMT |
4 | Content-Type: application/octet-stream |
5 | Content-Length: 280487524 |
6 | Last-Modified: Wed, 13 Dec 2017 20:44:43 GMT |
7 | Connection: keep-alive |
8 | ETag: "5a31913b-10b7e664" |
9 | Strict-Transport-Security: max-age=63072000; includeSubDomains; preload |
10 | X-Frame-Options: SAMEORIGIN |
11 | X-Content-Type-Options: nosniff |
12 | X-XSS-Protection: 1; mode=block |
13 | Accept-Ranges: bytes |
Es kann also je nach Mirror auch noch unterschiedliches passieren.
Rolf M. schrieb: > Es kann also je nach Mirror auch noch unterschiedliches passieren. Ich habe eben mal 3 Downloads angekickt und wieder abgebrochen, nachdem ich gesehen hatte, womit die Datei anschließend geöffnet werden soll: 2 mal wars korrekt der Archiver, einmal der Editor. Der Server mirror.kumi.systems war der Übeltäter.
:
Bearbeitet durch User
Uhu U. schrieb: > Ich erlebe es immer wieder: nach dem Download z.B. eines .tar.gz-Archivs > öffnet sich der Texteditor ... > Allerdings sind die Fälle häufiger, in denen sich das passende Programm > nach dem Download öffnet. Das hat nichts mit Linux zu tun, sondern in erster Linie mit dem Programm, das den Download durchführt. Die normal zu erwartende Aktion (und immer auch eine auswählbare Option) ist das Abspeichern der Datei auf der Festplatte. Wobei man dann auch einen Ordner (vulgo: Directory) vorgeben kann. Natürlich kann man einen Firefox oder Crome oder $YOUNAMEIT auch kaputt konfigurieren. Und vielleicht kann ein Webbrowser sogar den Mimetype, den der Webserver sendet, für die Auswahl der Aktion verwenden (obwohl es schlauer ist, den Mimetype nach dem Download anhand des Inhalts der Datei festzustellen). Sag uns also, was genau du machst, dann können wir dir auch raten.
Axel S. schrieb: > Sag uns also, was genau du machst, dann können wir dir auch raten. Das kannst du doch oben nachlesen... Ich lade den Update herunter und anschließend öffnet sich ein Programm, das dieses .tar.gz-Ding weiterverarbeiten soll. Einer von zwei Servern, den die Downloadseite irgendwie auswählt, schickt den falschen Mime-Type und die Folge ist, dass nicht der Archiver gestartet wird, sondern der Editor - der Server hat FF angelogen. Ich beobachte das nicht nur bei LibreOffice, sondern immer wieder bei allem möglichen anderen Zeug. Weiß der Teufel, warum gepackte Dateien immer wieder als application/octet-stream gesendet werden. > dann können wir dir auch raten. Ich kann da gar nichts machen, außer die Serverbetreiber auf den Fehler hinzuweisen. Obs was hilft, steht in den Sternen.
:
Bearbeitet durch User
Bei Firefox kann man das Verhaltune von heruntergeladenen Dateien unter "Einstellungen" -> "Anwendungen" einstellen.
Das ist aber nutzlos, wenn der Server einen falschen Mime Type übermittelt.
Uhu U. schrieb: > Das ist aber nutzlos, wenn der Server einen falschen Mime Type > übermittelt. Aber nur wenn er das tatsächlich tun würde. "application/octet-stream" ist völlig korrekt für eine downloadbare Datei. Mein FF fragt bei obigem Link z.B. ob er die Datei mit 7zip öffnen oder irgendwohin speichern soll.
guest schrieb: > "application/octet-stream" ist völlig korrekt für eine downloadbare Datei. Nicht für ein zip-Archiv...
Uhu U. schrieb: > guest schrieb: >> "application/octet-stream" ist völlig korrekt für eine downloadbare Datei. > > Nicht für ein zip-Archiv... Naja, sagen wir mal so: Falsch ist es nicht direkt, aber sinnvoll auch nicht. Letztendlich könnte man im Prinzip für alles, was irgendwie download- oder übertragbar ist, application/octet-stream angeben, denn es ist ja prinzipiell ein Stream aus Oktetts. Das würde allerdings den Sinn und Zweck von Mimetypes ad absurdum führen.
Uhu U. schrieb: > Axel S. schrieb: >> Sag uns also, was genau du machst, dann können wir dir auch raten. > > Das kannst du doch oben nachlesen... > > Ich lade den Update herunter Mit welchem Programm tust du das? Wenn ich ein Update zu irgend etwas herunter lade, dann nehme ich bevorzugt die Paketverwaltung (für mich also aptitude). Und für generelle HTTP-Download am ehesten wget:
1 | $wget http://download.documentfoundation.org/libreoffice/stable/5.4.4/deb/x86_64/LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz |
2 | ... |
> und anschließend öffnet sich ein Programm, > das dieses .tar.gz-Ding weiterverarbeiten soll. Bei mir nicht.
1 | ... |
2 | HTTP request sent, awaiting response... 302 Found |
3 | Location: ... |
4 | Resolving mirror.irq1.org (mirror.irq1.org)... 88.198.84.4 |
5 | Connecting to mirror.irq1.org (mirror.irq1.org)|88.198.84.4|:80... connected. |
6 | HTTP request sent, awaiting response... 200 OK |
7 | Length: 280487524 (267M) [application/x-gzip] |
8 | Saving to: ‘LibreOffice_5.4.4_Linux_x86-64_deb.tar.gz’ |
Es gibt einen HTTP-Redirect. Dem läuft wget hinterher. Und das File vom Mirrorserver legt es brav im aktuellen Verzeichnis ab. Was anderes sollte es tun? Und: selbst wenn dein Browser etwas anderes macht: willst du das wirklich? Was ist jetzt gleich nochmal der Vorteil, wenn du den Inhalt des .tar.gz in einem "Archiver" (ich traue mich gar nicht zu fragen, was du damit meinst) anzeigt? Wolltest du nicht eigentlich das Update installieren? Tut das dein "Archiver"? Ach, nein? Sowas!1!elf!! > der Server hat FF angelogen. OMG! Call The Police! The Scoundrel Lied!!!1!eins > Ich beobachte das nicht nur bei LibreOffice, sondern immer wieder bei > allem möglichen anderen Zeug. Weiß der Teufel, warum gepackte Dateien > immer wieder als application/octet-stream gesendet werden. Der Fehler liegt nach wie vor auf deiner Seite. Weil dein Browser (welcher, verdammt noch mal, wie oft soll ich noch fragen?) den Content-Type "application/octet-stream" glaubt, an einen Texteditor (LOL?!) weitergeben zu müssen. Der MIME Type sollte eigentlich selbsterklärend sein. Aber sei es drum. "application" steht für "application defined" aka "anwendungsspezisch" und "octet stream" für "Folge von Bytes". Ich bin mir gerade nicht sicher was man in welcher Menge getrunken haben muß, um das für die geeignete Eingabe für einen Texteditor zu halten. Aber gesundheitsfördernd ist das sicher nicht. > Ich kann da gar nichts machen Na klar. Du kannst deinen Browser passend konfigurieren. Wiewohl ich gerade lernen durfte, daß Firefox kein Werkzeug zum (sinnvollen) Bearbeiten der Zuordnung von MIME-Type und Action an Bord hat. Oder als Extension. So glaubt mein Firefox bspw. daß application/octet-stream ein PDF-Dokument sei (keine Ahnung wie der darauf kommt). Und es gibt keine Möglichkeit, ihn mit Bordmitteln diese Verknüpfung vergessen zu lassen. OK, ich kann ein .RDF File editieren. Du solltest dich vielleicht bei den Firefox-Leuten beschweren (lies: einen Bugreport schreiben). OH, verzeih. Da bin ich doch glatt davon ausgegangen, daß du Firefox benutzt. Obwohl du das so konsequent verschwiegen hast. Aber auch wennn du den so grauenhaft verstümmelten Firefox Browser benutzen solltest, kannst du trotzdem (unter Edit->Preferences, Reiter "applications") die Action für application/octet-stream auf (sinnvollerweise) "save file" stellen. Notfalls halt "Always ask".
Uhu U. schrieb: > Nicht für ein zip-Archiv... Doch, auch für Zip ist das prinzipiell korrekt: https://www.iana.org/assignments/media-types/application/octet-stream [pre] The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. {/pre] Und das trifft definitiv auch auf .gz Dateien zu. Geneu genommen macht es sogar der andere Server auf jeden Fall verkehrt. "application/x-gzip" war vor Urzeiten eine Idee in irgendeinem Draft, die seit mindestens 5 Jahren obsolet ist. Korrekt wäre eigentlich "application/gzip". Generell sind alle "x-" Typen 'deprecated', wenn schon unregistrierte Typen verwendet werden, dann mit "x." Die offiziell registrierten Typen gibt es hier: https://www.iana.org/assignments/media-types/media-types.xhtml
guest schrieb: > Geneu genommen macht es sogar der andere Server auf jeden Fall verkehrt. Eine .tar.gz ist ein geziptes tar-Archiv. Entsprechend enthält es eine Sammlung von zig .deb-Files und eine Readme, die beschreibt, wie man den Inhalt installiert. Nachdem Firefox diese Datei heruntergeladen hat, ruft er das zum Mimetype gehörige Programm auf und das ist für .tar.gz definitiv nicht der Editor - das macht der andere Server also definitiv richtig. Wenn also der Archiver gestartet ist, entpackt man den Inhalt sinnvollerweise nach /tmp, liest die Readme und führt das dort aufgeführt dpkg aus - fertig ist die Laube. Dazu muss man nicht mit wget rumfrickeln.
Uhu U. schrieb: > das macht der andere Server also definitiv richtig. Nö, der liefert einen ungültigen content type. Wenn dann Dein Browser trotzdem was sinnvolles zaubert hast Du einfach nur Schwein, ändert aber nichtsd daran, daß der Server nicht den eigenlich richtigen Typ ohne das "x-" vor dem "gzip" liefert. Und wenn Du Deine Konfiguration so dermaßen versaust, daß Dein Browser mit dem allgemeineren, aber trotzdem korrekten "application/octet-stream" nichts anfangen kann, dann gib nicht dem Server die Schuld sondern bring erstmal Deinen eigenen Mist in Ordnung.
guest schrieb: > Uhu U. schrieb: >> Nicht für ein zip-Archiv... > > Doch, auch für Zip ist das prinzipiell korrekt: > https://www.iana.org/assignments/media-types/application/octet-stream > [pre] > The "octet-stream" subtype is used to indicate that a body contains > arbitrary binary data. > {/pre] Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch einfach komplett weglassen. Das wäre genauso informativ. Also: Korrekt, aber nutzlos. > Und das trifft definitiv auch auf .gz Dateien zu. Wenn der Server aus dem Mittelalter kommt, könnte man sich vielleicht vorstellen, dass er mit gzip-Files nun mal so gar nix anzufangen weiß und deshalb sagen muss: "Keine Ahnung, sind halt irgendwelche Bytes mit Daten drin..."
Zur Lösung des Problems: du hast deinem Browser wahrscheinlich einmal gesagt, dass er application/octet-stream mit einem Editor öffenen soll. Dies musst du einfach wieder rückgängig machen. Im Firefox geht das unter Preferences -> Applications, nach octet-stream suchen und Einstellung entsprechend ändern.
Rolf M. schrieb: [application/octet-stream] > Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine > Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch > einfach komplett weglassen. Das wäre genauso informativ. > Also: Korrekt, aber nutzlos. Falsch. Es bedeutet "das sind Binärdaten, für die es keine wohldefinierte Interpretation in diesem Kontext gibt". Und das wird seit ewigen Zeiten für Daten genutzt, die primär für den Download, also die uninterpretierte Speicherung auf Client-Seite, gedacht sind. > >> Und das trifft definitiv auch auf .gz Dateien zu. > > Wenn der Server aus dem Mittelalter kommt, könnte man sich vielleicht > vorstellen, dass er mit gzip-Files nun mal so gar nix anzufangen weiß > und deshalb sagen muss: "Keine Ahnung, sind halt irgendwelche Bytes mit > Daten drin..." Oder dass der Admin des Servers das eben besser wusste. Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man das am saubersten eben als "application/x.tar" (wenn es denn dafür eine Registrierung gäbe) mit einem transport-encoding "gzip" verwenden. Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu, dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst weiterverabeitet werden. Und Download-Daten will man üblicherweise in der komprimierten Form speichern, nicht in der dekomprimierten - was der Browser eigentlich als einzige Möglichkeit anbieten kann (außer der direkten Weiterverarbeitung), da die Umkehrung der Transport-Kodierung ja von Browser zu erledigen ist. :-( Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes tar-Archiv" (denn es aber AFAIK nicht gibt). Dann könnte man clientseitig sinnvoll zwischen einfacher Speicherung des komprimierten Archivs oder seiner Verarbeitung durch irgendein anderes Programm entscheiden. Und wenn es so einen speziellen Typ für die Anwendungsdaten nicht gibt, dann verwendet man dafür seit ewigen Zeiten ... TADA ... eben genau "application/octet-stream". Working as designed - wenn man nicht am Client Mist konfiguriert (wie ja auch schon von anderer Seite angemerkt wurde).
Ralf D. schrieb: > Rolf M. schrieb: > [application/octet-stream] >> Also zu deutsch in etwa: Das ist irgendwas, und ich hab absolut keine >> Ahnung, was da drin stecken könnte. Da könnte man den Content-Type auch >> einfach komplett weglassen. Das wäre genauso informativ. >> Also: Korrekt, aber nutzlos. > > Falsch. Es bedeutet "das sind Binärdaten, für die es keine > wohldefinierte Interpretation in diesem Kontext gibt". Das ist die gleiche Aussage, nur nicht umgangssprachlich formuliert. > Und das wird seit ewigen Zeiten für Daten genutzt, die primär für den > Download, also die uninterpretierte Speicherung auf Client-Seite, gedacht > sind. Das sollte meiner Meinung nach auf Client-Seite entschieden werden und nicht auf Serverseite. Warum muss mir denn der Server vorschreiben, dass ich das nicht einfach direkt vom Browser aus öffnen darf, sondern es erst irgendwo speichern, dann in einem separaten Fenster dorthin navigieren, draufklicken und nach der Installation wieder manuell löschen muss? > Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man > das am saubersten eben als "application/x.tar" (wenn es denn dafür eine > Registrierung gäbe) mit einem transport-encoding "gzip" verwenden. Du meinst vermutlich Transfer-Encoding, aber um sowas geht es doch gar nicht. Transfer-Encoding dient dazu, dass der Server es beim Senden on-the-fly komprimieren kann und der Empfänger dann weiß, dass er es erstmal wieder dekomprimieren muss, um an das Original zu kommen. Hier ist aber das Original bereits gzip-komprimiert. > Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu, > dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst > weiterverabeitet werden. Ja, weil Transfer-Encoding das völlig falsche Mittel dafür ist. > Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes > tar-Archiv" (denn es aber AFAIK nicht gibt). Den bräuchte man. Müsste dann am ehesten sowas wie application/tar+gzip sein. Wobei es einen gzip-Suffix wohl auch bisher nicht gibt.
:
Bearbeitet durch User
Rolf M. schrieb: [...] >> Und das wird seit ewigen Zeiten für Daten genutzt, die primär für den >> Download, also die uninterpretierte Speicherung auf Client-Seite, gedacht > > sind. > > Das sollte meiner Meinung nach auf Client-Seite entschieden werden und > nicht auf Serverseite. IBTD. Wer Daten bereitstellt, der hat dabei ja eine gewisse Intention, und die beeinflußt natürlich auch, wie er die Daten bereitstellt. Bei EMails kannst du z.B. als Absender entscheiden, ob Attachment inline gezeigt oder extern gespeichert werden sollen. > Warum muss mir denn der Server vorschreiben, dass > ich das nicht einfach direkt vom Browser aus öffnen darf, sondern es > erst irgendwo speichern, dann in einem separaten Fenster dorthin > navigieren, draufklicken und nach der Installation wieder manuell > löschen muss? Das kannst du natürlich machen, nur sagt hier eben der Publisher via Server/MIME-Type, daß diese Daten primär nicht zur Darstellung/Verwendung im Browser (ggfls. mittels Hilfsprogramm) gedacht sind, sondern für externe Verwendung. Ob du die speicherst, via Datenträger auf ein anderes Gerät überträgst und dort dann installierst oder direkt vom Browser aus an ein Installationsprogramm verfütterst ist ganz alleine deine Entscheidung (hängt halt von der konkreten Client-Implementierung ab). >> Klar, das ist ein komprimiertes tar-Archiv, aber rein formal würde man >> das am saubersten eben als "application/x.tar" (wenn es denn dafür eine >> Registrierung gäbe) mit einem transport-encoding "gzip" verwenden. > > Du meinst vermutlich Transfer-Encoding, ACK > aber um sowas geht es doch gar > nicht. Transfer-Encoding dient dazu, dass der Server es beim Senden > on-the-fly komprimieren kann und der Empfänger dann weiß, dass er es > erstmal wieder dekomprimieren muss, um an das Original zu kommen. Hier > ist aber das Original bereits gzip-komprimiert. Jein. Das Transfer-Encoding kann gerade bei komprimierten Daten auch bei vorkomprimierten Daten zur Anwendung kommen. Man muß also kein x.tar auf dem Server lagern, das dann on-the-fly mittels gzip komprimiert wird, sondern kann dies genauso gleich mit x.tar.gz machen. BTDT, ist nicht unüblich, da es auf dem Server natürlich Rechenleistung spart. >> Dummerweise führt das dann aber mit sehr hoher Wahrscheinlichkeit dazu, >> dass auf Client-Seite die Daten erst einmal dekomprimiert und dann erst >> weiterverabeitet werden. > > Ja, weil Transfer-Encoding das völlig falsche Mittel dafür ist. > >> Also bräuchte man eher einen MIME-Type für "gzip-komprimiertes >> tar-Archiv" (denn es aber AFAIK nicht gibt). > > Den bräuchte man. Müsste dann am ehesten sowas wie application/tar+gzip > sein. Wobei es einen gzip-Suffix wohl auch bisher nicht gibt. Eben. Und damit landen wir dann wieder beim klassischen Fallback "application/octet-stream". Muss man halt einfach so hinnehmen, dessen Semantik nach Jahrzehnten ändern zu wollen, wäre unrealistisch und kontraproduktiv.
Angehängte Dateien:
-
Screenshot.png
26 KB -
Screenshot-1.png
31 KB -
Screenshot-2.png
29 KB
guest schrieb: > Und wenn Du Deine Konfiguration so dermaßen versaust, Die habe ich nie angefaßt. Das Profil, das ich benutze ist allerdings schon ziemlich alt - von einer Linux-Version zur nächsten migriert... Im Übrigen bringt ja der zweite Server, der dieselbe Datei verbreitet als Mimetype application/x-gzip. Rolf M. schrieb: > Da könnte man den Content-Type auch einfach komplett weglassen. Das wäre > genauso informativ. So ist es. Ich habe mir jetzt mal die Tabelle "Applications Choose how Firefox handles the files you download from the web or the applications you use while browsing." näher angesehen - dort steht nichts über application/octet-stream. Beim Download öffnet sich ein Fenster, das abfragt, ob die Datei nur gespeichert werden soll, oder mit der jeweils vorgeschlagenen Applikation geöffnet werden soll - da liegt der Fehler. Offenbar holt FF sich die Information vom System (Mint 17) - auch dort habe ich nie Hand angelegt.
:
Bearbeitet durch User
Rolf M. schrieb: > Wobei es einen gzip-Suffix wohl auch bisher nicht gibt. Wohl doch: https://www.iana.org/assignments/media-types/application/gzip Uhu U. schrieb: > Im Übrigen bringt ja der zweite Server, der dieselbe Datei verbreitet > als Mimetype application/x-gzip. Und genau das ist eigenlich verkehrt da 'x-gzip' ein nicht registrierter experimenteller Subtype ist und darüber hinaus so - mit dem '-' - schon seit Ewigkeiten eigenlich nicht mehr verwendet werden soll. Wenn schon, dann sollte der Server 'x.gzip' (mit '.') verwenden oder noch besser das dafür offiziell registrierten 'gzip'. Du hast einfach Glück, daß die Browser-Entwickler so gnädig sind und das 'x-' einfach ignorieren (sofern der Rest dann noch irgendwas sinnvolles darstellt). Und ja, sinnvollerweise sollte auch der andere Server 'application/gzip' verwenden. Ändert aber nichts daran, daß 'application/octet-stream' trotzdem ebenfalls korrekt ist. Uhu U. schrieb: > Offenbar holt FF > sich die Information vom System (Mint 17) - auch dort habe ich nie Hand > angelegt. siehe z.B.: https://www.faqforge.com/linux/change-default-application-to-open-files-linux-mint/
guest schrieb: > Rolf M. schrieb: >> Wobei es einen gzip-Suffix wohl auch bisher nicht gibt. > > Wohl doch: https://www.iana.org/assignments/media-types/application/gzip Das ist ein Subtyp, kein Suffix.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.