Le problème c'est que c'est un fichier binaire, donc si il y a des 0 dans le fichier, et il s'arrêterait au premier 0 trouvé.
comment faire l'équivalent de:
if(buf[i] == 'x' && buf[i+1] == 'X' ....
avec des seek() et des file.position ?
a moins que si j'utilise
while(file.available()) {
...
}
si je charge le fichier dans un buffer et que je créé un pointeur sur ce buffer, je n'ai plus besoin de tester le '\0', car de toutes facon la lecture s'arrêtera avec le file.available(), je suppose.
C’est facile de connaître la taille totale du fichier
Vous connaissez la position donc par soustraction vous pouvez savoir s’il reste 3 octets à lire
Si ce n’est pas le cas ➜ erreur
Si c’est le cas vous faites un read des 3 octets dans un petit buffer de 3 octets et ensuite un memcmp() permet de comparer ces 3 octets avec des valeurs prédéfinies
Par contre le read de 3 octets va modifier la position dans le fichier de 3 position (seek+3), si le memcmp ne correspond pas je dois reculer de 3 position ou mémoriser la position avant de faire le read de 3 car.
Je suis obligé de me positionner et je j'utilise la valeur dans le test.
Si le test passe, je suis obligé de faire avancer le pointeur du fichier pour sauter les 3 lectures pour lire le caractère suivant après les trois codes (92,101,91).
Meme si je ne lit pas la valeur avec un read, je dois faire avant la position du fichier.
Ca fonctionne très bien, la seule chose un peu plus propre serait de faire comme J-M-L le dit, dans le cas ou ca dépasse la taille du fichier, mais ce n'est pas trop grave c'est une lecture et si correspond pas ca valide mon test, mais ce serait plus propre de le faire.
Je n'arrive pas a trouver le calcul pour le reste de la fin, j'ai le même problème avec l'éditeur hexa, comme je n'ai pas trouvé la solution j'ai laissé comme cela en attendant.
Pour l'éditeur hexa c'est plus compliqué car je lis par bloc de 16 et si le fichier à une longueur de 2300 car. par exemple,
je dois calculer le reste du bloc de 16 bytes par rapport à la longueur du fichier. j'ai fait cette formule mais il reste toujours deux caractères en plus.
int nbPos;
if (fin - (mptr + BYTE_COLUMN) < BYTE_COLUMN) nbPos = fin - mptr;
else nbPos = BYTE_COLUMN;
Comme c'est un buffer il y a le car. '\0' à la fin. donc au final ca m'affiche
0x0D 0x0A 0x00 0xXX 0xXX
Le 0xXX c'est 2 car. de la mémoire en dépassement.
Ba alors c'est moi qui ne comprends pas ce que tu veux dire
tu as dans psBuf tout le fichier, ce qui le rend complétement indépendant de la pseudo lecture du flux file.
Du coup tu te positionne dans le flux avec des seek, mais si tu ne lis jamais, à quoi cela te sert?
Apres j'ai peut être lu trop vite
void _putch(uint8 c)
{
if (SERCTL_ENABLED) {
SEROUT.write(c);
}
#ifdef FABGL
Terminal.write(c);
#endif
}
ca affiche juste un car. dans le terminal soit sur le port série ou l'écran.
Terminal.write, c'est l'équivalent d'un print en c ou du serial.write, mais sur le terminal.
Le flux file me sert juste à lire le fichier pour atteindre la fin du fichier, car dans le buffer je ne peux pas dire quand est ce que j'arrive à la fin du fichier.
oui, mais on peut toujours refaire un seek si nécessaire
mais en fait c'est inutile de passer par le fichier si effectivement vous avez le fichier en mémoire dans un buffer et que vous connaissez la taille occupée par le buffer
comme disait terwal, je n'ai pas besoin, tout compte du seek et comme tu dit j'ai déjà la taille du fichier.
ca se résume à un
for (int i = 0; i < size_file, i++) {
.....
Je veux juste afficher le contenu d'un fichier, mais il peut être binaire aussi, même si ca affiche des caractères bizarre à l'écran, comme le cat sous unix ou le type sous dos, et je prend en compte les caractère ansi chart, pour afficher les fichiers ansi art.
Il y a des des packs sur internet, j'ai fait quelques tests sur ces fichiers et ca fonctionnait.
Je suis tellement concentré que je n'ai pas vu que je me compliquait la vie.
Sinon un des problèmes que je rencontre souvent c'est quand on arrive à la fin du fichier, et n'afficher que le ce qui doit être traité, un peu comme l'éditeur hexa sur mon exemple plus haut et même pour cet exemple.
si je fait:
buf[i], buf [i+1], buf[i+2]
Un moment donné je vais dépassé le buffer.
Je connais la taille du fichier
je connais combien de car. doit être lut,
j'ai le début du buffer
Peut être un truc du genre modulo avec le %
mais je but la dessus.
si dans le code vous avez besoin d'utiliser buf[i], buf [i+1], buf[i+2]
faites simplement
for (int i = 0; i < size_file-2, i++) {
// ici buf[i], buf [i+1], buf[i+2] sont sûrs d'exister
}
ou si vous avez vraiment besoin d'aller jusqu'au bout il faut tester
for (int i = 0; i < size_file, i++) {
if (i < size_file-2) {
// ici buf[i], buf [i+1], buf[i+2] sont sûrs d'exister
} else
if (i == size_file-2) {
// ici buf[i], buf [i+1] sont utilisables
} else
if (i == size_file-1) {
// ici seulement buf[i] est utilisable
}
}
J'ai testé avec le for et la taille du fichier ca ne fonctionne pas et ca ne prend plus en compte les escape code, je vais donc laissé avec le seek + available et le buffer. et pour le dépassement tanpis lol
je viens de refaire un test et je suis obligé de faire avancer le seek et l'indice en même temps pour que ca coîncide sinon j'ai un décalage.
Le file.available() dans la boucle fait avancer le seek+1, et l'indice saute certains caractère spécifique.
En gros le available me sert de EOF.
il n'existe pas l'équivalent:
while(buffer != EOF)
et avec le size du buffer ca ne fonctionne pas. en tous cas ca fonctionne comme tel.
le for ne fonctionne, sans les seek ca ne marche pas, et le size -2 ne fonctionne pas.
Dois je comprendre que selon ce que vous voyez à la position i il faut lire un ou deux caractères en plus ?
Dans ce cas un for avec juste i++ n’est pas forcément le mieux
Un while avec progression du caractère courant de 1 2 ou 3 positions en fonction de ce que l’on a lu est plus approprié
