The symptom, precisely
The offset is consistent. Zoom in and out and the gap stays roughly the same, rather than growing with scale the way a projection error would. Pan across a province and the direction of the gap may drift a little, but it does not change sign. Coastlines still look like coastlines, rivers still follow their valleys; the whole layer is simply displaced a few hundred meters against the basemap.
That signature is what separates a datum mismatch from the other things that make layers disagree. A wrong projection distorts shape and scale. A wrong extent puts the layer somewhere else entirely. A boundary file that is out of date has individual polygons in the wrong place while its neighbors stay correct. A uniform sideways displacement over the entire country is a datum question.
What GCJ-02 and BD-09 actually are
WGS 84 is the datum that raw survey and satellite positioning produces, and it is what EPSG:4326 names. GCJ-02 is a different coordinate system, built on the same ellipsoid, that applies an obfuscating transform to latitude and longitude before a map is published. Public web maps in China are served in GCJ-02, so a WGS 84 boundary drawn on one of those basemaps lands off target.
The transform is not a shift by a fixed distance. It varies with position, in direction as well as magnitude, which is why the same file can sit one way over Shanghai and another way over Lhasa. Published measurements put the displacement between roughly 100 and 700 meters, with most cities landing in the middle of that range. Treat it as a range that has to be measured locally, never as a constant to subtract.
BD-09 goes one step further. It is the coordinate system some Chinese basemaps apply on top of GCJ-02, adding a second offset. A point therefore has three possible positions, and a chain of two conversions to move between the outer two. Since the published algorithm runs in one direction and no official inverse is offered, converting back is an iterative estimate rather than an exact reversal.
Working out which one a file is in
Read the metadata first. A shapefile carries a .prj beside the .shp; a GeoPackage, a GML or a PostGIS table carries a CRS or srid declaration; a GeoJSON is assumed to be WGS 84 unless something says otherwise. If the declaration names EPSG:4326 or WGS 84, the file should align with satellite imagery and with any WGS 84 basemap. If it names nothing, do not assume.
Then test one known point. Take a landmark whose position can be checked independently, such as a river confluence or a runway threshold, and see whether it falls inside the polygon that should contain it. A point that lands consistently outside, by a couple of hundred meters, on the side away from the nearest boundary, is the usual sign of a GCJ-02 file over a WGS 84 basemap.
Finally, load the same point on two basemaps. If it sits correctly on satellite imagery but shifts on a Chinese street map, the difference between the two basemaps is the offset, and the point is in whichever datum the imagery uses. Coordinates alone will not settle it: the two positions differ by a few thousandths of a degree, which is invisible in a table and obvious on a map.
What this shop ships, and why
Every dataset here is WGS 84, EPSG:4326. That is stated on each product page and in the file itself: the .prj beside the shapefile, the srsName in the GML, and for the GeoJSON the format's own definition, which fixes coordinates to WGS 84 and needs no declaration. The KML is WGS 84 as the format requires. The DXF is the one exception in appearance only: it is projected to Lambert Conformal Conic in meters, from the same WGS 84 coordinates, because CAD drawings need a projected unit.
The choice is deliberate. A boundary file is a record of where places are, and that record should be in the datum the coordinates were measured in, so it can be checked against imagery, joined to GPS work and reprojected into anything. The offset applied for a particular basemap is a rendering concern, and applying it at the source would bake one country's display convention into a file that may be used for something else entirely.
The formats page states the coordinate system for each of the seven files, and the FAQ covers reprojection questions that come up before purchase.
Converting, and checking the result
If the target is a Chinese basemap, convert on the way in: keep the purchased file as the master copy, and produce a converted copy for that one delivery. Shipping both versions doubles the chance that someone loads the wrong one, and a converted copy drifts out of date the moment the source is regenerated.
Several open-source libraries implement the transform in both directions. They are worth using rather than reimplementing, but treat the output as an estimate: check a handful of landmarks against the basemap before publishing, and expect agreement within a meter or two rather than exactness. A vertex that was on a river bank in the source file should still be on the river bank after conversion, at the zoom levels the map will be read at.
One practical note on the legal side, stated as a technical consequence rather than as advice. Publishing maps in China is regulated, and the regulation is the reason the offset exists at all; whether a particular use needs a license is a question for counsel, not for a data page.