Dateien unter Windows automatisch verarbeiten mit Google Apps Script

Lesedauer: 10 Min – Beitrag erstellt: 13. September 2026, zuletzt aktualisiert: 13. September 2026
Transparenzhinweis: Dieser Beitrag wurde ganz oder teilweise mithilfe generativer KI erstellt. Das Titelbild stammt entweder aus eigener KI-gestützter Erstellung oder aus einer lizenzierten Bildquelle.

Google Apps Script kann nicht unmittelbar auf Ordner wie C:Import oder lokale Netzlaufwerke zugreifen. Die zuverlässige Verbindung entsteht über Google Drive für Desktop: Windows synchronisiert einen ausgewählten Drive-Ordner, während ein Apps-Script-Projekt dessen Dateien in der Google-Cloud verarbeitet. Für eine automatische Ausführung eignet sich ein zeitgesteuerter Trigger, der den Eingangsordner regelmäßig prüft.

Die folgende Anleitung richtet einen vollständigen Ablauf für CSV- und TXT-Dateien ein. Das Skript bereinigt den Inhalt, schreibt das Ergebnis in einen Ausgabeordner und verschiebt die Originaldatei anschließend in ein Archiv. Unbekannte Dateitypen und fehlerhafte Dateien landen nicht unbemerkt im Archiv, sondern bleiben zur Prüfung im Eingang liegen.

Warum Apps Script keinen lokalen Windows-Ordner öffnen kann

Google Apps Script läuft auf Systemen von Google und nicht auf dem Windows-PC. Ein Pfad wie C:DatenEingang ist deshalb nur für Programme erreichbar, die tatsächlich auf diesem Computer ausgeführt werden. Auch ein freigegebener Windows-Ordner wird durch seine Freigabe nicht automatisch für Apps Script zugänglich.

Google Drive dient als Übergabeschicht. Drive für Desktop stellt die Cloud-Dateien im Windows-Explorer bereit und synchronisiert Änderungen in beide Richtungen. Dadurch ergibt sich dieser Ablauf:

  1. Ein Windows-Programm oder der Benutzer legt eine Datei im synchronisierten Eingangsordner ab.
  2. Drive für Desktop lädt die Datei zu Google Drive hoch.
  3. Der Apps-Script-Trigger findet und verarbeitet sie.
  4. Das Skript legt das Ergebnis im Drive-Ausgabeordner ab.
  5. Drive für Desktop synchronisiert das Ergebnis zurück zu Windows.

Diese Architektur ist für kleine und mittlere Stapel wiederkehrender Dateien geeignet. Sie ist jedoch keine Echtzeitüberwachung des Windows-Dateisystems. Zwischen dem lokalen Ablegen, der Drive-Synchronisierung und dem nächsten Triggerlauf entsteht eine Verzögerung.

Die drei Drive-Ordner für den Arbeitsablauf vorbereiten

Lege in Google Drive einen übergeordneten Arbeitsordner und darin drei Unterordner an:

  • Eingang nimmt neue CSV- und TXT-Dateien auf.
  • Ausgabe enthält die bereinigten Dateien.
  • Archiv bewahrt erfolgreich verarbeitete Originale auf.

Öffne jeden Unterordner einzeln und notiere seine Ordner-ID. Die ID ist die lange Zeichenfolge in der Adresszeile hinter dem Ordnerpfad. Benötigt werden drei unterschiedliche Werte; der sichtbare Ordnername allein reicht dem Skript nicht.

Richte anschließend Google Drive für Desktop ein und stelle sicher, dass der Arbeitsordner im Windows-Explorer verfügbar ist. Ob die Dateien gestreamt oder gespiegelt werden, verändert den cloudseitigen Skriptzugriff nicht. Für Programme, die einen dauerhaft lokal vorhandenen Ordner verlangen, kann eine gespiegelte beziehungsweise offline verfügbare Ablage nötig sein.

Führe vor der Automatisierung einen Synchronisationstest aus: Erstelle unter Windows eine kleine Textdatei im Eingangsordner und kontrolliere, ob sie kurze Zeit später auch in Google Drive erscheint. Solange diese Übertragung nicht funktioniert, kann das Skript die Datei nicht sehen.

Was das Beispiel mit CSV- und TXT-Dateien macht

Das Skript behandelt die beiden Formate unterschiedlich. Bei einer CSV-Datei liest es kommaseparierte Felder ein, entfernt vollständig leere Zeilen und beseitigt Leerzeichen am Anfang und Ende jedes Feldes. Danach erstellt es wieder eine syntaktisch gültige CSV-Datei. Felder mit Kommas, Zeilenumbrüchen oder Anführungszeichen werden beim Schreiben ordnungsgemäß maskiert.

Bei einer TXT-Datei vereinheitlicht das Skript Zeilenumbrüche, entfernt Leerzeichen am Zeilenende und verwirft leere Zeilen am Dateiende. Die Ausgabe wird als UTF-8-Text gespeichert.

Jede Ergebnisdatei erhält einen Namen nach diesem Muster:

verarbeitet_DATEI-ID_URSPRÜNGLICHER-NAME

Die Drive-Datei-ID macht den Namen eindeutig. Wird eine Ausführung nach dem Schreiben des Ergebnisses unerwartet unterbrochen, kann der nächste Lauf erkennen, dass die Ausgabe für dieselbe Quelldatei bereits vorhanden ist. Dadurch wird eine zweite Ergebnisdatei vermieden.

Das Apps-Script-Projekt vollständig einrichten

Erstelle ein neues eigenständiges Projekt in Google Apps Script. Ersetze den vorhandenen Editorinhalt durch den folgenden vollständigen Code. Trage oben die drei zuvor notierten Ordner-IDs ein. Die Platzhalter dürfen nicht stehen bleiben.

Anleitung
1Ein Windows-Programm oder der Benutzer legt eine Datei im synchronisierten Eingangsordner ab.
2Drive für Desktop lädt die Datei zu Google Drive hoch.
3Der Apps-Script-Trigger findet und verarbeitet sie.
4Das Skript legt das Ergebnis im Drive-Ausgabeordner ab.
5Drive für Desktop synchronisiert das Ergebnis zurück zu Windows.

const CONFIG = {
  inboxFolderId: "EINGANG_ORDNER_ID",
  outputFolderId: "AUSGABE_ORDNER_ID",
  archiveFolderId: "ARCHIV_ORDNER_ID"
};

function processInbox() {
  const lock = LockService.getScriptLock();

  if (!lock.tryLock(1000)) {
    console.log("Eine andere Ausführung ist noch aktiv.");
    return;
  }

  try {
    const inbox = DriveApp.getFolderById(CONFIG.inboxFolderId);
    const output = DriveApp.getFolderById(CONFIG.outputFolderId);
    const archive = DriveApp.getFolderById(CONFIG.archiveFolderId);
    const files = inbox.getFiles();

    while (files.hasNext()) {
      const file = files.next();
      const sourceName = file.getName();
      const extension = getExtension(sourceName);

      if (extension !== "csv" && extension !== "txt") {
        console.log("Übersprungen: " + sourceName);
        continue;
      }

      const resultName = "verarbeitet_" + file.getId() + "_" + sourceName;
      const existingResults = output.getFilesByName(resultName);

      try {
        if (!existingResults.hasNext()) {
          const inputText = file.getBlob().getDataAsString("UTF-8");
          const resultText = extension === "csv"
            ? cleanCsv(inputText)
            : cleanText(inputText);
          const mimeType = extension === "csv"
            ? "text/csv"
            : "text/plain";
          const resultBlob = Utilities.newBlob(
            resultText,
            mimeType,
            resultName
          );

          output.createFile(resultBlob);
        }

        file.moveTo(archive);
        console.log("Verarbeitet: " + sourceName);
      } catch (fileError) {
        console.error(
          "Fehler bei " + sourceName + ": " + fileError.message
        );
      }
    }
  } finally {
    lock.releaseLock();
  }
}

function cleanCsv(inputText) {
  const rows = Utilities.parseCsv(inputText);
  const cleanedRows = rows
    .map(function(row) {
      return row.map(function(value) {
        return String(value).trim();
      });
    })
    .filter(function(row) {
      return row.some(function(value) {
        return value !== "";
      });
    });

  return cleanedRows.map(function(row) {
    return row.map(escapeCsvField).join(",");
  }).join("rn") + (cleanedRows.length ? "rn" : "");
}

function escapeCsvField(value) {
  const text = String(value);

  if (/[",rn]/.test(text)) {
    return """ + text.replace(/"/g, """") + """;
  }

  return text;
}

function cleanText(inputText) {
  const normalized = inputText.replace(/rn/g, "n").replace(/r/g, "n");
  const lines = normalized.split("n").map(function(line) {
    return line.replace(/[ t]+$/g, "");
  });

  while (lines.length > 0 && lines[lines.length - 1] === "") {
    lines.pop();
  }

  return lines.join("rn") + (lines.length ? "rn" : "");
}

function getExtension(fileName) {
  const match = fileName.toLowerCase().match(/.([^.]+)$/);
  return match ? match[1] : "";
}

function createProcessingTrigger() {
  deleteProcessingTriggers();

  ScriptApp.newTrigger("processInbox")
    .timeBased()
    .everyMinutes(5)
    .create();
}

function deleteProcessingTriggers() {
  ScriptApp.getProjectTriggers().forEach(function(trigger) {
    if (trigger.getHandlerFunction() === "processInbox") {
      ScriptApp.deleteTrigger(trigger);
    }
  });
}

Speichere das Projekt. Wähle danach im Funktionsmenü zuerst processInbox und starte die Funktion manuell. Apps Script fordert beim ersten Zugriff die erforderlichen Berechtigungen für Google Drive an. Verwende das Google-Konto, das auf alle drei Ordner zugreifen darf.

Die erste manuelle Ausführung ist zugleich der wichtigste Funktionstest. Liegt eine unterstützte Datei im Eingang, muss danach eine Datei mit dem Präfix verarbeitet_ in der Ausgabe erscheinen. Das Original muss sich im Archiv befinden.

Den automatischen Trigger erst nach dem Test aktivieren

Funktioniert die manuelle Verarbeitung, wähle createProcessingTrigger und führe diese Funktion einmal aus. Sie entfernt zunächst ältere Trigger für processInbox und erstellt anschließend genau einen Zeittrigger im Abstand von fünf Minuten.

Das Löschen vorhandener Trigger verhindert, dass die Verarbeitung versehentlich mehrfach parallel geplant wird. Zusätzlich schützt LockService den Ablauf: Beginnt ein Triggerlauf, während eine vorherige Ausführung noch arbeitet, beendet sich der neue Lauf ohne Änderungen.

Zeittrigger werden nicht sekundengenau ausgeführt. Auch die Synchronisierung von Drive für Desktop benötigt Zeit. Der Ablauf eignet sich daher für regelmäßige Verarbeitung, nicht für Anwendungen, die unmittelbar nach dem Speichern innerhalb weniger Sekunden reagieren müssen.

Ergebnis und Fehler anhand der Ordnerposition erkennen

Die Position einer Datei bildet den Verarbeitungsstatus ab. Damit lässt sich die Ursache eines Problems meist ohne Änderung am Skript eingrenzen.

  • Liegt das Original weiterhin im Eingang und fehlt eine Ausgabe, wurde die Datei übersprungen oder die Verarbeitung ist fehlgeschlagen.
  • Liegt das Original im Archiv und das Ergebnis in der Ausgabe, war der Lauf erfolgreich.
  • Liegt bereits ein passendes Ergebnis in der Ausgabe, aber das Original noch im Eingang, verschiebt der nächste Lauf das Original ins Archiv, ohne die Ausgabe erneut zu erzeugen.
  • Erscheint die Windows-Datei nicht in der Drive-Weboberfläche, liegt das Problem vor dem Skript bei der lokalen Synchronisierung.
  • Funktioniert der manuelle Start, aber kein späterer Lauf, muss der installierte Trigger im Apps-Script-Projekt geprüft werden.

Ausführungsdetails und Fehlermeldungen findest du im Bereich der Projektausführungen. Ein Fehler mit einer Ordner-ID deutet häufig auf einen falsch übernommenen Wert oder fehlende Zugriffsrechte hin. Ein Parsing-Fehler bei CSV-Dateien kann entstehen, wenn die Datei kein kommasepariertes Format verwendet oder beschädigte Anführungszeichen enthält.

Semikolon-CSV aus deutschen Windows-Programmen berücksichtigen

Viele deutsch konfigurierte Programme exportieren CSV-Dateien mit Semikolon statt Komma. Das Beispiel ist absichtlich auf kommaseparierte CSV-Dateien festgelegt. Das verhindert, dass ein unbekanntes Trennzeichen stillschweigend falsch interpretiert wird.

Verwendet deine Eingabe ausschließlich Semikolons, ändere in cleanCsv den Aufruf der Parserfunktion und das Trennzeichen beim Zusammensetzen. Die beiden betroffenen Zeilen müssen dann sinngemäß Utilities.parseCsv(inputText, ";") und join(";") verwenden. Eine Datei mit wechselnden Trennzeichen sollte dagegen vorab eindeutig standardisiert werden.

Für tabulatorgetrennte Daten, Excel-Arbeitsmappen, PDF-Dateien oder binäre Formate reicht ein geändertes Trennzeichen nicht aus. Diese Dateitypen benötigen eine eigene Verarbeitungsfunktion. Eine XLSX-Datei ist beispielsweise keine Textdatei und darf nicht mit getDataAsString wie eine CSV-Datei behandelt werden.

Unvollständig synchronisierte Dateien vermeiden

Apps Script sieht eine Datei erst, nachdem sie in Google Drive angekommen ist. Dennoch können Arbeitsabläufe problematisch werden, wenn ein anderes Programm Dateien wiederholt unter demselben Namen überschreibt oder während des Exports Zwischendateien erzeugt.

Am sichersten ist ein Übergabemuster mit temporärem Namen: Das erzeugende Windows-Programm schreibt die Datei zunächst außerhalb des synchronisierten Eingangsordners vollständig fertig. Danach verschiebt oder kopiert es die abgeschlossene Datei in den Eingang. Falls das Programm während der Erstellung Erweiterungen wie .tmp nutzt, ignoriert das Beispiel diese Dateien ohnehin, weil ausschließlich .csv und .txt verarbeitet werden.

Bei großen Dateien und umfangreichen Stapeln müssen außerdem die Ausführungs- und Speicherkontingente des verwendeten Google-Kontos berücksichtigt werden. Apps Script ist für kompakte Automatisierungen gedacht. Bleiben regelmäßig viele Dateien im Eingang oder brechen Ausführungen wegen einer Laufzeitgrenze ab, sollte die Zahl der Dateien pro Lauf begrenzt oder eine serverseitige Anwendung mit Warteschlange eingesetzt werden.

Berechtigungen und freigegebene Ordner sauber trennen

Der Trigger läuft unter dem Konto, das ihn erstellt hat. Dieses Konto benötigt Zugriff auf Eingang, Ausgabe und Archiv. Es genügt nicht, wenn nur der Windows-Benutzer oder ein anderes Google-Konto die Ordner öffnen kann.

Bei Ordnern, die mehreren Personen gehören oder organisatorisch verwaltet werden, können Richtlinien die Skriptausführung, das Verschieben von Dateien oder den Zugriff auf bestimmte Ablagen einschränken. Prüfe dann mit einer einzelnen Testdatei, ob das Triggerkonto Dateien erstellen und verschieben darf. Ein erfolgreicher Lesezugriff beweist noch keinen Schreibzugriff.

Verarbeite keine vertraulichen Dateien in einer gemeinsam genutzten Ablage, ohne die Freigaben aller drei Ordner zu kontrollieren. Besonders der Ausgabe- und Archivordner werden leicht übersehen, obwohl dort der bereinigte Inhalt beziehungsweise das unveränderte Original liegt.

Verarbeitung sicher an eigene Regeln anpassen

Die geschäftliche oder technische Logik gehört in cleanCsv beziehungsweise cleanText. Ordnerzugriff, Fehlerbehandlung, Sperre und Archivierung können unverändert bleiben. Sinnvolle Erweiterungen sind etwa das Prüfen einer vorgeschriebenen CSV-Kopfzeile, das Entfernen leerer Datensätze oder das Vereinheitlichen definierter Datumsfelder.

Prüfungen sollten einen ungültigen Datensatz nicht kommentarlos verändern. Wirft die Verarbeitungsfunktion stattdessen einen Fehler, bleibt das Original im Eingang und wird im Ausführungsprotokoll sichtbar. So lässt sich eine fehlerhafte Eingabe von einer erfolgreich bereinigten Datei unterscheiden.

Ändere immer nur eine Verarbeitungsregel und teste sie mit Kopien unkritischer Dateien. Verwende dabei mindestens eine normale Datei, eine leere Datei, eine Datei mit Sonderzeichen und eine absichtlich ungültige Datei. Erst wenn Ausgabe, Archivierung und Fehlerfall wie erwartet funktionieren, sollte der automatische Trigger wieder aktiviert werden.

Automatisierung pausieren oder vollständig zurückbauen

Zum Pausieren reicht es, deleteProcessingTriggers einmal manuell auszuführen. Bereits vorhandene Dateien bleiben dabei unverändert; lediglich neue automatische Aufrufe von processInbox entfallen. Die Verarbeitung kann weiterhin manuell gestartet werden.

Für einen vollständigen Rückbau löschst du zusätzlich das Apps-Script-Projekt oder entziehst ihm in deinem Google-Konto die erteilten Zugriffsrechte. Die erzeugten Ergebnis- und Archivdateien werden dadurch nicht gelöscht. Soll auch die Windows-Verbindung enden, entferne den betreffenden Ordner aus der Drive-Synchronisierung, nachdem alle noch benötigten lokalen und cloudseitigen Dateien gesichert wurden.

Damit bleibt die Zuständigkeit klar: Windows und Drive für Desktop übernehmen den Dateitransport, Google Apps Script führt die Inhaltsregeln aus, und die drei Ordner dokumentieren den jeweiligen Bearbeitungsstand. Diese Trennung macht den Ablauf kontrollierbar und verhindert die falsche Annahme, ein Cloud-Skript könne direkt auf beliebige lokale Windows-Pfade zugreifen.


Unsere Redaktion

Über 15 Jahre Erfahrung mit Windows- und PC-Problemen aller Art. Wir sind Euer Technikratgeber seit 2009.

Mitarbeiter Porträt Martin Keller

Martin Keller

34, Hamburg, gelernter IT-Systemadministrator und Schachfreund. Mag außerdem gerne gutes Bier.

Mitarbeiter Porträt Daniel Cho

Daniel Cho

29, Frankfurt am Main, Data Analyst. Fotografie-begeistert und Stratege durch und durch. Kann alles.

Mitarbeiterin Porträt Sofia Mendes

Sofia Mendes

27, Köln, Projektmanagerin. Workshop-Junkie und Handy-süchtig. Sprachen-Genie mit italienischen Wurzeln.

Mitarbeiter Porträt Tobias Wagner

Tobias Wagner

36, Stuttgart, Softwareentwickler. Digital Native und PC-Freak durch und durch. Spielt perfekt Gitarre.

Mitarbeiter Porträt Enzokuhle Dlamini

Enzokuhle Dlamini

55, Düsseldorf, Personalmanagerin. Liebt ihren Garten genauso wie WordPress. Geboren in Südafrika.

Mitarbeiter Porträt Joachim Freising

Joachim Freising

52, Bergisch-Gladbach, Teamleiter IT. Technik-affin. Hat für jedes Problem eine Lösung parat. Sehr geduldig.

Unsere Redaktion:

Über 15 Jahre Erfahrung mit Windows- und PC-Problemen aller Art. Wir sind Euer Technikratgeber seit 2009.

Mitarbeiter Porträt Martin Keller

Martin Keller

Mitarbeiter Porträt Daniel Cho

Daniel Cho

Mitarbeiterin Porträt Sofia Mendes

Sofia Mendes

Mitarbeiter Porträt Tobias Wagner

Tobias Wagner

Mitarbeiter Porträt Enzokuhle Dlamini

Enzokuhle Dlamini

Mitarbeiter Porträt Joachim Freising

Joachim Freising

Schreibe einen Kommentar