ラテン文字の代わりに中国語の文字がファイルに書き込まれます。

ラテン文字の代わりに中国語の文字がファイルに書き込まれます。

sed次のように実行してコンソールに印刷すると、すべてが正常です。

sed '/Q/{
s/Q//g
r /Users/ericbrotto/Desktop/question.txt
}' Commision.txt

しかし、このようにしてtaファイルを出力すると、次のようになります。

sed '/Q/{
s/Q//g
r /Users/ericbrotto/Desktop/question.txt
}' Commision.txt > newFile

...私の新しい文字列(以前の出力で正しく置き換えられた文字列)は、アジア(北京語であると信じています)文字の束として読み込まれます。

どんなアイデアがありますか?

フォローアップの質問です私の前の質問

ベストアンサー1

以前にASCIIでエンコードされたテキスト(または同等にUTF-8でエンコードされたASCIIテキスト)をUTF-16でデコードすると、「漢字」(UTFでデコードするかどうかによって異なる文字)が表示されることが多いことがわかります。あります。 -16BEまたはUTF-16LE)。これに基づいて、混合エンコーディングを扱っていると思います。私の考えでは、通常のASCII(またはUTF-8でエンコードされたASCII)であるCommision.txtUTF-16BEまたはUTF-16LEでエンコードされ、question.txt最終的にnewFile両方のファイルに対して誤ったエンコードの組み合わせになるようです。

両方のファイルで同じエンコーディングを使用すると、状況がより良くなります。おそらくUTF-8が最もうまくいくでしょう。最終出力が異なるエンコーディングで必要な場合は、次のものを使用できます。変換( iconv -f UTF-8 -t UTF-16BE <newFile >newfile.utf16be.txt)します。


実際、ASCII文字のUTF-16エンコーディングはASCIIエンコーディングと同じですが、追加のNUL文字が各ASCII文字の間に挿入され、別のNULが文字全体の前後に挿入されます(UTF-16エンコーディングによって異なります)。キャラクターのセクション順)。これは、UTF-8またはUTF-16でエンコードされたASCIIテキストがUTF-8端末で直接表示される場合(つまり、「コンソールに印刷された」)、「正常」と見なされることを意味します。

ファイルの内容が独立している限り、すべてのエンコーディング検出ビュー環境(エディタなど)は、エンコードを正しく検出する可能性が高い(またはUTF-8と多くのシングルバイトエンコーディングが同じ)ASCIIの範囲内です。

しかし、あなたが持っています。sedファイルを一緒に混ぜる。残念ながら、sed2つの異なるテキストエンコーディングを使用してファイルを処理していることを認識するほど、「インテリジェント」ではありません。私の推測では、ほとんどはUTF-16でエンコードされたファイル(from)にCommision.txtなり、中間(またはどこにでも)UTF-8でエンコードされた部分があります。完全にUTF-8でデコードされた場合、結果は無効になる可能性がありますが、UTF-16で完全にデコードされた場合は有効です(UTF-8データがある場所に予期しない内容が含まれているにもかかわらず)。question.txtQ


例は次のとおりです。

Commision.txtUTF-16BEでエンコードされたASCII(BOMを含む)。

% xxd Commision.txt 
0000000: feff 0046 0069 0072 0073 0074 0020 006c  ...F.i.r.s.t. .l
0000010: 0069 006e 0065 000a 004c 0069 006e 0065  .i.n.e...L.i.n.e
0000020: 0020 0077 0069 0074 0068 0020 0061 0020  . .w.i.t.h. .a. 
0000030: 0075 0063 0020 0027 0071 0027 003a 0020  .u.c. .'.q.'.:. 
0000040: 0028 0051 0029 000a 004c 0061 0073 0074  .(.Q.)...L.a.s.t
0000050: 0020 006c 0069 006e 0065 000a            . .l.i.n.e..

question.txtASCII(またはUTF-8でエンコードされたASCII)。

% xxd question.txt
0000000: 5768 6174 2069 7320 7468 6520 6169 722d  What is the air-
0000010: 7370 6565 6420 7665 6c6f 6369 7479 206f  speed velocity o
0000020: 6620 616e 2075 6e6c 6164 656e 2073 7761  f an unladen swa
0000030: 6c6c 6f77 3f0a                           llow?.

私はそれらを組み合わせるsed

% sed '/Q/{
s/Q//g
r question.txt
}' Commision.txt >newFile

newFileめちゃくちゃです。

sed2バイトUTF-16表現()の代わりにQシングルバイト()を削除しました。これは、ファイルの残りの部分の2バイトソートを中止し、全長の代わりに奇数を提供し、UTF-16 NULL()を導入します。5100 51
0000

% xxd newFile
0000000: feff 0046 0069 0072 0073 0074 0020 006c  ...F.i.r.s.t. .l
0000010: 0069 006e 0065 000a 004c 0069 006e 0065  .i.n.e...L.i.n.e
0000020: 0020 0077 0069 0074 0068 0020 0061 0020  . .w.i.t.h. .a. 
0000030: 0075 0063 0020 0027 0071 0027 003a 0020  .u.c. .'.q.'.:. 
0000040: 0028 0000 2900 0a57 6861 7420 6973 2074  .(..)..What is t
0000050: 6865 2061 6972 2d73 7065 6564 2076 656c  he air-speed vel
0000060: 6f63 6974 7920 6f66 2061 6e20 756e 6c61  ocity of an unla
0000070: 6465 6e20 7377 616c 6c6f 773f 0a00 4c00  den swallow?..L.
0000080: 6100 7300 7400 2000 6c00 6900 6e00 6500  a.s.t. .l.i.n.e.
0000090: 0a                                       .

混乱しても私のUTF-8ターミナルでは大丈夫に見えます。

% cat newFile
First line
Line with a uc 'q': ()
What is the air-speed velocity of an unladen swallow?
Last line

しかし、Vimにロードすると、何かが間違っていました(実際に開いている括弧の後にNULがありますが、その存在によってこの投稿が切り捨てられます)。 Vimは「ライン2の変換エラー」と警告します。

First line
Line with a uc 'q': (⤀੗桡琠楳⁴桥⁡楲⵳灥敤⁶敬潣楴礠潦⁡渠畮污摥渠獷慬汯眿਀䰀愀猀琀 氀椀渀攀

疑問符を削除してquestion.txt(再び偶数バイトを提供)、再生成すると、最後の行が「戻るnewFile」(2行目の末尾に付いています)がインポートされ、Vimの変換警告が回避されます。

First line
Line with a uc 'q': (⤀੗桡琠楳⁴桥⁡楲⵳灥敤⁶敬潣楴礠潦⁡渠畮污摥渠獷慬汯眊Last line

おすすめ記事