RFC 23.1:OGR中的Unicode支持

作者：弗兰克·温特丹

联系方式：warmerdam@pobox.com

状态：通过（实施）

总结

本文提出了GDAL/OGR在UTF-8内部处理字符串和支持不同编码之间转换的初步步骤。

主要概念

GDAL的修改应支持以下三个主要思想：

  1. 将提供C函数来支持各种编码转换，包括表示之间的转换（即UTF-8到UCS-16/wchar-t）。

  2. 字符编码将由iconv（）样式字符串标识。

  3. OGR中的OFTString/OFTStringList特性属性将被视为UTF-8中的属性。

此RFC特别不试图解决使用非ascii文件名的问题。它也不试图定义GDAL/OGR中使用的其他字符串（如字段名、元数据等）的编码。这些问题可能会在稍后的RFC大楼中解决。

cprecode接口

将引入以下三个C可调用函数，用于对字符串进行重新编码，以及在wchar_t（宽字符）和char（多字节）格式之间进行转换：

char *CPLRecode( const char *pszSource,
                 const char *pszSrcEncoding, const char *pszDstEncoding );

char *CPLRecodeFromWChar( const wchar_t *pwszSource,
                          const char *pszSrcEncoding,
                          const char *pszDstEncoding );
wchar_t *CPLRecodeToWChar( const char *pszSource,
                           const char *pszSrcEncoding,
                           const char *pszDstEncoding );

在每种情况下，返回的字符串都是以零结尾的，输入字符串也是这样，返回的字符串应该使用CPLFree（）释放。如果出现错误，返回的字符串将为空，函数将发出CPLError（）。这些函数将用CPL_DLL标记，并被视为公共GDAL/OGR API的一部分，用于应用程序和内部使用。

编码名称

建议编码名称与iconv（）使用的名称类型相同。所以像“UTF-8”、“LATIN5”、“CP850”和“ISO_-1”这样的东西。这些编码名称似乎与C库语言环境名称（例如“en_C a.utf8”）的比例不是1:1，这可能会导致一些问题。

一些特别感兴趣的名字：

  • “”当前区域设置。在从/转换为用户区域设置时使用此选项。

  • “UTF-8”：多字节编码的Unicode。大多数情况下，这将是我们的内部林加法郎。

  • “POSIX”：我认为这大概是ASCII（可能有一些扩展字符？）。

  • “UCS-2”：双字节unicode。这是一种宽字符格式，仅适用于wchar_t方法。

在某些系统上，您可以使用“iconv--list”获取支持的编码列表。

iconv（）

建议在可用时使用iconv（）和相关函数实现cprecode（）方法。

这个API有一个很好的实现，即GNU libiconv（），Linux上的C库使用它。还有一些操作系统提供了iconv（）API作为C库的一部分（所有unix？）；但是，系统iconv（）通常支持一组受限制的转换，因此可能需要优先使用libiconv而不是系统iconv（），即使它是可用的。

如果iconv（）不可用，将提供recode服务的存根实现：

  • 使用mbtowc/wctomb或派生自 http://www.cl.cam.ac.uk/~mgk25/unicode.html .

  • 通过不执行任何操作实现从“”到“UTF-8”的重新编码，但如果当前区域设置似乎不是“C”区域设置，则在第一次使用时发出警告。

  • 实现从“ASCII”到“UTF-8”的作为空操作的重新编码。

  • 通过将所有非ASCII多字节字符转换为“？”，实现从“UTF-8”到“ASCII”的重新编码。

希望在不使用iconv（）的情况下，这会给我们一个弱操作状态，但在它可用的情况下，会给我们一个完整的操作状态。

--with iconv=选项将添加到configure中。参数可以是libiconv安装的路径，也可以是表示应使用系统库的特殊值“system”。或者，--不带iconv可以用来避免使用iconv。

OFTString/OFTStringList字段

声明OGR字符串属性值将采用UTF-8格式。这意味着OGR驱动程序负责在读取时将特定于格式的表示转换为UTF-8，在写入时将其转换回特定于格式的表示。在许多情况下（简单的ASCII文本），这不需要转换。

这意味着OGRFeature：：SetField（int i，const char）等方法的参数 * )应该是UTF-8，GetFieldAsString（）将返回UTF-8。

同样的问题也适用于字符串的OFTStringList列表。每个字符串都假定为UTF-8。

OLCStringsAsUTF8功能标志

一些驱动程序（如CSV）无法有效地知道其输入的编码。因此，以保证的方式把东西变成UTF-8并不总是可行的。因此，用宏“OLCStringsAsUTF8”表示的名为“StringsAsUTF8”的新层级功能将可以在层级使用TestCapability（）进行测试。确定返回字符串属性为UTF-8的驱动程序应该返回TRUE，而不知道返回的编码的驱动程序应该返回FALSE。任何知道编码的驱动程序都应该转换成UTF-8。

OGR驱动程序更新

以下OGR驱动程序可以立即从以某种方式重新编码到UTF-8支持中获益。

  • ODBC（添加对wchar_t/NVARSHAR字段的支持）

  • 整形器

  • GML（我不确定XML编码值是如何映射到我们的编码概念的）

  • 博士后

我确信其他一些驱动程序，特别是RDBMS驱动程序，可以从更新中受益。

实施

Frank Warmerdam将实现核心iconv（）功能、cprecode（）添加和更新ODBC驱动程序。其他OGR驱动程序将随着时间和需求的要求而更新，以符合感兴趣的开发人员在本RFC中的定义。

核心工作将在GDAL/OGR 1.6.0版本中完成。

工具书类