responseText.length klopt niet?

Status
Niet open voor verdere reacties.

ErikBooy007

Terugkerende gebruiker
Lid geworden
24 mei 2007
Berichten
3.814
Goeiemiddag, ik zit al een tijdje met de handen in het haar vanwege een probleempje met een AJAX request.

Ik vraag een pagina op, en check of de content gelijk is aan "[|]"... (dat heb ik voor nu even als delimiter gebruikt, om te splitten, uiteindelijk zal ik er een JSON object van maken).

En het script zegt steeds van niet terwijl dat volgens mij wel het geval is ;)

Script:

[JS]
<?php echo '<?xml version="1.0" encoding="UTF-8"?>'; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
</head>
<body>
<script type="text/javascript">

function createXML() {

var objXml = false;
try {
objXml = new XMLHttpRequest();
} catch (e) {
try {
objXml = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
objXml = new ActiveXObject("Microsoft.XMLHTTP");
}
}
return objXml;
}

window.onload = function(){

var xmlHttp = createXML();
xmlHttp.open("GET", "getInfo.php?type=w&ICAO=EHTE", true);
xmlHttp.onreadystatechange = function() {

if ( xmlHttp.readyState == 4 && xmlHttp.status == 200 ) {

for ( var i in xmlHttp.responseText ) {
alert(xmlHttp.responseText);
}

}

}
xmlHttp.send(null);

}

</script>
</body>
</html>
[/JS]

Deze pagina staat op www.erikbooy.nl/SAA/test.php
En het bestand dat opgevraagd wordt, kun je vinden op www.erikbooy.nl/SAA/getInfo.php?type=w&ICAO=EHTE .

Zoals je ziet geeft het voor elk teken een alert (4x nu) en de charCode van het eerste teken is 65279 ...

Kan iemand me uitleggen waar dat door komt?
 
Hoi,


Nou, volgens mij is het volgende aan de hand: je gebruikt AJAX (ha!). Dit is nogsteeds Async. Javascript en XML. Een korte google zei mij dat char 65279 iets van xml was oid.

Je kan eens even proberen om de data op te vragen via een ander MIME type, want standaard doet je script dit met application/xml (of text/xml, ik weet t niet zeker).

Probeer dus eens zoiets:
[JS]var handle = (XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject('Microsoft.XMLHTTP');

if(handle.overrideMimeType)
{
// IE support dit geloof ik niet, tenminste, de activeX niet.
handle.overrideMimeType('text/plain'); // of: application/json als je dat gebruikt.
}

// hier je request.[/JS]
 
Bedankt voor je moeite, maar het lijkt helaas niet te werken...

Heb wel een temp-fix, door te kijken of de charcode van het eerste character 65279 is, en dan gewoon het eerste teken eraf te knippen, maar dat is natuurlijk niet ideaal.
 
Hmmm, mischien moet je het probleem bij de wortel aanpakken: je getInfo.php. Wat doet deze precies, etc? Of echoed deze alleen [|] uit?



:thumb:
 
Deze pagina zoekt weersinformatie op internet voor een vliegveld naar keuze. Stopt in een array de actuele luchtdruk en wind en echoot die...

De enige output die de pagina geeft is echt [|] ... :P
 
Whuh?

Ik zie wat anders... :P

Damn, daar snap ik niks van, maar die tekens komen me wel bekend voor. Toen ik namelijk laatst met jouw probleempje (output buffering) bezig was, kwamen die ook regelmatig tevoorschijn... terwijl ik zou verwachten dat er niets te zien zou zijn...

Weet jij wat die tekens inhouden?
 
Geen idee, maar mischien kan je in je php script eens eventjes de hex. waardes neerzetten van wat je echoe'd.

Als je de php pagina eventjes 20x refreshed (gewoon, direct in je browser), kom je af en toe die rare tekentjes tegen. Soms is de output ook helemaal leeg.

Overgens denk ik dat die tekens dus je mysterieuse char 65279 is, maar dat kan ook aan mij liggen.
 
Met een packet sniffer is het ook te zien. Volgens mijn packet sniffer levert het op:
\357\273\277\357\273\277[|]
(in de browser is overigens alleen "[|]" te zien (zonder aanhalingstekens))
 
Laatst bewerkt:
Ha! Mijn Google-beschouwing van char 65279 - was ook wel nieuwsgierig - gaf als eerste hit de verklaring: "The character is a Unicode Byte Order mark (BOM)."
Juist, dat is niet zo onwaarschijnlijk! :P
Roept de vraag op: hoe heb je het bestandje met alleen de [|] er in opgeslagen? Met Kladblok (als ANSI, als UNICODE, als UTF-8)? En zeker een Windows-machine?
  • Ik heb de www.erikbooy.nl/SAA/getInfo.php?type=w&ICAO=EHTE eens gedownload, en die blijkt een UTF-8 te zijn; waarschijnlijk met BOM. Zou hetzelfde als deze getInfo-ori.php moeten zijn.
  • Even omgezet naar "UTF-8 zonder BOM" levert deze getInfo-new.php.
  • Op het oog mooi dezelfde.
  • Maar het origineel is 8 bytes, en de BOM-loze is 3 bytes. Die 3 zouden wel eens [|] kunnen zijn.
  • Hé, 65279[|] zijn 8 tekens, zouden wel eens 8 bytes kunnen zijn. Mijn kwartje viel als een bom! :D

Kortom: wat gebeurt er als je de nieuwe versie gebruikt?
  • BOM? > BOM, een verraderlijke soort onzichtbaarheden.
  • BOM-beschouwingen kan je prima doen met Notepad++, Menu: Codering (zowel voor diagnose als voor omzetten naar ander type, bv. BOM-loze UTF-8).
Met vriendelijke groet,
CSShunter

[edit]Kwam in mijn favorietenbak nog een online BOM-tester tooltje tegen:
Het wettig en overtuigend bewijs! :)[/edit]

PS: Ik stuiterde hier ook tegenop toen een html-fragment via een php-include plotseling begon met een witte regel, terwijl er helemaal geen <br> stond en de css er ook geen aanleiding toe gaf. Exact dezelfde html rechtstreeks erin gaf geen enkel probleem! Urenlang vergeefs gezocht naar subtiele tikfoutjes en knip- & plak-foutjes, die ook de HTML-validator en de CSS-validator niet konden vinden. Begon uiteindelijk serieus aan mijn verstandelijke vermogens te twijfelen. - Bleek de include.php een BOM te hebben. Pfff!
 
Laatst bewerkt:
Zo, jullie hebben niet stilgezeten! :D

@csshunter, dat is nog eens duidelijk! Ik had dus gewoon even in m'n editor (ik gebruik overigens UltraEdit) moeten selecteren UTF-8 - NO BOM en dan was het goed geweest :P

Kun je me toevallig ook nog vertellen wat het nut/effect is van een BOM?

In ieder geval heel hartelijk bedankt allemaal! :D:D
 
Kun je me toevallig ook nog vertellen wat het nut/effect is van een BOM?
Niet uit m'n hoofd, dat moet ik altijd weer even opzoeken. :)

In computing, endianness is the ordering of individually addressable sub-units (words, bytes, or even bits) within a longer data word stored in external memory.
The most typical cases are the ordering of bytes within a 16-, 32-, or 64-bit word, where endianness is often simply referred to as byte order.
The usual contrast is between most versus least significant byte first, called big-endian and little-endian respectively.
  • Dit komt uit het Wiki-topic "Endianness".
  • "Endianness" is "Eindjesheid", er zit een leuke anekdote achter uit Gullivers Reizen over het eindje van een ei: of je een ei nu aan de punt (little end) of aan de platte kant (big end) moet opentikken. Moraal: maakt niet uit, maar je moet één van de twee opgeven (met het BOM).
  • Zie ook eerdergenoemde link naar de Wiki-BOM.
  • Het gaat hier dus geloof ik om interne geheugenplaatsen, en Windows schijnt hier (weer eens) omgekeerd mee om te gaan dan kasten met Linux of een ander OS. Vooral bij koppelen van netwerken kan het mis gaan, als de BOM niet dezelfde is.
  • Voor UTF-8 maakt een BOM niets uit, leer ik, wel voor UTF-16 e.a. UNICODE-toestanden.
  • En Windows schijnt er een handje van te hebben om er bij UTF-8 altijd een BOM aan vast te plakken. Niet gevraagd, en toch gekregen!
  • Leesvoer genoeg, verder bij UNICODE. - Ook W3C schrijft er ingewikkelde verhalen over, bv. te beginnen hier (met links naar links naar links ...).
Afijn het is allemaal redelijk basic, en gaat de kant op van de machinetaal - niet m'n sterkste punt (oftewel het gaat me flink boven de pet, als ik probeer te begrijpen wat er staat). ;)
Dus ik doe het maar met BOM-verklikkers. :p
Neem je hier genoegen mee?

Groetjes,
CSShunter

PS: Behalve Notepad++ is UltraEdit is dus ook goed te gebruiken voor de BOM-verwijdering. Mooi; er zullen er nog wel meer zijn. - Waar mogelijk, dus als default voor UTF-8 opgeven: BOMloos!
 
Laatst bewerkt:
Fantastisch CSShunter, ik zou niet weten wat ik zonder jou moest ;)

Nogmaals harstikke bedankt, het is met (grotendeels) duidelijk nu!! :D
 
[*]Het gaat hier dus geloof ik om interne geheugenplaatsen, en Windows schijnt hier (weer eens) omgekeerd mee om te gaan dan kasten met Linux of een ander OS. Vooral bij koppelen van netwerken kan het mis gaan, als de BOM niet dezelfde is.

Het heeft niets te maken met het besturingssysteem, maar met de architectuur. Intel (en AMD) gebruikt little-endian wat wil zeggen dat bytes van rechts naar links worden geschreven en gelezen. Als je nu een bestand op een little-endian architectuur wilt overzetten naar een computer met een big-endian architectuur (bijv. SPARC) (of andersom) moet je aangeven dat je little-endian gebruikt anders worden de bytes in omgekeerde volgorde geschreven.
 
  • Aha, dan had ik dit stukje verkeerd geïnterpreteerd. Inderdaad, bv. MacOS staat in beide rijtjes, en het Big of Little Endian hang niet van het OS maar van de processor af. Wat ik dan niet snap, is dat PowerPC in beide rijtjes zit: zijn zeker twee varianten van (?).
  • Ah: "Ondersteuning voor gebruik zowel in de Big-Endian als de Little-Endian-modus; de PowerPC kan tijdens het draaien (runt-time) omschakelen van de ene naar de andere modus." zegt de Wiki over de PowerPC.
Weer wat geleerd! :)

CSShunter
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan