Pos ou ansipos sur ansistring longueur > 255

Bonjour à tous,

J'utilise Delphi 2010 et je reçois d'une socket IP des données dont la longueur est d'environ 20 000 caractères UTF8.

J'ai déclaré une variable XLMTextIN: RawByteString;

Ensuite sur l'évevenement SocketServerClientRead
je récupère les données reçues sur la socket

XLMTextIN := Socket.ReceiveText;

Pour info, XLMTextIN = '<?xml version="1.0" encoding="utf-8"?>....

si je fais un pos('utf-8', XLMTextIN)
ou ansipos('utf-8', XLMTextIN)

la valeur renvoyée est toujours 0.

Est ce parce que la longueur de XLMTextIN dépasse les 256 caractères ?
Ou alors est ce pour une autre raison ?


Merci d'avance pour vos réponses,
Wilco

je ne sais pas où est l'erreur, mais pas dans la limite de taille, les string ne sont plus limité à 255 caractères depuis Delphi 2 :)

Bonjour,

Citation:

---

Envoyé par Wilco

J'ai déclaré une variable XLMTextIN: RawByteString;
...
si je fais un pos('utf-8', XLMTextIN)
...
la valeur renvoyée est toujours 0.

---

Il faudrait peut être convertir XMLTextIN en string avant de faire le test ?

RawByteString est un type brut mais reste une AnsiString d'un point de vue mémoire

je pense que c'est plus lié à un problème de conversion d'encodage !
Quel variante utilise-t-il de Pos utilise-t-il ?

Citation:

---

Envoyé par aide

Code:

---

1 2 3 4

function Pos(const SubStr, Str: ShortString): Integer; function Pos(const SubStr, Str: UnicodeString): Integer; overload; function Pos(const SubStr, Str: WideString): Integer; overload; function Pos(const SubStr, Str: RawByteString): Integer; overload;

---

---

tu passes un UnicodeString et RawByteString
du coup il doit avoir des difficultés pour choisir entre la variante 2 UnicodeString ou 2 RawByteString

essaye ceci

Code:

---

1 2 3 4 5 6 7 8 9 10

var XLMTextIN: RawByteString; const XML_ENCODE:RawByteString = 'utf-8'; // force le typage et donc le choix de la variante begin index := Pos(XML_ENCODE, XLMTextIN); if index > 0 then ...   end;

---

ReceiveText d'un Socket retourne une AnsiString, c'est normalement théorique le plus proche du binaire avec un mode chaine

As-tu essayé un ReceiveBuf dans TByteDynArray temporaire recopié ensuite dans un TMemoryStream pour finalement effectué un TXMLDocument LoadFromStream ?

Pense aussi que tu ne recevra jamais les 20000 caractères d'un coup mais découpé en lot de 8Ko, il te faudra donc accumuler le XML dans le TMemoryStream, une fois complet, tu pourras le lire

Il faudrait déjà s'assurer qu'il n'y a pas de #0 dans la chaîne. Ceci permettrait de le contrôler :

Code:

---

ShowMessage(PAnsiChar(XLMTextIN) +#13 +IntToStr(Length(XLMTextIN)));

---

Si la longueur du texte affiché ne correspond pas à la taille renvoyée, il y a un #0 ;)

Merci à tous pour vos réponses ... J'ai peut être une explication sur le problème que je rencontre.

J'utilise un TServerSocket et lorque la socket reçoit environ 20Ko de données, effectivement elle les reçoit en plusieurs paquets.

J'ai mis un point d'arrêt sur l'évènement OnRead de la socket.

Lors du 1er arrêt, si je consulte la variable
XLMTextIN = Socket.ReceiveText; elle affiche bien '<?xml version="1.0" encoding="utf-8"?>.. je vois donc son contenu

la seconde variable est :
x := ansipos('utf-8', XLMTextIN);

A ce moment, x = 0 ( ce qui est perturbant car il devrait afficher 31 )

Et ce n'est qu'au 4ème passage sur le point d'arrêt que x = 31.

Comme le dit justement Shail, les données n'arrivent pas en une seule fois et il semblerait que la fonction pos et/ou ansipos ne renvoie pas la bonne valeur tant que l'intégralité des données aient été reçues. C'est étrange car lors de chaque passage au point d'arrêt, le contenu de la variable XLMTextIN, qui reçoit les données de la socket, est bien visible.

Au final j'arrive à faire fonctionner ce programme mais le débogage n'est pas facilité en raison du comportement soit de Delphi soit de mon application.


Merci encore une fois à tous ceux qui ont apporté leur contribution à ce post.

Wilco

Je ne fais que lire l'aide :

Citation:

---

La déclaration de variables ou de champs de type RawByteString doit être rarement effectué car cela peut conduire à un comportement indéterminé et à des pertes de données potentielles.

---

Peut-être serait-il temps d'essayer un autre type...

RawByteString ne perd pas réellement de données, il perd sa page de code, du code le caractère #145 n'est pas forcément le caractère "æ", mais #65 sera toujours un "A" :)

pour identifier clairement le problème en mettant de côté le debugueur j'utilise souvent une méthode très efficace:

Code:

---

1 2 3 4 5 6

{$IFDEF BUG} AllocConsole; // ouvre une console si elle n'existe pas déjà WriteLn('XLMTextIN = ', XLMTextIN, ' (', Length(XLMTextIN),')'); WriteLn('Pos(utf-8)=', Pos('utf-8', XLMTextIN)); {$ENDIF}

---

en plaçant ce code juste avant ou après le Pos() qui pose problème on voit clairement ce qu'il se passe.

ensuite on peut aller plus loin

Code:

---

1 2 3 4 5 6 7 8

{$IFDEF BUG} AllocConsole; // ouvre une console si elle n'existe pas déjà if Length(XMLTextIn) >= 31 then begin WriteLn('XLMTextIN[31+] = ', Copy(XLMTextIN,31, MaxInt)); end; {$ENDIF}

---