航迹数据转换实践：CSV转GPX/KML/GeoJSON及坐标纠偏指南

简介：这是一款面向航空航海、GIS分析及户外运动等场景的航迹数据转换工具，主要用于解决GPS轨迹在GPX、KML、TCX等格式间的互转与兼容问题，帮助用户在不同设备、地图服务或分析软件之间顺畅迁移轨迹数据。资源包共4个文件，整体仅84KB，包含可直接运行的exe主程序、记录转换参数的ini配置文件、用于中国区域坐标偏移修正的xml数据文件，以及txt格式的使用说明，结构精简且易于携带。该工具支持数据导入、预览编辑、格式转换与导出等流程，可应对野外轨迹记录、无人机路径设计、物流跟踪等典型任务，避免因格式不兼容而重复采集或处理数据。虽然该版本发布较早，但核心转换逻辑与现代工具一致，仍具参考价值。当前已有1740人学习下载，适合测绘从业者、轨迹管理爱好者和需要批量处理GPS数据的开发者快速上手。

1. 航迹数据转换：先把格式对齐再说分析

一次外业项目里，某台设备导出的航迹是一份带私有列名的 CSV，字段叫lat_std、lon_std、time_local，看起来是坐标和时间，但导入到 GIS 平台里先是列名对不上，接着时间戳被识别成文本，最后轨迹还因为空坐标被补成 0 而画出一条跨海斜线。前前后后折腾了两天才把数据洗干净。这个航迹数据转换软件包就是为解决这类问题准备的：把杂乱的航迹数据统一转成 GPX、KML、GeoJSON，顺带处理坐标纠偏、时间戳规范化和批量转换。适合做航迹后处理、外业数据整理、GIS 入库的从业者，凡是手里有“能打开但用不了”的航迹文件，都可以先拿它过一遍。

2. 航迹格式差异与转换设计：三个关键维度

2.1 主流航迹格式的数据组织方式

航迹数据落到文件里，常见的形态就四种：GPX、KML、GeoJSON，以及各种自定义 CSV。格式之间的差异不只是后缀名不同，而是坐标组织方式、时间表达方式、轨道分段方式都不一样。

GPX 是 XML 结构，轨迹放在gpx/trk/trkseg/trkpt层级里，trkpt节点用lat和lon属性表示坐标，子节点ele、time、name分别表示高度、时间、点名。它的优点是结构清晰，GPS 设备和运动软件普遍支持；缺点是层级固定，字段冗余比较明显。

KML 面向地图可视化，轨迹用<Placemark>下的<LineString>表达，坐标全部拼在<coordinates>标签里，格式是“经度,纬度,高度”，多个点之间用空格分隔。它在 Google Earth 和大多数 WebGIS 里加载速度最快，但坐标顺序和 CSV 里常见的“纬度在前”完全相反，这是一个非常容易翻车的点。

GeoJSON 是 JSON 格式，轨迹以FeatureCollection包LineString或Point集合的形式存在，坐标数组为[经度, 纬度]，可选加高度组成三维坐标。它的优势是跟现代 GIS 工具链、PostGIS、Leaflet 配合好，程序处理最方便。

CSV 最自由，也最乱。列名可能是latitude/longitude，可能是lat/lon，也可能是x/y，还可能出现lat_std这种私有命名。时间字段有的带时区、有的不带，甚至同一个文件里混两种格式。转换工具的核心工作，就是把这种不确定性收口成一套固定逻辑。

2.2 转换脚本的模块划分

这个工具包按输出格式拆成几个独立模块，再加一个命令行入口和批量脚本。文件结构大致如下：

依赖方面刻意只用 Python 3.8+ 标准库，csv、xml.etree.ElementTree、json、argparse就够，不需要安装任何第三方包。这样做的原因很实际：航迹处理经常发生在离线环境的外业笔记本上，装依赖本身就是一个障碍。

2.3 为什么不用在线转换工具

在线转换网站确实方便，但在这个场景下有四个绕不开的问题。第一，私有列名对不上，绝大多数在线工具只认固定列名，碰到lat_std这种基本无解。第二，批量转换不方便，几十个文件一个个上传再下载，时间和精力成本远高于本地跑一次。第三，坐标系处理是黑匣子，转换结果准不准、有没有做纠偏，完全不可控。第四，数据隐私问题，航迹往往关联作业区域，丢到第三方服务上有风险。本地脚本方案把每一环节都暴露在眼皮底下，参数可调、可重试、可检查，这才是工程上能长期用的做法。

3. 从CSV到GPX/KML/GeoJSON：三种格式的转换实现

3.1 CSV转GPX：层级节点与自动分段

GPX 转换的核心是把 CSV 行映射成trkpt节点，再按时间间隔决定是否新开一个trkseg。自动分段这一步容易被忽略，但实际航迹里如果有长时间停靠，不分段会导致运动软件把整个文件判定成一条断裂的轨迹。

# gpx_builder.py import csv import xml.etree.ElementTree as ET GPX_NS = "http://www.topografix.com/GPX/1/1" def parse_coord(value, lo, hi): try: v = float(value) except (TypeError, ValueError): return None return v if lo <= v <= hi else None def parse_ts(ts_str): # 简化版：只覆盖 ISO8601，完整多格式解析见 4.2 节 from datetime import datetime return datetime.fromisoformat(ts_str.strip().replace("Z", "+00:00")).timestamp() def csv_to_gpx(csv_path, gpx_path, lat_col="latitude", lon_col="longitude", alt_col="altitude", time_col="timestamp", name_col="name", segment_gap_sec=300): ET.register_namespace("", GPX_NS) gpx = ET.Element("gpx", version="1.1", creator="track-converter", xmlns=GPX_NS) trk = ET.SubElement(gpx, "trk") trkseg = ET.SubElement(trk, "trkseg") last_ts = None point_count = 0 with open(csv_path, "r", encoding="utf-8-sig") as f: reader = csv.DictReader(f) for row in reader: lat = parse_coord(row.get(lat_col, ""), -90, 90) lon = parse_coord(row.get(lon_col, ""), -180, 180) if lat is None or lon is None: continue ts = row.get(time_col, "").strip() if time_col and ts: try: cur_ts = parse_ts(ts) if last_ts is not None and segment_gap_sec > 0 and \ (cur_ts - last_ts) > segment_gap_sec: trkseg = ET.SubElement(trk, "trkseg") last_ts = cur_ts except ValueError: pass trkpt = ET.SubElement(trkseg, "trkpt", lat=f"{lat:.7f}", lon=f"{lon:.7f}") if alt_col: alt = row.get(alt_col, "").strip() if alt: ET.SubElement(trkpt, "ele").text = f"{float(alt):.1f}" if time_col and ts: ET.SubElement(trkpt, "time").text = ts if name_col: nm = row.get(name_col, "").strip() if nm: ET.SubElement(trkpt, "name").text = nm point_count += 1 tree = ET.ElementTree(gpx) tree.write(gpx_path, encoding="utf-8", xml_declaration=True) return point_count

这段代码有几个参数值得细说。lat_col、lon_col是列名映射，针对私有 CSV 最有用，不需要改代码，命令行传不同的列名就行。parse_coord做了范围校验，经纬度超出合理范围直接丢弃，避免“跳到非洲再飞回来”的轨迹。segment_gap_sec控制自动分段，默认 300 秒，意思是某条记录与上一条的时间差超过 5 分钟，就另起一个trkseg；设成 -1 则强制不分段。所有被跳过的无效点都不会计入返回的point_count，转换完成后拿这个数字和源文件行数对比，能快速判断是否有大量数据被过滤。

3.2 CSV转KML：经度在前，逗号分隔

KML 的坐标顺序是整个转换过程里最容易写错的地方。CSV 里常见的是latitude, longitude顺序，但 KML 的<coordinates>要求经度,纬度,高度，顺序反了轨迹就会乱成蜘蛛网。另外一个工程细节是 XML 转义：<name>内容如果来自 CSV 且包含&或<，直接拼字符串会让 KML 文件无法解析。

# kml_builder.py import csv from xml.sax.saxutils import escape from common import parse_coord KML_NS = "http://www.opengis.net/kml/2.2" def csv_to_kml(csv_path, kml_path, lat_col="latitude", lon_col="longitude", alt_col="altitude", name="track"): coords = [] with open(csv_path, "r", encoding="utf-8-sig") as f: for row in csv.DictReader(f): lat = parse_coord(row.get(lat_col, ""), -90, 90) lon = parse_coord(row.get(lon_col, ""), -180, 180) if lat is None or lon is None: continue alt = 0.0 if alt_col and row.get(alt_col, "").strip(): alt = float(row[alt_col]) coords.append(f"{lon:.7f},{lat:.7f},{alt:.1f}") body = " ".join(coords) kml_text = ( '<?xml version="1.0" encoding="UTF-8"?>\n' f'<kml xmlns="{KML_NS}">\n' '<Document><Placemark>\n' f'<name>{escape(name)}</name>\n' f'<LineString><coordinates>{body}</coordinates></LineString>\n' '</Placemark></Document></kml>\n' ) with open(kml_path, "w", encoding="utf-8") as f: f.write(kml_text) return len(coords)

这里用f"{lon:.7f},{lat:.7f},{alt:.1f}"拼坐标，7 位小数大约对应厘米级精度，对航迹展示完全够用。escape(name)处理 XML 特殊字符，这个细节能在处理含&的地理名称时避免整个文件报废。KML 有个特点：坐标串越长，地图加载越慢，如果一个文件有上万点，建议后续按时间切片成多个<Placemark>，而不是压进一条<LineString>。

3.3 CSV转GeoJSON：保留扩展属性

GeoJSON 转换的逻辑最直观，因为 JSON 本身就是键值对结构，CSV 行可以几乎无损地映射进去。除了经纬度和高度，我还支持把额外的业务字段透传到properties里，这样后续在地图上做样式区分时，不需要再回查原始 CSV。

# geojson_builder.py import csv import json from common import parse_coord def csv_to_geojson(csv_path, geojson_path, lat_col="latitude", lon_col="longitude", alt_col="altitude", time_col="timestamp", name_col="name", extra_cols=()): features = [] with open(csv_path, "r", encoding="utf-8-sig") as f: for row in csv.DictReader(f): lat = parse_coord(row.get(lat_col, ""), -90, 90) lon = parse_coord(row.get(lon_col, ""), -180, 180) if lat is None or lon is None: continue coord = [lon, lat] if alt_col and row.get(alt_col, "").strip(): coord.append(float(row[alt_col])) props = {} if name_col and row.get(name_col, "").strip(): props["name"] = row[name_col] if time_col and row.get(time_col, "").strip(): props["timestamp"] = row[time_col] for key in extra_cols: if row.get(key, "").strip(): props[key] = row[key] features.append({ "type": "Feature", "geometry": {"type": "Point", "coordinates": coord}, "properties": props, }) geojson = { "type": "FeatureCollection", "features": features, } with open(geojson_path, "w", encoding="utf-8") as f: json.dump(geojson, f, ensure_ascii=False, indent=1) return len(features)

每个 CSV 行独立成一个Feature，几何类型是Point。如果你需要把整条轨迹输出成一个LineString，把过滤后的coord收集到同一个数组，最后包一层geometry就行。extra_cols参数是元组，传入类似("speed", "heading")就能把这些字段原样写进 GeoJSON 的属性里。ensure_ascii=False保证中文属性正常显示，indent=1是为了调试时能直接打开文件查看结构，不会牺牲多少写盘性能。

4. 坐标纠偏与批量转换：影响数据质量的三个环节

4.1 GCJ-02坐标纠偏：什么时候该用，什么时候千万别用

航迹数据里经常出现一种情况：设备导出的 CSV 标注是 WGS84，但坐标实际是 GCJ-02（国内地图厂商常用坐标系）。把这类数据直接叠加到标准 WGS84 底图上，整体会偏移几百米。判断方法很朴素：把轨迹与卫星影像叠加，如果整体偏移方向一致且距离大致固定，大概率就是坐标系标注错误。

# common.py import math # 简化版 GCJ-02 转 WGS84，适用于航迹日常纠偏 def gcj02_to_wgs84(lng, lat): a = 6378245.0 ee = 0.00669342162296594323 d_lat = _transform_lat(lng - 105.0, lat - 35.0) d_lng = _transform_lng(lng - 105.0, lat - 35.0) rad_lat = lat / 180.0 * math.pi magic = math.sin(rad_lat) magic = 1 - ee * magic * magic sqrt_magic = math.sqrt(magic) d_lat = (d_lat * 180.0) / ((a * (1 - ee)) / (magic * sqrt_magic) * math.pi) d_lng = (d_lng * 180.0) / (a / sqrt_magic * math.cos(rad_lat) * math.pi) return lng - d_lng, lat - d_lat def _transform_lat(x, y): ret = -100.0 + 2.0 * x + 3.0 * y + 0.2 * y * y + 0.1 * x * y ret += 0.2 * math.sqrt(abs(x)) ret += (20.0 * math.sin(6.0 * x * math.pi) + 20.0 * math.sin(2.0 * x * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(y * math.pi) + 40.0 * math.sin(y / 3.0 * math.pi)) * 2.0 / 3.0 ret += (160.0 * math.sin(y / 12.0 * math.pi) + 320.0 * math.sin(y * math.pi / 30.0)) * 2.0 / 3.0 return ret def _transform_lng(x, y): ret = 300.0 + x + 2.0 * y + 0.1 * x * x + 0.1 * x * y ret += 0.1 * math.sqrt(abs(x)) ret += (20.0 * math.sin(6.0 * x * math.pi) + 20.0 * math.sin(2.0 * x * math.pi)) * 2.0 / 3.0 ret += (20.0 * math.sin(x * math.pi) + 40.0 * math.sin(x / 3.0 * math.pi)) * 2.0 / 3.0 ret += (150.0 * math.sin(x / 12.0 * math.pi) + 300.0 * math.sin(x / 30.0 * math.pi)) * 2.0 / 3.0 return ret

注意：这个函数只适用于 GCJ-02 转 WGS84。如果你的数据源本身就是 WGS84，调用它反而会引入几百米偏移，转换前务必做坐标系确认。

我一般会在批量转换前抽样三个点，把源坐标和已知 WGS84 坐标做对比，偏差在 5 米以内就跳过纠偏，偏差在 50 米以上才启用--coord-system gcj02。这个阈值不是死规则，但能避免绝大多数误判。

4.2 时间戳规范化：多格式兼容解析

航迹 CSV 的时间字段格式比想象中更不可控。常见的有 ISO8601 标准格式、带Z结尾的 UTC 时间、带毫秒的时间戳、以及完全没有时区信息的本地时间。第 3 章的简化版parse_ts只覆盖标准情况，生产环境建议换成下面这版。

# time_utils.py from datetime import datetime def parse_ts(ts_str): if not isinstance(ts_str, str): raise ValueError(f"非法时间戳类型: {ts_str}") ts_str = ts_str.strip().replace("Z", "+00:00").replace("/", "-") for fmt in ("%Y-%m-%dT%H:%M:%S.%f%z", "%Y-%m-%dT%H:%M:%S%z", "%Y-%m-%d %H:%M:%S%z", "%Y-%m-%d %H:%M:%S", "%Y-%m-%d %H:%M"): try: return datetime.strptime(ts_str, fmt).timestamp() except ValueError: continue raise ValueError(f"无法解析时间戳: {ts_str}") def normalize_iso(ts_str): ts = parse_ts(ts_str) return datetime.utcfromtimestamp(ts).isoformat() + "Z"

解析顺序是有讲究的：先匹配带小数秒和时区的完整格式，再退到秒级，最后处理没有时区的本地时间。所有没有时区信息的字符串统一视作 UTC 处理。这个假设不一定正确，但至少保证转换结果稳定可复现，不会因为运行环境不同出现时间漂移。normalize_iso生成的Z结尾格式是 GPX 标准推荐的，QGIS 和运动软件都能正确识别。

4.3 统一命令行入口与批量转换

有了单个格式的转换函数，还需要一个顺手的总入口。converter.py用标准库argparse实现，不需要额外引入 Click 这类第三方库。

# converter.py import argparse from gpx_builder import csv_to_gpx from kml_builder import csv_to_kml from geojson_builder import csv_to_geojson BUILDERS = { "gpx": csv_to_gpx, "kml": csv_to_kml, "geojson": csv_to_geojson, } def main(): parser = argparse.ArgumentParser(description="航迹数据转换工具") parser.add_argument("--input", required=True, help="输入CSV路径") parser.add_argument("--output", required=True, help="输出文件路径") parser.add_argument("--format", required=True, choices=["gpx", "kml", "geojson"]) parser.add_argument("--lat-col", default="latitude") parser.add_argument("--lon-col", default="longitude") parser.add_argument("--alt-col", default="altitude") parser.add_argument("--time-col", default="timestamp") parser.add_argument("--name-col", default="name") parser.add_argument("--segment-gap", type=int, default=300) args = parser.parse_args() builder = BUILDERS[args.format] kwargs = { "lat_col": args.lat_col, "lon_col": args.lon_col, "alt_col": args.alt_col, "time_col": args.time_col, "name_col": args.name_col, } if args.format == "gpx": kwargs["segment_gap_sec"] = args.segment_gap count = builder(args.input, args.output, **kwargs) print(f"转换完成，写入 {count} 个点: {args.output}") if __name__ == "__main__": main()

对应命令示例：

python converter.py --input track.csv --output track.gpx --format gpx \ --lat-col lat_std --lon-col lon_std --time-col time_local python converter.py --input track.csv --output track.kml --format kml \ --name "2024-10-野外轨迹" python converter.py --input track.csv --output track.geojson --format geojson \ --extra-cols speed heading

批量场景我建议直接写个小循环脚本，不引入复杂调度。逐个文件转换，失败重试两次，日志记录到本地文件。

# batch_convert.py import glob import os import traceback from converter import BUILDERS def batch(input_dir, output_dir, fmt, patterns=("*.csv",)): os.makedirs(output_dir, exist_ok=True) files = [] for p in patterns: files.extend(glob.glob(os.path.join(input_dir, p))) failed = [] for fp in files: base = os.path.splitext(os.path.basename(fp))[0] out = os.path.join(output_dir, f"{base}.{fmt}") ok = False for attempt in range(3): try: kwargs = {"lat_col": "lat_std", "lon_col": "lon_std"} BUILDERS[fmt](fp, out, **kwargs) ok = True break except Exception: if attempt == 2: failed.append((fp, traceback.format_exc())) if ok: print(f"[OK] {fp} -> {out}") if failed: with open("batch_failed.log", "w", encoding="utf-8") as f: for fp, err in failed: f.write(f"{fp}\n{err}\n") return len(files), len(failed)

批量脚本里我直接写死了私有列名lat_std、lon_std，这是因为工具包本来就是配合某类设备使用的。如果你接的是别的数据源，把这些列名提成函数参数即可。日志单独落盘很重要，上百个文件跑完，靠控制台输出根本找不全失败原因。

5. 航迹转换避坑：五条高频问题与解决记录

5.1 BOM标记导致首列名匹配失败

现象：转换脚本跑完，输出文件里只有零个点或几十个点，但源 CSV 明明有几千行；命令行不报错，数据就是丢了。

原因：CSV 是 Windows 记事本保存的 UTF-8 编码，文件头部带了 BOM（字节顺序标记）。csv.DictReader读进来后，第一个列名会变成\ufefflatitude，代码里用row.get("latitude")永远取不到值，这一列的数据全部被跳过。

解决：打开文件时统一使用encoding="utf-8-sig"，Python 会自动剥掉 BOM。如果项目里已有大量代码用encoding="utf-8"，可以写一个公共读取函数，集中改一处。这条踩坑记录基本适用于所有处理中文环境 CSV 的脚本。

5.2 时间戳混用多种格式导致轨迹时间轴断裂

现象：部分点的<time>字段生成后格式不统一，有的带+00:00，有的带Z，有的完全没有时区；导入软件后时间轴排序错乱，甚至某几个点被判定为无效数据。

原因：源 CSV 里不同时间段的数据是不同设备汇总的，一部分是YYYY-MM-DDTHH:MM:SSZ，一部分是YYYY-MM-DD HH:MM:SS。简单用datetime.fromisoformat解析会直接抛异常，程序静默跳过这些行，保留下来的时间格式也五花八门。

解决：统一走 4.2 节的parse_ts和normalize_iso。所有解析都转成 UTC 时间戳，输出时重新格式化为标准 ISO 格式。如果发现有解析失败的行，不要静默跳过，至少打印行号和内容，留一条排查线索。

5.3 空坐标被填充为0导致轨迹飞出几千公里

现象：KML 打开后轨迹一开始正常，中间突然出现一条从真实位置指向大西洋的斜线，然后又跳回真实位置。

原因：源 CSV 的坐标字段里存在缺失值，但设备导出的文件把这些位置填成了0,0，而不是留空。转换脚本没有做范围校验，把0,0当作真实坐标写进输出。

解决：所有坐标读取必须经过parse_coord做范围检查，经度值必须在[-180, 180]，纬度值必须在[-90, 90]，越界的行直接丢弃并计数。转换结束后把point_count与源文件行数做个减法，差值就是被过滤掉的无效点数量。如果这个数字超过总行数的 5%，就要检查数据源是不是有系统性的缺测问题。

5.4 缺少trkseg分段导致轨迹断线

现象：GPX 导入运动软件后，轨迹显示成好几段，或者软件提示“轨迹包含过多断点，无法显示”。

原因：设备记录的航迹里有长时间停靠，比如作业中间休息了两小时。转换脚本把所有点放进同一个trkseg，但点与点之间的时间间隔过大，软件按默认逻辑判定为无效连接，自动断开。

解决：用segment_gap_sec参数控制自动分段。当相邻两点的间隔超过阈值时，新建一个trkseg。默认 300 秒对大多数无人机和车载航迹都适用；如果你处理的场景是长时间低速作业，可以把阈值调大到 600 秒，避免把正常轨迹拆成碎片。

5.5 KML坐标顺序写反导致地图乱码

现象：KML 能打开，轨迹点也在，但连线方向乱七八糟，一会儿向东一会儿向西，整条轨迹像被随机打乱。

原因：<coordinates>要求的顺序是经度,纬度,高度，但习惯读 CSV 的人很容易按latitude, longitude的顺序拼接。经度值应该在[-180, 180]，纬度在[-90, 90]，如果写反了，坐标点就会在两张完全不同的地图位置上乱跳。

解决：在kml_builder.py里强制用f"{lon:.7f},{lat:.7f},{alt:.1f}"拼接，并在代码注释里写明顺序。转换完成后抽前三个点打印出来，人工扫一眼经度是否落在合理区间。这个自检动作只要做一次，就能避免后续所有同类问题。

6. 到最后一步：用QGIS验证输出结果

转换脚本跑通只是第一步，数据能不能用，必须在真实 GIS 环境里验证。我习惯固定用 QGIS 做三个检查，花不了五分钟，但能筛掉大部分质量问题。

首先加载输出文件。QGIS 直接支持 GPX 和 KML，GeoJSON 也没问题。加载后用“识别”工具点选轨迹上的任意三个点，把显示的坐标与源 CSV 中对应行的坐标对比，误差应小于数据精度范围。如果发现整体偏移，优先怀疑坐标系没对齐；如果只有个别点偏差，可能是源数据本身有问题。

第二个检查是看轨迹总长度。QGIS 右侧图层面板打开字段计算器，对轨迹要素计算长度，与设备记录的里程对比。误差在 1% 内说明坐标和高度转换基本正确，如果误差超过 5%，检查是不是有被过滤的点，或者trkseg分段导致轨迹挨不上。

第三个检查是坐标范围和首尾点位置。我写了一个小脚本verify.py，读回刚生成的 GPX，自动打印点总数、首点坐标、尾点坐标和经度纬度范围，不需要打开 GIS 就能完成一次快速体检。

# verify.py import xml.etree.ElementTree as ET NS = {"g": "http://www.topografix.com/GPX/1/1"} def verify_gpx(path): tree = ET.parse(path) pts = tree.findall(".//g:trkpt", NS) if not pts: print("错误: 没有找到trkpt节点") return False first = pts[0] last = pts[-1] lats = [float(p.get("lat")) for p in pts] lons = [float(p.get("lon")) for p in pts] print(f"点总数: {len(pts)}") print(f"起点: {first.get('lat')}, {first.get('lon')}") print(f"终点: {last.get('lat')}, {last.get('lon')}") print(f"经度范围: {min(lons):.6f} ~ {max(lons):.6f}") print(f"纬度范围: {min(lats):.6f} ~ {max(lats):.6f}") return True

这三个检查做完，转换结果基本可以放心入库。一次线上演示时我发现生成轨迹里多了一个“跳海”点，就是因为跳过了自检直接交付，当场被数据拖垮。从那以后我每次转换完都强制跑一遍verify.py，再用 QGIS 目检首尾点，这套流程至少帮我避免了三次返工。希望帮到你。

本文还有配套的精品资源，点击获取