分享内容的格式决定接收端可用性
别名: 分享格式 · MIME · UTI · item provider
概念解释
分享面板递出去的不是「一份内容」这么笼统的东西，而是带类型标注的载荷（payload）：纯文本、URL、图像位图、文件副本，或同一对象的多种表示。接收方按自己登记的类型来认领；对不上的目标要么灰掉，要么收下后打不开、丢字段、只剩一串看不懂的字符。类型在 iOS 上常以 UTI 声明，在 Android 上常以 MIME 与 ClipData 声明。这条只谈「交出去的是哪种数据」，不谈该不该走系统面板，也不谈目标列表里会出现谁。
机制
接收方在安装时向系统登记「我能消化哪些类型」。匹配发生在面板弹出时：发送方提供的类型集合与接收方过滤器求交，交集为空的应用不会作为可点目标出现，或者出现后打开空白页。单一表示最脆：只交 URL 字符串，地图应用未必能把它解析成坐标；只交 JPEG，财务应用抽不出金额和税号；只交 HTML，对方若只声明纯文本，版式和表格结构会掉光。系统因此允许同一对象多种表示（item provider / 多 MIME 的 ClipData）：接收方取自己能用的那一种，其余被忽略。还有一类静默失败来自生命周期：交出的是沙盒内路径而不是可读副本，接收方进程无权打开该路径，预览缩略图在，文件本身是空的。
边界
接收方如果是人而不是解析器（把链接贴进聊天），纯文本几乎总够用，类型精度的收益下降。超大原文件的多表示会把内存和流量打满，缩略图加远程 URL 比内嵌整份视频更合适。加密或权限保护的内容不能靠类型声明越过接收方的权限模型：对方即使声明能收 PDF，也不应拿到未授权的附件副本。系统面板自己会做一层类型过滤，发送方不必为每个目标手写分支，但必须把「人真正要带走的那层信息」放进至少一种接收方普遍登记的类型里。
怎么落地
- 为同一对象同时提供至少两种表示：人能读的纯文本或 URL，外加接收方能解析的结构化文件（PDF、vCard、图像）。
- 分享文件时交出可读副本或系统级文件提供器，不要只传应用沙盒里的绝对路径。
- 验证：用三个接收方分别收同一条分享——纯文本编辑器、该类型的专用应用、不声明该 MIME 的应用。专用应用应打开完整字段，文本编辑器应得到可读摘要，未声明类型的应用不应以可点目标出现；若专用应用打开后缺字段，补一种它登记过的表示。