Mám soubor, který jsem vytvořil (ve vim), pro účely testování (testování výstupu UTF-8 v klientovi SSH). S tímto souborem se však dějí zvláštní věci.
Zajímalo by mě, jaké bajty jsou v souboru, tak jsem použil hexdump :
[email protected]:~$ hexdump -x intl.txt
0000000 9ecf 000a
0000003
Ok, jsou tam čtyři bajty, jak se tam dostaly 00 a 0a, není mi jasné, ale co už. Zde je to však divné:
[email protected]:~$ ls -al intl.txt
-rw-rw-r-- 1 username username 3 Mar 26 15:14 intl.txt
Počkat, to jsou tři bajty? Co se tady děje?
Jako by to nebylo dost divné, hexdump -C dává velmi odlišný výstup:
[email protected]:~$ hexdump -C intl.txt
00000000 cf 9e 0a |...|
00000003
Vim je v souboru také trochu zmatený. Když to spustím, zobrazí to ve stavovém řádku toto:
"intl.txt" 1L, 3C
Nahoře to však dostanu (pomocí set list ):
Ϟ$
~
~
~
~
Myslí si tedy, že existují 3 znaky, ale vytiskne pouze jeden. Pochopil bych, kdyby to vytisklo koppa a pod ním prázdný řádek…
Přijatá odpověď:
Jak poukázali jiní, je to proto, že hexdump -x považuje soubory za obsahující 2bajtová slova. Na systémech little endian (téměř všechny desktopy) to znamená, že bajty budou před zobrazením prohozeny. To znamená, že hodnoty bajtů jsou vytištěny ve dvojicích a že pořadí těchto bajtů je prohozeno. Protože máte lichý počet bajtů, hexdump jen přidá nulu, aby se vytvořil poslední pár. Nula je poté zaměněna za 0a . Toto je zdokumentované chování pro hexdump , takže vám nelže!
Pomocí hexdump -C je lepší příkaz pro získání formátovaného výstupu, který zobrazuje bajty v pořadí, v jakém jsou v souboru. Také 0a je nový řádek a byl pravděpodobně přidán potichu tím, co vytvořilo soubor (vim dělá to ve výchozím nastavení). Např. echo vždy přidá nový řádek, pokud mu to neřeknete. V bash :
echo -e '\xcf\x9e' | hexdump -C
poskytne stejný výsledek, ale potlačí nový řádek pomocí -n dá to, co jste očekávali:
echo -ne '\xcf\x9e' | hexdump -C
Chcete-li zastavit vim z přidání nového řádku:
:set noeol
:set binary