Différences entre les fichiers Unix et Windows
Suis-je raison de supposer que la seule différence entre les "fichiers de windows" et "fichiers unix" est le saut de ligne?
Nous avons un système qui a été déplacé à partir d'un ordinateur windows vers une machine unix et que vous rencontrez des problèmes avec le format.
J'ai besoin d'automatiser la traduction entre unix/windows avant que les fichiers livrés pour le système dans notre "transportsystem". Je vais probablement besoin de quelque chose pour déterminer le format actuel et quelque chose pour le transformer en un autre format.
Si c'est juste le retour à la ligne c'est la grande différence, alors j'envisage seulement de lire les fichiers avec le java.io. Autant que je sache, ils sont capables de gérer à la fois avec readLine. Et puis il suffit d'écrire chaque ligne de retour avec
while (line = readline)
print(line + NewlineInOtherFormat)
....Résumé:
Ce n'est qu'une différence dans les fichiers texte, où UNIX utilise un seul saut de Ligne (LF) pour signifier une nouvelle ligne, Windows utilise un Retour Chariot/saut de Ligne (CRLF) et Mac utilise juste un CR.
à qui Cebjyre commente:
OS X utilise FL, le même que UNIX, MacOS 9 et ci-après n'ont CR si
Il pourrait également être une différence de codage de caractères pour les caractères nationaux. Il n'y a pas de "unix-encoding" mais beaucoup linux-variantes d'utilisation de l'UTF-8 comme encodage par défaut. Mac OS (qui est aussi un unix) utilise son propre codage (macroman). Je ne suis pas sûr, qu'en windows par défaut l'encodage.
En plus de la nouvelle ligne de différences, la marque d'ordre d'octet peut causer des problèmes si les fichiers sont traités comme Unicode sur Windows.
Cependant, un autre ensemble de problèmes que vous pouvez rencontrer peuvent être liées à des single/multi-octets encodages de caractères. Si vous voyez étrange, inattendu caractères (pas de fin de ligne), puis cela pourrait être la raison. Surtout si vous voyez des carrés, des points d'interrogation à l'envers à la question des marques, des caractères supplémentaires ou imprévus des caractères accentués.
sous unix, les fichiers qui commencent par un . sont cachés. Sur windows, c'est un système de fichiers drapeau que vous n'avez probablement pas facile d'accès. Cela peut résultat dans des fichiers qui sont censé être caché désormais visible sur les machines client.
autorisations d'un Fichier de varier entre les deux. Vous trouverez probablement, lorsque vous copiez des fichiers sur un système unix, les fichiers appartenant à l'utilisateur qui a fait la copie et ont des droits limités. Vous aurez besoin d'utiliser chown/chmod s'assurer que les utilisateurs ont accès à eux.
Il existe des outils pour aider avec le problème:
Si vous êtes simplement intéressé par le contenu des fichiers de texte, alors oui les fins de ligne sont différents. Jetez un oeil à quelque chose comme dos2unix, il peut être de l'aide ici.
Comme pauldoo suggère, des outils comme dos2unix peut être très utile. Notez que ceux-ci peuvent être sur votre système linux/unix comme fromdos ou tofrodos, ou peut-être même que l'objectif général de boîte à outils recode.
De l'aide pour java
Lors de l'écriture de fichiers ou de lecture de fichiers (que vous êtes en contrôle de l'), il vaut souvent la peine de spécifier l'encodage à utiliser, comme la plupart des méthodes de Java permettent. Cependant, aussi veiller à ce que les paramètres régionaux du système correspond peut économiser beaucoup de douleur
source d'informationauteur svrist
Vous devez vous connecter pour publier un commentaire.
Ce n'est qu'une différence dans les fichiers texte, où UNIX utilise un seul saut de Ligne (LF) pour signifier une nouvelle ligne, Windows utilise un Retour Chariot/saut de Ligne (CRLF) et Mac utilise juste un CR.
Fichiers binaires il devrait y avoir aucune différence (c'est à dire un JPEG sur une machine windows sera octet le même que le même format JPEG sur une machine unix.)
Il pourrait également être une différence de codage de caractères pour les caractères nationaux. Il n'y a pas de "unix-encoding" mais beaucoup linux-variantes d'utilisation de l'UTF-8 comme encodage par défaut. Mac OS (qui est aussi un unix) utilise son propre codage (macroman). Je ne suis pas sûr, ce que windows encodage par défaut est.
Mais cela pourrait être une autre source de problèmes (à part les différents retours à la ligne ().
Quels sont vos problèmes? Le saut de ligne-liées à des problèmes peuvent être facilement corrigées avec les programmes dos2unix ou unix2dos sur l'unix de la machine
Si vous êtes simplement intéressé par le contenu des fichiers de texte, alors oui les fins de ligne sont différents. Jetez un oeil à quelque chose comme dos2unixil peut être utile ici.
(Bien sûr, il ya beaucoup d'autres choses qui font unix et windows fichiers différents, mais je ne pense pas que vous êtes intéressé à ceux d'autres différences droit maintenant.)
En plus de la réponse donnée, vous pouvez trouver des problèmes avec les différents systèmes de fichiers:
Sur unix, les fichiers qui commencent par un . sont cachés. Sur windows, c'est un système de fichiers drapeau que vous n'avez probablement pas facile d'accès. Cela peut résultat dans des fichiers qui sont censé être caché désormais visible sur les machines client.
Autorisations d'un fichier de varier entre les deux. Vous trouverez probablement, lorsque vous copiez des fichiers sur un système unix, les fichiers appartenant à l'utilisateur qui a fait la copie et ont des droits limités. Vous aurez besoin d'utiliser chown/chmod s'assurer que les utilisateurs y ont accès.
En plus de la nouvelle ligne de différences, la marque d'ordre d'octet peut causer des problèmes si les fichiers sont traités comme Unicode sur Windows.
Comme pauldoo suggère, des outils comme dos2unix peut être très utile. Notez que ceux-ci peuvent être sur votre système linux/unix comme fromdos ou tofrodosou peut-être même que l'objectif général de boîte à outils recode.
Cependant, un autre ensemble de problèmes que vous pouvez rencontrer peuvent être liées à des single/multi-octets encodages de caractères. Si vous voyez étrange, inattendu caractères (pas de fin de ligne), puis cela pourrait être la raison. Surtout si vous voyez des carrés, des points d'interrogation à l'envers à la question des marques, des caractères supplémentaires ou imprévus des caractères accentués.
L'exécution de la commande locale sur votre *nix box va vous dire ce que les paramètres régionaux du système. Si c'est différent de l'encodage utilisé dans le texte des fichiers qui ont été transférés de la machine windows, ceci peut parfois causer des problèmes, en fonction de l'utilisation de ces fichiers. Vous pouvez utiliser le très puissant recode de commande pour convertir entre les différents jeux de caractères ainsi que toutes les questions de fin de ligne. recode -l vous montrera tous les formats et les codages que l'outil peut convertir entre. Il est susceptible d'être une TRÈS longue liste.
Lors de l'écriture de fichiers ou de lecture de fichiers (que vous êtes en contrôle de l'), il vaut souvent la peine de spécifier l'encodage à utiliser, comme la plupart des méthodes de Java permettent. Cependant, aussi veiller à ce que les paramètres régionaux du système correspond peut économiser beaucoup de douleur.