Postgres pro standard de documentare 9

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:
  • libpq (Secțiunea 33.10) are funcții pentru gestionarea codării clientului.
  • 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ă:
  • Folosind PGCLIENTENCODING. Dacă este setată variabila de mediu PGCLIENTENCODING. atunci această codificare a clientului este selectată automat când este conectat la server. (Acest lucru poate fi mai târziu suprascris de oricare dintre metodele enumerate mai sus.)
  • 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.)

  • <





    ?php include ($ _SERVER ["DOCUMENT_ROOT"]. "/ vstavki / blokvtext2.php"); ?>

    Î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.







    Trimiteți-le prietenilor: