Analyse lexicale avec un StreamTokenizer

Bonjour

je developpe actuellement une calculatrice qui utilise la notation polonaise inverse mais, là n'est pas le problème^^
Pour faire les calculs, je dois ouvrir un fichier qui contient les données au bon format NPI.
Lorsque le StreamTokenizer (ST par la suite) que j'utilise sur un BufferReader(FileReader) analyse les tokens j'ai quelques petits effets de bords:
- Si le fichier commence par un chiffre ou un nombre (sans espace avant), le ST reconnait ce chiffre
comme une chaine (celà ne me le fait pas lorsque j'insère un espace avant le nombre au début du fichier)
- Lorsque je compare les caractères de signe du fichier je n'arrive pas à les matcher, j'ai essayé:
* de créer un tableau de char contenant l'ensembles de signes autorisés ca ne fonctionnait pas dans tous les cas
* de comparer la valeur retournée par sval.charAt(0) aux char '+' '-' '*' '/'
* de comparer la valeur retournée par Character.getNumericalValue(ST.sval.charAt(0)) aux Character.getNumericalValue() de'+' '-' '*' '/'
* de comparer la valeur contenue dans ST.sval avec par exemple la chaine "+" "-" "*" "/"
Tout ça sans grand succès jusqu'à présent...
En sachant qu'au départ j'étais parti sur un FileReader qui gère uniquement l'encodage par défaut de l'os hôte,
j'ai l'impression d'echaîner galères sur galères avec cet exercice pourtant pas compliqué
Autre petite question:
J'utilise une switch sur ST.nextTokken() pour ensuite determiner par case StreamTokenizer.TT_WORD ou case StreamTokenizer.TT_NUMBER
si la valeur contenue dans ttype est celle d'un nombre ou d'une chaine
Est-ce la bonne façon de faire?
A priori celà fonctionne jusqu'à présent.
Je crie à l'aide :D

Merci par avance pour vos réponses

$@t@n-lui-]v[ ]v[

Bonsoir

J'ai finalement pus gérer les opérateurs en les traitant comme des mots via la méthode wordChars puis en testant la valeur de sval via la méthode equals.
Je suis ensuite tombé sur un autre problème, le cas du moins (-)...
Alors que les autres opérateurs étaient reconnu, le moins quand à lui avait un comportement bizarre, le ttype a pris la valeur du moins de la table ascii soit 45 ...:aie:

Bon en rajoutant un case 45 ce se laisse traiter mais je trouve ça dégueulasse :lol:
Pour l'instant tout marche, excepté le fait qu'il faille que j'insère un espace en début de ligne pour que les caractères numériques soit reconnus
je ne passe donc pas le topic en résolu et j'aimerais bien avoir quelques avis sur la chose!

Bonne nuit

Bon j'ai fini par trouver la solution

Le problème des chiffres reconnus comme des chaines en début de fichiers étaient lié à l'encodage utf8 de mes fichiers, sans avoir de détails les basculer dans l'encodage en ANSI sur notepad++ à résolu le problème.

Il reste des cas dans lesquels ma calculette échoue dans mes tests JUnit mais comme la plateforme de tests de mon école ne me balance plus aucunes erreurs je laisse tomber ^^

Sûrement le BOM, reconnu comme un (ou des) caractère "normal," en tout cas ni chiffre ni blanc.