Speciale karakters weg uit bestand vanaf HTTP?

[Verwijderd]

Graag uw aandacht voor het volgende. Ik maak via PHP een geocoding request via de Google Maps HTTP interface, voorbeeld:

code:

http://maps.google.com/maps/geo?output=xml&q=tokyo,%20jp&key=<mijn_key_maar_even_weggehaald>

Dit werkt allemaal prima, behalve als we gaan zoeken naar wat meer exotische locaties, zoals in het voorbeeld hierboven Tokyo in Japan. Je krijgt dan in de XML de plaatsnaam terug, in lokale schrijfwijze of iets dergelijks:



Het probleem: in PHP worden de speciale karakters vervangen door spaties, dus ik zie alleen "T ky ". Karakters zoals ë en ö enzo werken overigens wel.

Na verschillende dingen geprobeerd te hebben in PHP besloot ik om het eens vanaf de Linux command line (CentOS webserver) te proberen. Zowel curl als wget vervingen ook de speciale karakters in spaties, waardoor ik tot de conclusie kwam dat het iets dieps in het OS moet zijn, vandaar dat ik deze topic niet in het Programming forum heb gezet.

Weet iemand hoe dit op te lossen is? Het is vrij frustrerend.

[ Voor 6% gewijzigd door Verwijderd op 20-07-2007 14:37 . Reden: Speciale karakters werden HTML entities :-/ , heb er maar screenshotje bijgezet ]

[Boudewijn]

wat voor codering gebruik je box standaard?
utf8?

[Verwijderd]

Ik ben bang dat ik qua Linux config een noob ben.. Deze webserver is door een bedrijf ingericht, ik vermoed dat ze gewoon de codering op de default waarde hebben gehouden.. waar kan ik dat zien?

[Sir Isaac]

echo $LANG

[Snake]

Verwijderd schreef op vrijdag 20 juli 2007 @ 15:05:
Ik ben bang dat ik qua Linux config een noob ben.. Deze webserver is door een bedrijf ingericht, ik vermoed dat ze gewoon de codering op de default waarde hebben gehouden.. waar kan ik dat zien?

Niets te server, header met content type utf8, evenals in je html

[Verwijderd]

Snake> de header aan Google zijn kant staat correct neem ik aan, als ik het direct output met curl op de linux command line dan komt er geen html bij kijken dus kan dan ook geen header geven...

[Verwijderd]

@Sir Isaac: Sorry, zie je bericht nu pas...
echo $LANG geeft: en_US.UTF-8

Lijkt dus goed te staan?

[Confusion]

Waarschijnlijk behandel je ergens in je verwerkingsproces de tekst niet als UTF-8. Daar gaat het mis. Zolang je de tekst overal als UTF-8 behandelt, zou de tekst normaal moeten worden weergegeven... mits je browser op UTF-8 ingesteld staat en je de noodzakelijk fonts geinstalleerd hebt.

[Verwijderd]

Uhm, maar in de browser wordt het juist prima weergegeven, zie screenshot in eerste bericht. Zodra ik er iets mee wil doen op de webserver gaat het mis. Het lijkt mij dat curl toch goed om zou moeten gaan met die karakters. NB ik doe in de test met curl zelf niks met de tekst, ik vraag de XML direct op bij Google.

[Verwijderd]

De vraag is natuurlijk ook of jouw console die tekens überhaupt wel kan weergeven.

[Verwijderd]

Dat is waar.. maar zelfs al zeg ik op de console:
wget <url>

Als het opgeslagen bestand dan via de browser open, dan ontbreken de tekens ook... ra ra... ?

[ Voor 19% gewijzigd door Verwijderd op 21-07-2007 11:30 ]

[Confusion]

Verwijderd schreef op zaterdag 21 juli 2007 @ 00:57:
Uhm, maar in de browser wordt het juist prima weergegeven, [..]

Verwijderd schreef op zaterdag 21 juli 2007 @ 11:22:
Dat is waar.. maar zelfs al zeg ik op de console:
wget <url>

Als het opgeslagen bestand dan via de browser open, dan ontbreken de tekens ook... ra ra... ?

Dit is tegenstrijdig: wordt het nou wel of niet goed getoond in de browser?

[Harm]

Als hij de in de TS geplaatst url (inclusief zijn key) opvraagt in zijn browser, ziet hij de vreemde tekens.

Als hij via wget dezelfde url ophaalt en vervolgens in zijn browser opent, ziet hij de vreemde tekens niet.

[Icelus]

Worden de velden wel door PHP goed uitgelezen uit de XML?
De ‘ō’ in Tōkyō wordt in UTF-8 als 2 bytes gecodeerd. De strlen functie zou dan de waarde 7 terug moeten geven en mb_strlen('Tōkyō','UTF-8') de waarde 5.

Edit: de ō kan op twee manieren worden gecodeerd; als enkel karakter of als een ‘o’ gevolgd door een macron ‘¯’. In het eerste geval wordt het karakter als 2 bytes gecodeerd, in het 2e geval als 3 bytes.

[ Voor 43% gewijzigd door Icelus op 21-07-2007 17:56 ]

[Confusion]

Harm schreef op zaterdag 21 juli 2007 @ 12:36:
Als hij de in de TS geplaatst url (inclusief zijn key) opvraagt in zijn browser, ziet hij de vreemde tekens.

Als hij via wget dezelfde url ophaalt en vervolgens in zijn browser opent, ziet hij de vreemde tekens niet.

Als zijn locale settings en_US.UTF-8 zijn, dan zou dat niet moeten kunnen. Er zit vrijwel geen enkel verschil tussen 'een bestand ophalen en direct weergeven in de browser' en 'een bestand ophalen, opslaan op schijf in een en_US.UTF-8 omgeving en dan weergeven in de browser'. Ik vermoed dat er wat details worden overgeslagen; anders betekent het dat hij een bestand op schijf opslaat en het plotseling van character encoding verandert.

@Bananeman2
Heb je al met een hex-editor gecontroleerd of de vreemde tekens in het opgeslagen bestaand aanwezig zijn?

[Verwijderd]

@Harm: dat klopt inderdaad

@Icelus: Nee, in PHP gebeurt precies hetzelfde als op de console.

@Confusion: ik heb het bestand verkregen met wget vergeleken met het bestand opgeslagen via Internet Explorer, en in het 1e geval zijn de karakters een spatie, als een byte met hex code 20, en in het 2e geval beslaat het karakter twee bytes, met codes C5 en 8D.

NB: vergeef me als ik de terminologie niet juist heb, heb weinig kaas gegeten van hex dingen.

[CyBeR]

Wellicht doet google dit al als je geen UTF-8 Accept-Encoding header meestuurt? Wget zal vreemde tekens namelijk zeker niet vervangen door spaties.

Ik heb geen google maps key dus ik kan 't niet voor je proberen. Maar kijk even wat curl doet als je zegt curl -H "Accept-Encoding: UTF-8"

[ Voor 62% gewijzigd door CyBeR op 21-07-2007 21:22 ]

[Verwijderd]

@CyBeR: ik heb even wat gespit n.a.v. je idee, en ik denk dat je de "Accept-Charset" header bedoelt, "Accept-Encoding" moet volgens mij bv. "gzip", "deflate" etc. bevatten. Ik heb het geprobeerd in curl maar het geeft helaas hetzelfde resultaat.

Geinteresseerden kunnen hier trouwens een gratis Google map API key krijgen:
http://www.google.com/apis/maps/signup.html

[ Voor 20% gewijzigd door Verwijderd op 22-07-2007 00:03 ]

[Icelus]

C5 en 8D is inderdaad UTF-8 voor ō — U+014D.

Eerst gevonden Japanse KML-link geprobeerd en dit werkt. Kun je die in jouw wget proberen?
http://noblesse-oblige.jp/matsue/horikawa.kml

[ Voor 32% gewijzigd door Icelus op 22-07-2007 01:19 ]

[CyBeR]

Verwijderd schreef op zaterdag 21 juli 2007 @ 23:55:
@CyBeR: ik heb even wat gespit n.a.v. je idee, en ik denk dat je de "Accept-Charset" header bedoelt, "Accept-Encoding" moet volgens mij bv. "gzip", "deflate" etc. bevatten. Ik heb het geprobeerd in curl maar het geeft helaas hetzelfde resultaat.

Eh, ja. Ik heb een key gevonden iig (even die van plazes gestolen ) en ik zie al hoe 't komt: Google doet dit idd server-side. Stuur "Mozilla/5.0" als User-Agent: en je krijgt de goede data.

[Verwijderd]

Jaa, geniaal, het werkt!!!

Heb nu dit in PHP:

code:

$ch = curl_init($url); 
curl_setopt ($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)"); 
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); 
$r = curl_exec ($ch);
curl_close ($ch);

Thanks iedereen!