IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Retour chariot, détection, échange


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 86
    Par défaut Retour chariot, détection, échange
    Bonjour à tous,

    Je développe actuellement un algo de chiffrage légé de mon cru, il n'a pas pour but de concurencé ce qui existe déjà, mais de rendre ilisible des infos en clair, et que la méthode ne soit pas quelque chose d'existant (usage professionnel donc je ne donnerais que peu de détail).

    Actuellement mon moteur de chiffrement fonctionne mais sans gestion du retour chariot, à cause de la difficultée que je vais vous énoncer.

    Sans rentrer dans les détails de mon algo, le retour à la ligne me pose beaucoup de problème.

    En effet, selon wikipedia, il est différent suivant l'os employé :
    - Windows - cariage return + line feed : \r\n - ascii(13) / ascii(10)
    - MacOs - cariage return : \r - ascii(13)
    - Linux - line feed : \n - ascii(10)

    Je cherche un moyen simple de convertir les retours à la ligne quelques soit le système d'exploitation vers quelque chose d'uniforme.

    Normalement l'algo sera coté serveur, qui recevra du client la chainse saisie.

    Plutot que de forcer coté client la conversion, je préfère faire ce quil faut coté serveur.

    Est ce que quelqu'un aurait-il déjà eu affaire à ce genre de conversion ?

    J'ai quelques idées vagues, la première :

    fonction qui détecte le type de retour chariot et qui retournerais l'os d'entrée détecté, qui serait capable de convertir un retour chariot en le caractère " ^ ".

    Comme l'os d'entrée serait détecté, je retournerais une chaine chiffrer ou les retour chariot serait réecrit pour l'os d'entrée.

    La seconde serait de convertir le retour quelque soit l'os vers " ^ ", sans me préocupé de l'os d'entrée.

    Au moment du retour de la chaine chiffrer, je convertirais avec une autre fonction les " ^ " au format Windows (CRLF ascii(13) + ascii(10)).

    Sans dire de bêtise, linux détecte et comprends les CRLF dans la pluspart des logiciels, et Mac de la même manière, est ce que quelqu'un aurait une idée plus précise que la mienne pour traiter ce soucis ?

  2. #2
    Membre très actif

    Femme Profil pro
    Collégien
    Inscrit en
    Juillet 2010
    Messages
    591
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Afghanistan

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Juillet 2010
    Messages : 591
    Par défaut
    Salut,

    Je pense que tu te trompe de problème. Le plus simple serait que ton algo supporte les retours chariot.

    Imagine que quelque t'énonce le même problème mais avec le la lettre 'A' ou le chiffre 42 en lieu et place de ton problème avec \r.

  3. #3
    Membre Expert
    Avatar de kwariz
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Octobre 2011
    Messages
    898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2011
    Messages : 898
    Par défaut
    Bonsoir,

    je plussoie mith06. Tu as un problème de retour chariot mais tu risques aussi de te retrouver face à un problème d'encodage (encore). Ton client windows pourrait générer des chaines avec un encodage win1252/CRLF, ton client mac avec un encodage UTF8/CR et un client linux avec un encodage ISO8859-15/LF.
    L'idéal est que chaque client transforme les chaines saisies vers un encodage de travail (par exemple UTF8/LF ou UCS4/CRLF) et l'envoie à la routine de chiffrage qui ne fera que chiffrer/déchiffrer une suite d'octets sans signification particulière (c'est ton workflow qui manque de détails, qui chiffre, qui déchiffre, comment est transmis la chaine ... ce n'est pas clair).
    Je suppose que tu codes en C, que ton code client sera suffisamment portable pour ne garder qu'un ensemble de source aux define près pour toutes les plateformes ?

  4. #4
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 86
    Par défaut
    Citation Envoyé par kwariz Voir le message
    Bonsoir,

    je plussoie mith06. Tu as un problème de retour chariot mais tu risques aussi de te retrouver face à un problème d'encodage (encore). Ton client windows pourrait générer des chaines avec un encodage win1252/CRLF, ton client mac avec un encodage UTF8/CR et un client linux avec un encodage ISO8859-15/LF.
    L'idéal est que chaque client transforme les chaines saisies vers un encodage de travail (par exemple UTF8/LF ou UCS4/CRLF) et l'envoie à la routine de chiffrage qui ne fera que chiffrer/déchiffrer une suite d'octets sans signification particulière (c'est ton workflow qui manque de détails, qui chiffre, qui déchiffre, comment est transmis la chaine ... ce n'est pas clair).
    Je suppose que tu codes en C, que ton code client sera suffisamment portable pour ne garder qu'un ensemble de source aux define près pour toutes les plateformes ?
    Je ne peux donner aucun détail sur l'algo de chiffrement car il sera utilisé par mon entreprise.

    On m'a imposé de le programmer en un temps record, et ne devant se basé sur rien d'existant, et supporter des contraintes qu'on m'à imposé.

    C'est à cause de ces contraintes que ce pose le problème de retour chariot.

    D'une part parce que je ne chiffre pas au niveau binaire, mais au niveau caractères ...

    Très grossièrement, je récupère le code ascii d'un caractère que je modifie de façon XXXXX pour chiffrer.

    Je suis obliger de chiffer au niveau ascii à cause de certaines contraintes xxxx, une d'entre elle est un stockage sur une base de donnée obsolète de la donnée chiffrer, qui ne supporte pas le type le donnée binaire, et utilise une table ascii assez restreinte.

    J'ai par ailleurs proposé d'utiliser un algo au niveau binaire, plus facile à mettre en oeuvre et très facilement programmable.

    Au lieu de ça, chiffrement sur la couche ascii et ça beaucoups de contraintes.

    Je comprends vos point de vue, qui sont réellement justifiée... seulement ces arguments que j'ai eu avec mon chef de service n'ont servit à rien, pour une question de base de donnée, de budget, il m'a envoyé boulé.

    Du coup retour à la case départ ... ou encore CRLF pour ne pas faire de mauvais jeu de mot.

    Je suis obligé de gérré le retour chariot à la main et de faire avec donc ...

    Que penser vous de mon idée de retourner à chaque fois CRLF, et de détecter les retour chariot en entrée afin de les convertir, quelque soit le type (windows linux mac) ?

  5. #5
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    J'imagine que tu as bien expliqué à ton chef de projet que ton implémentation personnelle en temps record serait évidemment au moins aussi sure que celle fournie dans des outils standards comme openSSL ou autre…

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 86
    Par défaut
    Le but principale de mon algo ne recherche pas une sécurité, mais juste une ilisibilité del a donnée au niveau utilisateur. Il n'a donc pas besoin d'être très fort comme d'autre solution.

    Sinon, je ne me serais pas vraiment casser la tête à développer qq chose alors qu'il existe des solutions beaucoup plus sûr en terme de sécurité.

    Le problème c'est qu'avec la somme des contraintes qui me sont donnée, je n'ai pas le choix, je suis obligé de développer quelque chose, rien d'existant ne se plie à tout ce qu'on m'impose, j'ai beau faire ou chercher.

  7. #7
    Membre Expert
    Avatar de kwariz
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Octobre 2011
    Messages
    898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2011
    Messages : 898
    Par défaut
    Citation Envoyé par enzo68290 Voir le message
    Je ne peux donner aucun détail sur l'algo de chiffrement car il sera utilisé par mon entreprise.

    On m'a imposé de le programmer en un temps record, et ne devant se basé sur rien d'existant, et supporter des contraintes qu'on m'à imposé.

    C'est à cause de ces contraintes que ce pose le problème de retour chariot.

    D'une part parce que je ne chiffre pas au niveau binaire, mais au niveau caractères ...

    Très grossièrement, je récupère le code ascii d'un caractère que je modifie de façon XXXXX pour chiffrer.

    Je suis obliger de chiffer au niveau ascii à cause de certaines contraintes xxxx, une d'entre elle est un stockage sur une base de donnée obsolète de la donnée chiffrer, qui ne supporte pas le type le donnée binaire, et utilise une table ascii assez restreinte.

    J'ai par ailleurs proposé d'utiliser un algo au niveau binaire, plus facile à mettre en oeuvre et très facilement programmable.
    Bon on va faire un coup de out of the box si tu veux bien. Tu n'es pas obligé d'avoir un chiffrage ascii du tout, la contrainte n'est pas au niveau du chiffrage mais du stockage.
    Stockage ascii me fait immédiatement penser à Base64. Ta base de donnée aussi obsolète soit elle sera certainement capable de supporter une chaine de caractères piochant ses valeurs dans un sous ensemble de 64 caractères ...
    Ma première conclusion est : chiffre comme tu le sens, transforme la donnée binaire en ascii par base64. À la limite un algo Base64 un peu modifié sera peut-être même amplement suffisant pour tes besoins de chiffrage ...

    Citation Envoyé par enzo68290 Voir le message
    Au lieu de ça, chiffrement sur la couche ascii et ça beaucoups de contraintes.

    Je comprends vos point de vue, qui sont réellement justifiée... seulement ces arguments que j'ai eu avec mon chef de service n'ont servit à rien, pour une question de base de donnée, de budget, il m'a envoyé boulé.

    Du coup retour à la case départ ... ou encore CRLF pour ne pas faire de mauvais jeu de mot.

    Je suis obligé de gérré le retour chariot à la main et de faire avec donc ...

    Que penser vous de mon idée de retourner à chaque fois CRLF, et de détecter les retour chariot en entrée afin de les convertir, quelque soit le type (windows linux mac) ?
    Bah oui de toute façon il faudra bien le faire quelque part. Comme tu codes en C (apparemment avec la glibc) tu pourrais avoir un workflow comme :

    saisie --- iconv ---> saisie transcodée en UTF8 (par ex.) --- remplacement des CR et LF par CRLF ---> saisie prête au format UTF8/CRLF ---- Chiffrage ---> donnée binaire illisible --- BASE64 ---> donnée toujours illisible mais ne contenant que des caractères ascii acceptés par la bdd obsolète : bingo

    Dans l'autre sens tu déBase64, tu déchiffres, tu remplaces les CRLF par un \n et finalement tu transcodes de UTF8 vers l'encodage local.

    C'est un workflow possible. Ensuite ce serait sympa de nous détailler juste quelle partie tu comptes implémenter côté serveur et quelle partie tu comptes implémenter côté client car (me concernant) ce n'est toujours pas clair.

  8. #8
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Pour le coup des changements de ligne, si ton programme n'est pas censé traiter des fichiers avec un encodage des changements de ligne différent du système hôte, tu peux tout simplement ouvrir les fichier en mode texte, ce qui convertit les encodages du fichier hôte en \n.

    Sinon, tu épluches toi-même avec une fonction capable d'examiner un caractère et le suivant:
    • Si ton caractère lu est un \n, tu l'écris dans ton buffer tel quel (pourquoi le transformer, après tout?).
    • Si ton caractère lu est un \r, tu regardes s'il est suivi d'un \n:
      • Si oui, tu l'ignores (tu le laisses tomber sans rien écrire dans le buffer).
      • Si non, tu le transformes en \n.

    Bien sûr, dans tous les cas l'inconvénient est que le fichier ne sera pas idéntique au bit près en sortie qu'en entrée, vu que les erreurs ne seront pas préservées.

    Ensuite, si ta table ne peut même pas stocker un \n, là l'idée du codage en base 64 ressort. Vu que ton texte doit être illisible de toute façon, pas besoin d'utiliser autre chose du genre UTF-7.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

Discussions similaires

  1. [WD-2010] Détection de retour chariot fichier word
    Par CristofMartins dans le forum VBA Word
    Réponses: 2
    Dernier message: 20/03/2013, 13h39
  2. Retour chariot
    Par raf_gug dans le forum MFC
    Réponses: 9
    Dernier message: 13/01/2004, 17h54
  3. afficher texte avec retour chariot aprèq requète sql
    Par frenchy371 dans le forum Requêtes
    Réponses: 2
    Dernier message: 07/01/2004, 17h33
  4. retour chariot dans un string
    Par bono dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 29/12/2003, 12h17
  5. Retour chariot dans un TMemo ?
    Par Vincent PETIT dans le forum C++Builder
    Réponses: 7
    Dernier message: 27/08/2002, 18h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo