Lokale map naar tekstconverter

Lokale map naar tekst: uw codebase in één bestand, zonder deze te uploaden

Richt dit op een map op uw machine en u krijgt een enkel tekstbestand terug: een directorystructuur op de top, dan elk bestand dat je hebt geselecteerd, elk gescheiden door een koptekst met zijn pad. Hoe je het ook noemt — het combineren van een codebase in één bestand, het aaneenschakelen van bronbestanden, het samenvoegen van een map tot één document – dat is het hele idee. Het is het formaat dat een LLM het beste kan verwerken, omdat het model de vorm van het project en de inhoud tegelijkertijd, en kan redeneren over hoe één bestand zich verhoudt naar een ander.

Het is gratis, u hoeft zich niet aan te melden en u hoeft niets te installeren. Kies een map, vink het model uit niet nodig heeft, en exporteer het project als één tekstbestand dat u overal kunt plakken.

Het onderdeel waar de meeste mensen om geven: er wordt niets geüpload. Er is geen server hierin pijpleiding. Uw bestanden worden in de browser gelezen, in het geheugen verzameld en aan u teruggegeven. Als je dat hebt gedaan Ik heb online converters vermeden omdat de codebase van een klant is, of onder een geheimhoudingsverklaring valt, of gewoonweg is het niet aan jou om in een service van derden te plakken, dan is dat bezwaar hier niet van toepassing – en de volgende sectie legt precies uit waarom, want "vertrouw ons, het is veilig" is geen antwoord dat iemand zou moeten accepteren.

Hoe een Private Codebase to Text Converter feitelijk werkt zonder te uploaden

Moderne browsers kunnen bestanden van schijf lezen zonder ze ergens heen te sturen. Wanneer u een map kiest, wordt de browser overhandigt de pagina een lijst met bestandsingangen. Ze worden allemaal gelezen met de standaard FileReader API, die de bytes decodeert naar een string in het eigen geheugen van het tabblad. De directorystructuur, het aantal tokens, de aaneenschakeling: het gebeurt allemaal in JavaScript dat op uw computer draait machine. Er is geen fetch, geen XHR, geen API-eindpunt, geen analyseoproep van derden bestandsinhoud dragen. Open het netwerktabblad van uw browser terwijl u converteert en u zult zien hoe het blijft leeg.

Dat mechanisme heeft een aantal nuttige bijwerkingen die verder gaan dan privacy:

• Het werkt offline. Zodra de pagina is geladen, trekt u aan de ethernetkabel. Conversie loopt nog steeds. Handig op een air-gapped machine of een vergrendeld bedrijfsnetwerk.
• Geen uploadlimieten of snelheidslimieten. Er is geen API-quotum dat moet worden gehaald, want dat is er niet API. Het enige plafond is het geheugen van uw browser en uw geduld.
• Het werkt op code die nooit is vastgelegd. Een krastak, een spoorloze experiment, een map die nog nooit een git init – de GitHub repository naar tekstconverter kan niet raak een van deze aan, omdat deze leest uit de GitHub API. Deze leest van schijf, dus dat gebeurt niet geeft überhaupt om uw versiebeheersituatie.
• Er wordt niets behouden. Sluit het tabblad en de status is verdwenen - geen geschiedenis om te verwijderen, geen account met een kopie van uw bron.

Drie manieren om een project binnen te halen

Gebruik de mapkiezer om naar een map te bladeren, of sleep de map rechtstreeks vanuit Finder of Verkenner naar de dropzone. Beiden lopen recursief door de boom, zodat je het hele project inclusief genest krijgt submappen, niet alleen het hoogste niveau.

Je kunt ook een ZIP-archief neerzetten en het wordt uitgepakt in de browser - handig als iemand je een e-mail heeft gestuurd project, of u wilt het liever helemaal niet extraheren. Eén onderscheid dat de moeite waard is om te weten: gebruik deze pagina wanneer de archief bevat een codeproject, omdat u de directorystructuur en padheaders per bestand wilt. Als het een stapel documenten is (rapporten, spreadsheets, pdf's) ZIP naar tekst of ZIP naar Markdown past beter, omdat deze de leesbare inhoud uit elk document halen in plaats van bestanden als bron te behandelen.

Elke IDE, elke editor: hij wil alleen een map

Er hoeft geen plug-in te worden geïnstalleerd en geen extensie te worden goedgekeurd, omdat deze niet met uw systeem kan worden geïntegreerd redacteur helemaal niet. Er is een map voor nodig. Of die map nu een VS Code-werkruimte is, an IntelliJ IDEA- of PyCharm-project, een Visual Studio-oplossing, een Android Studio-module, een Xcode project, een Eclipse-werkruimte of een map die u alleen in Neovim hebt geopend, het is dezelfde set bestanden op dezelfde schijf. Richt de kiezer erop en je bent klaar.

De moeite waard om te spellen, omdat "mijn VS Code-project exporteren als een enkele TXT" en "een IntelliJ project to one file' zijn vragen die mensen vaak eerst aan hun redacteur stellen. Redacteuren zijn meestal de verkeerde plek om te kijken. Ze exporteren bestanden, één voor één. Een paar hebben een marktplaatsextensie dat lost het voor de helft op, de meeste niet, en elk lost het anders op, dus een antwoord voor één IDE is nutteloos het moment dat je overstapt. De map is de gemene deler.

Het is ook een betere zet dan het project te zippen en te verzenden. Een archief is een prima ontwikkelaar ontwikkelaar, maar een chatmodel wil tekst, geen container, en een recensent moet deze eerst uitpakken een regel lezen. Een geconsolideerd .txt is leesbaar inline: plak het in een gesprek, voeg het toe aan een ticket, plaats het in een e-mailthread. En als iemand heeft al gestuurd jij een ZIP, je kunt die rechtstreeks op deze pagina plaatsen in plaats van eerst uitpakken.

Snoei hard voordat u genereert

Dit is de stap die mensen overslaan en die bepaalt of de uitvoer bruikbaar is. Alles begint aangevinkt in de selectievakjesboom, wat betekent dat u standaard een heleboel dingen gaat opnemen nee model moet zien.

Eén ding werkt hier in uw voordeel. Als de map een .gitignore, het wordt gelezen en de regels worden toegepast - inclusief geneste regels dieper in de boom, beperkt tot hun eigen map, met commentaarregels overgeslagen. Op een normale repository die stilletjes de meeste van de ergste overtreders vóór u verwijdert raak niets aan, omdat de dingen die een puinhoop doen opzwellen meestal dezelfde dingen zijn die je al aan git hebt verteld met rust laten. De .git directory zelf is altijd uitgesloten.

Leun er echter niet helemaal op. Een map met nr .gitignore — een uitgepakte ZIP, a vendor handoff, een map die nooit een repository is geweest, krijgt niets van die bescherming. En veel lawaai dingen worden legitiem bijgehouden in git. Scan de boom en vink deze uit:

• node_modules, vendor, .venv, site-packages. De afhankelijkheidsbomen zijn enorm en niets ervan is jouw code. Een ongesnoeid node_modules alleen al kunnen honderdduizenden tokens van andere mensen zijn bron. Het zal het eigenlijke project overspoelen en de antwoorden van het model zullen naar de bibliotheek afdrijven interne onderdelen.
• Bouw output op — dist, build, .next, target, out, dekkingsrapporten. Het is je eigen code, verkleind of getranspileerd, gedupliceerd. Puur geluid.
• Bestanden vergrendelen. package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Duizenden regels hashes met bijna geen semantische informatie. Bewaar het manifest (package.json, pyproject.toml) — dat is het deel dat het model vertelt op welke stapel je zit.
• Gegenereerde code en armaturen — protobuf-uitvoer, GraphQL-codegen, database migraties, grote zaad- of snapshotbestanden.
• Alles met geheimen. Er wordt niets verzonden, maar het uitvoerbestand wordt ingevoerd uiteindelijk een chatvenster. Vertrekken .env uit.

Binaire bestanden worden voor u afgehandeld: afbeeldingen, lettertypen, gecompileerde artefacten en dergelijke worden eruit gefilterd extensie voordat ze ooit de boom bereiken, en alles wat er doorheen glipt, wordt opgevangen door een null-byte scannen en vervangen door een korte tijdelijke aanduiding in plaats van als afval te worden gedumpt. Bestanden groter dan 1 MB krijgen een tijdelijke aanduiding waarbij ook de grootte wordt vermeld, waardoor een verdwaalde CSV niet uw hele contextbudget opslokt.

Er is ook een schakelaar voor de directorystructuur bovenaan de uitvoer: gefilterd toont alleen wat je hebt geselecteerd, vol toont de volledige structuur met uw selecties gemarkeerd. Volledig is de betere keuze als je naar architectuur vraagt, omdat het model dat kan zien tests/ directory bestaat, ook al heb je deze niet opgenomen. Gefilterd is beter als je wil dat het model zich nauw concentreert en niets anders.

Binnen het contextvenster blijven

De gegenereerde uitvoer wordt geleverd met een echte tokentelling, geproduceerd door de gpt-tokenizer bibliotheek in plaats van een gok van de karakters gedeeld door vier. Vergelijk het met uw model voordat u gaat plakken. Het is een veel betere workflow dan plakken, wachten en een lengtefout terugkrijgen.

Ruwe richtlijnen voor hoeveel u moet verzenden. Stuur de hele project als het klein genoeg is past comfortabel en uw vraag is architectonisch: "waar wordt authenticatie daadwerkelijk afgedwongen", "wat zou er kapot gaan als ik deze interface zou veranderen", "leg de gegevensstroom uit van aanvraag naar database". De Het model heeft het volledige beeld nodig om deze eerlijk te kunnen beantwoorden, en een gedeeltelijke dump levert zelfverzekerde gissingen op over bestanden die het nooit heeft gezien.

Stuur een plak als de vraag lokaal is: één module plus de tests die deze behandelen, plus de twee of drie bestanden waaruit het importeert. Een kleinere context betekent scherpere antwoorden en minder drift Normaal gesproken behaal je betere resultaten met 5.000 goedgekozen tokens dan met 200.000 willekeurige tokens.

Monorepos een bewuste aanpak nodig. Converteer de repo-root niet. Converteer één pakket per keer, en als dat pakket afhankelijk is van een gedeelde interne bibliotheek, neem dan de public van die bibliotheek op oppervlak ernaast. Als je context voor meerdere pakketten nodig hebt, is het een goede truc om twee passen uit te voeren: één volledige boom met bijna geen bestanden geselecteerd – dat geeft het model een kaart – en dan een tweede, bestand-zware doorgave het pakket waarin u daadwerkelijk werkt.

Waarom niet gewoon rennen cat of een Shell-script?

Eerlijke vraag, en soms is het eerlijke antwoord dat je dat zou moeten doen. Als u drie bekende bestanden wilt samengevoegd, cat auth.py models.py routes.py > out.txt is sneller dan het openen van a browser. Niemand probeert je daar uit te praten.

Het punt waarop het niet meer rendeert, is op het moment dat u het op een heel project richt. Rennen find . -type f -exec cat {} + op een echte repository en dit is wat je krijgt:

• Binaire bestanden in het midden van uw bron. PNG's, lettertypen, gecompileerde objecten, een verdwaalde SQLite-fixture - alles gedecodeerd als tekst, allemaal mojibake. Je begint dan met het onderhouden van een extensie witte lijst.
• De hele afhankelijkheidsboom. node_modules, .venv, vendor, targeten de inhoud van .git zelf. Exclusief dat betekent dat u pruimuitdrukkingen schrijft en deze actueel houdt voor elk project waaraan u werkt. Hier, jouw .gitignore beschrijft dat al precies, inclusief geneste bestanden, en it wordt voor u aangevraagd.
• Geen idee hoe groot het is. Aaneenschakeling geeft je bytes, geen tokens, en verdeling tekens per vier is een gok die in beide richtingen verkeerd is. Je komt erachter dat het niet past wanneer het model weigert het.
• Selectieve controle kost meer script. "Alles onder src behalve de gegenereerde API-client, plus de twee configuratiebestanden in de root" is nog een vlag en nog een regex. Een selectievakje-boom doet dat in ongeveer vier klikken.
• Geen kaart bovenaan. Ruwe aaneenschakeling is een tekstmuur zonder structuurkop, het model kan dus niet vertellen waar het ene bestand eindigt en het volgende begint, of wat de lay-out van het project is lijkt op. Door paden gescheiden secties en een directorystructuur zijn de belangrijkste factoren die een dump leesbaar maken.

Het is allemaal bouwbaar en veel mensen hebben het gebouwd. Het is een middagje scripten en dan een klein gereedschap dat u onderhoudt. De ruil is of u het script of de uitvoer wilt.

Waar mensen dit eigenlijk voor gebruiken

• De codebase die je zojuist hebt geërfd. Er is iemand vertrokken, en nu is er een dienst met 40.000 lijnen de jouwe. Converteer het, plak het en vraag naar de toegangspunten, de belangrijkste abstracties en de drie dingen die een nieuwe beheerder het meest zouden verbazen. Het is een snellere oriëntatie dan welke overdracht dan ook document dat u krijgt.
• Documentatie uit echte bron. README's rotten omdat ze één keer zijn geschreven. Genereer ze uit de code die nu bestaat - architectuuroverzichten, modulesamenvattingen, een accuraat lijst met omgevingsvariabelen die de app daadwerkelijk leest.
• Tests voor niet-geteste code. Neem de module plus één bestaand testbestand op als stijl referentie. Het model komt overeen met uw raamwerk, uw naamgeving, uw armatuurpatronen, in plaats van een testconventie bedenken die je niet gebruikt.
• Migratie- en refactorplanning. Klassecomponenten aan hooks, JavaScript aan TypeScript, de ene ORM naar de andere. Een model dat elke bellocatie kan zien, geeft u eerder een echt plan dan een algemene checklist.
• RAG en inbedding. Eén enkel schoon tekstbestand met door paden gescheiden secties is Het is eenvoudig om die scheidingstekens op te delen en in een vectoropslag te plaatsen.

Wanneer u klaar bent, kopieert u de uitvoer naar het klembord of downloadt u deze als .txt bestand - waard behouden als u dezelfde context in meerdere gesprekken hergebruikt.

Code is slechts de helft van de context

De meeste echte vragen over een project gaan ook over zaken die geen bronbestanden zijn. De specificatie woont in een PDF, het schema in een JSON-bestand, de configuratie in XML, de gegevens in een CSV. Converteer deze afzonderlijk en plak ze naast je codebase-dump: PDF naar Markdown voor specificaties en leveranciersdocumentatie, Woord naar Markdown voor vereistendocumenten, JSON naar Markdown voor API payloads en schema's, XML naar Markdown voor erfenis configuratie, CSV naar Markdown voor monster gegevens, en HTML naar Markdown voor geëxporteerde pagina's. Als u liever geen formaat kiest, File2Txt neemt wat je gooit erbij.

Veelgestelde vragen

Hoe converteer ik een map naar een tekstbestand?

Kies hierboven een map en je krijgt de boomstructuur als een lijst met selectievakjes. Vink de gewenste bestanden aan en exporteer één enkel tekstbestand: eerst de mapstructuur en vervolgens elk bestand onder een kop met zijn pad. Gratis, geen aanmelding, niets te installeren.

Wordt mijn code geüpload naar een server?

Nee. Er zit helemaal geen server in deze pijplijn. De map wordt in de browser gelezen, de uitvoer wordt in de browser samengesteld en er gaat niets via het netwerk - je kunt devtools openen en bekijken, of de verbinding met internet verbreken nadat de pagina is geladen en het werkt nog steeds. Dat is het verschil tussen deze en de GitHub converter, die de API moet aanroepen.

Is het veilig om een bedrijfscodebase online te converteren?

Deze pagina is de versie die die vraag beantwoordt met een mechanisme in plaats van met een belofte: de bestanden verlaten de machine nooit, dus er is niets om ons over te vertrouwen. Wat er nog steeds toe doet, is wat u vervolgens doet: als u de uitvoer in een gehost model plakt, wordt deze naar die provider verzonden. Controleer dus het beleid van uw organisatie en ontdoe u van geheimen voordat u dat doet.

Kan ik een heel project inclusief submappen converteren?

Ja, de hele boom wordt bewandeld en elk niveau is selecteerbaar. Als u een map deselecteert, wordt alles eronder met één klik verwijderd, en dat is hoe u de map neerzet node_modules of .git zonder op kinderen te jagen. De tokenteller wordt gaandeweg bijgewerkt, zodat u het effect onmiddellijk kunt zien.

Welke browsers kunnen een hele map kiezen?

Mapselectie maakt gebruik van het directory-upload-attribuut dat Chrome, Edge, Firefox en Safari allemaal al jaren ondersteunen, dus elke huidige desktopbrowser werkt. Mobiele browsers vormen de kloof: noch iOS noch Android beschikt over een mapkiezer. Op een telefoon zipt u de map en gebruikt u ZIP naar tekst in plaats daarvan.

Wat is de limiet voor de bestandsgrootte?

Er is geen upload, dus er is ook geen uploadlimiet. De beperking is het geheugen van uw machine en de hoeveelheid tekst die u achteraf nuttig ergens kunt plakken. In de praktijk wordt de tokenteller de echte limiet lang voordat de browser dat doet. Een repository waarvan de bruikbare bron minder dan een megabyte bedraagt, dekt de meeste projecten zodra de afhankelijkheden zijn gedeselecteerd.

De rest van de gereedschapskist

Als de code wordt gehost in plaats van lokaal, wordt de GitHub naar tekstconverter en de GitLab naar tekstconverter doe hetzelfde taak tegen een externe repository, inclusief privérepository's met een token. Alleen voor documentatie bestaat op internet, Web2Txt schraapt een URL naar schone Markdown — koppel een geschraapte API-referentie met uw lokale bron en een codeerassistent kan beide kanten tegelijk zien.

Er staat nog meer op de blog als je verder wilt gaan: een codebase omzetten in een LLM-klaar bestand, een walkthrough van de map naar tekstconverter, een gids voor het voeden van een hele repository in een AI, en de generaal conversiegids voor bestanden naar tekst voor alles wat geen code is.

Repo2Txt is gebouwd en onderhouden door v12hero, een onafhankelijke ontwikkelaar die native- en web-apps bouwt die privacy voorop stellen.