Am întâlnit o problemă destul de neobișnuită (poate doar pentru mine) cu codificarea:
phpbb 1.52 Plus - instalat pe MySQL 4.1 PHP 4 - instalat implicit rusesc
Există o bază de date cu tabele de codare cp1251_general_ci
toate fișierele de limbă sunt afișate în mod normal, toate modificările în limba rusă sunt efectuate prin intermediul administratorului. panoul sau orice mesaje și altele sunt afișate corect (codul sursă al paginilor se referă la ferestrele de codare-1251)? și același text din baza de date este înlocuit cu semne de întrebare. ""
pe de altă parte, dacă încercați să completați datele în limba rusă prin intermediul bazei de date, atunci în fișierul phpMyAdmin acestea sunt afișate corect - în codarea cp1251, iar pe forum și pe portal există un gunoi sub formă de întrebări. ""
Alfabetul latin este afișat corect
Cyrillicul din fișierele de limbă este afișat corect
Cyrillic din baza de date nu este afișat
Întrebare: în ce poate exista un motiv de astfel de eșec? Prima dată în 3 ani este o astfel de întâlnire.
Voi fi recunoscător pentru ajutor.
Versiunea MySQL 4.1. suportă Unicode la nivelul încorporat, codificarea cu numele win1251 este eliminată în loc de acesta - cp1251. În plus, ultima versiune a phpMyAdmin conține multe erori care apar atunci când lucrează cu MySQL 4.1 într-o altă codare decât UTF-8. Aici pe aceste greble ați apărut și ați dat peste cap. Vă sfătuiesc să descărcați și să vă retrageți din Denver Dklabov acolo phpMyAdmin - băieții l-au reglat pentru compatibilitate.
O altă informație este MySQL 4.1.5
phpMyAdmin versiunea încorporată 2.6
a încercat să lucreze prin efectul denver - zero. aceleași prostii:
adevărul este acum dezvăluit
parametrul character_set_server are valoarea latin1 Înțeleg că aceasta este cauza inițială a eșecului: (
Probabil ar fi trebuit să fie inundat cu același software și cu aceeași versiune ca și backup-ul. Dacă totul este afișat corect în fișierul de rezervă, în codarea MySQL de admin: Windows Cyrillic (cp1251) o Maparea conexiunii la MySQL: cp1251_general_ci - character_set_server nu ar trebui să fie afectată.
Asta este. Cu versiunea musculară MySQL 4.1.5, toate datele din acesta sunt stocate în formatul utf-8. Înseamnă că baza de date TREBUIE să fie creată cu suportul cp 1251
* CREAȚI DATABASE "MEM_MySQL_BD" SET DE CARACTER DEFINITIV cp1251 COLLATE cp1251_general_ci
Apoi, un gimor complet - datele stocate ca 1251 sunt traduse în utf-ul însuși și invers atunci când se emite. Când se editează în phpaddam, se pare că totul este corect afișat, însă, în realitate, în timpul înregistrării apare gunoi, iar când se afișează scriptul pe forum, se afișează abracadabra.
Pe scurt, dacă drumul este la bază, luptați cu codificările. Baza Phpadmin nu se pronunță, deși Dklabovul este lipsit de multe probleme cu codificarea.
Probabil ar fi trebuit să fie inundat cu același software și cu aceeași versiune ca și backup-ul. Dacă totul este afișat corect în fișierul de rezervă, în codarea MySQL de admin: Windows Cyrillic (cp1251) o Maparea conexiunii la MySQL: cp1251_general_ci - character_set_server nu ar trebui să fie afectată.
Asta este. Cu versiunea musculară MySQL 4.1.5, toate datele din acesta sunt stocate în formatul utf-8. Înseamnă că baza de date TREBUIE să fie creată cu ajutorul cp 1251
* CREAȚI DATABASE "MEM_MySQL_BD" SET DE CARACTER DEFINITIV cp1251 COLLATE cp1251_general_ci
Apoi, un gimor complet - datele stocate ca 1251 sunt traduse în utf-ul însuși și invers atunci când se emite. Când se editează în phpaddam, se pare că totul este corect afișat, însă, în realitate, în timpul înregistrării apare gunoi, iar când se afișează scriptul pe forum, se afișează abracadabra.
Pe scurt, dacă drumul este la bază, luptați cu codificările. Baza Phpadmin nu se pronunță, deși Dklabovul este lipsit de multe probleme cu codificarea.
Aici este interesant, pe cererea serverului anterior SHOW VARIABLES a arătat astfel de Vechi, pe același server aceeași versiune, dar a lucrat ca un ceas fără probleme:
caracter_set_client cp1251
caracter_set_connection cp1251
caracter_set_database cp1251
character_set_results cp1251
caracter_set_server cp1251
caracter_set_system utf8
caracter_sets_dir / usr / local / share / mysql / charsets /
Din nou, baza de date de rezervă pe localhost pe mașină sa ridicat fără probleme și nu există probleme cu codificările și aceeași interogare arată:
caracter_set_client cp1251
caracter_set_connection cp1251
caracter_set_database cp1251
character_set_results cp1251
caracter_set_server cp1251
caracter_set_system utf8
caracter_sets_dir \ usr \ local \ mysql4 / share / charsets
Nu pot exista astfel de coincidențe?
ca întotdeauna nu merge pentru a crea un subiect nou - voi scrie în acest
cand pentru prima data am incercat sa instalez phpbbplus pe Denver-ul meu nativ am scos un bjaka cu codificari
forumul nu a funcționat - nu a existat nimeni care să ceară
toate rusii au fost scrise de croați
scotea tot Internetul, a scris manual codarea în mysql, phpmyadmin - oriunde ar fi putut - nu a ajutat
\ db \ mssql.php
\ db \ mysql.php
\ db \ mysql4.php
prin instinct, au avut unele modificări în ele (ceva ca o alegere obligatorie de codificare la accesarea bazei de date) și totul a funcționat
acum întregul forum se blochează în limba rusă obișnuită, cu excepția câtorva momente
De exemplu, există un sondaj - opțiunile din sondaj sunt scrise în limba rusă, persoana votează - imediat după aceasta există o pagină cu rezultatele votării - boom-ul listei CROP - apăsați pentru a reîmprospăta pagina - iar din nou rusa
după cum înțeleg că este necesar să reparăm fișierele de mai sus undeva, astfel încât totul să fie complet OK
P.S. Forumul phpbb toată viața mea a fost în Denver meu natal și totul a fost ok.
P.S.S. A înlocuit deja 3 ansambluri web (acum Topserver)? dar o problemă în vechiul loc
SCALOlaz
Omul nostru
E ciudat. Am 1.53 o dată plug în rusă, fără probleme și finches.
Nu credeți că greșelile actuale sunt rezultatul unor editări precoce?
Este doar o chestie de strigare și lovirea pălăriei nu este necesară. Dy.
Articole similare
Trimiteți-le prietenilor: