顧客は、改行が0xD 0xD 0xA
というシーケンスで構成される.csvファイルを私に送信しています。私の知る限り、改行はMacまたはUnixの0xA
またはWindowsの0xD 0xA
のいずれかです。
0xD 0xD 0xA
は既知のエンコーディングですか?これを引き起こすファイルの行末を破損する節約の既知のシーケンスはありますか(顧客はMacを使用していると思います)?
ファイルはエンコーディングマーカーで始まるのではなく、テキストコンテンツから直接始まります。コードページ1252で開いた場合、テキストは正しく表示されます。
CRCRLFは、 Windows XP notepad Word wrap bug 。
将来の参考のために、リンクされたブログからの関連性の抜粋を以下に示します。
WindowsコンピューターでEnterキーを押すと、キャリッジリターン(CR)とラインフィード(LF)の2つの文字が実際に保存されます。オペレーティングシステムは、文字シーケンスCR LF Enterキーと同じ方法で常に解釈します。次の行に移動します。ただし、CRまたはLF =文字だけで、これは時々問題を引き起こす可能性があります。
Windows XP Notepadのバージョンにはバグがあり、表示ウィンドウに余分なCR文字が保存される可能性があります。このバグは次の状況で発生します。
Wordの折り返しオプションがオンになっていて、表示ウィンドウに折り返す長い行が含まれている場合、ファイルを保存すると、メモ帳が表示ウィンドウの各折り返しポイントに文字CR CR LF 、しかし保存されたファイルにはありません。
CR CR LF文字は、コピーして他のプログラムに貼り付けると奇妙になります。また、メモ帳ウィンドウのサイズを変更すると、メモ帳が行を適切に再ラップできなくなります。
CR CR LF文字を削除するには、ワードラップ機能をオフにしてから、必要に応じてオンに戻します。ただし、これを行うと、カーソルは表示ウィンドウの先頭に再配置されます。 。
Netscape ANSIエンコードファイルは、改行に0D 0D 0Aを使用します。
Appleメールは、テキストおよびcsv添付ファイルの送信時にエンコードエラーを発生させることも知られています。本質的には、各行で改行コードを= 0Dのように見えるソフト改行で置き換えます。添付ファイルがOutlookに電子メールで送信された場合、Outlookはソフト改行を確認し、=を削除してから実際の改行、つまり0D0Aを追加して、各行の最後に0D0D0A(cr cr lf)を取得します。エンコードは、Mac形式のファイル(または他のUNIX形式)の場合は= 0D =、Windows形式のファイルの場合は= 0D0A =にする必要があります。
Apple mail(少なくともmavericksまたはyosemiteで))からメールを送信する場合、添付ファイルをテキストまたはcsvファイルではなくすることは、許容される回避策です(例:圧縮する)。
バグは、Windows VMを並行して実行し、そこからAppleメールを使用してtxtファイルを電子メールで送信します。これは電子メールのエンコードです。ここでコメント、netscapeにも同じ問題があったようです。
これは通常、リビジョン管理システムのバグなどに起因します。ファイルがWindowsからUnixサーバーにチェックインされ、その後再びチェックアウトされた場合、これはCVSの製品でした...
つまり、壊れているだけです...
ちょうど言って、これはまたphpから返される値(のような...)です。
<?php var_dump(urlencode(PHP_EOL)); ?>
// Prints: string '%0D%0A' (length=6)-- used in 5.4.24 at least