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

日期

2013/08

作者

托马斯堡

联系

thomas.bonfort@gmail.com

状态

采用

版本

MAPServer 7

1。现状

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

  • 映射文件中的筛选器和表达式必须以与数据源相同的编码写入映射文件。对于完全UTF8数据源和映射文件来说,这不是一件容易的事情,但是在使用非UTF8数据源时(因为映射文件需要以另一种编码方式保存),这会变得难以管理(例如,第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存在一些显著的向后不兼容问题:

  • 映射文件本身应该是UTF8编码的。非utf8编码的映射文件需要是iconv'd到utf8。

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

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

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

2.3性能影响

无或几乎不明显:

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

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

三。实施细节

3.1受影响的文件

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

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

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

3.2跟踪问题

TBD

第四章。讨论

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

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

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

5.投票历史

+1人来自托马斯布、米克斯、丹尼尔、史蒂文、佩里克莱斯、史蒂文、塔马斯和斯蒂芬。