KML文件格式全解析：从结构、核心特性到格式转换实战

搞测绘和地理信息这行，谁没被各种格式的文件折腾过。有一次外业回来，甲方直接丢来一个 KML 文件，说“就按里头画的边界放线”。我在 Google 地球里打开，地标、线、面都显示得清清楚楚，心里还觉得挺省事。结果和同事手里的 SHP 一叠，坐标整体偏移了老远——不是 KML 错了，而是我们对这个格式的“脾性”没吃透。那之后我专门花了段时间把 KML 文件格式和支持添加的内容从头捋了一遍，今天这篇就把我积累的经验整理出来，尤其是那些文档里不太好找的坑。

KML 全称是 Keyhole Markup Language，早期是 Keyhole 公司给自家地球浏览软件设计的标记语言，后来 Google 收购了这家公司，KML 也顺势成了 Google 地球等产品的主力数据格式。2008 年它被 OGC（开放地理空间信息联盟）接纳为标准，所以今天你在 QGIS、ArcGIS 乃至各种 WebGIS 平台里，都能看到 KML 的身影。简单说，它基于 XML 语法，专门用来描述地理要素，点、线、面、图片、三维模型、动态轨迹都能往里塞。你要问它和 SHP、GeoJSON 比有什么特别，最直接的一点是：KML 不只是“画图”用的，它把“描述信息”和“样式”也带上了，一个文件发过去，对方看到的不只是几何形状，还能看到图标、颜色、气泡说明甚至网络动态刷新。这篇文章适合两类人看，一类是刚接触 GIS 数据、经常要和 Google 出来的文件打交道的新人，另一类是已经在用 KML 但被转换、样式、编码问题卡过脖子的人。

1. KML 的身世与文件骨架：先搞清楚它到底是什么

1.1 从 Keyhole 到 OGC：一个“为了地球浏览而生”的标准

我最早接触 KML 的时候，以为它只是 Google 地球的私有格式，能用就行，没想过深挖。后来整理项目资料，发现政府和企业发布的公开地理数据里有大量 KML，很多国产地图工具也有导入接口，这时才明白它早就不是一家公司的“私货”了。

KML 的底层逻辑可以这么理解：它把地球当作一张无限大的画布，每个地标、每条路径、每个多边形，都像你在网页上写的 HTML 元素一样，有标签、有属性、有内容。不同于普通图片格式只记录像素，KML 记录的是“经纬度坐标 + 显示样式 + 附带说明”，所以它天然适合跨平台交换。更难得的是，因为它是纯文本的 XML，你可以用记事本直接打开修改，也能写脚本批量处理，这给数据纠错、批量生成带来了很大便利。

当然，它的短板也很明显。KML 本质上是“表现层”格式，不是空间数据库格式，它不擅长存海量属性记录，也没有复杂拓扑关系。很多初学者会拿它当成万能容器，往里面灌上万条要素，结果打开卡得要命。正确的思路是：KML 适合“可视化交换”和“轻量共享”，到了分析和入库环节，通常要转成 SHP、GeoJSON 或者进 PostgreSQL/PostGIS 这类空间数据库。

1.2 最小可用文件：一个 KML 的“骨骼”长什么样

先看一个手动写出来的最小例子：

xml复制<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <name>我的第一个地标</name>
    <Placemark>
      <name>示例点</name>
      <description>这是一个点</description>
      <Point>
        <coordinates>116.397,39.909,0</coordinates>
      </Point>
    </Placemark>
  </Document>
</kml>

这段结构并不复杂。最外层是 <kml> 根节点，必须带上 OGC 的命名空间 xmlns="http://www.opengis.net/kml/2.2"，少了它很多软件会不认。里面是 <Document>，相当于一个容器，可以理解成图层或项目文件。<Placemark> 是最核心的要素节点，它对应地图上的一个“地标”，可以是点，也可以是一条线或一个面。<name> 是显示名称，<description> 是气泡里显示的文字，而 <Point> 里的 <coordinates> 就是具体坐标。

请注意坐标的书写顺序：经度在前，纬度在后，海提高度可省略。很多人写代码都习惯“纬度,经度”，到这里就容易栽跟头。更坑的是，XML 里如果经纬度有一处写反，整条线会画到完全错误的位置，数据量一旦大了肉眼很难察觉。所以我的习惯是：拿到任何 KML，先用一个轻量查看器打开，随机抽几个坐标和已知地名核验，确认没有坐标顺序问题后再做下一步。

文件层级上看，<Document> 内部还可以套 <Folder>，实现类似文件夹的分组效果。比如一个项目文件里，分成“规划范围”“巡查点位”“历史建筑”三个文件夹，对方打开后就能按图层开关这些要素，这比把所有东西平铺在一个列表里强太多。

2. KML 能往里“添加”哪几类核心内容

2.1 点、线、面：所有 KML 的几何基础

KML 最基础的内容是三件套：点（Point）、线（LineString）、面（Polygon），使用频率最高，也是后续所有高级功能的地基。

点要素在野外调查、基站标注、检查井定位里很常见。一个点其实就是 <Point> 标签里放一对坐标。不过要注意，如果你的点集很多，比如几百个检修井，你不应该创建几百个 <Placemark> 各写一个 <Point>，而应该集约组织文档结构或者考虑合并成其他数据格式，否则文件会显得很臃肿。

线要素的写法是 <LineString>，用来表示道路、河流、管线、飞行轨迹等：

xml复制<Placemark>
  <name>一段巡查路线</name>
  <LineString>
    <tessellate>1</tessellate>
    <coordinates>
      116.391,39.907,0
      116.400,39.912,0
      116.413,39.921,0
    </coordinates>
  </LineString>
</Placemark>

这里 <tessellate>1</tessellate> 是让折线沿着地表地形弯曲贴合，而不是在三维地球里拉一根悬浮的直线。很多人画山谷里的徒步路线时忘记加这个参数，结果在 Google 地球里看到路线直接“钻”进了山体或横空飞过了山脊，就是因为它没贴地。

面要素用 <Polygon> 表示，在地籍边界、规划范围、土地区块这类场景最常用。它的结构稍微别扭一点，不能直接把坐标丢在 <coordinates> 里，而是要先写 <outerBoundaryIs>，意思是“外边界”，下面再套一个必须闭合的 <LinearRing>。如果有洞，还要加 <innerBoundaryIs>。初学者最容易犯的错误：外环没闭合。KML 要求最后一个坐标点等于第一个点，图形才能正常填充，如果没闭合，很多浏览器依旧能显示，但在 QGIS 里导出就可能出错。所以建议导出前先做一个校验。

2.2 覆盖层：把图片、历史地图、实时画面“贴”到地球上

我的同事第一次看到我用 <GroundOverlay> 把一张 1950 年代的历史地图叠到现在的地形上时，愣了老半天——KML 居然还能干这种事。这就是 KML 和 SHP 这类“纯几何格式”拉开差距的地方，它支持几种覆盖层（Overlay），把栅格影像、历史图片、全景照片塞进地理上下文里。

最常用的是地面覆盖层 <GroundOverlay>，它把一张图片（PNG、JPG 都可以）按指定的范围铺在地球表面上。比如你扫描了一张老地图，想把它和今天的卫星影像做对比，或者想给某个区域贴一张现场平面图，就能用这一招。核心写法是给 <Icon> 指定图片地址，再用 <LatLonBox> 设置图片的四至范围，也就是北、南、东、西的经纬度，还可以带一个 <rotation> 旋转角。有一点特别注意：如果图片只是普通扫描件，没有配准过坐标，贴上去存在偏差是正常的，你得先在 GIS 软件里用控制点做地理配准，再导出为带坐标信息的 GeoTIFF 或图片，最后填好 LatLonBox，位置才可能准确。

屏幕覆盖层 <ScreenOverlay> 则是另一种形态，它固定显示在屏幕某处，不随地图平移，常用于图例、Logo、水印。这在实际工作中也会用到，比如给一张汇报用的 KML 叠加“图纸仅供内部参考，不得用于施工”的水印，或者把项目的统一图例放在右上角。它靠 <screenXY>、<size> 来对齐屏幕位置和尺寸，不需要经纬度，理解成“贴在地图播放器窗口上的图层”就行。

还有一类是照片覆盖层 <PhotoOverlay>，适合把拍摄地点的全景照片或带方向信息的普通照片关联到地理坐标，浏览时可以在虚拟场景里环视，适合做现场影像记录。

2.3 网络链接：让 KML 可以自己“更新”

很多人把 KML 当成一次性静态文件，做完发出去就完事了。但实际上 KML 有个很硬核的能力：通过网络链接动态加载远端 KML。也就是说，你发给别人的 KML 文件里可以只放一个“指针”，它指向服务器上的另一个 KML 文件，客户端会按照设定频率自动去拉取最新内容。

这个能力在气象雷达、空气质量监测、车辆定位等实时图上特别实用。比如我给一个工地做过车辆轨迹共享，方式就是在公司内部 Web 服务上生成最新坐标的 KML，用户的 Google 地球客户端每 30 秒自动刷新一次，不需要安装了专门的 GIS 系统就能看到实时位置。

核心写法是：

xml复制<NetworkLink>
  <name>动态图层</name>
  <Link>
    <href>http://example.com/data/live.kml</href>
    <refreshMode>onInterval</refreshMode>
    <refreshInterval>60</refreshInterval>
  </Link>
</NetworkLink>

refreshMode 有三种常用值：onInterval 固定时间间隔刷新；onChange 在本地文件变化时刷新；onExpire 基于服务端返回的有效期刷新。还有 viewRefreshMode，可以在浏览视角停下来时触发生成新的 KML，实现“我只要看某一区域，服务器才返回该区域的要素”，这在海量数据服务里很好用。不过这东西对服务器地址的稳定性和网络环境要求很高，如果数据源在内网且对方无法访问，网络链接就等于白写；更稳妥的做法是保留一份离线 KML 兜底。

2.4 时间与三维：KML 不只是静态二维标注

KML 可以用来描述“随时间变化”的地理对象。在 Google 地球里，带时间标签的要素会自动出现在时间滑块上，拖动滑块能播放动画，这在台风路径、人口扩散、工程进度回溯这些场景很实用。

具体有两种时间标签：<TimeStamp> 表示某一时刻，适合表示突发点、事件点：

xml复制<TimeStamp>
  <when>2024-06-01T08:00:00Z</when>
</TimeStamp>

<TimeSpan> 则表示一个时间段，有起止时间，适合表示一段工期的道路封闭、某片区域的季节变化等。时间标签可以放在 <Placemark> 里，和点线面一样属于“可添加内容”，这种带时间维度的特性是 SHP 文件默认不具备的，需要靠属性字段额外约定。

三维方面，KML 支持通过 <Model> 引用 Collada 格式的 .dae 三维模型，把建筑、桥梁或规划方案放到真实经纬度的高程上。此外，如果你需要表现带高程的点位序列，比如山区通信基站覆盖、楼宇轮廓，可以使用 altitudeMode 控制高度模式：clampToGround 贴地、relativeToGround 相对于地面高度、absolute 绝对海拔。做飞行航线或地质剖面时，这三个模式的差异会非常明显，选错模式意味着对象跑到地下或天上。

3. 三个容易被忽略的“软装”能力

3.1 样式系统：想让地图好看，别只堆地标

坐标再准，没有合适的样式，出来的图也只是一堆难看的默认标记。KML 的样式系统和 CSS 有点类似，可以预先定义一个 <Style>，然后在多个 <Placemark> 里通过 styleUrl 引用。

比如我常用的一套点样式：

xml复制<Style id="cameraPoint">
  <IconStyle>
    <scale>1.2</scale>
    <Icon>
      <href>http://maps.google.com/mapfiles/kml/paddle/red-circle.png</href>
    </Icon>
  </IconStyle>
  <LabelStyle>
    <color>ffffffff</color>
    <scale>1.0</scale>
  </LabelStyle>
</Style>

这里涉及 KML 里最容易记错的一个细节：颜色的十六进制顺序是 aabbggrr，不是网页里常见的 rrggbb。前两位是透明度，后面对应蓝、绿、红。比如红色不透明应该写 ffff0000，半透明红写 7fff0000。很多人在线抄代码把颜色顺序抄错，结果原本想标红的地方变成了蓝色。

样式还包括线型 <LineStyle>，用 <color> 和 <width> 控制颜色、线宽；面对应 <PolyStyle>，可以设置填充色和是否显示轮廓。还有一个实用的升级是 <StyleMap>，它允许同一要素在“普通状态”和“鼠标高亮状态”下切换显示不同图标或颜色，交互感更强。要素数量多、类别多的时候，我建议提前规划一份样式表，把类别 ID 和颜色映射写清楚，避免做到一半全乱套。

3.2 description 字段中的 HTML：能在气泡里放很多东西

很多人以为 <description> 只是显示一小段普通文字，用起来才发现它支持 HTML 片段，文字、链接、图片、表格都能塞进去。这相当于每个地标都自带了一个弹窗页面。

比如我做过一个外业点位台账，每个点名的 description 里有现场照片、负责人电话和检修记录链接，点击地标后弹出的气泡就是一页简易报告。写法很简单，用 CDATA 包裹避免尖括号和符号被 XML 解析：

xml复制<description>
  <![CDATA[
    <h3>3号监测站</h3>
    <p>负责人：李工</p>
    <p>上次巡检：2024-05-12</p>
    <img src="http://example.com/photos/site003.jpg" width="200"/>
    <a href="http://example.com/detail?id=003">查看详细记录</a>
  ]]>
</description>

这里有个容易忽略的现实问题：CDATA 里的 <img> 如果引用的是外网图片，对方打开 KML 时网络不通，图片就会裂掉。用 KMZ 打包时图片要是没有作为资源压缩进去，也同样处理。所以在做外发文件时，最稳妥的方式是把附带的图片放到 KMZ 内，用相对路径引用，而不是纯靠 URL。

另一个坑是有些转换工具把 description 里的 HTML 原封不动搬进属性表，导出后会变得很难看。遇到这种情况要留意转换工具的字段映射选项，看是否能丢弃或简化 HTML。

3.3 ExtendedData 与属性查询：KML 不是只有坐标的空壳

纯几何加一个名字，往往满足不了业务需求。比如你要标注一批管线检修井，每个井不仅要有坐标，还得有编号、材质、埋深、维修状态这些属性。SHP 文件有专门的 dbf 属性表，GeoJSON 有 properties，KML 对应的就是 <ExtendedData>。

基础用法是使用 <Data> 标签：

xml复制<Placemark>
  <name>J-015</name>
  <ExtendedData>
    <Data name="井深">
      <value>2.5</value>
    </Data>
    <Data name="材质">
      <value>混凝土</value>
    </Data>
    <Data name="状态">
      <value>正常</value>
    </Data>
  </ExtendedData>
  <Point>
    <coordinates>116.401,39.915,0</coordinates>
  </Point>
</Placemark>

这样做的好处是属性随文件共享，别人拿到后可以在支持 KML 的 GIS 软件里查询、筛选、按属性设样式，甚至参与字段计算。比把所有信息硬塞进 name 或者 description 要专业得多。

不过 ExtendedData 的兼容性在不同软件里有差异，Google 地球对它的支持相对完整，但在 QGIS 里打开时，某些版本的默认读取会把 ExtendedData 转换成名字带 ExtendedData 前缀的字段，需要手动整理。另外如果面对的数据量很大，比如几千条带复杂属性的要素，KML 的处理性能远不如直接存 PostgreSQL/PostGIS 或 FileGDB。我的一般原则是：KML 适合小批量交换和查看，大规模建库分析坚决不用它当主力。

4. KMZ、SHP、GeoJSON，格式边界与转换重点

4.1 KMZ 的本质是一个 ZIP 压缩包

使用 KML 一段时间后，你会发现很多业务单位要求交付的是 KMZ，而不是 KML。KMZ 其实就是把 KML 文件连同它引用的图标、图片、模型一起打成 ZIP 压缩包。默认情况下，包内会有一个主文档，通常命名为 doc.kml，其他资源按相对路径引用。

比如在 KML 里写 <href>icons/red.png</href>，打包 KMZ 时这个 icons/red.png 就对应包内同一路径下的文件。把单个 KML 发给别人往往会导致引用的本地图片丢失，而 KMZ 不会，因为图片都在包里。正因如此，我在需要交付带照片、自定义图标或三维模型的方案时，普遍选择 KMZ 格式。

需要注意：KMZ 不是对 KML 的语法升级，只是“外套”。你可以把 .kmz 后缀改成 .zip 直接解压出来看内部文件，里面除了 doc.kml 还可能有资源目录、多级文件夹。有些人想手动编辑 KMZ 里的 KML，又不了解这一点，直接用文本编辑器打开 KMZ 看到乱码就懵了——那是因为它被压缩了，得先解压再编辑。

4.2 三种主流格式的差异对比

KML、GeoJSON、SHP 是三种最常见的矢量交换格式，很多项目里需要来回转。一张表可以看明白它们的分工：

这几个格式的差异造成了一个常见的尴尬：KML 里头明明画了很漂亮的点图标和线颜色，转成 SHP 后样式全丢了，只留下素坐标和几个属性字段。这不是软件出错，而是因为 SHP 这种格式本来就只承担几何和属性的存储，样式不在它的核心职责范围内。所以在做数据转换前，心里要有预期：跨格式转栅格、转 SHP，样式损失是必然的；如果要保留视觉呈现，尽量优先交付 KML/KMZ 或者做一套 SLD 样式对应文件。

4.3 kml 转 shp 的 5 个典型翻车点

从热搜词看，现在搜“kml转shp”的人特别多，我也处理过大量这类需求，其中反复踩的坑基本可以归纳为五个：

第一个是几何类型混杂。SHP 的一个文件只允许包含一种几何类型，点的文件不能混线，线文件不能混面。可 KML 一个文件里经常既有点位又有路线还有范围，直接整体转 SHP 常常失败，必须在转换前按类型分别导出。

第二个是属性字段限制。SHP 的 dbf 属性表字段名不能超过 10 个字符，且每条记录的长度也有限制，KML 里的 name、description、ExtendedData 转换后对应关系不一致，description 里超长 HTML 内容很容易被截断或写入失败。

第三个是坐标系和投影问题。KML 默认是 WGS84 经纬度坐标，而 SHP 虽然也可以存经纬度，但更多项目要求的是高斯投影或 UTM 投影坐标。如果只是简单转换没做重投影，导出的数据在 CAD 或专业软件中会落在完全错误的位置。转换时必须在工具里同时设定目标坐标系并执行投影变换。

第四个是中文编码。KML 标准是 UTF-8，部分老工具生成的 SHP 属性 dbf 是 GBK/ANSI，转换后中文可能乱码。GDAL 转的时候如果发现乱码，可以指定 ENCODING=UTF-8 或其他合适的编码重新生成。

第五个是 MultiGeometry 展开。KML 的一个字面要素可能用 <MultiGeometry> 装了多个点/线/面，转换为 SHP 后一条坐标记录会变成多条要素，不梳理的话要素计数对不上。查“数量对不上”时，第一反应先数数 MultiGeometry 里嵌套了几个。

5. 创建与处理 KML 的手段与经验

5.1 手写最小 KML：建议从纯文本开始建

我在培训新人时，经常让他们用文本编辑器手写一个最基本的点、一条线、一个面。这样虽然慢，但对理解标签嵌套关系非常有帮助。写完一个最小文件以后，用 Google 地球打开，看到自己手写的坐标出现在地球上，这个直观反馈比任何教程都有效。

手写过程中，要特别注意 XML 的转义字符：如果坐标之外的内容里出现了 &、<、> 这些符号，直接裸写会导致 XML 坏掉。比如描述里写“A & B 公司”，这儿的 & 必须写成 &，否则解析器会报错。长文本我建议用 <![CDATA[ ... ]]> 包住，这样能在里面自由写 HTML 标签和特殊符号，不用一个个转义。

5.2 用 Python 批量处理：命名空间是绕不开的门槛

实际项目里很少需要手工编辑几十个 KML，通常我会用 Python 做批量改写。Python 有个底层手段 xml.etree.ElementTree，处理几千个地标也能胜任。举一个简单例子，把文件里所有点坐标的经度批量加一个偏移值：

python复制import xml.etree.ElementTree as ET

ns = {"kml": "http://www.opengis.net/kml/2.2"}
tree = ET.parse("input.kml")

for coord in tree.findall(".//kml:Point/kmL:coordinates".replace("kmL", "kml"), ns):
    lon, lat, *alt = coord.text.strip().split(",")
    coord.text = f"{float(lon) + 0.001},{lat},{','.join(alt)}"

tree.write("output.kml", encoding="UTF-8", xml_declaration=True)

等会，这行其实我写出来是为了说明一个现象：操作 KML 时最烦人的并不是坐标计算，而是命名空间。KML 的标准命名空间字符串很长，ElementTree 的 findall 必须显式传命名空间字典，不传就找不到任何节点。我见过不少人在这一步卡住，明明 Python 没报错，结果一个地标都遍历不到。

批量处理的实际需求常见有两种。一种是把一批 Excel 表格里的坐标批量生成 KML 地标，另一种是对一个大的 KML 做坐标纠偏、字段重命名、按类别拆分输出。后一种如果基于 gpx、坐标文件的处理，你还需要引入 lxml 性能会更好。需要注意的是，处理完务必抽样打开目视检查，工具转换再多也不如人眼抽查可靠。

5.3 用 QGIS 做可视化编辑与转换检查

要是你不想写代码，只想快速看看 KML 有没有问题，或者做一些小范围修整，QGIS 是最顺手的免费工具。它原生支持直接拖入 KML，也可以将任意图层导出为 KML/KMZ。

在 QGIS 里打开一个 KML 之后，我通常先看右下角的坐标系，确认是 WGS84。然后打开属性表，看要素数量和字段内容是否完整。如果想转成 SHP，选中图层后右键“导出”并选择“要素另存为”，在格式里选 ESRI Shapefile。此时记得指定目标坐标系，比如如果项目要求平面坐标，就选择对应的投影坐标系，让 QGIS 自动做投影转换。

还有个小技巧：QGIS 的 KML 读取能力虽然强，但在显示复杂 StyleMap、屏幕覆盖层和气球样式时和 Google 地球差别很大。遇到这类“在 Google 地球里正常，在 QGIS 乱掉”的文件，不一定是文件坏了，而是两个软件对 KML 规范的实现程度不同。做跨软件检查时，尽量准备两个查看器对照，不要看到一边异常就断定数据有问题。

6. 实际项目里反复踩的 KML 坑位与提醒

6.1 坐标系与坐标顺序：出问题最难察觉

这些年我收到过很多坐标异常的 KML，排在第一位的原因永远是坐标顺序搞反。KML 写的是“经度,纬度”，但 GPS 设备、地图 App 导出的文本经常是“纬度,经度”。如果一个文件全部坐标经纬度互换，在 Google 地球里点会出现在海洋里或偏差很大，而如果只是部分互换，往往定位到邻近城市，更难发现。

坐标系方面，KML 默认遵循 WGS84 经纬度，不含投影信息。有人拿到 CAD 图里提取的“坐标”（通常是高斯平面坐标）直接填进 KML，结果点位完全不在预期位置。正确做法是先把平面坐标在 GIS 软件里转成 WGS84 经纬度，再写入 KML。反过来，KML 转 CAD 时也要把经纬度转回目标投影，否则你得到的“线”没有正确的平面坐标意义。

6.2 文件体积和性能：几万条地标压垮客户端

另一个常见问题是：非专业人士喜欢把大量地标堆在一个 KML 里，几千上万个 Placemark 全放在一个 <Document> 下，不加文件夹，也不做分级加载，最后文件动辄几十上百 MB，打开一次卡顿几分钟。

对策主要有几种。第一种，如果只是地图展示，可以把不需要带属性的坐标点优化成多坐标的 LineString 或 MultiGeometry，而不是每个点单独一个 Placemark。第二种，使用 <Region> 和 <Lod> 控制细节层次，让不同缩放级别加载不同密度数据，但这套机制维护成本高，适合服务端动态生成。第三种也是最实际的，大体积数据就不要强行用 KML 了，转成 GeoPackage 或 SHP 入库，KML 只保留结果图或少量关键点。

6.3 打开方式与编码问题：同一个文件在不同软件里不一样

编码是我做数据交接时很头大的点。如果 KML 文件不是 UTF-8 编码，或者 XML 声明里的 encoding 和实际编码不一致，多数软件都可能出现中文乱码。一个稳妥习惯是：所有 KML 一律用 UTF-8 保存，并在 XML 第一行写明 encoding="UTF-8"。当别人发给我的 KML 打开乱码时，我会先用文本编辑器另存为 UTF-8 再试。

还有一个常见的“显示差异”现象：同一个 KML 在 Google 地球里点的图标正常，在 QGIS 里变成红色小圆点，在 Web 地图里甚至完全不显示。原因是 KML 里定义的图标地址如果指向本地文件比如 file:///C:/...，其他软件访问不到；如果指向外网地址，内网环境也加载不了。所以我在共享文件时会优先把图标嵌入 KMZ，或者使用公开稳定的在线图标地址，避免对方打开后图标全丢、只剩文字。

6.4 给新人的一条工作流建议

和数据打交道这么多年，我觉得处理 KML 最重要的不是背下所有标签，而是先建立一套可复用的检查流程：拿到 KML 后，第一步用文本编辑器打开看文件头和编码；第二步用 Google 地球或 QGIS 打开，随机抽查关键坐标是否对得上；第三步确认有没有外链图片和本地图标，盘算对方打开时能否正常显示；第四步根据需要决定要不要转成 SHP 或 GeoJSON，转换时先理清几何类型、字段限制、坐标系和编码这四个点。

我个人做外业协调项目时，还会坚持留一份 KMZ 作为视觉交付物，同时导出一份带 ExtendedData 的 KML 或 SHP 作为数据存档。这样既保留了最终呈现效果，也方便后续入库分析。KML 的支持内容越丰富，越要在分享时多想一步：对方用什么软件打开、网络通不通、要不要做投影转换。把这几个问题想透，就不容易被格式折腾了。