MS RFC 103：层级字符编码处理

日期

2013／08

作者

托马斯堡

联系方式

thomas.bonfort@gmail.com

状态

采用

版本

MAPServer 7

1。现状

MapServer不知道数据源的字符编码，这有多种含义：

  • Mapfile 中的筛选器和表达式必须以与数据源相同的编码写入 Mapfile 。对于完全UTF8数据源和 Mapfile 来说，这不是一件容易的事情，但是在使用非UTF8数据源时（因为 Mapfile 需要以另一种编码方式保存），这会变得难以管理（例如，第1层是UTF8，而第2层是Latin1）。

  • 必须手动指定编码头的处理，以便将正确的内容类型头和XML编码标记发送回OGC文档的客户端（getCapabilities、getFeature等…）

  • 对于呈现，我们讨厌地指定标签级别的编码来将标签文本转换为utf8，因为我们的呈现器只支持这种转换。

2.第2条。层级编码

此RFC建议在层级别添加一个编码关键字。具有编码集且不同于utf8的层数据源的属性将在getshape和getnextshape vtable包装器中转换为utf8。

2.1影响

  • mapserver的核心可以忘记处理编码，并将所有字符串视为utf8。

  • 所有文本文档（如功能、GetFeature、查询等）将以utf8格式发出。

  • 不需要在mapfile中指定编码元数据条目，以便生成稍微正确的ogc文档。

2.2向后兼容性

对于处理非UTF8或ASCII数据集的用户，此RFC存在一些显著的向后不兼容问题：

  • Mapfile 本身应该是UTF8编码的。非utf8编码的 Mapfile 需要是iconv'd到utf8。

  • 所有文本文件将以UTF8格式发送，并带有相应的标题和/或前言。不支持在其他编码中发出。

  • 将删除标签级编码。为了帮助向后兼容，我们可能希望在加载 Mapfile 时将层级编码设置为标签级编码。

然而，应该注意的是，这些不兼容性可以而且应该被视为修复MapServer对这些编码数据源的错误处理的一种方法。

2.3性能影响

无或几乎不明显：

  • 对于utf8和ascii数据源：不需要

  • 对于其他数据源：ICONV调用的开销应该是边际的。

三。实施细节

3.1受影响的文件

  • mapfile.c：编码关键字的层级处理，可能处理标签级编码以实现向后兼容性

  • maplayer.c:iconv调用以转换mslayergetshape（）和mslayergetnextshape（）中属性的编码

  • tbd：删除编码解决方法并修改头/前导码打印以宣布utf8。

3.2跟踪问题

TBD

第四章。讨论

虽然对这个问题的更一般的处理可能还包括处理实际 Mapfile 的编码（为了避免强制将utf8作为强制的映射文件编码），但不建议使用此解决方案，因为：

  • 这在整个代码库中增加了大量的复杂性

  • utf8是目前广泛推荐使用的编码方式

5.投票历史

托马斯布、米克斯、丹尼尔、史蒂文、佩里克莱斯、史蒂文、塔马斯和斯蒂芬