スズメは小さいが、五臓がそろっている:DEBUGの奇妙な小さな問題
前回の「スズメは小さくて、五臓がそろっている」が人気で、今日はもう一つ書きましたが、今回は小さな問題のデバッグの過程を話しています.今日、ある同僚は私にJAVAコードを反映して、もし出力したファイルの接尾辞は.idxでは、書き込まれた改行が失われ、Editplusからすべての内容が1行に表示されます.ファイル名と接尾辞がストリームの内容に影響するのは不思議です.これは明らかに不可能で、まさか本当に霊異事件に出会ったのだろうか.そこで、以下の手順に従って問題をデバッグして解決する:1、独立したテストコードを書くには、まずこの問題がJAVA自身の問題ではないことを検証し、すぐにテストコードを書いた.
Java code
実行後、UltraEditで結果ファイルを開き、問題ありません.同僚によると、彼女が直接使っているFileWriterは、少し修正してから測定して、大丈夫だという.同僚はまた、彼女のファイルは追加モードで開いて、更に直して、更に測定して、やはり問題がありませんと言いました.2、問題を再現するのはちょっと不思議なので、同僚の機械で調べてみました.確かにこの現象が発見された.3、コードを読み歩いてコードを見たが、特別なところは見つからなかった.4、ローカル置換を行い、位置決め問題を試みる出力ファイル名、ファイル接尾辞を修正することによって、何度も試みることによって、問題が存在しないことを発見する.idx接尾辞には、新しく作成したファイルにはこの問題はありませんが、彼女のマシンにすでに存在するlogに続けます.idxに追加してはいけません.5、環境を整理した後、問題が特定のファイルに関連している以上、この奇妙なファイルを削除し(削除前にバックアップを行い、問題が解決した後に根源を追及する)、プログラムを再実行して新しい同名ファイルを生成し、問題は再再現されなかった.では、問題の根本的な原因はこの文書内にあるに違いない.6、私は同僚にロゴを要求した.idxファイルは私に送って、私はUltraEditで開けて、改行が正しいことを発見して、同僚の機械の上でEditplusで同じファイルを開けて改行が正しくありません.そこでまたEditplusを使う同僚を見つけて、このファイルを開けて、改行も正しくありません.したがって、ファイル自体に大きな問題はありません.問題は、テキストエディタのテキスト内の改行の処理方法が一致していないことです.さらにUltraeditのバイナリモードでこのテキストファイルを研究したところ、このテキストファイルには2つの改行フォーマットがあることが分かった.一部の行の間にはwindowsの「/r/n」があり、一部の行の間にはunixの「/n」がある.これが違いの原因だと初歩的に判断し、Editplusは2つのリターン式のファイルが存在し、1つしか認識されていない可能性がある.7、検証推測Ultraeditに空白テキストファイルを新規作成し、入力:123 456 789はUEでバイナリモードに切り替え、表示:00000000 h:31 32 33 D 0 A 34 35 36 D 0 A 37 38 39;123..456..789はEditplusで開き、通常は3行がUEバイナリモードで表示され、2番目の0 Dが削除され、00000000 h:31 32 33 D 0 A 34 35 36 A 37,38となる.123.456.789 Editplusで開き、後ろの車は認識されず、2行表示:123 456789
最初の0 Dを削除すると、00000000 h:31 32 33 0 A 34 35 36 0 A 37,3839になります.123.456.789はEditplusで開き、正常に3行123 456 789と表示され、2番目の0 Dが回復し、00000000 h:31 32 33 A 34 35 35 36 D 0 A 37 38となった.123.456..789はEditplusで開き、前の折り返しは認識されず、2行として表示される:123456 789、結論Editplusはテキストファイルの改行を判断する上で、テキストファイルに改行フォーマットが1つしか存在しない場合(/r/nでも/nでも)、Editplusはテキストファイルに2つの改行フォーマットが存在する場合、/r/nを優先し、単純な/nは無視されることを正しく認識することができる.9、この現象を起こした過程で同僚の第1版コードがファイルに追加した改行符は「/r/n」で、後に「/n」に変更されたが、元のファイルは削除されず、ファイルの書き方が追加されたため、ファイルには2つの改行形式が現れた.6歩目が完成した後に止まる人もいるかもしれないが、私が好きなのは後の3歩だ.
補足結論:
Bao 110908レスEditplusの改行に対する処理メカニズムを詳しく説明します.
EditPlusには、3つの改行の1つを区別するファイル形式があります.一、/r/nと/nが混合(すなわちPCとUnixの改行が混合)1、テキスト中の/r/nの数が/nの数より大きい場合は、PCの/r/n方式で表示され、この場合/nは新しい行として表示されず、非表示文字となる.2、テキスト中の/r/nの数が/nの数より小さい場合は、Unixの/n方式で表示され、この場合/r/n中の/rは非表示文字となり、/rの後ろの/nは改行される.3、テキスト中の/r/nの数が/nの数と同じであれば、優先的に/r/n方式で表示され、この場合、個別の/nは非表示文字となる.二、/nと/rを混合する(すなわち、UnixとMacの改行を混合する)1、テキスト中の/nの数が/rの数より大きい場合は、Unixの/n方式で改行し、このとき/rは不可視文字となる.2、テキスト中の/nの数が/rの数より小さい場合は、Macの/rで改行します.この場合/nは非表示文字になります.3,テキスト中の/nが/nと同じ数であれば,優先的にUnixの/n方式で置き換え,同時に/rは非表示文字となる.三、/r/nと/rを混合する(すなわち、PCとMacの改行を混合する)1、テキスト中の/r/nの数が/rの数より大きい場合は、PCの/r/n方式で改行し、このとき/rは非表示文字となる.2、テキスト中の/r/nの数が/rの数より小さい場合は、Macの/r方式で改行し、/r/nのうちの/rが改行符となり、後の/nが非表示文字となる.3,テキスト中の/r/nが/rの数と同じ数であれば,PCの/r/n方式で優先的に置き換え,単独の/rは非表示文字となる.四、/r/n、/nと/rを混合する(すなわちPC、Unix、Mac改行混合)1、この3種類の改行のどの改行が多いかはどの方式を採用する.2.3つの改行数または2つの改行数が同時にある場合、/r/n、/n、/rの優先順位で改行パターン行を決定する.実験ツールテキスト表示:EditPlus 3.00(254)betaバイナリ修正:PSPad 4.5.3(2298)
Java code
import
java.io.BufferedWriter;
import
java.io.File;
import
java.io.FileWriter;
public
class
TestIdx {
public
static
void
main(String[] args)
throws
Exception{ File f
=
new
File(
"
d://test.idx
"
); BufferedWriter w
=
new
BufferedWriter(
new
FileWriter(f)); w.write(
"
abc
"
); w.write(
"
/n
"
); w.write(
"
123
"
); w.flush(); w.close(); } }
実行後、UltraEditで結果ファイルを開き、問題ありません.同僚によると、彼女が直接使っているFileWriterは、少し修正してから測定して、大丈夫だという.同僚はまた、彼女のファイルは追加モードで開いて、更に直して、更に測定して、やはり問題がありませんと言いました.2、問題を再現するのはちょっと不思議なので、同僚の機械で調べてみました.確かにこの現象が発見された.3、コードを読み歩いてコードを見たが、特別なところは見つからなかった.4、ローカル置換を行い、位置決め問題を試みる出力ファイル名、ファイル接尾辞を修正することによって、何度も試みることによって、問題が存在しないことを発見する.idx接尾辞には、新しく作成したファイルにはこの問題はありませんが、彼女のマシンにすでに存在するlogに続けます.idxに追加してはいけません.5、環境を整理した後、問題が特定のファイルに関連している以上、この奇妙なファイルを削除し(削除前にバックアップを行い、問題が解決した後に根源を追及する)、プログラムを再実行して新しい同名ファイルを生成し、問題は再再現されなかった.では、問題の根本的な原因はこの文書内にあるに違いない.6、私は同僚にロゴを要求した.idxファイルは私に送って、私はUltraEditで開けて、改行が正しいことを発見して、同僚の機械の上でEditplusで同じファイルを開けて改行が正しくありません.そこでまたEditplusを使う同僚を見つけて、このファイルを開けて、改行も正しくありません.したがって、ファイル自体に大きな問題はありません.問題は、テキストエディタのテキスト内の改行の処理方法が一致していないことです.さらにUltraeditのバイナリモードでこのテキストファイルを研究したところ、このテキストファイルには2つの改行フォーマットがあることが分かった.一部の行の間にはwindowsの「/r/n」があり、一部の行の間にはunixの「/n」がある.これが違いの原因だと初歩的に判断し、Editplusは2つのリターン式のファイルが存在し、1つしか認識されていない可能性がある.7、検証推測Ultraeditに空白テキストファイルを新規作成し、入力:123 456 789はUEでバイナリモードに切り替え、表示:00000000 h:31 32 33 D 0 A 34 35 36 D 0 A 37 38 39;123..456..789はEditplusで開き、通常は3行がUEバイナリモードで表示され、2番目の0 Dが削除され、00000000 h:31 32 33 D 0 A 34 35 36 A 37,38となる.123.456.789 Editplusで開き、後ろの車は認識されず、2行表示:123 456789
最初の0 Dを削除すると、00000000 h:31 32 33 0 A 34 35 36 0 A 37,3839になります.123.456.789はEditplusで開き、正常に3行123 456 789と表示され、2番目の0 Dが回復し、00000000 h:31 32 33 A 34 35 35 36 D 0 A 37 38となった.123.456..789はEditplusで開き、前の折り返しは認識されず、2行として表示される:123456 789、結論Editplusはテキストファイルの改行を判断する上で、テキストファイルに改行フォーマットが1つしか存在しない場合(/r/nでも/nでも)、Editplusはテキストファイルに2つの改行フォーマットが存在する場合、/r/nを優先し、単純な/nは無視されることを正しく認識することができる.9、この現象を起こした過程で同僚の第1版コードがファイルに追加した改行符は「/r/n」で、後に「/n」に変更されたが、元のファイルは削除されず、ファイルの書き方が追加されたため、ファイルには2つの改行形式が現れた.6歩目が完成した後に止まる人もいるかもしれないが、私が好きなのは後の3歩だ.
補足結論:
Bao 110908レスEditplusの改行に対する処理メカニズムを詳しく説明します.
EditPlusには、3つの改行の1つを区別するファイル形式があります.一、/r/nと/nが混合(すなわちPCとUnixの改行が混合)1、テキスト中の/r/nの数が/nの数より大きい場合は、PCの/r/n方式で表示され、この場合/nは新しい行として表示されず、非表示文字となる.2、テキスト中の/r/nの数が/nの数より小さい場合は、Unixの/n方式で表示され、この場合/r/n中の/rは非表示文字となり、/rの後ろの/nは改行される.3、テキスト中の/r/nの数が/nの数と同じであれば、優先的に/r/n方式で表示され、この場合、個別の/nは非表示文字となる.二、/nと/rを混合する(すなわち、UnixとMacの改行を混合する)1、テキスト中の/nの数が/rの数より大きい場合は、Unixの/n方式で改行し、このとき/rは不可視文字となる.2、テキスト中の/nの数が/rの数より小さい場合は、Macの/rで改行します.この場合/nは非表示文字になります.3,テキスト中の/nが/nと同じ数であれば,優先的にUnixの/n方式で置き換え,同時に/rは非表示文字となる.三、/r/nと/rを混合する(すなわち、PCとMacの改行を混合する)1、テキスト中の/r/nの数が/rの数より大きい場合は、PCの/r/n方式で改行し、このとき/rは非表示文字となる.2、テキスト中の/r/nの数が/rの数より小さい場合は、Macの/r方式で改行し、/r/nのうちの/rが改行符となり、後の/nが非表示文字となる.3,テキスト中の/r/nが/rの数と同じ数であれば,PCの/r/n方式で優先的に置き換え,単独の/rは非表示文字となる.四、/r/n、/nと/rを混合する(すなわちPC、Unix、Mac改行混合)1、この3種類の改行のどの改行が多いかはどの方式を採用する.2.3つの改行数または2つの改行数が同時にある場合、/r/n、/n、/rの優先順位で改行パターン行を決定する.実験ツールテキスト表示:EditPlus 3.00(254)betaバイナリ修正:PSPad 4.5.3(2298)