Quelles sont les différences entre les fichiers .txt de Linux et Windows (codage Unicode)

"Unicode" sur Windows est UTF-16LE, et chaque caractère est de 2 ou 4 octets. Linux utilise UTF-8 et chaque caractère est compris entre 1 et 4 octets.

"Le minimum absolu absolu de chaque développeur de logiciel, doit absolument savoir sur Unicode et les jeux de caractères (pas d'excuses!)"

Rupture de ligne

Windows utilise les terminaisons de ligne CRLF ( \r\n , 0D 0A ) alors que Unix utilise simplement LF ( \n , 0A ).

Encodage de caractère

Les systèmes les plus modernes (c'est-à-dire depuis 2004) Unix-like font de UTF-8 l'encodage de caractères par défaut.

Windows, cependant, manque de support natif pour UTF-8. Il fonctionne en interne dans UTF-16 et suppose que les chaînes à base de char trouvent dans une page de code hérité. Heureusement, le Bloc-notes est capable de lire des fichiers UTF-8; Malheureusement, le codage "ANSI" est toujours par défaut.

Personnages spéciaux problématiques

U + 001A SUBSTITUTE

Windows (rarement) utilise Ctrl + Z comme caractère de fin de fichier. Par exemple, si vous type un fichier à l'invite de commandes, il sera tronqué au premier octet 1A .

Sur Unix, Ctrl + Z n'est rien de spécial.

U + FEFF ZERO AVEC NO-BREAK SPACE (Byte-Order Mark)

Sur Windows, les fichiers UTF-8 commencent souvent avec une "marque de commande d'octet" EF BB BF pour les distinguer des fichiers ANSI.

Sur Linux, la nomenclature est découragée car elle brise des choses comme les lignes shebang dans les scripts shell. De plus, il serait inutile d'avoir une signature UTF-8 lorsque UTF-8 est le codage par défaut de toute façon.

Une différence que j'ai entendue est l'utilisation de \ r \ n (Windows) vs \ n pour les sauts de ligne (Linux).

Oui. La plupart des éditeurs de texte UNIX traiteront cela automatiquement, les éditeurs de programmeurs Windows peuvent gérer cela, les éditeurs de texte généraux (Bloc-notes de base) ne le feront pas.

Windows semble avoir également besoin de l'EOF (Ctrl-Z) comme FIN DE FICHIER dans certains contextes, alors que vous ne le verrez probablement jamais sur UNIX.

Rappelez-vous que MacOS X est maintenant UNIX en dessous, donc il utilise les terminaisons de ligne UNIX. Bien qu'avant OS X (MacOS 9 et ci-dessous), il avait sa propre fin (\ r)

EDIT: dans d'autres formats CR et LF:

• \ N est ASCII 0x0A, Line Feed (LF)
• \ Est ASCII 0x0D, retour de chariot (CR)

Le codage Unicode utilisé n'est pas basé sur le système d'exploitation.

Même Windows notepad.exe a des options listées – (je mettrais entre parenthèses ce que signifie le bloc-notes par là) ANSI (non unicode), Unicode (bloc-notes signifie Unicode LE), Unicode Big Endian (BE), UTF-8

ANSI n'est pas unicode, il implique un nombre très limité de caractères, alors laissez-le de côté.

Mais voir même le bloc-notes peut faire LE, ou BE, ou UTF-8

Et notepad à part, UTF-8 peut être avec ou sans une nomenclature.

Et j'utilise Windows avec Cygwin, bien que les ports Windows puissent bien faire \ r \ n même lorsque vous spécifiez \ n Avez-vous vu que cela le faisait.

Il n'existe aucune règle sur le codage d'un système d'exploitation particulier utilisé par Unicode. Ce ne serait pas un système d'exploitation très flexible s'il y avait.

Pour voir vraiment les différences, connait le Logiciel, qu'est-ce que l'encodage d'un logiciel utilise ou offre.

Obtenez Cygwin et xxd, et / ou un éditeur hexadécimal et regardez ce qui est vraiment dans le fichier. Utilisez la commande 'fichier' pour aider à identifier un fichier. Ensuite, vous voyez vraiment ce qu'est UTF 16bit LE. Qu'est-ce que UTF 16bit BE est. Ce que UTF-8 est (et UTF-8 peut être avec ou sans nomenclature).

Parfois, vous pouvez indiquer le bloc-notes pour enregistrer en unicode (par quel bloc-notes signifie unicode 16 bit little endian), et ce ne sera pas le cas. Mais choisissez une police unicode comme arial unicode, et copiez dans certains caractères unicode de charmap et ce sera … Et une bonne façon de voir quel bloc-notes ou n'importe quel logiciel est en regardant l'hex d'un fichier

 C:\asdf>notepad.exe aa C:\asdf>file aa aa; Little-endian UTF-16 Unicode text, with no line terminators C:\asdf>type aa aaa慡ൡ <-- though displayed aaa followed by some boxes in my cmd window C:\asdf> C:\asdf>xxd aa 0000000: fffe 6100 6100 6100 6161 610d ..aaaaaa. C:\asdf> ^^ The portion of the byte that stores the 61 is the lower value portion which with LE is stored first. 

La commande dd (une commande * nix que je cours à partir de cygwin dans Windows) peut la commuter

 C:\asdf>xxd -p aa fffe6100610061006161610d C:\asdf>file aa aa; Little-endian UTF-16 Unicode text, with no line terminators C:\asdf>dd if=aa conv=swab of=a.a2 0+1 records in 0+1 records out 12 bytes (12 B) copied, 0 seconds, Infinity B/s C:\asdf>type a.a2 a aa aaa C:\asdf>xxd -p a.a2 feff00610061006161610d61 C:\asdf>file a.a2 a.a2; Big-endian UTF-16 Unicode text, with no line terminators C:\asdf> 

Et le bloc-notes peut lui-même enregistrer en UTF-16 Big Endian ou UTF-16 Little Endian ou UTF-8

Si vous êtes une personne technique ou même simplement un utilisateur de bloc-notes, vous n'êtes pas lié à un codage en raison de votre système d'exploitation!

Je suppose que UTF-8 a plus de sens que UTF-16, UTF-16 utiliserait 16 bits même pour les caractères qui ne devraient nécessiter que 8 bits. Cependant, gardez à l'esprit que charmap affiche le code UTF-16.

Sublime (Un éditeur de texte Windows) enregistre unicode comme UTF-8 par défaut.

J'utilise Windows et parfois unicode, et j'utilise l'UTF-8 principalement.

Et comme Windows est techniquement flexible, linux est au moins aussi techniquement flexible!