Postgres + PHP = unicodeproblem

Vilken version av PostgreSQL? Vilken libpq-version är PHP-modulen kompilerad mot? Det låter som att du har en gammal version, utan stöd för multibyte-tecken.

Det där var bara php-modulen. Hur är det med själva servern? (SHOW ALL är din kompis...)

7.4 är ju i vilket fall som helst inte pinfärsk. Har du möjlighet att uppgradera så rekommenderar jag det.

Fanns det inget om multibyte character support?

Jag har iofs aldrig kört en klient med multibyte-stöd mot en server som inte har det, men jag kan tänka mig att det skulle leda till problem. (Man tycker att klienten skulle kunna översätta själv, men det är inte självklart.) Kolla en gång till om servern har multibyte-stöd; har den inte det skulle jag satsa ända upp till en femtioöring på att det är orsaken till ditt problem.

För att börja nysta i en annan tråd: vad är responsen när du försöker sätta klientkodningen från PHP? (Vad är exempelvis returvärdet från pg_set_client_encoding? Vad svarar servern efter SET client_encoding?)

Eh, joo... Den teckenkodning som PostgreSQL betecknar som UNICODE är egentligen UTF-8, vilken använder från en till fyra bytes per tecken, allt efter behov. För att kunna lagra UTF-8 kodad text måste PostgreSQL < v 8.0 kompileras med multibytestöd. Nu var det inte detta som var ditt problem, eftersom texten var lagrad som SQL_ASCII.

Detta får mig åter att misstänka att, för att klienten framgångsrikt ska kunna konvertera från SQL_ASCII till UTF-8, så måste även servern vara kompilerad med multibyte-stöd. Jag kan dock inte verifiera det eftersom jag inte har tillgång till en såpass gammal version av PostgreSQL. (Har tyvärr inte tid eller lust att kompilera en heller...)

Givetvis kan det vara en bugg i PHP också, men om du har tillgång till servern via psql borde du kunna verifiera problemet den vägen. Se bara till att psql använder samma libpq som PHP.

Hittade följande upplysande stycke i dokumentationen:

vilket borde förklara situationen till fullo.

Gjorde även ett snabbtest i 8.1.3 och samma fenomen uppstår här, så det ser ut som att enda lösningen skulle vara att byta databasens teckenkodning. (Eller att låta PHP koda om, som du redan prövat...)

Man behöver inte köra initdb om det är det du menar, däremot behöver man dumpa -> konvertera dump till rätt teckenkodning -> skapa ny databas med rätt teckenkodning -> importera konverterad dump. Har du BLOBar eller bytea-fält måste du även hantera dem.

För konvertera-steget ovan brukar folk rekommendera iconv.

(Jag tycker mig minnas nån på mailinglistan som helt enkelt uppdaterade pg_database, men då var datan ren ASCII, alltså inga å,ä,ö eller liknande. Möjligen skulle man kunna använda CREATE DATABASE med TEMPLATE parametern, men det kan nog gå åt skogen det med. )

Den frågan kan du nog svara bäst själv på genom att svara på frågan: vad för data ska lagras?

De två naturliga alternativen är väl i detta fallet LATIN1 (iso-8859-1) om det rör sig om västeuropeiska skriftspråk och UTF8 (UNICODE är du nog tvungen att skriva eftersom du har en äldre PG-version) om du vill kunna hantera ex. kinesiska, arabiska eller liknande. Givetvis funkar UNICODE bra även för västeuropeiska språk, och det kan ju vara bra att ligga steget före om kraven nån gång skulle ändras. Prestandan för de respektive kodningarna får du testa själv med riktiga data, men om det inte rör sig om extremt hög belastning skulle jag inte tro att du märker nån skillnad. (Och då kan du nog ändå vinna betydligt mer på att uppgradera till version 8.1, som innehåller många förbättringar jämfört med 7.4)