Access WeChat Article: a Windows workbench for archiving public article metadata

What this tool is for, stated as research work

The project description mixes two languages and makes the intent clear in both. It is a WeChat article crawler used to collect, organise and archive metadata from public WeChat official account articles, and the English half calls it a Windows research workbench for collecting, organizing, and archiving public WeChat article metadata. The README expands on the framing: the tool assists researchers in systematically handling public WeChat articles and their metadata, such as reading trends and interaction indicators, and it emphasises controllability, reproducibility and research usability for work in communication studies, social science, public opinion and data mining. That is a narrower and more defensible scope than a scraper, and it shows in the design. The goal is described as a clearer, reviewable, maintainable workbench for a research corpus, so that researchers can do the organising, field recording and preparation for later analysis in one workflow.

The v2 line is a Windows desktop application, not a script

The single most important engineering fact is on the page, in the development and contribution section. The v2 version supports Windows environments only, aimed at development and use on Windows 10 and 11 desktops, and Linux and macOS are not supported environments in v2. The user interface is a Windows desktop workbench based on WebView2, giving a more direct way to configure tasks, watch run status and review history, and the stated goal is to lower the barrier for researchers who would otherwise live in a command line for long stretches. The repository layout matches that description: a vue-project/ directory for the front end, a src/ directory for the Python side, a main.py entry point, a dev_server.py for local development, a data/ directory for the local archive, a doc/ directory including a quick_start.md, and a pyproject.toml with a uv.lock beside it. The contributor guidance is to fork first, work in your own branch, and use the .venv virtual environment in the project root so the system Python and other projects are not affected.

Why mitmproxy and Playwright are both in the dependency list

The dependency set in pyproject.toml explains the collection mechanism, and it is unusual enough to be worth reading closely. The project requires Python 3.13 or newer and depends on fastapi, uvicorn, requests, httpx2, huey for task scheduling, psutil for process information, imageio-ffmpeg, uiautomation for Windows UI automation, playwright for browser automation, and pywebview for the desktop shell. The two that stand out are mitmproxy and uiautomation. mitmproxy is a man in the middle proxy, and the badge in the README names it explicitly, and the project description in Chinese refers to the MITM collection flow as one of the areas it wants contributions on. Combining a proxy with browser automation and Windows UI automation means the tool can observe requests as they happen rather than only fetching pages, which is how a client that loads article content dynamically can be captured at all. The trade-off is inherent: a proxy-based approach requires the collector to be positioned in the request path, and it is only usable where you control the client that makes the request.

The dependency list from pyproject.toml is the shortest way to see the stack:

dependencies = [
    "fastapi>=0.138.1",
    "httpx2>=2.5.0",
    "huey>=3.3.4",
    "imageio-ffmpeg>=0.6.0",
    "mitmproxy>=12.2.3",
    "playwright>=1.60.0",
    "psutil>=7.2.2",
    "pywebview>=6.2.1",
    "requests>=2.34.2",
    "uiautomation>=2.0.29",
    "uvicorn>=0.49.0",
]

The field structure is the research output

The README devotes most of its length to what gets recorded, and the emphasis is on a consistent field structure rather than on raw scraping. The core highlights list a unified record built around account, title, publication time, link, interaction indicators and task status, and a research process that is traceable, keeping sample selection, corpus organisation, task progress and exception states inside the same flow. The feature table breaks this down further. Public article corpus organisation turns the title, account, publication time, short link and collection status into reviewable research corpus records. Research field structuring covers article details, interaction indicators, collection time, task result and duration. Interaction indicator recording covers reading, likes, recommendations and comments as the basis for descriptive statistics, trend observation and sample comparison. Task progress and exception records distinguish saved, failed and pending-review states, which the README frames as reducing repeated organisation, missed entries and manual tracking.

A local SQLite archive and a scheduled task layer

The storage model is local. SQLite appears in the pyproject keywords alongside fastapi, pywebview, mitmproxy and playwright, and the repository has a data/ directory, which together point to a local database file holding the collected records. The application stack behind the window is a FastAPI service served by uvicorn, with the Vue front end talking to it, and huey providing the scheduling for collection tasks. The tool is therefore a local application with a web backend, not a crawler you run against a remote endpoint, and the design choice has a practical consequence: the archive is yours, on your disk, in a format you can query, and the README says the organised records feed into manual coding, thematic annotation, statistical summaries, text processing and paper source checking. It is a data preparation stage, and it is honest about that. The pyproject metadata is also candid about maturity, with a Development Status of 3 Alpha and an Intended Audience of Science/Research.

The licence is a research licence, not a software licence

This is the detail to check before you build anything on top of it. The repository listing classifies the licence as other, a custom licence GitHub cannot classify, pointing at the LICENSE file, and the pyproject.toml declares license as CC-BY-NC-SA-4.0. The README badge says the same. Creative Commons Attribution-NonCommercial-ShareAlike 4.0 is a content licence, which is why the file cannot be classified by GitHub's software licence detector. For a research tool used by a scholar, that is a defensible choice. For anyone planning to use it in a commercial product, in a commercial research engagement, or to redistribute a modified tool, the non-commercial and share-alike terms are a real constraint, and you should read the LICENSE file rather than rely on the badge. The recent release tags carry a second signal: v2.2.0 added date filtering, v2.1.0 adapted to the PC client version 4.1.12.26, and v2.0.1 is the first of the 2.0 line. Adapting to a client version is a reminder that the collection target moves underneath the tool.

The compliance warning the README puts first

Before the highlights there is a note block, and it is not decorative. The project states that it is a research assistance tool aimed at academic research, course projects and personal study. Users are told they should comply with the WeChat platform service agreement, the Cybersecurity Law and related laws and regulations, and handle public article content, citation methods and research results appropriately. The block also says that the legal, platform rule and research ethics responsibilities arising from use are borne by the user. The repository is not archived, the last push was on 2026-09-28, and the default branch is main. The practical reading of all this is that the tool is a workbench for a researcher who is already careful about what they collect and how they use it. It is a way to make the collection reproducible and the fields consistent. It is not a tool that removes the judgement call about whether a particular collection is appropriate, and the README says so in as many words.

Editorial conclusion

Adopt Access WeChat Article if your academic work involves collecting public WeChat article metadata into a structured, reviewable local archive and you run on Windows 10 or 11, since the v2 line is Windows only and the whole workflow is built around a local desktop app rather than a headless script. Do not adopt it as a general purpose crawler, as a production service, or for redistribution of collected items, because the project is licensed CC BY-NC-SA 4.0 with non-commercial and share-alike terms, and the README puts the legal and platform-rule responsibility on the user. Before you start, read the quick start document referenced from the README, and confirm that the way you plan to collect respects the WeChat platform agreement.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. yeximm/Access_wechat_article on GitHub