ugrás a tartalomhoz

Ékezet helyett õ forma MySQL UPDATE esetén

Anonymous · 2006. Júl. 3. (H), 09.28
Sziasztok!

Mysql 4.0.20 -t használok, php4 el, DBTools-al. Van egy kis táblám A és B mezővel. ISO latin2. 'A' mezőbe be INSERT-elek egy 'ő' vagy egy 'ű' betűt. Tökéletesen megjelenik. Abban az esetben ha 'B' mezőbe UPDATE-elek egy ugyanilyen(ő v. ű) betűt akkor 'A' mező tartalma átváltozik õ re vagy &# 251; re. Ha kitörlöm 'B' mező tartalmát akkor 'A' mező vissza áll az eredeti betűre (ő v. ű). Persze ez keresésnél gondot okoz. Valami ötelet esetleg arra nézve hogy ez miért is van? Előre is köszi.
‹ InnoDB foreign key - a törlést hogyan propagáljam más táblákba? mysql egy másik gépen a belső hálón? ›
 ■
1

Hogy kerül be az adat?

Poetro · 2006. Júl. 3. (H), 12.41
Igazából a legfontosabb kérdés, hogy hogyan is kerül be az adat a táblába.
Milyen szövegmanipulációk történnek, amikor az UPDATE / INSERT kérés metörténik, mert ez megváltoztatja, hogy mi is kerül be a táblába.
Másik kérdés, hogy hogyan kerül kiolvasásra ez az adat az adatbázisból, azaz milyen manipulációk történnek rajta, míg megjelenésre kerül.
Először ezeket a kérdéseket kellene tisztázni, hogy segíteni lehessen a problémán.
2

ékezet

Anonymous · 2006. Júl. 4. (K), 08.58
Egy űrlapból küldöm át az adatokat POST-tal az INSERT INTO talba (A)values('ő') nek. A kiolvasás igazából meg sem történik csak megnézem a DBManager-rel az adatokat a táblában. A keresést is itt próbáltam, de nem működött a õ miatt.
3

Bevitel

Poetro · 2006. Júl. 4. (K), 10.58
Nem lehet hogy az INSERT-kor már õ szerepel a POST változó értékében? Ennek utána kellene járni.
4

ékezet

Anonymous · 2006. Júl. 4. (K), 12.04
Kiirattam magát az INSERT parancsot, hogy hogy néz ki mikor megkapja a POST tól az adatot, és akkor még "normális'. Amíg meg nem jelenik a 'B' mezőben az Ő betű addig tökéletes az 'A' mező, illetve ha kitörlöm akkor is visszaváltozik 'A' mező õ ről ő re. :(((
5

Ilyet nem "tud" a MySQL

Poetro · 2006. Júl. 4. (K), 12.17
Valami mégis csak történik... Hogy kerül be a b oszlopba a tartalom? És hogy kerül ki onnan? Mert a hiba akkor ott lehet.
6

megjelenítés?

jbtibor · 2006. Júl. 4. (K), 17.12
Nem inkább a megjelenítéssel van gond?
Véletlenül nem browserben nézed, és rosszul ismeri fel az encodingot?
7

böngészőben jó kéne legyen

Hodicska Gergely · 2006. Júl. 5. (Sze), 08.32
Pont a böngészőben kéne jó legyen, hisz a HTML entitásokat jól meg fogja tudni mutatni. Itt nagyon nagy eséllyel arról van szó, hogy annak az oldalnak a kódolása, amely az adatokat küldő formot tartalmazza, nincs jól beállítva. Ezt kéne a kérdezőnek beállítani, és meggyőződni, hogy ha meta tagben adja meg, akkor nincs-e esetleg headerben érkező, ettől eltérő beállítás (pl. webszerver default).

A meg korábban bevitt tartalmakat pedig ha fontosak, akkor konvertálni kell.


Felhő
8

Yahoo

jbtibor · 2006. Júl. 5. (Sze), 14.35
Valami olyanra gondoltam, mint pl. a Yahoo mailben történik:
ha megnyitok egy levelet, majd átváltok a következőre, az encoding nem változik, és ha a két levél másképpen volt kódolva, akkor a másodikban hibásan jelennek meg az ékezetes karakterek (IE6-ban és FireFoxban is előfordul).
Ilyenkor az a megoldás, hogy a browserben a character encodingot kézzel be kell állítani a megfelelőre.

Azért gondoltam hasonlóra, mert az ő esetében is attól függ a megjelenítés, hogy mi van a másik mezőben. Lehet aszerint állítódik valahol valami kódolás.
9

html entities

Hodicska Gergely · 2006. Júl. 6. (Cs), 00.44
Itt most nem erről van szó. Az oké, hogy mondjuk egy latin2-es ő betű egy latin1-es kódlappal kiadva nem tud jól megjelenni, de itt HTML entitásokról van szó: a karakter helyett annak HTML entitása kerül már be a DB-be is, tehát a form ilyen formában küldi el.


Felhő