Bekijk Volledige Versie : In plaast van vreemde tekens opeens "fffd".
Op een van de servers laat een pagina gemaakt middels een door de klant gemaakt scriptje in plaats van vreemde tekens opeens fffd zien in een blokje.
Zie afbeelding.
Voor zover mij bekend is er op de server niets gewijzigd, misschien is het door een php of apache update gekomen.
Volgens de klant (en voor zover mij geheugen rijkt) gaf de pagina in het verleden wel gewoon de vreemde tekens goed weer.
Het gaat hier om alle vreemde tekens, dus ook umlaut etc.
Iemand een idee hoe c.q. waar dit de fixen is?
Waarschijnlijk een verschil in encoding tussen hoe de gegevens in bv de database staan en hoe ze aan de browser worden geserveerd.
https://www.google.nl/search?q=utf8+8859-1+fffd&pws=0&hl=nl&num=10
Ja ik had er al iets over gevonden, ook over iso-8859-1 en utf.
Het gekke is dat er niets in het script gewijzigd is en bij mijn weten ook niet op de server behalve de normale updates.
Maar als ik je goed begrijp moet het dus gezocht worden in de database danwel het script van de klant? Dus ik kan er middels de server zelf niets aan wijzigen, zonder andere sites in gevaar te brengen?
systemdeveloper
11/11/13, 21:56
Kan zijn dat je browser default op een andere codering staat.
Switch hem eens van utf-8 naar iso of andersom.
De codering die werkt zet je dan in de header van de page.
Als het de browser zou zijn zou ik er ergens anders ook last van moeten hebben of niet? En ik heb er nergens last van.
Is alleen die ene site.
http://www.hengstenstation.com/uytert/index.php/hengsten.html
En klik daar maar eens op een paard, overal kom je wel vreemde tekens tegen. Op forums op dezelfde server heb ik er geen last van.
Ook nergens anders en ben ook niet de enige.
Het lijkt erop dat of je default charset in php.ini gewijzigd is of de settings van joomla
Ik denk dat het opgelost is als je:
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
weet te veranderen in:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-15">
Even snel googlen zegt:
DEFINE('_ISO','charset=utf-8');
you can change it to
DEFINE('_ISO','charset=iso-8859-1');
//Edit
Het lijkt erop dat joomla 1.5 normaal altijd UTF-8 is, dus ik denk dat de teksten perongeluk in de verkeerde encoding in de database gekomen zijn.
Misschien toch een php update geweest naar 5.4
http://nikic.github.io/2012/01/28/htmlspecialchars-improvements-in-PHP-5-4.html
Wij draaien nog php 5.3.25 (moet nog even upgraden naar .27) op deze server.
@SDGM: Het is een door klant zelfgemaakt scriptje wat vanuit Joomla aangeroepen wordt waar dit op draait. Maar het kan goed zijn zoals je zegt dat er iets niet goed gegaan is en het nu UTF-8 in de database staat. Want het heeft zijn eigen database.
Dus daar gaan we eens naar kijken, bedankt!
Klant is het nagegaan. De database stond op Latin Swedish en is via phpmyadmin omgezet naar UTF-8. Dat heeft helaas niet mogen helpen. Dus wilde hij iso-8859-1 proberen, maar deze optie stond niet bij de mogelijkheden van phpmyadmin.
Zou dat het probleem kunnen zijn of is er een manier om dat toch te wijzigen?
Dit is een stukje dump van die database:
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
Dat helpt niet omdat weliswaar de tabel omschakelt naar UTF8, maar de data in de tabel natuurlijk ongewijzigd blijft.
Veel databases van CMS'en vertonen dit soort probleempjes als ze jaren meegaan en de developer van het CMS de code tabel in de loop der jaren gewijzigd heeft.
Is er geen eenvoudige methode om de data ook te converteren dan?
Database terug zetten op Latin Swedish, export maken, database legen, database omzetten naar UTF-8, importeren << heb je dat al geprobeerd?
Yep, het is een rommeltje, heb het ook nog op andere wijze geprobeerd maar ik krijg steeds onderstaand resultaat (zie afbeelding).
Verder zie ik in de backup van de database nog de nodige dingen als dit:
CREATE TABLE `album` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`fotoID` text CHARACTER SET latin1 NOT NULL,
`onderschrift` text CHARACTER SET latin1 NOT NULL,
`onderschrift2` text CHARACTER SET latin1 NOT NULL,
Raar genoeg staat hier dus latin1, terwijl je in de afbeelding kunt zien dat er latin2 staat.
Nu kan ik dit ook wel allemaal in die backup file gaan wijzigen maar welke moet het dan worden?
1.) utf8
2.) utf-8
3.) utf8_general_ci
Ik heb nog ooit eens een database moeten omzetten naar utf8 maar dat was zo moeilijk niet toen. Inderdaad even exporteren, leegmaken, wijzigen naar utf 8, weer importeren en klaar, allemaal met phpmyadmin.
Heb je die server ook gecontroleerd op malware?
De laatste keer dat ik dat zag, was de malware in de Joomla database opgeslagen. Die was snel genoeg gevonden. Ik heb wel nog zes maanden zitten zoeken naar nog iets, tot ik ontdekte dat de gebruikers (redacteurs) via IE met knip en plak tekens konden ingeven die hoorden gefilterd te worden. Toe hielp export/import niet meer. Die database (CMS met >15.000 pagina's) hebben we met zoek en vervang in een ander db systeem moeten herstellen, want MySQL bleef er op fout lopen. Er zitten nog steeds fouten in de database, maar die veroorzaken geen zichtbare fouten meer.
SebastiaanStok
15/11/13, 09:07
Voor de duidelijkheid fffd is hexdecimaal voor 65533.
Wat leuk genoeg neerkomt op het � teken :balloon:
http://www.fileformat.info/info/unicode/char/0fffd/index.htm
cyrano: Die is gecontroleerd op malware inderdaad. Binnen Joomla zit het probleem niet, want dat stuk wat door Joomla aangestuurd wordt is alllemaal goed.
Het euvel zit hem in dit kleine database wat apart gebruikt wordt door dit custom scriptje.
Ik ben zelf eens in de database gaan snuffelen en daar zie je als tekst gewoon bijv. "éérste" terwijl online dus "fffdrste" zichtbaar is.
Bij een van de pogingen toen ik een deel van dat databaseje naar latin1 had omgevormd kwam er "fffd??rste" te staan, dus bij alle rare tekens kwamen er achter de fffd code twee vraagtekens.
Als ze klant ze met een alt code wijzigt, dan schijnt het wel goed online te komen, dat is echter een monikkenwerk. Maarja op een gegeven moment houdt het op met de support bij die zelfgemaakte scriptjes. Alles op de server draait verder prima, inclusief rare tekens, behalve die ene database van dat scriptje.
Gebruikt de klant toevallig een webfont, want bij sommige krijg je dat ook als ze het karakter niet herkennen of bvb bij font-icons krijg je dat ook als het niet gehost is onder dezelfde virtual host (zelf subdomain werkt niet).
Ik heb geen flauw idee. Maar zal het hem eens vragen. Maar zo te zien is het volgens mij gewoon Arial.
cyranoIk ben zelf eens in de database gaan snuffelen en daar zie je als tekst gewoon bijv. "éérste" terwijl online dus "fffdrste" zichtbaar is.
Bij een van de pogingen toen ik een deel van dat databaseje naar latin1 had omgevormd kwam er "fffd??rste" te staan, dus bij alle rare tekens kwamen er achter de fffd code twee vraagtekens.
Zou het kunnen dat door een MySQL update de tabellen default als MyISAM gezet zijn, terwijl ze horen innoDB te zijn? Ik meen me te herinneren dat het tweede, "fffd??rste" daarmee te maken had.
Als ze klant ze met een alt code wijzigt, dan schijnt het wel goed online te komen, dat is echter een monikkenwerk. Maarja op een gegeven moment houdt het op met de support bij die zelfgemaakte scriptjes. Alles op de server draait verder prima, inclusief rare tekens, behalve die ene database van dat scriptje.
Ik heb uiteindelijk een input en output lijst zitten maken en heb het met een scriptje in een andere db tool opgelost om dat monnikenwerk te vermijden.
Zou het kunnen dat door een MySQL update de tabellen default als MyISAM gezet zijn, terwijl ze horen innoDB te zijn?
Dat zou kunnen want ik was me ook al over dat MyISAM aan het verbazen. Op de DA servers hebben we zoiets in de my.cnf staan:
default-storage-engine=MyISAM
innodb_file_format=Barracuda
innodb_file_per_table=1
Dat staat echter niet in de my.cnf van deze Cpanel server.