土耳其语字符上的 Postgres upper 函数未返回预期结果

看起来像 postgresupper/lower函数不处理土耳其语字符集中的选择字符。

select upper('Aaı'), lower('Aaİ') from mytable;

返回：

AAı, aaİ

代替 ：

AAI, aai

请注意，正常的英语字符可以正确转换，但土耳其语 I（小写或大写）不能正确转换

Postgres 版本：9.2 32 bit

数据库编码（其中任何一个结果相同）：UTF-8, WIN1254, C

客户端编码：

 UTF-8, WIN1254, C

OS: Windows 7 enterprise edition 64bit

SQL函数lower and upper在 UTF-8 编码数据库上为 ı 和 ï 返回以下相同字节

\xc4b1    
\xc4b0   

以及以下关于 WIN1254（土耳其语）编码数据库的内容

\xfd      
\xdd     

我希望我的调查是错误的，我错过了一些东西。

你的问题is100% 窗户。（或者更准确地说，是 Microsoft Visual Studio，PostgreSQL 是用它构建的。）

作为记录，SQLUPPER最终调用 Windows'LCMapStringW http://msdn.microsoft.com/en-us/library/windows/desktop/dd318700.aspx (via towupper http://msdn.microsoft.com/en-us/library/45119yx3.aspx via ) with almost所有正确的参数（区域设置 1055 土耳其语UTF-8-编码，Turkish_Turkey数据库），

but

Visual Studio 运行时（towupper）不设置LCMAP_LINGUISTIC_CASING http://www.siao2.com/2004/12/11/279942.aspx bit in LCMapStringW's dwMapFlags。 （我可以确认设置它确实有效。）Microsoft 不认为这是一个错误；这是设计使然，可能永远不会被“修复”（噢，遗产的乐趣。）

你有三种方法可以摆脱这种情况：

• 实现 @Sorrow 的包装解决方案（或编写您自己的本机函数替换（DLL）。）
• 在例如上运行您的 PostgreSQL 实例乌班图它表现出适合突厥语言环境的正确行为（@Sorrow 确认这对他有效）；这可能是最简单、最干净的出路。
• drop in 已修补的 32 位MSVCR100.DLL在你的 PostgreSQL 中bin目录（但是尽管UPPER and LOWER会起作用，但其他事情（例如排序规则）可能会继续失败——同样是在 Windows 级别。 YMMV。）

为了完整性（和怀旧的乐趣）ONLY，这里是修补 Windows 系统的过程（但请记住，除非您从头到尾管理这个 PostgreSQL 实例，否则您可能会给您的继任者带来很多痛苦；每当从如果您或您的继任者必须记住再次应用补丁——如果有一天您升级到 PostgreSQL 10，则表示使用MSVCR120.DLL代替MSVCR100.DLL，那么您也必须尝试修补新的 DLL。）在测试系统上

• use HxD http://mh-nexus.de/en/hxd/打开C:\WINDOWS\SYSTEM32\MSVCR100.DLL
• 立即以相同的名称将 DLL 保存在您的 PostgreSQL 下bin目录（不要尝试使用资源管理器或命令行复制文件，它们可能会复制 64 位版本）
• with the file still open in HxD, go to Search > Replace, pick Datatype: Hexvalues, then
  • 搜索......4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 00
  • 用。。。来代替...4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 01
  • ……然后再一次……
  • 搜索......FC 51 6A 01 8D 4D 08 51 68 00 02 00 00 50 E8 E2
  • 用。。。来代替...FC 51 6A 01 8D 4D 08 51 68 00 02 00 01 50 E8 E2
• ...and re-save under the PostgreSQL bin directory, then restart PostgreSQL and re-run your query.
  • 如果您的查询仍然不起作用（请确保您的数据库是 UTF-8 编码的Turkish_Turkey对彼此而言LC_CTYPE and LC_COLLATE) open postgres.exe in 32 位依赖项遍历器 http://www.dependencywalker.com并确保它指示已加载MSVCR100.DLL来自 PostgreSQLbin目录。
  • 如果所有函数都正常，则将修补的 DLL 复制到生产 PostgreSQLbin目录并重新启动。

但请记住，当您将数据从 Ubuntu 系统或已修补的 Windows 系统移至未修补的 Windows 系统时，您将再次遇到问题，并且如果 Windows 实例在Acitext场或在UPPER/LOWER基于函数的索引。