2013-07-07 10 views
15

disclaimer: Per Git, intendo "I" incasinato.Git ha incasinato i miei file, mostrando caratteri cinesi in alcuni posti

Earlier, ho voluto git-gui di mostrarmi la diff per il quale pensa sono file binari.

così ho fatto alcuni cambiamenti alla mia .\.gitattributes

*.ini  text 
*.inc  text 

But it didn't work.Then I made some changes alla mia .\.git\info\attributes

*.ini  text 
*.inc  text 
*.inc crlf diff 
*.ini crlf diff 

e ha funzionato.

Ma ora, quando torno a precedente commette scombina ...

chinese characters questo è come dovrebbe aspetto: english characters

non succede in tutti i file. EDIT: Succede solo nei file che contengono caratteri speciali.

Q: È il problema con il commit stesso o solo alcune impostazioni?
Q: Posso recuperare?

+0

si può spiegare cosa si sta mostrando negli screenshot di cui sopra? Il problema è che il contenuto del file stesso è corrotto o il diff? – djs

+0

@djs Il contenuto del file è incasinato. Quelli sono gli screenshot del file attuale (incasinato dopo il "check out" dal repository VS normale). Si può vedere che è incasinato (rispetto al normale file (proprio sotto di esso)). – laggingreflex

risposta

23

I file ini vengono salvati in UTF-16LE, la codifica che Windows descrive erroneamente come "Unicode".

Gli strumenti di diffusione predefiniti di Git non funzionano su UTF-16, perché non è una codifica ASCII compatibile. Questo è il motivo per cui git ha rilevato i file come binari in origine.

La conversione di nuova riga LF/CRLF vede ogni byte 0x0A come una nuova riga e lo sostituisce con 0x0D-0x0A. Ma, in un file UTF-16LE, un newline è effettivamente segnalato da 0x0A-0x00 e sostituendolo con 0x0D-0x0A-0x00 significa che hai un numero dispari di byte, quindi l'allineamento di ogni unità di codice a due byte nella riga successiva è fuori sincrono. Di conseguenza ogni altra linea viene mutilata.

Le opzioni disponibili sono:

  1. annullare la modifica dell'attributo e lasciare Git gestire i file in formato binario (perdendo il beneficio di diff).

  2. Salvare i file in una codifica compatibile ASCII. Sembra che il tuo contenuto non abbia effettivamente caratteri non ASCII, quindi spero che non sia un problema? Normalmente vorrai salvare tutti i tuoi file come UTF-8 - questo è compatibile ASCII ma consente anche l'uso di tutti i caratteri Unicode. Ma questo dipende dal fatto che Rainmeter supporti la lettura di file INI codificati in quel modo (probabilmente no).

  3. Configurare git su use a different diff tool, anche se questo renderà più complicato per gli altri lavorare con il repository.

+0

controlla se utf8 funziona e se sì, prova a farlo. – mnagel

+0

Bella risposta. Sembra che Git potrebbe probabilmente verificare che una distinta base sia più intelligente in merito. Ho capito che @laggingreflex stava vedendo il danneggiamento dovuto alla conversione di nuova riga, ma il problema di UTF-16 non mi era venuto in mente. Ho trovato alcune discussioni su questo problema per [libgit2] (https://github.com/libgit2/libgit2/issues/1009), ma nessuna soluzione. – djs

6

Ho avuto un problema simile di recente.Abbiamo una .gitattributes di file a livello di progetto a livello radice, che comprende le linee: -

* text=auto 
*.sql  text 

Uno della nostra squadra è stata la scrittura di codice SQL utilizzando SQL Management Studio, che, a sua insaputa, è stato il salvataggio dei file come UTF -16. È stato in grado di effettuare il check-in del codice a Git senza problemi, ma al momento del check-out il codice è stato tradotto in caratteri cinesi come descritto da questo post.

Un dump esadecimale dei file in questione ha confermato che il problema era effettivamente la conversione da 0x000A a 0x000A0D.

Per noi la soluzione è stato quello di convertire i file ASCII utilizzando il seguente: -

  1. Eliminare il file incriminato dalla directory di lavoro
  2. creare un file temporaneo .gitattributes nella directory locale per forzare git per estrarre il file senza eseguire la conversione di fine riga. per esempio. includere la riga *.sql binary

  3. Controllare i file da Git. Dovresti vedere che i file non sono stati tradotti e non hanno caratteri cinesi.

  4. Convertire il file in ASCII. Abbiamo usato Notepad ++ per questo, ma è anche possibile usare iconv, che è installato come parte di Git For Windows. Penso che UTF-8 sarebbe anche un'opzione se il file contiene caratteri non ASCII - ma questo non era necessario per i nostri scopi.
  5. check-nella versione ASCII del file
  6. Eliminare il .gitattributes file locale
-1

Nel mio caso usando ho risolto utilizzando il Blocco note ++ e modificare il file di codifica da "UTF-8" a "UTF- 8 BOM ". I personaggi cinesi sono diventati di nuovo i personaggi originali.

0

Per aggiungere una buona spiegazione a @bobince. Una soluzione a questo problema (eccetto i file con caratteri speciali) è convertire tutto in utf-8. Ho risolto questo problema eseguendo uno script python in Notepad ++ su tutti i file in una directory (da un computer che non aveva i file incasinati).

Ho trovato la sceneggiatura originale here

Una copia del blocco note ++ script python:

import os; 
import sys; 
filePathSrc="C:\\Temp\\UTF8" 
for root, dirs, files in os.walk(filePathSrc): 
    for fn in files: 
     if fn[-4:] != '.jar' and fn[-5:] != '.ear' and fn[-4:] != '.gif' and fn[-4:] != '.jpg' and fn[-5:] != '.jpeg' and fn[-4:] != '.xls' and fn[-4:] != '.GIF' and fn[-4:] != '.JPG' and fn[-5:] != '.JPEG' and fn[-4:] != '.XLS' and fn[-4:] != '.PNG' and fn[-4:] != '.png' and fn[-4:] != '.cab' and fn[-4:] != '.CAB' and fn[-4:] != '.ico': 
     notepad.open(root + "\\" + fn) 
     console.write(root + "\\" + fn + "\r\n") 
     notepad.runMenuCommand("Encoding", "Convert to UTF-8 without BOM") 
     notepad.save() 
     notepad.close() 
Problemi correlati