[JAVA][Eclipse] Problema con la codifica e la portabilità dei sorgenti su altri OS

[fbcyborg]

Da qualche tempo ho un problema con la codifica in Eclipse.

Sto lavorando in coppia con un collega che usa MacOS, ed io ora purtroppo sono costretto a lavorare su Windows.
Il problema è che ogni volta che passo a lui tutti i sorgenti che sono sul mio PC, quando apre il progetto con Eclipse, tutte le lettere accentate dell'interfaccia grafica spariscono e vengono sostituite da simboli "aramaici". Questo problema ce l'ho anche se carico il progetto sviluppato su windows, su un pc che ha Linux.

Ho visto che la codifica impostata su Eclipse è: "Inherited from container (Cp1252)" e che se ne possono impostare altre.
Prima di fare qualche casino, volevo chiedere a voi. Ho paura che cambiando la codifica quì su Windows mi si incasinino tutte le lettere accentate che sono state scritte nel progetto (sono molte forse!!).
Pensavo di cambiare la codifica nelle proprietà del progetto, con un'altra che sia "compatibile" sia con quella che usa (in realtà non so quale sia, dovrei approfondire) il mio collega, sia con quella usata da Eclipse su Linux.

Su Linux leggo "Inherited from container (ANSI_X3.4-1968)". Sicuramente andrà cambiata pure quella.

Consigli?

Grazie!!

EDIT: Nel frattempo mi sono deciso a fare alcune prove. Pare che con la codifica ISO-8859-1 le cose vadano meglio.

[tomsmile]

Io ho lo stesso problema... hai poi risolto? :(

[fbcyborg]

Appunto come avevo scritto, impostando ISO-8859-1 non ho avuto problemi.

[pabloski]

probabilmente il software sta usando la codifica windows-1252 ( ovviamente ms non può mai usare qualcosa di standard, altrimenti si farebbe troppo male )

però mi pare strano che eclipse non sfrutti unicode visto che comunque nel sistema c'è

viceversa macos e linux usano utf-8 di default e ovviamente windows-1252 non è manco mappabile direttamente perchè è una 8859-1 modificata

comunque se in Eclipse vai in Project->Properties->Resource puoi settare l'encoding desiderato ( usa utf-8 )

[WarDuck]

probabilmente il software sta usando la codifica windows-1252 ( ovviamente ms non può mai usare qualcosa di standard, altrimenti si farebbe troppo male )

però mi pare strano che eclipse non sfrutti unicode visto che comunque nel sistema c'è

viceversa macos e linux usano utf-8 di default e ovviamente windows-1252 non è manco mappabile direttamente perchè è una 8859-1 modificata

comunque se in Eclipse vai in Project->Properties->Resource puoi settare l'encoding desiderato ( usa utf-8 )

Il problema non è il SO, ma l'applicazione, come ha detto anche l'utente.

Tra l'altro Linux e derivati usano per il fine riga una sequenza che non era contemplata nello standard.

[pabloski]

Il problema non è il SO, ma l'applicazione, come ha detto anche l'utente.

si ok ma se di default avessero usato iso-8859-1 invece di windows-1252, l'amico non avrebbe avuto quel problema


Tra l'altro Linux e derivati usano per il fine riga una sequenza che non era contemplata nello standard.

capirai, praticamente è usata da 50 anni su tutti i sistemi a partire dal primo unix

[WarDuck]

si ok ma se di default avessero usato iso-8859-1 invece di windows-1252, l'amico non avrebbe avuto quel problema


Mah invece si dato che ha scritto che anche sotto Linux andava cambiato...

Comunque è stato introdotto perché lo standard originario non era granché, in particolare i primi 32 elementi che sono di controllo e non sono stampabili sono inutili e MS ha pensato bene di introdurre delle modifiche proprio a quei 32 caratteri.


capirai, praticamente è usata da 50 anni su tutti i sistemi a partire dal primo unix

Infatti è stato ratificato dopo che UNIX ha cominciato a prendere piede :asd:

Classico esempio di come gli standard sulla carta spesso non catturano le esigenze reali e/o richiedono troppo tempo per essere ratificati (ad esempio TCP/IP vs ISO/OSI).

[banryu79]

Sarebbe bene non usare mai lettere accentate nei sorgenti... e sarebbe buona pratica scrivere tutto in lingua inglese, commenti comprensi.

[fbcyborg]

Sì, specialmente se gli utenti del software in questione sono persone che a fatica sanno accendere il computer, figuriamoci l'inglese.
Ragazzi non dimentichiamoci che un gestionale, per esempio, potrà essere usato anche da gente che di computer ne sa veramente poco, figuriamoci se glielo metti in inglese, le crisi di panico che potrebbero esserci!

È chiaro che ove possibile, l'inglese è preferito.

[banryu79]

Sì, specialmente se gli utenti del software in questione sono persone che a fatica sanno accendere il computer, figuriamoci l'inglese.
Ragazzi non dimentichiamoci che un gestionale, per esempio, potrà essere usato anche da gente che di computer ne sa veramente poco, figuriamoci se glielo metti in inglese, le crisi di panico che potrebbero esserci!

È chiaro che ove possibile, l'inglese è preferito.
Temo di non avre capito... per "utenti del software" cosa intendi?
Gli utenti dell'applicazione o altri programmatori che dovranno mettere le mani sui sorgenti?

[fbcyborg]

Per utenti del software, intendo gli utenti finali.
Ti faccio un esempio. Se ho un gestionale e devo inserire in una tabella, nome e quantità, mostrerò a video una schermata di inserimento dove dovrò fare due JLabel con scritto:
Nome [casella di testo per inserire il nome]
Quantità [casella di testo per inserire la quantità]

Tipicamente queste sono cose che le imposti nel codice sorgente, ad esempio:
jLabel1.setText("Quantità");
Inevitabilmente comparirà nei sorgenti una lettera accentata. Se ho capito bene quello che dici, a parte il discorso dei commenti, dovrei fare:
jLabel1.setText("Quantity");
per evitare il problema con le lettere accentate.

Ricordo che il problema che avevo io inizialmente era che passando da Linux a Windows, o da Mac a Windows, le lettere accentate sulla GUI venivano sostituite con un quadratino, con la conseguenza che le ho dovute riscrivere tutte per più di una volta.

[marco.r]

Classico esempio di come gli standard sulla carta spesso non catturano le esigenze reali e/o richiedono troppo tempo per essere ratificati (ad esempio TCP/IP vs ISO/OSI).

Mi risulta che la scelta del solo line feed operata da Unix sia intervenuta dopo.
La necessita' di dover dare tanto il carattere LF quanto il CR era dovuta al fatto che erano i codici di controllo delle telescriventi (prima dell'avvento del monitor). Quindi un comando per far avanzare di una linea la stampante (Line Feed) , e uno per farla tornare a capo riga (Carriage Return).
Col tempo questa necessita' e' venuta meno, per cui c'e' chi ha scelto per semplicita' o per risparmiare spazio (!) di tenere solo il CR (Mac ad esempio) solo il LF (Unix), piuttosto che tenere entrambi (Windows).

[banryu79]

...
Tipicamente queste sono cose che le imposti nel codice sorgente, ad esempio:
jLabel1.setText("Quantità");
Inevitabilmente comparirà nei sorgenti una lettera accentata. Se ho capito bene quello che dici, a parte il discorso dei commenti, dovrei fare:
jLabel1.setText("Quantity");
per evitare il problema con le lettere accentate.
...

Ah, capito.
Prova a guardarti questo (http://download.oracle.com/javase/tutorial/i18n/resbundle/index.html), quando avrai tempo (i particolare "Backing a ResourceBundle with Properties Files").
Ciao :)

[fbcyborg]

Gli ho dato uno sguardo veloce, è interessante.
Però si fa prima a impostare il charset come ho scritto nel primo post! :p

A proposito, ma la documentazione che hai segnalato, se non ho capito male, si riferisce più che altro ai comandi "comuni", appunto come dice l'esempio il bottone "Cancel"/"Abbrechen". Cioè, impostando il locale che vuoi, dovrebbe venir tradotto automaticamente. Forse ciò non è proprio facilmente applicabile al caso di esempio che ho fatto io. Magari mi è sfuggito qualcosa, però te l'ho detto, l'ho letto velocemente.

[DvL^Nemo]

Con eclipse c'e' la possibilita' di "esternalizzare" le stringhe dal codice, fa tutto lui, genera classi e file properties, se non erro lo aggancia al locale e usa lo standard UTF-8 ( se non erro )