能否无需百分编码，用base64外字符集安全编码data URL二进制？

核心结论 #

在Apple API的Data URL场景下，完全可以使用base85、base91或自定义Base80这类比base64更紧凑的编码，但需关注字符兼容性与标准/实现的差异，避免因百分编码抵消体积优势。

编码选择要点 #

• 优先适配无编码字符集：RFC2397定义Data URL的data部分无需百分编码的字符为字母数字及-_.!~*'()，若编码方案的字符集完全落在这个范围内，能最大化紧凑性。
  • base85（ASCII85）的字符集覆盖!-u区间，其中部分字符（如<>等）需百分编码，会小幅削弱体积优势。
  • base91的字符集排除了空格、双引号、单引号等少数字符，仍有部分字符需编码，但整体比base64更高效。
  • 自定义Base80编码时，建议完全基于上述无编码字符集设计，彻底避免百分编码的额外开销。

标准与实际实现的差异 #

• RFC2397规范要求：Data URL的data部分仅允许urlchar（字母数字+-_.!~*'()），其余字符必须做百分编码。
• 实际实现兼容：包括Apple API在内的多数实现对Data URL的字符限制更宽松，允许大部分可打印ASCII字符（含冒号、分号、逗号等分隔符）直接使用，无需编码，这与多年实践经验一致。
• 关于base64的+和/：Mozilla文档指出这类字符在Data URL中无需编码，虽不符合RFC2397严格定义，但实际实现均支持，因为Data URL无路径或查询参数，不会产生歧义。

实践建议 #

• 先做兼容性测试：直接用base85/base91编码后的字符串构造data:,SOME_ENCODED_DATA格式的URL，验证Apple API能否正确解析。
• 评估实际体积：若存在需百分编码的字符，计算编码后的总长度，确认是否仍优于base64。
• 自定义编码最优：若需极致紧凑，可基于RFC2397允许的无编码字符集设计Base80编码，彻底消除编码开销。

内容的提问来源于stack exchange，提问作者Andy Dent