L'obtention de std :: ifstream pour gérer LF, CR, et CRLF?

Que Neil a souligné, "le C++ runtime doit traiter correctement avec la ligne de fin de la convention est à votre plate-forme."

Cependant, les gens ne déplacer des fichiers texte entre les différentes plates-formes, donc qui n'est pas assez bon. Voici une fonction qui gère tous les trois fins de ligne ("\r", "\n" et "\r\n"):

std::istream& safeGetline(std::istream& is, std::string& t)
{
    t.clear();

    //The characters in the stream are read one-by-one using a std::streambuf.
    //That is faster than reading them one-by-one using the std::istream.
    //Code that uses streambuf this way must be guarded by a sentry object.
    //The sentry object performs various tasks,
    //such as thread synchronization and updating the stream state.

    std::istream::sentry se(is, true);
    std::streambuf* sb = is.rdbuf();

    for(;;) {
        int c = sb->sbumpc();
        switch (c) {
        case '\n':
            return is;
        case '\r':
            if(sb->sgetc() == '\n')
                sb->sbumpc();
            return is;
        case std::streambuf::traits_type::eof():
            //Also handle the case when the last line has no line ending
            if(t.empty())
                is.setstate(std::ios::eofbit);
            return is;
        default:
            t += (char)c;
        }
    }
}

Et ici est un programme de test:

int main()
{
    std::string path = ...  //insert path to test file here

    std::ifstream ifs(path.c_str());
    if(!ifs) {
        std::cout << "Failed to open the file." << std::endl;
        return EXIT_FAILURE;
    }

    int n = 0;
    std::string t;
    while(!safeGetline(ifs, t).eof())
        ++n;
    std::cout << "The file contains " << n << " lines." << std::endl;
    return EXIT_SUCCESS;
}

OriginalL'auteur

Êtes-vous de lire le fichier dans BINAIRE ou dans TEXTE mode? Dans TEXTE mode, la paire de retour chariot/saut de ligne, CRLF, est interprété comme TEXTE la fin de la ligne, ou le caractère de fin de ligne, mais dans BINAIRE vous récupérer uniquement UN octet à la fois, ce qui signifie que l'un des personnages DOIT être ignoré et laissé dans la mémoire tampon pour être extraites comme un autre octet! Retour chariot signifie, dans la machine à écrire, que la machine à écrire de voiture, d'où l'impression bras réside dans, a atteint le bord droit du papier et est renvoyé vers le bord gauche. C'est un très mécanique modèle, celui de la machine à écrire mécanique. Puis le saut de ligne signifie que le rouleau de papier est tourné un peu pour que le papier est en position de commencer une nouvelle ligne de saisie. Comme fas comme je me souviens de l'un de la faible chiffres ASCII signifie se déplacer vers la droite d'un caractère sans avoir à taper, le char morts, et bien sûr, \b signifie backspace: déplacer la voiture un caractère de retour. De cette façon, vous pouvez ajouter des effets spéciaux, comme des sous-jacent (type de trait de soulignement), barré (type moins), approximative des accents différents, annule (type X), sans avoir besoin d'un clavier étendu, simplement en ajustant la position de la voiture le long de la ligne avant d'entrer dans la ligne d'alimentation. Ainsi, vous pouvez utiliser octets de taille ASCII tensions de contrôler automatiquement une machine à écrire sans un ordinateur entre les deux. Lorsque la détection automatique d'une machine à écrire est introduit, AUTOMATIQUE signifie qu'une fois que vous atteignez le plus éloigné bord de la feuille, la voiture est retournée à la gauche de la ET le saut de ligne appliquée, qui est, la voiture est supposé être retourné automatiquement à mesure que le rouleau se déplace vers le haut! Donc, vous n'avez pas besoin à la fois des caractères de contrôle, un seul, le \n, nouvelle ligne, ou un saut de ligne.

Cela n'a rien à voir avec la programmation, mais ASCII est plus âgé et HEY! regarde comme certaines personnes n'ont pas été pensée quand ils ont commencé à faire du texte de choses! La plate-forme UNIX suppose électrique automatique typemachine; le modèle de Windows est plus complet et permet le contrôle de la mécanique des machines, même si certains caractères de contrôle deviennent de moins en moins utile dans les ordinateurs, comme la cloche de caractère, 0x07 si je me souviens bien... Certains textes oubliés doit avoir été à l'origine capturé avec des caractères de contrôle pour la commande électrique des machines à écrire et elle a perpétué le modèle...

Fait le bon variation serait simplement d'inclure les \r, saut de ligne, retour chariot inutile, c'est automatique, donc:

char c;
ifstream is;
is.open("",ios::binary);
...
is.getline(buffer, bufsize, '\r');

//ignore following \n or restore the buffer data
if ((c=is.get())!='\n') is.rdbuf()->sputbackc(c);
...

serait la plus correcte pour gérer tous les types de fichiers. Notez cependant que les \n dans TEXTE mode est en fait l'octet paire 0x0d 0x0a, mais 0x0d EST \r: \n comprend \r dans TEXTE mode mais pas dans BINAIRE, ainsi \n et \r\n sont équivalentes... ou devrait l'être. C'est un très de base de l'industrie de la confusion en fait, typique de l'inertie de l'industrie, comme la convention est de parler de CRLF, dans TOUTES les plates-formes, tombent ensuite dans différents binaires interprétations. Strictement parlant, les fichiers, y compris SEULEMENT 0x0d (retour chariot) \n (CRLF ou saut de ligne), sont mal formés dans TEXTE mode (typewritter de la machine: il suffit de retourner la voiture et barré tout...), et sont un non-ligne orientée format binaire (soit \r ou \r\n sens de la ligne), de sorte que vous ne sont pas censés lire que du texte! Le code devrait échouer peut-être avec quelques message de l'utilisateur. Cela ne dépend pas de l'OS, mais aussi sur la bibliothèque C de mise en œuvre, ajoutant à la confusion et les variations possibles... (en particulier pour la transparence de traduction UNICODE couches d'ajouter un autre point d'articulation dans la confusion entre les variations).

Le problème avec l'extrait de code précédent (machine à écrire mécanique), c'est qu'il est très inefficace si il n'y a aucun \n caractères à la suite de \r (automatique machine à écrire du texte). Puis il suppose également BINAIRE mode où la bibliothèque C est contraint d'ignorer texte interprétations (paramètres régionaux) et donner la pure octets. Il devrait y avoir aucune différence dans le texte tous les caractères entre les deux modes, que dans le contrôle des personnages, donc en général la lecture BINAIRE est mieux que TEXTE mode. Cette solution est efficace pour BINAIRE mode typique de système d'exploitation Windows fichiers texte, indépendamment des variations de la bibliothèque C, et inefficace pour les autres plate-forme de formats de texte (y compris les traductions dans le texte). Si vous vous souciez de l'efficacité, de la manière de faire est d'utiliser un pointeur de fonction, faire un test pour \r vs \r\n des contrôles en ligne cependant manière dont vous le souhaitez, puis sélectionnez le meilleur getline utilisateur-code dans le pointeur et l'invoquer.

D'ailleurs je me souviens que j'ai trouvé un \r\r\n fichiers texte trop... ce qui se traduit par une double ligne de texte, tout comme l'est toujours exigé par certains textes imprimés aux consommateurs.

OriginalL'auteur Danilo J. Bonsignore

Une solution serait de d'abord rechercher et remplacer toutes les fins de ligne '\n' - comme par exemple Git le fait par défaut.

OriginalL'auteur user2061057