Ich kann keinen Fehler in deinem Design finden. Ich habe es versucht.
Gebietsschemata und Sortierung
Ich habe diese Frage noch einmal aufgegriffen. Betrachten Sie diesen Testfall für sqlfiddle
. Es scheint gut zu funktionieren. Ich habe sogar das Gebietsschema ca_ES.utf8 erstellt in meinem lokalen Testserver (PostgreSQL 9.1.6 auf Debian Squeeze) und das Gebietsschema zu meinem DB-Cluster hinzugefügt:
CREATE COLLATION "ca_ES" (LOCALE = 'ca_ES.utf8');
Ich erhalte die gleichen Ergebnisse wie im obigen sqlfiddle.
Beachten Sie, dass Sortierungsnamen Bezeichner sind und doppelt in Anführungszeichen gesetzt werden müssen, um die CamelCase-Schreibweise wie "ca_ES" beizubehalten . Vielleicht gab es einige Verwechslungen mit anderen Gebietsschemas in Ihrem System? Überprüfen Sie Ihre verfügbaren Sortierungen
:
SELECT * FROM pg_collation;
Im Allgemeinen werden Kollatierungsregeln von Systemgebietsschemas abgeleitet . Lesen Sie mehr über die Details im Handbuch hier
. Wenn Sie immer noch falsche Ergebnisse erhalten, würde ich versuchen, Ihr System zu aktualisieren und das Gebietsschema für "ca_ES" neu zu generieren . In Debian (und verwandten Linux-Distributionen) kann dies erfolgen mit:
dpkg-reconfigure locales
NFC
Ich habe noch eine andere Idee:nicht normalisierte UNICODE-Strings .
Könnte es sein, dass Ihr 'Àudio' ist tatsächlich '̀ ' || 'Audio' ? Das wäre dieses Zeichen:
SELECT U&'\0300A';
SELECT ascii(U&'\0300A');
SELECT chr(768);
Lesen Sie mehr über den akuten Akzent in Wikipedia
.
Sie müssen SET standard_conforming_strings = TRUE SETZEN um Unicode-Strings wie in der ersten Zeile zu verwenden.
Beachten Sie, dass einige Browser unnormalisierte Unicode-Zeichen nicht korrekt anzeigen können und viele Schriftarten keine richtige Glyphe für die Sonderzeichen haben, sodass Sie hier möglicherweise nichts oder Kauderwelsch sehen. Aber UNICODE erlaubt diesen Unsinn. Testen Sie, um zu sehen, was Sie bekommen haben:
SELECT octet_length('̀A') -- returns 3 (!)
SELECT octet_length('À') -- returns 2
Wenn Ihre Datenbank davon betroffen ist, müssen Sie sie entfernen oder die Konsequenzen tragen. Das Heilmittel besteht darin, Ihre Zeichenfolgen auf NFC zu normalisieren . Perl verfügt über überlegene UNICODE-foo-Fähigkeiten, Sie können ihre Bibliotheken in einer plperlu-Funktion verwenden, um dies in PostgreSQL zu tun. Ich habe das getan, um mich vor dem Wahnsinn zu bewahren.
Lesen Sie die Installationsanweisungen in diesem exzellenten Artikel über UNICODE-Normalisierung in PostgreSQL von David Wheeler .
Lesen Sie alle blutigen Details über Unicode-Normalisierungsformulare auf unicode.org
.
