Poslední příspěvky81
Software / Re:Lze zvolit puvodni znakovou sadu pri rozbalovani, kterou byl stary archiv balen?
« Poslední příspěvek od miro_ kdy 03 Dubna 2024, 18:53:47 »Udelal jsem pro test na XP maly testovaci adresar s podadresari a txt soubory s daty v cestine.
Zavery jsou nasledujici:
- v XP tento testovaci podadresar sbaleny pres 'ztree' po jeho rozbaleni 'rozipovanim-vykopirovani' primo XP je poradku.
- Zkusil jsem pres 'flesku' prenest testovaci '.zip' do W10. Ve W10 je po 'rozipovanim-vykopirovani' vse rovnez v poradku !
! Preneseni testovaci rozbalene struktury pres sit (sambou) do U22mate
jsou cz pojmenovani vsech souboru a podadresaru v poradku ale data souboru jsou spatne kodovana !
! Pri prenosu komprimovaneho testovaciho adresare z XP do U22mate pres sit (sambou) jsou v U22 spatne
jiz i cz jmena souboru i data souboru s cestinou !
Potvrzuje to ze pro prenosy mezi linux a win je cestina problem.
Jen dodatek k mezeram ve jmenech. Dle mych zkusenosti je hlavni problem mezera na konci extension
nebo ve jmenu bez extension, kterou se mi obcas pri kopirovani jmen souboru povede pridat.
Pak samba a nektera aplikace (FreFileSync, ...) maji problem.
Podobny problem dela nektery 'C' kompilator pri uzivani '#ifdef jmeno\'. Mezera za '\' dela chybu v prekladu
(spatne se tento problem hleda).
- Jeste dodam k interpretaci pri kopirovani z obrazovky.
To co mi vypisuje na obrazovce nejaka aplikace nebo terminal zavisi na jeho interpretaci nactenych binarnich dat
v nejakem bufferu, jak jej jeho autor resil.
Dodnes se mi obcas hodi stare XP s UTF-8, kde mam moznost pri 'debug' paketu v prenosech dat napr. z 485 atd.
V techto XP je jeste funkcni editor ze systemu DOS z 80-tych let 'e.exe' (nebo podobny 'aedit.exe').
Tento editor umoznuje 'hledat' i 'editovat' hex znaky pod 0x20 a nad '0x7f' vcetne 0x00.
Obcas se mi to hodi (napr upravy "crlfcr" na "crlf", kdy je takto nekdy nasledujici text nezobrazen,
vlozeni nebo nahrazeni "tabulatoru" atd...
Zatim jak resit podobne problemy v linuxu neznam. (Samozrejme to souvisi s uzivanim UTF-8).
Tehdy by bral hex data z buferu mezi 'otagovanim', bez ohledu na uzite kodovani znaku.
Je mozne ze jsem Tve prispevky zcela nepochopil..
Pro mne je timto testovanim problematika cz mezi win a linux uzavrena.
Prikladam testovaci '.zip' pro moznost vyzkouseni, nutno uzit i win ! , pozor zipovano v U22 !
(Zajimave, baleni '.7z' melo problem ! Nejde prilozit. nemam chut problem '.7z' zkoumat.)
Zavery jsou nasledujici:
- v XP tento testovaci podadresar sbaleny pres 'ztree' po jeho rozbaleni 'rozipovanim-vykopirovani' primo XP je poradku.
- Zkusil jsem pres 'flesku' prenest testovaci '.zip' do W10. Ve W10 je po 'rozipovanim-vykopirovani' vse rovnez v poradku !
! Preneseni testovaci rozbalene struktury pres sit (sambou) do U22mate
jsou cz pojmenovani vsech souboru a podadresaru v poradku ale data souboru jsou spatne kodovana !
! Pri prenosu komprimovaneho testovaciho adresare z XP do U22mate pres sit (sambou) jsou v U22 spatne
jiz i cz jmena souboru i data souboru s cestinou !
Potvrzuje to ze pro prenosy mezi linux a win je cestina problem.
Jen dodatek k mezeram ve jmenech. Dle mych zkusenosti je hlavni problem mezera na konci extension
nebo ve jmenu bez extension, kterou se mi obcas pri kopirovani jmen souboru povede pridat.
Pak samba a nektera aplikace (FreFileSync, ...) maji problem.
Podobny problem dela nektery 'C' kompilator pri uzivani '#ifdef jmeno\'. Mezera za '\' dela chybu v prekladu
(spatne se tento problem hleda).
- Jeste dodam k interpretaci pri kopirovani z obrazovky.
To co mi vypisuje na obrazovce nejaka aplikace nebo terminal zavisi na jeho interpretaci nactenych binarnich dat
v nejakem bufferu, jak jej jeho autor resil.
Dodnes se mi obcas hodi stare XP s UTF-8, kde mam moznost pri 'debug' paketu v prenosech dat napr. z 485 atd.
V techto XP je jeste funkcni editor ze systemu DOS z 80-tych let 'e.exe' (nebo podobny 'aedit.exe').
Tento editor umoznuje 'hledat' i 'editovat' hex znaky pod 0x20 a nad '0x7f' vcetne 0x00.
Obcas se mi to hodi (napr upravy "crlfcr" na "crlf", kdy je takto nekdy nasledujici text nezobrazen,
vlozeni nebo nahrazeni "tabulatoru" atd...
Zatim jak resit podobne problemy v linuxu neznam. (Samozrejme to souvisi s uzivanim UTF-8).
Citace
Jenže já ti psal o voze a ty něco jiného...Ja jsem jen chtel zkusit zda 'linux terminal' nahodou pres 'ctrl_c/v' nenatahuje pro tyto akce binarni data z bufferu.
Tehdy by bral hex data z buferu mezi 'otagovanim', bez ohledu na uzite kodovani znaku.
Je mozne ze jsem Tve prispevky zcela nepochopil..
Pro mne je timto testovanim problematika cz mezi win a linux uzavrena.
Prikladam testovaci '.zip' pro moznost vyzkouseni, nutno uzit i win ! , pozor zipovano v U22 !
(Zajimave, baleni '.7z' melo problem ! Nejde prilozit. nemam chut problem '.7z' zkoumat.)
Nevadí.