ugrás a tartalomhoz

Karakterkódolás PHP vs Oracle

antimgs · 2012. Május. 27. (V), 20.08
Sziasztok!

A php kód eredménytáblázat kódolása során az ékezetes karakterek kérdőjelként jelennek meg.
Az Oracle AMERICAN WE8ISO8859P1.

A php kapcsolat végén a
:'WE8ISO8859P1');
nem hozta a megfelelő eredményt.

Mit kell beállítani a php oldalon, hogy jól jelenjenek meg a karakterek?

Köszönettel Anti
 
1

A WE8ISO8859P1 az nyugat

eddig bírtam szó nélkül · 2012. Május. 27. (V), 20.22
A WE8ISO8859P1 az nyugat európai kódkészletet jelent.
Van benne pár ékezet (pl. franciák), de a magyarokkal nincs túl jó viszonyban.
Vagy unicode (pl. UTF8) kellene, vagy EE8ISO8859P2.
Ha jól emlékszem, az adatbázis létrehozásakor megadott karakterkészlet is okozhat gondot, ha olyan, amiben eleve nem tárolhatóak az ékezeteid. (hű, de rég volt... :-(((( )
2

Már majdnem működik

antimgs · 2012. Május. 28. (H), 16.10
Köszönöm a segítséget!
Most már valahol jók a ékezetek csak még nincs ő;ű.
A beállítás a kapcsolatnál EE8ISO8859P2 volt a jobb, a php charsetben pedig iso-8859-2.
Üdv: Anti
3

Meg kellene nézni az

eddig bírtam szó nélkül · 2012. Május. 28. (H), 16.51
Meg kellene nézni az adatbázisod alapértelmezett beállítását.
(NLS_DATABASE_PARAMETERS view-ból NLS_CHARACTERSET)
Ha a default character set valami olyan, ami nem képes normálisan kezelni a magyar ékezeteket, akkor így jártál.

Egyébként az oldalad kódolása és a headerben kiküldött infó biztosan összhangban vannak?
4

NLS_LANGUAGE

antimgs · 2012. Május. 28. (H), 17.06
NLS_LANGUAGE AMERICAN
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET AL16UTF16
5

Akkor eddigi ismereteim

eddig bírtam szó nélkül · 2012. Május. 28. (H), 17.11
Akkor eddigi ismereteim szerint a varchar2 típusú mezőkbe írt ékezeteidre keresztet vethetsz.
Ha nvarchar2, akkor van esély rá, hogy megmaradtak.
Ráadásul 9i-ig úgy működött a dolog, hogy ezt a beállítást csak egy full export/import segítségével lehetett korrigálni, plusz az adatok manuális javításával.
----
Mérget ne vegyél rá, évek óta nem láttam Oracle-t!
6

Az adatbázishoz jelenleg csak

antimgs · 2012. Május. 28. (H), 17.15
Az adatbázishoz jelenleg csak lekérdezés szinten nyúlok, nincs szükség az írásra. A php kódbóli kimenet helyes megjelenítésre viszont igen.
8

google ugyanezt dobta, az

inf · 2012. Május. 28. (H), 22.24
google ugyanezt dobta, az N-el kezdődő az international, az arra vonatkozó karakterkészlet utf16, a simánál meg latin1. Ha az oszlopoknál a típusnevek N-el kezdődnek, akkor utf16-os adatot ki tudsz nyerni. Ez egyébként vicces lesz, mert mb_ lib talán lekezeli őket, ha jól állítod be, viszont a pcre-nek búcsút mondhatsz, a sima függvények közül meg olyanokat használj csak, amik összefűznek, de nem darabolnak, pl: implode. Ha sikerül kinyerni utf-16-os adatot, akkor én a helyedben utf-8-ra konvertálnám, aztán tudok adni egy lib-et, amit úgy tákoltam össze, hogy működjön utf-8-ra bármilyen szerver beállítás mellett...
9

Kicsit pontosítanék: az

eddig bírtam szó nélkül · 2012. Május. 29. (K), 07.15
Kicsit pontosítanék: az adatbázist célszerű úgy létrehozni, hogy az alapértelmezett karakterkészlet utf8 legyen. (ha jól sejtem, a 11g-től már ez van).
PCRE-t azt hiszem, lehet használni ebben az esetben. (legalábbis rémlik valami egy u "kapcsolóról", de lehet, hogy a python unicode stringjeivel keverem)
Jelenleg az lehet a komolyabb gond, hogy egy ISO-8859-1 karakterkészlettel létrehozott adatbázisba írt valaki magyar ékezeteket, amik a konverzió során elvesz(het)tek.
10

Persze, érdemes utf-8-al

inf · 2012. Május. 29. (K), 10.12
Persze, érdemes utf-8-al létrehozni, ha php-zol, mert sok fejfájástól kíméled meg magad, és valóban pcre függvényeknél u flag-et kell használni. (Én mondjuk usD-vel szoktam tolna, azt könnyű megjegyezni.) Abból, amit a kérdező írt azt vettem ki, hogy erre nincs túl sok ráhatása...
7

Mindenképp utf-8-at javaslom,

inf · 2012. Május. 28. (H), 22.13
Mindenképp utf-8-at javaslom, php-val más karakterkódolással nincs túl sok esélyed. Ha nem akarsz sokat szenvedni, akkor meg php helyett válassz egy barátságosabb nyelvet, én most éppen node.js-re váltok...
11

Köszönöm a

antimgs · 2012. Jún. 3. (V), 22.29
Köszönöm a válaszokat!
Remélem a karakterkódolás miatt nem lesz sok problémám, mert "csak" lekérdezés szinten szeretnék ehhez az adatbázishoz nyúlni (kombóboxos választással az ékezeteket , majd igyekszem kerülni), ami írva lesz az egy nyelvbarátabb dbf.
Üdv Anti