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

16

J'utilise uniquement le jeu de 128 caractères défini dans la norme ANSI d'origine.

Mais dans l'ensemble, comment les fichiers sont-ils implémentés différemment?

Je ne suis pas concerné par l'affichage, c'est-à-dire si un onglet est affiché avec 6 ou 8 caractères mais la représentation interne réelle en mémoire

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

linux windows ascii Hennes
la source
Je pense que la marque d'ordre des octets tue mon #! (Première ligne) dans mes fichiers php que j'ai transférés de Windows à Linux. L'ensemble du fichier fonctionne mais il ne peut pas trouver l'interprète comme il se doit. Si je m'assure spécifiquement d'encoder en ANSI en sélectionnant la méthode d'encodage dans le bloc-notes, est-ce vrai ASCII ou Windows fait-il autre chose
Voyez si vous avez bomstrip sur votre box Gnu / Linux. Il fait partie de Debian (et au moins quelques autres), mais peut nécessiter une installation. Il est nécessaire car Microsoft ajoute par erreur une nomenclature au début des fichiers utf-8.
ctrl-alt-delor

Réponses:

17

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

"Le minimum absolu que tous les développeurs de logiciels doivent absolument et positivement connaître concernant l'Unicode et les jeux de caractères (pas d'excuses!)"

Ignacio Vazquez-Abrams
la source
Windows gaspille un octet?
1
Si vous n'utilisez rien en dehors de Latin-1, oui.
Ignacio Vazquez-Abrams
Ils sont dans l'article auquel j'ai lié.
Ignacio Vazquez-Abrams
1
A lancé une recherche pour UTF-16LE mais ne l'a pas trouvé dans l'article.
1
La plupart. Vous devez également compter la nomenclature si elle est présente.
Ignacio Vazquez-Abrams
11

Sauts de ligne

Windows utilise les fins de ligne CRLF ( \r\n, 0D 0A) tandis qu'Unix utilise uniquement LF ( \n, 0A).

Encodage de caractère

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

Windows, cependant, n'a pas de support natif pour UTF-8. Il fonctionne en interne en UTF-16 et suppose que les charchaînes basées sont dans une page de code héritée . Heureusement, le Bloc-notes est capable de lire des fichiers UTF-8; malheureusement, l'encodage "ANSI" est toujours la valeur par défaut.

Caractères spéciaux problématiques

U + 001A SUBSTITUT

Windows (rarement) utilise Ctrl+ Zcomme caractère de fin de fichier. Par exemple, si vous typeun fichier à l'invite de commande, il sera tronqué au premier 1Aoctet.

Sous Unix, Ctrl+ Zn'a rien de spécial.

U + FEFF ZERO AVEC ESPACE NO-BREAK (marque d'ordre des octets)

Sous Windows, les fichiers UTF-8 commencent souvent par une "marque d'ordre des octets" EF BB BFpour les distinguer des fichiers ANSI.

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

user46971
la source
1
Ctrl-Z fonctionne sur Windows, tout comme Ctrl-D (ou tout autre caractère lié à EOF stty) sous Linux: le pilote de la console le traduit en fin de fichier. Le caractère littéral n'apparaît pas dans le flux d'entrée; cela fait juste que read () retourne 0.
psusi
Je pense que la marque d'ordre des octets tue mon #! (Première ligne) dans mes fichiers php que j'ai transférés de Windows à Linux. L'ensemble du fichier fonctionne mais il ne peut pas trouver l'interprète comme il se doit. Si je m'assure spécifiquement d'encoder en ANSI en sélectionnant la méthode d'encodage dans le bloc-notes, est-ce vrai ASCII ou Windows fait-il autre chose?
1
Il convient de mentionner que le pseudo-terme «page de codes ANSI», bien qu'il apparaisse toujours dans des programmes tels que le Bloc-notes, est tout à fait inapproprié, et Microsoft l'a admis il y a longtemps. Voir en.wikipedia.org/wiki/Windows_code_page pour plus de détails.
Incnis Mrsi
utf-8 n'a pas de nomenclature, mais MS-Windows en insère une. Ce qui n'est pas vrai utf-8. L'une des règles d'utf-8 est que tout fichier pouvant être représenté en ascii est bit à bit identique dans utf-8. Vous pouvez également commencer à lire utf-8 à tout moment dans le flux.
ctrl-alt-delor
3

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 gèrent cela automatiquement, les éditeurs de programmeurs Windows peuvent gérer cela, pas les éditeurs de texte général (bloc-notes de base).

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

N'oubliez pas que MacOS X est désormais sous UNIX, il utilise donc les fins de ligne UNIX. Bien qu'avant OS X (MacOS 9 et inférieur), il avait sa propre fin (\ r)

EDIT: dans un autre format CR et LF:

  • \ n est ASCII 0x0A, saut de ligne (LF)
  • \ r est ASCII 0x0D, retour chariot (CR)
Rich Homolka
la source
Où sont \ r \ n et \ n dans le jeu de caractères ASCII? en.wikipedia.org/wiki/File:ASCII_Code_Chart.svg
2
@Chris \ n est ASCII 0x0A, saut de ligne. \ r est ASCII 0x0D, retour chariot
Rich Homolka
@Rich Et l'EOF? Est-ce un caractère ANSI?
2
@barlop, le terminal traduit la séquence de touches (c'est normalement ctrl-d sur les systèmes Unix) en EOF, sauf si cette touche de contrôle a été désactivée. L'application lit un EOF plutôt que la touche réelle que vous appuyez. C'est-à-dire, read()retourne zéro octet au lieu de n'importe quel caractère spécifique.
psusi
1
@barlop, c'est ce que j'ai dit: il ne retourne aucun caractère. read () renvoie le nombre d'octets qu'il a stockés dans votre tampon. Sur EOF, il vous donne simplement zéro octet. C'est le signal que vous avez atteint la fin du fichier et qu'il n'y a plus rien à lire.
psusi
1

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

Même Windows notepad.exe a des options répertoriées - (je mettrai entre crochets ce que le bloc-notes signifie par cela) ANSI (pas unicode), Unicode (le 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 mettons cela de côté.

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

Et le bloc-notes mis à part, l'UTF-8 peut être avec ou sans nomenclature.

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

Il n'y a pas de règle unique concernant le codage Unicode utilisé par un système d'exploitation particulier. Ce ne serait pas un système d'exploitation très flexible s'il y en avait un.

Pour vraiment voir les différences, connaissez le logiciel, ce que l'encodage utilise ou offre.

Obtenez Cygwin et xxd, et / ou un éditeur hexadécimal et regardez ce qui se trouve réellement dans le fichier. Utilisez la commande «fichier» pour identifier un fichier. Vous voyez alors ce qu'est l'UTF 16 bits LE. Qu'est-ce que l'UTF 16bit BE? Qu'est-ce que l'UTF-8 (et l'UTF-8 peut être avec ou sans nomenclature).

Parfois, vous pouvez dire au bloc-notes d'enregistrer en tant qu'unicode (par lequel le bloc-notes signifie unicode 16 bits petit endian), et il ne le fera pas. Mais choisissez une police unicode comme arial unicode, et copiez-y certains caractères unicode de charmap et ce sera le cas.

C:\asdf>notepad.exe a.a

C:\asdf>file a.a
a.a; Little-endian UTF-16 Unicode text, with no line terminators

C:\asdf>type a.a
aaa慡ൡ <-- though displayed aaa followed by some boxes in my cmd window
C:\asdf>

C:\asdf>xxd a.a
0000000: fffe 6100 6100 6100 6161 610d            ..a.a.a.aaa.

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 j'exécute à partir de cygwin dans Windows) peut la commuter 

C:\asdf>xxd -p a.a
fffe6100610061006161610d

C:\asdf>file a.a
a.a; Little-endian UTF-16 Unicode text, with no line terminators

C:\asdf>dd if=a.a 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  a a 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 lui-même peut enregistrer au format UTF-16 Big Endian ou UTF-16 Little Endian ou UTF-8

entrez la description de l'image ici

Si vous êtes un technicien ou même un simple utilisateur de bloc-notes, vous n'êtes pas lié à un seul encodage à cause de votre système d'exploitation!

Je suppose que UTF-8 est plus logique que UTF-16, UTF-16 utiliserait 16 bits même pour les caractères qui ne devraient avoir besoin que de 8 bits. Cependant, gardez à l'esprit que charmap affiche le code UTF-16.

Sublime (un éditeur de texte Windows) enregistre unicode au format UTF-8 par défaut.

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

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

barlop
la source
Avez-vous écrit les commandes fileet typedans l'invite Cygwin?
Vesnog
xxdet les typecommandes manquent dans l'installation Cygwin standard je présume. En dehors de cela, je veux reproduire vos résultats.
Vesnog
1
@Vesnog typeest une commande standard intégrée à cmd.exe qui xxdn'est probablement pas installée avec cygwin par défaut, mais lorsque vous installez cygwin ou après, si vous démarrez la configuration de cygwin, vous obtenez une longue liste de commandes que vous pouvez installer pour l'utiliser dans cygwin, et tapez simplement xxd dans la boîte de recherche de configuration de cygwin et il apparaît. xxd est également disponible après l'installation de vim7 afin que vous puissiez également l'obtenir à partir de là.
barlop
1
@Vesnog, vous pouvez exécuter des commandes cygwin à l'intérieur de cygwin ou à l'extérieur de cygwin. Si vous les exécutez en dehors de cygwin, ajoutez c:\cygwin\bin(si c'est là que se trouve le sous-répertoire bin de cygwin), dans votre chemin. De plus, toute commande cmd interne comme 'type' ou 'dir', ou tout fichier exe externe comme calc.exe (calculatrice Windows) peut être exécuté / lancé à partir de cygwin. À peu près tout ce qui peut être exécuté à partir de cygwin peut être exécuté à partir de cmd et vice versa. Si vous souhaitez utiliser bash, utilisez cygwin et si vous rencontrez des problèmes avec des guillemets simples ou doubles, exécutez les commandes cygwin dans cygwin et cmd dans cmd.
barlop
1
@Vesnog xxd peut écrire un fichier aussi, par exemple , echo 61|xxd -r -p>a.aessayez alors type a.a donc vous pouvez réellement obtenir une décharge d'octets avec xxd -p, réarranger ou modifier les octets dans Pais xxd -r -p et obtenir un nouveau fichier différent avec un codage différent ou différentes données basées sur les anciennes données. La commande "file" détermine l'encodage, sur la base des octets.
barlop
-1

Linux utilise UTF-8, et chaque caractère est compris entre 1 et 6 octets, pas entre 1 et 4 octets.

U00000000 - U0000007F: 0xxxxxxx
U00000080 - U000007FF: 110xxxxx 10xxxxxx
U00000800 - U0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U00010000 - U001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U00200000 - U03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U04000000 - U7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
it_is_a_literature
la source
Cela était déjà indiqué dans une réponse soumise en 2011.
Ramhound