24.3. Suport pentru codificare
Suportă codificare în Postgres Pro vă permite stocarea textului în codificări diferite, inclusiv codificări pe un singur octet, cum ar fi membri ai familiei ISO 8859 și codificările multi-octet, cum ar fi EUC (Extended Code Unix), UTF-8, și codul intern Mule. Toate codificările acceptate pot fi utilizate în mod transparent de către clienți, dar unele nu sunt acceptate de server (ca de codare pe partea de server). Codificarea este selectată implicit la inițializarea clusterului de baze de date Postgres Pro folosind initdb. Se poate suprascrie atunci când se creează o bază de date, care vă permite să aveți mai multe baze de date cu codificări diferite.
O limitare importantă este însă că codificarea fiecărei baze de date trebuie să fie compatibilă cu baza de date a parametrilor de localizare LC_CTYPE (simboluri de clasificare) și LC_COLLATE (ordinea de sortare a rândurilor). Pentru o localizare C sau POSIX, orice set de caractere este adecvat, dar pentru alte localizări există o singură codificare care va funcționa corect. (Cu toate acestea, în Windows, codificarea UTF-8 poate fi utilizată cu orice localizare.)
24.3.1. Codificări acceptate
Tabelul 24.1 prezintă codificările disponibile pentru utilizarea în Postgres Pro.
Tabelul 24.1. Postgres Pro codificări
Suport server
Bytes per personaj
Caractere tradiționale chinezești
Cod extins UNIX-CN
Caractere simplificate chineze
Cod extins UNIX-JP
Cod extins UNIX-JP, JIS X 0213
Cod extins UNIX-KR
Cod extins UNIX-TW
Caractere tradiționale chinezești, taiwaneze
Standardul național consolidat
Caractere simplificate chineze
ISO 8859-5, ECMA 113
ISO 8859-6, ECMA 114
ISO 8859-7, ECMA 118
ISO 8859-8, ECMA 121
ISO 8859-1, ECMA 94
ISO 8859-2, ECMA 94
ISO 8859-3, ECMA 94
ISO 8859-4, ECMA 94
ISO 8859-9, ECMA 128
ISO 8859-10, ECMA 144
LATIN1 cu limbile și dialectele europene
ISO 8859-16, ASRO SR 14111
Cod intern Mule
Mskanji. ShiftJIS. WIN932. Windows932
Shift JIS, JIS X 0213
nu este specificat (a se vedea textul)
Cod unic Hangul
ABC. TCVN. TCVN5712. VSCII
Nu toate API-urile client acceptă toate codificările listate. De exemplu, driverul Postgres Pro JDBC nu acceptă MULE_INTERNAL. LATIN6. LATIN8 și LATIN10.
24.3.2. Setarea codificării
initdb specifică codificarea implicită pentru clusterul Postgres Pro. De exemplu,
setează codificarea implicită la EUC_JP (sistem avansat de codificare japoneză). Puteți utiliza --codarea în loc de -E dacă preferați nume de parametri mai lungi. Dacă -e parametrul sau nu --encoding specificat, initdb încearcă să determine o codificare adecvată în funcție de locația specificate sau implicit.
Când creați o bază de date, puteți specifica o codificare diferită de cea standard, dacă această codare este compatibilă cu locația selectată:
Aceasta va crea o bază de date numită coreană. care utilizează codificarea EUC_KR și locale locale ko_KR. De asemenea, puteți obține rezultatul dorit folosind această comandă SQL:
Codificarea bazei de date este stocată în directorul sistem pg_database. Puteți să îl vedeți utilizând parametrul psql -l sau comanda \ l.
Pe cele mai moderne sisteme de operare, Postgres Pro poate determina ce codificare este implicată de parametrul LC_CTYPE. care va asigura utilizarea doar a codificării corespunzătoare a bazei de date. La sistemele mai vechi, trebuie să vă asigurați că codarea care corespunde mediului de limbă ales este utilizată pe cont propriu. O eroare în acest domeniu este probabil să conducă la un comportament ciudat al operațiilor dependente de localizare, cum ar fi sortarea.
Postgres Pro va permite super-utilizatorilor să creeze baze de date cu codificarea SQL_ASCII. chiar dacă valoarea LC_CTYPE nu este setată la C sau POSIX. După cum sa menționat mai sus, SQL_ASCII nu garantează că datele stocate în baza de date au o anumită codificare de caractere, și astfel încât această opțiune este plină de eșecuri asociate locale. Utilizarea acestei combinații este depășită și poate fi complet interzisă.
24.3.3. Transcodarea automată între server și client
Postgres Pro suportă transcodarea automată între server și client pentru anumite combinații de codificări. Informațiile privind conversia sunt stocate în directorul de sistem pg_conversion. Postgres Pro include unele codificări predefinite, după cum se arată în Tabelul 24.2. Este posibil să creați o nouă transcodare cu comanda SQL CREATE CONVERSION.
Tabelul 24.2. Client-server set de caractere transcoding
Codificări client disponibile
Pentru a activa transcodarea automată a caracterelor, trebuie să îi spuneți Postgres Pro codificarea pe care doriți să o utilizați pe partea clientului. Acest lucru se poate face în mai multe moduri:
Utilizați comanda \ encoding în psql. \ encoding vă permite să modificați rapid codificarea clientului. De exemplu, pentru a schimba codificarea la SJIS. introduceți:Folosind SET client_encoding TO. Clientul de codificare este setat de următoarea comandă SQL:
De asemenea, în acest scop, puteți utiliza sintaxa standard a SQL SET NAMES.
Obțineți codificarea curentă a clientului:
Resetați codificarea implicită:Utilizând variabila de configurare client_encoding. Dacă variabila client_encoding este setată. codificarea specificată a clientului este selectată automat când este conectat la server. (Aceasta poate fi ulterior suprascrisă de oricare dintre metodele de mai sus.)
În cazul în care anumite caractere nu pot fi transcodată (presupunând că serverul selectat EUC_JP Latin1 și client, și a trecut unele caractere japoneze nu sunt reprezentate în Latin1), apare o eroare.
Dacă codificarea clientului este definită ca SQL_ASCII. transcodarea este dezactivată indiferent de codarea serverului. În ceea ce privește serverul, nu folosiți SQL_ASCII. cu excepția cazului în care lucrați cu date care respectă pe deplin ASCII.
24.3.4. Surse suplimentare de informații
Surse recomandate pentru începerea studiului diferitelor tipuri de sisteme de codificare.
Informații de procesare în chineză, japoneză, coreeană Limbile vietnameză.
Site-ul Unicode Consortium. RFC 3629
UTF-8 (formatul de conversie al UCS / Unicode pe 8 biți) este definit aici.