Conversione file con codifica caratteri "custom"

di il
32 risposte

Conversione file con codifica caratteri "custom"

Ciao a tutti,
ho un problema nel convertire dei file che provengono da un macchinario industriale datato 1985 che ha come periferica di output un floppy disk.
L'idea sarebbe di montare un emulatore floppy-->usb così da non dover ricorrere al floppy (tiro un cavo e non devo più fare il giro della macchina due volte per caricare 50kB ).
Il problema sta nel convertire tali file in un formato leggibile da windows (ma andrebbe bene anche linux ).
Apparentemente il sistema operativo della macchina è DOS, in pratica il charSet non sembra essere standard, ho provato decine di software senza risultati.
Dispongo di un software proprietario che però per qualche INSPIEGABILE motivo può convertire solo da/per il floppy disk.
Ho provato ad ingannarlo usando una usb formattata come un floppy (1,44MB) e montata sulla lettera A: col risultato che funziona per passare da codificato a windows ma NON viceversa.

Avete qualche idea?

32 Risposte

  • Re: Conversione file con codifica caratteri "custom"

    Parti da un file originario e dal corrispondente convertito e, con un editor binario, cerca si comprendere quali e dove sono i dati da convertire e scrivi un codice che lo faccia (magari in C). Comprese le regole, il programma è banale (ricorda che questo forum si occupa di programmazione)
  • Re: Conversione file con codifica caratteri "custom"

    Ciao Oregon, grazie per l'interessamento.

    Certamente sto chiedendo idee a livello di programmazione, io ho studiato tutt'altro ma da autodidatta mi sono letto un libricino sul C ma senza fare molta pratica (quindi conoscenze nulle!) mentre ho provato a scrivere qualcosina in C# e java.

    Avevo già pensato di scrivere un software che legge un carattere alla volta dai due file per poi confrontarli e quindi ricostruire il charset, ma non ho un file contenente TUTTI i possibili caratteri.

    Io pensavo a qualcosa tipo il reverse engineering del software, apparentemente scritto in C o C++, o in alternativa qualche altra tecnica a me sconosciuta per estrapolare il charset! Si può fare? Sarà mica illegale?
  • Re: Conversione file con codifica caratteri "custom"

    Usa il linguaggio che conosci. Però la conversione potrebbe non essere solo un problema du set di caratteri ma di codifica binaria dei valori numerici e leggendo carattere per carattere non risolvi.
    Ripeto devi controllare il file originale e uno convertitor per capire.
  • Re: Conversione file con codifica caratteri "custom"

    Non capisco cosa intendi, dici di confrontare i file "manualmente" ?

    Vediamo se leggendo due righe tu ci capisci qualcosa, a me non tornano neanche i fine riga
    File originale:
    • 
      ‡¥N0 M00 (ÒUÌÌÉ D²35 Ì5·´¬5©
      MN± ÏZ5 
      ØN² Ô± M6 (ÔÏNDÏ Ò¸©
      PN3 M3 M´± G96 S±00 Æ0¬´5 
      ½N´ G00 Ø²50  Z¸  
      ·
    File convertito:
    • %N0 M00 (RULLI D235 L574,5)
      N1 OZ5
      N2 T1 M6 (TONDO R8)
      N3 M3 M41 G96 S100 F0,45
      N4 G00 X250 Z8

    Ho provato a buttare giù due righe in java, usando un input Stream che legge il file carattere per carattere usando diversi encoding.

    Ecco il codice:
    private void readCharByChar(String name,String enc,int num) throws FileNotFoundException, IOException, UnsupportedCharsetException {
            Charset encoding = Charset.forName(enc);
            File file = new File(name);
            InputStream input = new FileInputStream(file);
            Reader reader = new InputStreamReader(input,encoding);
            int r;
            while((r=reader.read()) != -1) {
                char c = (char)r;
                if(num==1) {
                    jTextArea1.append("\n"+c);
                }
                else if(num==2) {
                    jTextArea2.append("\n"+c);
                }
            }
        }
    Questi sono i diversi encoding provati per leggere il file originale:
    • String[] modElements = new String[] {"US-ASCII",
      "UTF-8","UTF-16","UTF-16BE","UTF-16LE","UTF-32",
      "IBM-00858","IBM437","IMB775","IBM-850","IBM852","IBM855","IBM857","IBM862",
      "ISO-8859-1","ISO-8859-2","ISO-8859-4","ISO-8859-5","ISO-8859-7","ISO-8859-9","ISO-8859-13","ISO-8859-15",
      "windows-1250","windows-1252",
      "IBM280","IBM-870",
      "ISO-8859-3","ISO-8859-6","ISO-8859-8"};
    L'output è quasi sempre diverso ma mai leggibile...
  • Re: Conversione file con codifica caratteri "custom"

    Sicuro che giri in MS-DOS? Non è che sia un CP/M?
    dico CPM perché a metà degl'anni 80 era molto diffuso e UN perché già allora vi erano diversi CP/M e non tutti compatibili tra loro.
    A parte che ricordo che i primi CNC erano in CPM, ricordo anche che allora i dischi avevano densità diverse dagl'ultimi, non è che gli 'errori' siano dovuti a quello? Dischi e lettore sono compatibili?
    NB il CNC non l'hanno sicuramente progettato lo stesso anno di uscita della macchina, in teoria c'era MS-DOS 2.11 ma potrebbe esservi stato anche quello precedente 1.xx, che era diverso dalle successive che potevano andare bene per le macchine IBM.

    a proposito di IBM... provato con EBCDIC a otto bit o una delle sue varianti? non cercare roba recente, stai parlando del neolitico informatico, l'età della pietra dei computer.

    LBNL il CNC che marca è? magari facendo qualche indagine ci salti fuori, altrimenti i programmi fai prima a rifarli piuttosto che saltarci fuori... sempre col beneficio del dubbio.
  • Re: Conversione file con codifica caratteri "custom"

    max265 ha scritto:


    File originale:
    ‡¥N0 M00 (ÒUÌÌÉ D²35 Ì5·´¬5©
    File convertito:
    %N0 M00 (RULLI D235 L574,5)
    Non mi sembrano questioni di "charset" (set di caratteri). Mi sembra più che altro una forma (stupida) di alterazione dei bit.

    ÒUÌÌÉ byte: D2 55 CC CC C9

    RULLI byte: 52 55 4C 4C 49

    Alcuni byte hanno il bit "alto" a 1 .. altri byte ce l'hanno a 0. Difatti tra 0xD2 e 0x52 l'unica differenza è il bit 7.

    D2 -> 11010010
    52 -> 01010010

    Ora:
    a) dietro il settaggio a 0/1 del bit alto c'è una qualche "logica" (da capire)
    b) il bit alto è stato impostato su alcuni byte a 1 in modo "casuale"
    c) il bit alto è diventato 1 a causa di danneggiamento dei dati

    quale sia ... non ho idea.

    Ma se forzi a 0 il bit alto dovresti credo riottenere il risultato leggibile.
    Prova e facci sapere.
  • Re: Conversione file con codifica caratteri "custom"

    Eh già, la preistoria dell'informatica, per un appassionato è frustrante doverci lavorare
    Sarà per quello che siamo tra i professionisti più bravi al mondo

    Nel software proprietario la title bar dice converti file dos --> pc, ma non sono sicuro che il cn giri su dos, non ho un display (se non limitato al puro cnc e con funzioni "avanzate" limitate comunque all'elettronica della macchina e non al cn).

    Abbiamo altre macchine però, una taragata 1990 e sono sicuro giri su dos, mentre quelle più recenti girano su windows, quindi credo che la più vecchia comunque sia una piattaforma x86.

    Ulteriore indizio il fatto che il floppy debba essere formattato da windows (1.44MB) senza particolari accorgimenti, il file poi si apre tranquillamente con il notepad, salvo ritrovarsi i caratteri come vedi sopra.
  • Re: Conversione file con codifica caratteri "custom"

    andbin ha scritto:


    Non mi sembrano questioni di "charset" (set di caratteri). Mi sembra più che altro una forma (stupida) di alterazione dei bit.

    ÒUÌÌÉ byte: D2 55 CC CC C9

    RULLI byte: 52 55 4C 4C 49

    Alcuni byte hanno il bit "alto" a 1 .. altri byte ce l'hanno a 0. Difatti tra 0xD2 e 0x52 l'unica differenza è il bit 7.

    D2 -> 11010010
    52 -> 01010010

    Ora:
    a) dietro il settaggio a 0/1 del bit alto c'è una qualche "logica" (da capire)
    b) il bit alto è stato impostato su alcuni byte a 1 in modo "casuale"
    c) il bit alto è diventato 1 a causa di danneggiamento dei dati

    quale sia ... non ho idea.

    Ma se forzi a 0 il bit altro dovresti credo riottenere il risultato leggibile.
    Prova e facci sapere.
    OK, un momento, che lingua stai parlando?

    Scherzi a parte, ora vedo di capire (leggasi aprire il manuale ) come posso fare, e vi faccio sapere!
  • Re: Conversione file con codifica caratteri "custom"

    max265 ha scritto:


    OK, un momento, che lingua stai parlando?
    La "lingua" dei sistemi di numerazione (in particolare esadecimale, binario)

    (che sono la BASE per gli elettronici/informatici)
  • Re: Conversione file con codifica caratteri "custom"

    andbin ha scritto:


    max265 ha scritto:


    OK, un momento, che lingua stai parlando?
    La "lingua" dei sistemi di numerazione (in particolare esadecimale, binario)

    (che sono la BASE per gli elettronici/informatici)

    Si certo scherzavo, devo comunque capire come arrivare al binario, se è una cosa fattibile in java (con cui ho più dimestichezza) o se sia meglio farlo magari con C...
  • Re: Conversione file con codifica caratteri "custom"

    max265 ha scritto:


    devo comunque capire come arrivare al binario, se è una cosa fattibile in java (con cui ho più dimestichezza) o se sia meglio farlo magari con C...
    Non devi "arrivare" ad alcun binario. Un qualunque valore numerico in Java (come in C, C#, ecc..) -è- in binario nella memoria.

    Devi semplicemente usare una operazione di AND per "mascherare" il valore in modo che i bit 0...6 restino tali come sono mentre il bit 7 sia messo a 0.
    E se non sai cosa questo voglia dire ... la soluzione c'è: si chiama studio delle basi.
  • Re: Conversione file con codifica caratteri "custom"

    Si questo è chiaro, ed è chiaro anche che qualsiasi cosa scrivo diventerà codice binario, ma evidentemente mi sono fatto un'idea sbagliata di come raggiungere l'obiettivo.

    Ho pensato di convertire il char in una stringa che rappresenta il binario, quindi modificare la stringa e riconvertire a int e poi char, ma alla prova dei fatti è evidente che sono fuori strada.

    Qualche indizio please?
  • Re: Conversione file con codifica caratteri "custom"

    max265 ha scritto:


    Si questo è chiaro, ed è chiaro anche che qualsiasi cosa scrivo diventerà codice binario, ma evidentemente mi sono fatto un'idea sbagliata di come raggiungere l'obiettivo.

    Ho pensato di convertire il char in una stringa che rappresenta il binario, quindi modificare la stringa e riconvertire a int e poi char, ma alla prova dei fatti è evidente che sono fuori strada.

    Qualche indizio please?
    Operatori bitwise.
  • Re: Conversione file con codifica caratteri "custom"

    Un paio di considerazioni:
    1) e' abbastanza improbabile che l'errore, se c'e' errore, avvenga SEMPRE sul bit alto.
    2) piu' probabile, il bit e' settato in modo da avere il numero di bit a 1 in numeri PARI: controllo di errore
    3) in ogni caso, il bit alto non serve a nulla, o quasi. SUPPONENDO che il testo sia in ASCII, basta estarre SOLO i primi 7 bit e impostare, o settare, il bit alto a 0.

    Se funziona, si e' gia' a buon punto

    Il giochino del char->int->char piu' o meno funziona. Il trucco e' questo (e' pseudocodice! NON codice in uno specifico linguaggio di programmazione)
    
    string s = ...
    char c;
    for i=0 to length(s)-1:
        c = s[i];
        c = c & 0x7F;
        s[i] = c;
    end
    
    L'operatore & e' l'operatore che applica l'AND binario a tutti i bit di c con la maschera fatta dal numebro binario "01111111", cio'e uno 0 e 7 bit a 1 (in esadecimante - base 16 - "7F").

    ---

    Ho visto ora il codice Java. Puoi tentare questa strada:
    
    ...
    char c = (char)r & 0x7F;
    ...
    
    In alternatic, c'e' un'EVIDENTE relazione 1:1 (univoca) tra i caratteri strani e la corrispondente versione in chiaro.
    Quello che si puo' fare e' implementare, a mano, la mappa di conversione.
    Al massimo sono 128 caratteri, in realta' saranno MOLTI meno di 70 (10 per le cifre, 26 per le minuscole, 26 per le maiuscole e qualche altro carattere come le parentesi, il percento, ...). Se poi non ci sono nemmeno le minuscole, la mappa si riduce ad una 40-na di caratteri. Probabilmente meno di 20

    Per la lettura del file, MEGLIO LEGGERLO IN BINARIO, SENZA le conversioni fatte dall'encoding: si rischia che l'ENCODING faccia piu' danni che altro.
Devi accedere o registrarti per scrivere nel forum
32 risposte