[RegEx] Right Single Quotation mark

[ElCondor]

Mijn vraag
Hey mensen, ik probeer een regex te bouwen die geocoordinaten moet vangen.
Een van de voorbeelden bevat een string als

code:

23°14’34’E

Het lukt om degrees te vangen, maar de quote wordt niet opgepikt. Deze heeft URL encoding: %E2%80%99 en als ik het goed heb gevonden een alt-2019 code.

Relevante software en hardware die ik gebruik
Vermoedelijk een C++ implementatie van RegEx
Het vervelende is dat we de regex expressie moeten definiëren in een XML bestand. Daarmee zitten we potentiëel met een dubbele encodering (zie hieronder).

Wat ik al gevonden of geprobeerd heb
We hebben al verschillende manieren van escapen of rechstreeks copy-pasten van het karakter geprobeerd, maar hij vind hem niet.
Omdat we verschillende schrijfwijzen willen vangen maken we gebruik van een groep:

code:

["’ ]

Daarbij wordt de schrijfwijze

code:

23°14'34'E

wel gevonden maar de versie met de right single quotes niet.
Volgens de XML documentatie zou de right single quote ook niet xml escaped hoeven te worden en zou deze dus als zodanig in de RegEx opgenomen moeten kunnen worden. Toch wordt de string niet gevangen. Iemand hier ideeën over?

[ Voor 3% gewijzigd door ElCondor op 13-05-2024 11:55 ]

[ValHallASW]

Het is een beetje koffiedik kijken omdat we niet weten hoe "23°14’34’E" intern gerepresenteerd wordt. Werkt je regex engine op unicode codepoints of op bytes? In het eerste geval: wordt de string goed gedecode, of worden de ’'s omgetoverd tot vraagtekens of �s? In het tweede geval: UTF-8? UTF-16? Windows-1252?

Ik zou er in dit geval voor kiezen om niet een specifiek karakter te matchen, maar "not-a-digit" te matchen. Dan krijg je dus:

code:

(\d+)[^\d](\d+)[^\d](\d+)[^\d][EW]

of eventueel

code:

(\d+)[^\d]+(\d+)[^\d]+(\d+)[^\d]+[EW]

als de eerste optie niet werkt (en dat suggereert dan weer dat er op byte-niveau wordt gematcht of dat de input verkeerd wordt gedecode).

[ElCondor]

Not a digit is wel een optie, maar maakt je vangnet wel weer heeeel breed. We moeten de geo-coordinaten uit lappen text vlooien, dus er is mogelijk een risico op false positives en daar willen we juist bij weg blijven.
Maar zeker een punt waar we wellicht ook naar kunnen kijken.

Wat betreft de engine, deze betrekken we van een software leverancier die het in zijn pakket heeft gebouwd. Dus dat is ook voor ons een beetje koffiedik kijken. We zouden daar een ticket bij de leverancier voor kunnen inschieten, maar dat kan soms lang duren en opent daarnaast een heel nieuw blik met wormen
(Vaak moeten we dan een reproduceerbare omgeving opleveren
Als we dat kunnen voorkomen, dan graag

[ValHallASW]

Dan zal je toch de encoding-details in moeten duiken, en systematisch alle opties afwerken aan zowel je inputbestand als je XML-configuratie. Welke bytes staan er, en hoe kunnen die bytes allemaal geinterpreteerd worden? En met welke combinatie aan regex'es kan je dat aantonen?

Voorbeeldje: stel dat
- je brontekst als utf-8 is opgeslagen
- je softwarepakket het als bytes matcht

dan:
- wordt je ’ intern opgeslagen als 0xE2, 0x80, 0x99

en dat zou je kunnen testen door:
- te kijken of je het karakter kunt matchen met een regex /.../

[ElCondor]

ValHallASW schreef op maandag 13 mei 2024 @ 13:11:
...
en dat zou je kunnen testen door:
- te kijken of je het karakter kunt matchen met een regex /.../

Dit snap ik even niet. Hoe zou ik dat dan moeten testen? Ik begrijp de regex \ ...\ niet

[ValHallASW]

/.../ - als in: drie puntjes, die '3x welk karakter dan ook' matchen. Nu ik het verder uitschrijf is dat alleen nog geen hele goede check:



(en hoe je oorspronkelijke bestand is opgeslagen is makkelijker met een hexeditor te checken dan met deze route)

[ElCondor]

Hmja, er lijken te veel variabelen te zijn welke voroons een zwarte doos blijven. Zeker mbt de regex implementatie van de geleverde software. We hebben voor nu besloten om die right single quote ven te laten voor wat het is. Het is, naast alle normale en dubbele quotes en exoot...