De functies ord en chr

Status
Niet open voor verdere reacties.

Vanderploeg

Gebruiker
Lid geworden
3 feb 2007
Berichten
201
Hallo vrienden,

In php bestaan de functies ord en chr.

Ord geeft de decimale ascii-waarde van een letter aan. Bijvoorbeeld: ord('a') = 97. Want 97 is de decimale ascii-waarde van de letter a.
En chr doet het tegenovergestelde en geeft vanuit de decimale ascii-waarde de letter terug. Bijvoorbeeld: chr(97) = 'a'.

Dit werkt prima en op basis hiervan heb ik een zoekmachine gebouwd voor mijn website. De website heeft tientallen pagina's. Wellicht worden het er meer dan 100. Maar met deze zoekmachine vindt men snel ieder woord, dat op de website voorkomt, terug.
Ik zou het ook een zoekfunctie kunnen noemen. Maar een zoekfunctie zoekt meestal slechts binnen 1 pagina. (Dat kan wel een zeer lange pagina zijn). Daarom heb ik mijn 'uitvinding' een zoekmachine genoemd, temeer daar hij zich net zo gedraagt als de zoekmachine van Google. Alleen wordt er bij mij slechts binnen 1 website gezocht.

Gisteren stuitte ik echter op een probleem. Woorden met ë (een e met 2 puntjes erop), bijvoorbeeld tweeërlei, worden binnen mijn systeem niet goed verwerkt. Op de plaats van dit teken komen twee vraagtekens te staan. Ik ging op onderzoek uit en toen ontdekte ik, dat de PHP-functies ord en chr helemaal niet goed werkten bij ascii-waarden boven de 127. We zitten dan in het gebied van de extended character set.

Volgens de tabel in mijn computerboek zou ord('ë') 137 moeten zijn. Maar PHP maakt er 235 van. Dat zou niet erg zijn, als het ook weer goed werd terugvertaald. Maar dat gebeurt helaas niet. Als ik opgeef chr(235) dan geeft PHP een vraagteken terug.

Mijn vraag aan jullie is: Is hier een oplossing voor? Bestaan er binnen PHP bijvoorbeeld nog andere functies, die de tekens wel goed verwerken?

Ik werk met een laptop met Windows 7 en met Mozilla Firefox. Maar ik heb niet de indruk, dat dat iets uitmaakt. De PHP-versie, die ik gebruik, is versie 5.5.19. Dat is al lang de nieuwste versie niet meer. Maar de functies ord en chr zijn al heel oud. Ik geef mezelf weinig hoop, dat het met een nieuwere PHP-versie wel goed gaat. Het schijnt ook iets te maken te hebben met al of niet UTF-8 en dus met de charset. Maar het is mij nog niet gelukt om dit dusdanig in mijn systeem te verwerken, dat het probleem is opgelost.
 
Een zoekmachine is het beslist niet. Een zoekmachine gebruikt een bot die van website naar website gaat en de data geindexeerd in een grote database opslaat. Een zoekmachine heeft veel zoekoperatoren om geavanceerd te zoeken. Op jouw website heb je een zoekfunctie (komt van zoekfunctionaliteit).

Alleen 7-bit ASCII tekens worden in UTF-8 ondersteund, daarvoor worden wel 8 bits gebruikt. Het 8e bit geeft aan of het een multibyte teken is.
De extended tekenset is dus een multi-byte in UTF-8. Je zal zelf een function moeten maken die de juiste waarde teruggeeft.

Je kan beter werken met een vertaaltabel (in een function).
a => a A â ä à å Ä Å á
enzovoort

Bijzondere letters worden omgezet naar kleine letters. Dit is veel handiger bij het vergelijken van een zoekopdracht. De andere symbolen in de extended tekenset negeer je gewoon.

Kijk eens bij mb_convert_encoding($letter, 'UCS-2LE', 'UTF-8');
of google even op: php ord extended ascii
 
Laatst bewerkt:
Dank voor je reactie. Ik denk dat de grens tussen zoekfunctie en zoekmachine niet altijd zo duidelijk aan te geven is. Het is ook niet zo belangrijk. Mijn systeem bestaat uit 3 onderdelen: Een zoekvak, een zoeklijst en een zoeksysteem. Als ik in de zoeklijst de namen zet van pagina's van verschillende websites, dan behoef ik aan het eigenlijke systeem niets te veranderen. Het gaat dan uit zichzelf die verschillende websites langs en verzamelt de gegevens. Ik heb het maar even een zoekmachine genoemd, opdat de mensen die de website bezoeken, direct weten dat het net als bij een echte zoekmachine werkt. Het systeem geeft dus als resultaat een lijst van de pagina's waarop het trefwoord of de trefwoorden gevonden zijn. Maar het geeft ook precies aan op welke regel, en wat de voorafgaande en de erop volgende woorden zijn. Het trefwoord/de trefwoorden ertussen is/zijn dan vetgedrukt, precies eender als bij Google.

Verder is de naam niet belangrijk. Als het beestje maar een naampje heeft.

Ik zal jouw tips verder onderzoeken. Ik heb al een halve nacht op Google gezocht. Maar ik zal nog verder zoeken.
 
In een simpele vorm
Code:
function zoeken($tekst, $zoek) {
    $t = iconv("ISO-8859-1", "UTF-8", $tekst);
    $z = iconv("ISO-8859-1", "UTF-8", $zoek);
    $p = stripos($t, $z);
    if ($p !== false) return $p;
    return false;
}

$result = zoeken("Maximaal één item met € 12 korting", "één");
if ($result !== false) echo "Gevonden op positie " . $result;
else echo "Niet gevonden";
Werkt helaas niet met € teken omdat dit teken boven de #FF ligt

Dit kan een zoekmachine: fruit (sport | fitness) -groente
Ofwel zoek naar: fruit EN (sport OF fitness) EN NIET groente.

Ook hoort een zoekmachine relevantie aan te geven door resultaten te sorteren of een percentage aan te geven.
Als je een Opel eruit laaat zien als een Ferrari dan is het echt geen Ferrari :D
 
Laatst bewerkt:
Voor voorlopig heb ik een oplossing gevonden. Ik vind het niet zo'n heel fraaie oplossing, maar het werkt in ieder geval goed.

Het teken ë heeft in mijn zoekprogramma 2 ord-waarden achter elkaar, nl. 195 en 171. Hoe dat kan weet ik niet, maar ik kan daar in ieder geval mee werken. Wanneer nu het teken ë voorkomt in een tekenreeks, dan vervang ik chr(195) door htmlspecialchars('ë'). En vervolgens sla ik chr(171) over.

Dit werkt perfect, alleen vind ik het een beetje omslachtig. Want er zijn natuurlijk meer van zulke tekens, zoals é, ï, enz. Overigens vind ik het niet zo erg, als de code van het gehele programma wat langer wordt. Als het maar niet ten koste gaat van de snelheid. Maar dat zal wel meevallen, denk ik.

Uit ervaring weet ik, dat de browsers behoorlijk snel werken, tenzij er een grote hoeveelheid tekst moet worden afgedrukt. Maar dat is hier niet het geval. Net als bij Google toont mijn zoekprogramma slechts 10 vindplaatsen per pagina.

Maar als iemand een fraaiere oplossing vindt, dan houd ik me aanbevolen. Met de tips die ik tot nu toe kreeg kon ik niet zo veel beginnen helaas.
 
Ik schreef: "Wanneer nu het teken ë voorkomt in een tekenreeks, dan vervang ik chr(195) door htmlspecialchars('ë'). En vervolgens sla ik chr(171) over."

Maar als ik het helemaal goed wil doen, dan moet ik het net andersom doen! Ik moet dan chr(195) overslaan en chr(171) vervangen! Want chr(195) komt ook bij andere tekens voor, bijvoorbeeld het teken é. Pas de tweede ord-waarde is specifiek kenmerkend voor het teken waar het om gaat!
 
De hoeveelheid extra code, die ik voor dit alles nodig heb, valt ontzettend mee. Ik kan alles zo opschrijven met de functies if, elseif en else, dat ik voor elk bijzonder teken slechts 1 extra regel nodig heb. Dus ik ben hoe langer hoe meer tevreden! Maar ik laat dit alles nog even staan, zodat anderen nog kunnen reageren, als ze dat willen.
 
RE: Hoe dat kan weet ik niet ...
Zie #4. Alleen 7-bit ASCII (dec. 0-127) wordt in 1 byte in UTF-8 ondersteund.
Wil je meer weten over UTF enoding op website pagina's? Lees dan dit

RE: Maar als iemand een fraaiere oplossing vindt, dan houd ik me aanbevolen
Zie #4. Als je deze functie gebruikt worden ascii 0-255 goed verwerkt. Alleen de € (Euro teken) niet omdat dit een multibyte teken is.
 
Hallo Bron,

Leuk dat je nog even reageert. De websitepagina, die je aan mij doorgeeft, nl. https://naveenr.net/unicode-character-set-and-utf-8-utf-16-utf-32-encoding/ ga ik nog bestuderen. Want dit interesseert mij!

Wat betreft jouw opmerkingen bij #4: De functie iconv werkte bij mij niet goed. Ik kreeg toen weer een ander vreemd teken op mijn beeldscherm. Maar ik sluit niet uit dat ik de functie verkeerd heb toegepast. Het teken € behoeft bij mij niet verwerkt te worden. Want de website waarvoor ik mijn zoeksysteem gebruik, is een wetenschappelijke website en geen webwinkel.

Inderdaad wordt mijn 'Opel' nooit een 'Ferrari'. Maar dat hoeft ook niet. Waarschijnlijk kan ik mijn zoekprogramma best wel zo maken, dat het ook nog kan werken met 'AND', 'OR', 'AND NOT'. Maar dat heeft mijns inziens te weinig zin. Het gaat er maar om, dat de bezoekers van de website even snel trefwoorden kunnen vinden binnen de tientallen pagina's van de website.

Maar ook als ik deze operatoren in mijn systeem integreer zal het systeem gebrekkig blijven. Want als ik het duizenden websites af laat zoeken, zal het systeem heel langzaam worden. Maar zover komt het niet, want het systeem is alleen bedoeld voor de pagina's van mijn website. En dan werkt het geweldig goed.
 
Het is in ieder geval wel een leuk project. Leuk om over na te denken en te maken.

Bij iconv is het belangrijk dat zowel de tekst van de pagina als het zoekwoord door iconv worden gehaald voordat je gaat vergelijken.
Dit bereik je door de paginatekst in een variabele te zetten, dan de html tags te strippen en dan samen met het zoekwoord aan de functie te geven.
 
Natuurlijk heb ik de te doorzoeken tekst in een variabele gezet. Maar verder ga ik niet meer veel sleutelen aan het systeem. Want dat is de moeite niet waard, aangezien ik al een goed werkende oplossing gevonden heb. Net als bij Google worden de zoekresultaten weergegeven als: Stukje voorafgaande tekst, dan het trefwoord of de trefwoorden in een andere kleur, en dan een stukje erop volgende tekst.

Voor het middelste stuk (dus het trefwoord) had ik al staan (ik pluk nu een stukje code uit een veel groter geheel):

while ($teller2 < $lengte2) {
$waarde2 = ord($stuk2[$teller2]);
....
....

Hier heb ik nu aan toegevoegd:

if ($waarde2 == 195) $invulwaarde2 = ""; //Hier wordt de ord-waarde dus overgeslagen.
elseif ($waarde2 == 160) $invulwaarde2 = htmlspecialchars('à');
elseif ($waarde2 == 162) $invulwaarde2 = htmlspecialchars('â');
elseif ($waarde2 == 164) $invulwaarde2 = htmlspecialchars('ä');
elseif ($waarde2 == 168) $invulwaarde2 = htmlspecialchars('è');
elseif ($waarde2 == 169) $invulwaarde2 = htmlspecialchars('é');
elseif ($waarde2 == 170) $invulwaarde2 = htmlspecialchars('ê');
elseif ($waarde2 == 171) $invulwaarde2 = htmlspecialchars('ë');
elseif ($waarde2 == 175) $invulwaarde2 = htmlspecialchars('ï');
elseif ($waarde2 == 179) $invulwaarde2 = htmlspecialchars('ó');
elseif ($waarde2 == 182) $invulwaarde2 = htmlspecialchars('ö');
elseif ($waarde2 == 188) $invulwaarde2 = htmlspecialchars('ü');
else $invulwaarde2 = chr($waarde2);

Tenslotte wordt het trefwoord teken voor teken op het scherm afgedrukt met:

echo "<font face="Verdana" size="4" color="#D20000"><b>" . $invulwaarde2 . chr(0) . "</b></font>";
$teller2++;
}

Daarna komt dus het volgende deel, met de tekens van de woorden, die op het trefwoord volgen. Dit alles werkt snel en perfect, dus ik houd het maar zo. Natuurlijk bestaan er veel meer bijzondere tekens dan de 11 tekens, die je hierboven ziet. Maar die komen op mijn website nog niet voor. Zonodig kan ik die altijd nog aan het systeem toevoegen.
 
Ondertussen merk ik, dat het systeem van Helpmij.nl de backslashes eruit gehaald heeft. Dat is natuurlijk niet erg. Wat ik geschreven heb is maar een indicatie van hoe zoiets opgelost kan worden.
 
Laatst bewerkt:
Hoewel deze vraag al aangemerkt is als opgelost, heb ik toch nog verder gestudeerd op deze dingen. Naar aanleiding daarvan wil ik een leuk zelfgemaakt PHP-programma'tje doorgeven:

1. <!DOCTYPE html>
2. <html>
3. <head>
4. <title>Ord en chr</title>
5. <meta http-equiv="content-type" content="text/html; charset=UTF-8">
6. </head>
7. <body>
8. <?php
9. // Let op! De encoding van dit bestand moet zijn: UTF-8 + BOM! (Als u het programma EditPlus 3 gebruikt: Klik hiervoor zonodig op 'Document' in de balk hierboven, en dan op 'File Encoding' en 'Convert Encoding').
10. $teken = "é";
11. echo "De ord-waarde van het teken é is: " . ord($teken) . "<br>";
12. echo "De ord-waarde van het eerste teken van é is: " . ord($teken[0]) . "<br>";
13. echo "De ord-waarde van het tweede teken van é is: " . ord($teken[1]) . "<br>";
14. echo "Het teken van de chr-waarde 195 is: " . chr(195) . "<br>";
15. echo "Het teken van de chr-waarde 169 is: " . chr(169) . "<br>";
16. echo "Het teken van de chr-waarden 195 en 169 samen is: " . chr(195) . chr(169);
17. // Zoals u ziet komt nu het teken é weer terug! Blijkbaar is het teken é opgebouwd uit 2 tekens met elk zijn eigen ord-waarde!
18. ?>
19. </body>
20. </html>

Toelichting:
De nummers aan het begin van iedere regel behoren niet tot het programma. Deze nummers heb ik even toegevoegd voor de duidelijkheid.

Als men dit programma nu draait geven de regels 14 en 15 een ruitje weer. Dat wil zeggen: Er bestaat geen bijbehorend teken.
Maar de regel 16 geeft de letter é weer terug!
 
Laatst bewerkt:
Ha, nog bezig met de ord().
Een reden om bom niet te gebruiken is dat php include() een blanco pagina's kan opleveren.
 
Laatst bewerkt:
Ach ja, zo heeft alles zijn voor- en nadelen. Eerst gebruikte ik UTF8 zonder BOM (Byte Order Mark).
Maar toen werd de instelling niet vastgehouden. Telkens sprong het bestand weer op ANSI. Daarna probeerde ik UTF8-BOM, en toen werd de instelling wel goed opgeslagen en vastgehouden. Vandaar dat ik UTF-8 BOM bleef gebruiken bij mijn bestanden.

php include() gebruik ik van tijd tot tijd ook wel. Zelfs bij mijn zoeksysteem. Maar dat gebeurt al in een vroeg stadium. Via include wordt de lijst met website-pagina's, die doorzocht moeten worden, in het hoofdbestand van mijn zoeksysteem ingevoerd. Maar nooit krijg ik daardoor een blanco-pagina. Dus ik houd het lekker zo.

Ja, ik wilde nog een extra studie doen naar ord en chr, omdat ik wilde weten of ik het systeem ook goed kon laten draaien, zonder elk bijzonder teken te noemen (zoals é, ë, ü, enz.). Dit is me nu ook gelukt.

Hoe meer inzicht ik in deze materie heb, hoe beter ik mezelf kan helpen, als ik later weer eens problemen heb met dergelijke dingen. Heel lastig kunnen nieuwe versies van PHP zijn, of van phpMyAdmin, enz. Soms moest ik honderden aanpassingen doen aan mijn codes om alles weer goed te laten draaien onder de nieuwe PHP-versie. Maar het lukte.
 
Kennis over multibyte encoding zoals bij utf-8 is altijd handig :) Je voorbeeld is goed te volgen.
Als je met Notepad++ werkt kan je de 'standaard" encoding aanpassen in de instellingen.

screenshot-utf-8.jpg
 
Dank voor alle tips!

In plaats van Notepad++ gebruik ik als code-editor EditPlus 3. Hiermee werk ik al meer dan 10 jaar (eerst met zijn voorganger EditPlus 2) en ik vind het een geweldig goed en fijn programma.

Maar ongetwijfeld zijn er zeer veel programma's waarmee men de encoding kan aanpassen.
 
Ik kende Edit Plus niet, ik denk omdat het een betaald programma is?
Grappig dat Notepad++ als direct alternatief wordt genoemd.

Ik zie ineens dat Notepad3 er is. Vroeger altijd Notepad2 gebruikt. Klein, zeer snel, en er zit veel in, zelfs een syntax debugger.
 
Inderdaad is EditPlus een betaald programma. Als ik het niet had zou ik Notepad++ of Notepad3 gaan proberen! :thumb:
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan