kwadraat teken in mysql

[JoramQ]

Ik heb een tabel met een omschrijving van een item waar vaak het kwadraat teken gebruikt wordt. Deze zijn er allemaal handmatig ingezet en dat werkt gewoon goed.
Alleen als ik op de site een item ga bewerken dan komt er ipv alleen het kwadraat teken een  voor te staan. Dus m² wordt m². Ik heb gekeken hoe de tekst wordt gecontroleerd op rare tekens maar als ik er helemaal geen controle tussen heb zitten gaat het ook fout. En als ik de variabele echo voordat hij wordt opgeslagen zie ik het gewoon goed.

Heeft iemand enig idee waar dit aan kan liggen?

[NiteSpeed]

Staat je character encoding in je database op UTF-8?

/Edit, je werkt de andere kant op, vanuit de database naar website.

[ Voor 44% gewijzigd door NiteSpeed op 29-06-2009 11:21 ]

[Invisible_man]

Moet je dat karakter niet escapen (dus er een \ voor zetten)? Weet het niet zeker, maar daar zou ik het zoeken.

[Ricvdp]

Kijk eens naar de character encoding.

[Joolee]

Je zult in je hele website ervoor moeten zorgen dat er één characterset wordt gebruikt met ondersteuning voor het Kwadraat teken. (UTF-8)
Lees ook even dit topic, daar staan wat nuttige linkjes in.

[JoramQ]

maar handmatig werkt alles goed, alleen bij het opslaan komt er een extra A voor in de database en daarna dus ook op de website. Als ik die A met phpmyadmin weer verwijder doet alles het goed

[Janoz]

Bij het opslaan worden blijkbaar verschillende encodings gebruikt. Vandaar dat het daar mis gaat. Als je tekst in de ene encoding opstuurt, maar vervolgens uitgaat van een andere encoding bij het verwerken zijn dit precies de problemen die je krijgt.

[Swaptor]

Wat er dus op neerkomt dat je ergens tussen de website en je DB een verschil hebt zitten in characterset.
Gokje: DB staat op UTF-8, en de site probeert met een Latin-set iets op te slaan.

EDIT: wat Janoz zegt dus. (grrrr )

[ Voor 10% gewijzigd door Swaptor op 29-06-2009 11:37 ]

[mithras]

Je gebruikt de data voor een website? Het is dan beter om het correcte html karakter te gebruiken, namelijk ² wat resulteert in ².

Dan weet je tenminste zeker dat het ook goed wordt getoont. Wil je met een goede encoding werken, zal je database, php script, php variabele, html document én apache allemaal goed moeten zetten. De kans op een fout is daar vele malen groter. Gewoon alle strings met htmlentities() encoden voordat je ze in de db stopt.

[JoramQ]

oke bedankt, dan ga ik dat fixen

[Voutloos]

mithras schreef op maandag 29 juni 2009 @ 11:42:
Je gebruikt de data voor een website? Het is dan beter om het correcte html karakter te gebruiken, namelijk ² wat resulteert in ².

Dan weet je tenminste zeker dat het ook goed wordt getoont. Wil je met een goede encoding werken, zal je database, php script, php variabele, html document én apache allemaal goed moeten zetten. De kans op een fout is daar vele malen groter. Gewoon alle strings met htmlentities() encoden voordat je ze in de db stopt.

Serieus, encoding moet je gewoon een keer grondig nalopen en klaar ben je. Wat jij zegt is gewoon pleisteren uit luiheid.

[Woy]

mithras schreef op maandag 29 juni 2009 @ 11:42:
Je gebruikt de data voor een website? Het is dan beter om het correcte html karakter te gebruiken, namelijk ² wat resulteert in ².

Dat lijkt me niet de juiste oplossing, maar gewoon symptoom bestrijding. Dat je het nu als output voor HTML gebruikt wil niet zeggen dat je dat straks ook nog wil doen. Misschien wil je wel PDF's gaan genereren aan de hand van die data.

Zoals al gezegd is moet je gewoon zorgen dat je de juiste encoding gebruikt.

[4of9]

leuk artikeltje:

http://www.joelonsoftware.com/articles/Unicode.html

[mithras]

Voutloos schreef op maandag 29 juni 2009 @ 11:53:
[...]

Serieus, encoding moet je gewoon een keer grondig nalopen en klaar ben je. Wat jij zegt is gewoon pleisteren uit luiheid.

Umh, nee hoor. Er zijn niet voor niets html characters uitgevonden. Het is niet gewoon een pleister en zéker niet uit luiheid.

Het is een feit dat php nog geen volledige unicode ondersteuning biedt. Dat daarnaast Apache doodleuk een iso-8859-1 als standaard doet. Ik heb ook nog eens problemen gehad met php dat het script zelf niet een utf-8 encoding had. En dan moet je natuurlijk ook je db tabellen goed zetten.

Als je even buiten je perfecte IDE om een nieuw php bestand aanmaakt kan het al mis gaan. Als je een webserver opzet en net de complete .htaccess vergeet over te nemen kan het al misgaan. Als ik Zend_Tool gebruik om een project op te zetten gebeurt dat automatisch met us-ascii. En ik kan zo nog wel even doorgaan

Die character entities zijn juist bedoelt om zekerheid te hebben buiten je encoding om. Ze werken namelijk altijd! Dit zie ik dan niet als een pleister hoor. En ik weet dat het niet een argument is, maar waarom gebruikt _iedereen_ html characters terwijl het slechts een pleister is en kennelijk de meest geniale ontwikkelaars dus ook lui zijn

[Creepy]

Omdat je geen html entities in een PDF of text output wil hebben lijkt me.

Apache kan prima files by default als UTF-8 serveren. Een fatsoenlijke texteditor kan ook files als UTF-8 opslaan. Op de server kan je een default charset invoeren en dan heb je geen last van de problemen die je nu noemt en hoeft je niet bij het ophalen van de content uit je database je HTML entities weer terug te gaan vertalen naar de daadwerkelijke tekens indien je output anders dan HTML wilt hebben.

[Voutloos]

Met 'De kans op een fout is daar vele malen groter' + een workaround geef je imo gewoon aan dat je Het Echt Probleem niet durf aan te pakken. Zelfs zonder PHP 6 kan je het al voor elkaar krijgen hoor.

Je moet oppassen met bijv. strlen(), maar die functie gedraagt zich met jouw fix ook al anders, omdat je html entities hebt. En daar zit een hele sloot aan problemen met je pleister: wat nou als je op dat soort karakters wil zoeken in de database? Dankzij collations is ColumnName = 'cafe' te gebruiken ondanks dat iemand het een keer met accent ingevoerd heeft. Zodra je htmlentities gebruikt, ben je daarmee de sjaak. Idem voor sorteren op dergelijke waarden. Etc. etc.

mithras schreef op maandag 29 juni 2009 @ 16:16:
Die character entities zijn juist bedoelt om zekerheid te hebben buiten je encoding om.

Als je bewust je encoding probleem laat zitten is dat toch echt 100% symptoombestrijding + kop @ zand.

En ik weet dat het niet een argument is, maar waarom gebruikt _iedereen_ html characters terwijl het slechts een pleister is en kennelijk de meest geniale ontwikkelaars dus ook lui zijn

Prima argument, want imo doet de meerderheid het ook gewoon fout uit luiheid en totale desinteresse (en in een aantal gevallen omdat het voorheen lastiger was om goed te krijgen). Zodra het op character sets en enc. aankomt wordt praktisch iedere devver in 1x superlui en gaat er gegokt worden. Bijv. 'ff met een headertje testen of het verdwijnt', of 'alles html entities en klaar is kees'.

Die laatste 2 quotes komen ook in zeker 90% van de 'vreemde tekens kloppen niet!!!11' topics @ got voor.

[.oisyn]

mithras schreef op maandag 29 juni 2009 @ 16:16:
Het is een feit dat php nog geen volledige unicode ondersteuning biedt.

Lekker boeiend, vaak is PHP en een database niet meer dan een doorgeefluik voor tekst. Zolang je geen bewerkingen op de tekst toepast is het voor een systeem totaal oninteressant in welke encoding de tekst is opgeslagen - zolang in- en uitvoer maar overeen komen.

Die character entities zijn juist bedoelt om zekerheid te hebben buiten je encoding om. Ze werken namelijk altijd! Dit zie ik dan niet als een pleister hoor.

Ik denk dat je de achterliggende gedachten van de reacties hier niet helemaal snapt. Niemand raadt het gebruik van html entities af. Het is echter geen volledige oplossing voor het probleem - leuk dat het dan voor bepaalde entities wel goed werkt, maar als je dan een keer iets wilt encoden waar geen entity voor is ben je alsnog de sjaak. Een ë is zo ingevoerd met toetsenbord, of tik jij elke keer handmatig ë? En wat als de uitvoer nou XML is ipv HTML?

En dat terwijl de oplossing zo simpel is - gewoon zorgen dat in- en uitvoer encodings overeen komen. En als Apache default iso-8859-1 aanhoudt, dan maak je toch lekker overal iso-8859-1 van?

[Confusion]

.oisyn schreef op maandag 29 juni 2009 @ 16:37:
Ik denk dat je de achterliggende gedachten van de reacties hier niet helemaal snapt. Niemand raadt het gebruik van html entities af.

Beg to differ.

Het is echter geen volledige oplossing voor het probleem - leuk dat het dan voor bepaalde entities wel goed werkt, maar als je dan een keer iets wilt encoden waar geen entity voor is ben je alsnog de sjaak. Een ë is zo ingevoerd met toetsenbord, of tik jij elke keer handmatig ë? En wat als de uitvoer nou XML is ipv HTML?

En daarom zou ik dus, met klem, het gebruik van HTML entities welzeker afraden. Als je die vorm wilt gebruiken, gebruik dan een XML character of entity reference.
Oftewel: &, <, >, ', " en de rest als &#getal;, tenzij je andere entity namen in je document definieert. Maar bij voorkeur, zoals Voutloos zegt, gewoon het goede character nemen. In iedere taal kan je unicode literals tikken.

En als Apache default iso-8859-1 aanhoudt, dan maak je toch lekker overal iso-8859-1 van?

Dan Apache ASAP naar UTF-8 omzetten? De beste manier om problemen nu en in de toekomst te vermijden is door gewoon alles in UTF-8 te doen. Daarmee kan je eigenlijk nooit mis gaan.

[ Voor 17% gewijzigd door Confusion op 29-06-2009 17:03 ]

[mithras]

Nog even op alle reacties hierboven

Ik zeg ook geenszins dat alles omzetten naar eenzelfde encoding een slecht idee is. Ik geef alleen een alternatief. Ikzelf gebruik ook door mijn hele applicatie utf-8, geen probleem. Maar wanneer je een groot systeem hebt en er ineens één karakter verkeerd gaat, is er meer mogelijk dan de eerst aangedragen oplossing. Je kan namelijk ook meer fout doen dan goed op zo'n moment. En dan ben je wel uren/dagen of misschien wel meer tijd kwijt aan het fixen van die problemen

Het was dus meer een reactie op het feit dat het getuigt van luiheid en pleisteren

[Megamind]

Maar waarom zou er opeens karakter verkeerd gaan? Als je er voor zorgt dat je data als UTF8 in de DB komt, en bij de presentatie ook UTF8 wordt gebruikt kan er niets mis gaan.

Behalve als je data gaat importeren van een niet UTF8 set.