変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

2018 / 1月

JAVA8 Streamで文字列をJoin

JavaのStreamクラスを使って、文字列のリストをJoin(デルミタを挟んで1つの文字列に)する方法を試してみた。

/**
 *
 */
package sample2;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
/**
 * @author ssiscirine
 *
 */
public class Sample1 {
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		// TODO 自動生成されたメソッド・スタブ
		{
			System.out.println("☆文字の配列をJOIN☆");
			List<String> lst = new ArrayList<String>();
			lst.add("aaa");
			lst.add("bbb");
			lst.add("ccc");
			String[] ar = lst.toArray(new String[0]);
			System.out.println(String.join(", ", ar));
		}
		{
			System.out.println("☆nullを含む文字の配列をJOIN☆");
			List<String> lst = new ArrayList<String>();
			lst.add("aaa");
			lst.add(null);
			lst.add("ccc");
			String[] ar = lst.toArray(new String[0]);
			System.out.println(String.join(", ", ar));
		}
		{
			System.out.println("☆nullを含む文字の配列からnullを取り除いてJOINING☆");
			List<String> lst = new ArrayList<String>();
			lst.add("aaa");
			lst.add(null);
			lst.add("ccc");
			String str = lst.stream()
					.filter(i -> (i != null))
					.collect(Collectors.joining(", "));
			System.out.println(str);
		}
		{
			System.out.println("☆nullを含む文字の配列からnullを取り除いてJOIN☆");
			List<String> lst = new ArrayList<String>();
			lst.add("aaa");
			lst.add(null);
			lst.add("ccc");
			String[] ar = lst.stream()
					.filter(i -> (i != null))
					.toArray(String[]::new);
			System.out.println(String.join(", ", ar));
		}
	}
}
☆文字の配列をJOIN☆
aaa, bbb, ccc
☆nullを含む文字の配列をJOIN☆
aaa, null, ccc
☆nullを含む文字の配列からnullを取り除いてJOINING☆
aaa, ccc
☆nullを含む文字の配列からnullを取り除いてJOIN☆
aaa, ccc
    普通の文字列なら特に問題は無い。
    しかし、文字列にnullが混ざっていると、普通に null と表示してしまう。
    なので、StreamのFilterで取り除いてみる。
    最後は出力の仕方を他と合わせてみた。

StreamのtoArrayをパラメータ無しで使うとObject[]が戻ってくるがそれでは使いようが無いからString[]を返して貰いたい。
しかし、そのためにはListのtoArrayのようにnew String[0]ではなく、String[]::newと書かなければいけない特殊なルールが適用される。
ま、new String[0]だって、かなりマイ・ルール的であるけどね。(大笑
なぜこんなことを書いたかと云えば、古への勘違いの伝承で、文字列の結合にはStringBuiderを用いよ。というのがある。
※servletでapplication/octet-stream形式でファイルをダウンロードさせるなら、Stringで返すよりも、StringBuiderからOutputStreamを作ってwriteに渡した方が速そう?な・・あたりから落ちてきたっぽい。⇒+++と何度も文字列の結合を繰り返すとメモリを捨てまくる⇒だがしかし、toStringの結果が巨大なテキストの場合、その直後にStringの中身を1文字づつコード変換(知らない文字を?に変える簡単なお仕事=getByte(“UTF-8”)等)がかかるのは明らかで、いくら苦労してもメモリ云々以前に処理が遅すぎるんだよね。というオチ。
それでも、単に文字列を結合するならStringBuiderでも構わないけど、後になって<BR>や¥n(改行コード)をデリミタとして差し込むとか言い出されることは多い。
そうなると、if(StringBuider.IsNotEmpty()) { StringBuider.append(デリミタ); } を全般に挿入することになる
さらに始末が悪いのが・・・
最初はサンプルHTMLのJavaScriptのInnerHTMLで差し込むのでバリバリに<BR>であったが、
後になってJSPタグで差し込むことになると、<BR>を¥n(改行コード)に一斉置換しなければいけない。
しかし、全ソースの<BR>を対象にする訳にはいかない。しかも<BR>とか¥nなんてソースに直書きしないのがお約束だから、猶更始末に負えない。
これはかなりの重労働になりそう。
そんな優柔不断な相手にはListに詰め込み最後にJoinすれば安心だろう。
と思ったので書いてみた。
そして、StringBuiderに joinがあったらとは云わない、でも、せめてtoArrayダケでもあったら良かったのに・・・とも思った。(かなり真剣に



間違ったMS-EXCELの使い方

間違ったMS-EXCELの使い方

  1. EXCELで書類を書く。
  2. EXCELで書いた書類を1つのブック(ファイル)にまとめる。
  3. ブック(ファイル)にまとめたEXCELファイルを配布する。
  4. ブック(ファイル)にまとめたEXCELファイルを多人数で同時に使う。
  5. ブック(ファイル)にまとめたEXCELファイルを共有モードにして多人数で同時に使う。

一見、何も間違っていない様に思える。
しかし、EXCELには様々な制約があり、特に書式の数の制限がとても痛い。64000個(大凡1シートで使うセル範囲程度)までと大目な数ではあるので、上の1.であればマズ問題は無い。
しかし、2.で沢山のシートをまとめると書式の数の上限に近くなったり、あっさり越えたりする。多くの場合、似たり寄ったりのレイアウトにまとめたシートであればいいが、シートごとに若干異なる書式を使うケースではあっさり超えてしまう。
例:1シート目の行にシリアル番号を付ける1.2.3・・・、しかし他のシートと区別するために、書式でAAA001、AAA002、AAA003・・・としてみると・・・
2シート目の行にシリアル番号を付ける1.2.3・・・、しかし1シート目と同様に、書式でBBB001、BBB002、BBB003・・・としてみると・・・
・・・
となり1シートごとに1個づつ書式が増えていく。
これが1シートごとに10個づつ書式が増え、更に100シートぐらいをまとめると、先のシリアル番号だけで1000個も使ってしまう。
EXCELの書式は色々使い道があるので、1シートごとに10個というのは少ない方だろう。そう考えると、自分が作ったシートをひとまとめにするまでは上限数的に大丈夫だろう。
しかし、10人のシートをひとまとめにするのはヒヤヒヤもの。
当然、100人のシートをひとまとめにするのは絶望的である。
故に、過去には、多人数にEXCELシートでアンケートに記入してもらい返事をメールで貰う場合は、書式の無いテキストファイルを添付してもらっていた。理由はメールの添付ファイルの容量×人数 > 当時のメール容量の上限の懸念であったが、実際にはEXCELシートをマージすると先の書式の数の上限に引っかかること間違いなかったからであった。
・・・
時には、他のシートの多いEXCELブックからどれかのシートを転記しようとすると、書式の分量の多い転記元+書式の分量の多い転記先の合計になり、これだけで書式の上限近くなってしまう場合には、シートのコピーができなくなってしまう。もちろん、1セルのコピーすら不能になってしまう。
この場合は、転記元のみ開き、新規にEXCELブックを作って、シートをコピーし、転記元を閉じてから、転記先を開くと、運の良いあなたなら、シートをコピーすることができる。
※但し、次の人が同じ方法で対処できる保証は全く無い。
という訳で上記の1.~5.のような使い方をしていると、書式の数の上限でヒドイ目に合うことは避けられないのだ。
長々と書いてしまったが・・・これらは書式の数の制約がもっときつかった1990年代ごろに既に(上限が低かっただけにスグに)判明していたことである。もうすでに21世紀になってもう20年近くになっているものの、MSがやってくれたことは、書式の上限を数百個から64000個まで段階的に増やしてくれたことだけだ。
・・・
早い話、「要らない!使っていない!書式を消してしまえばいいのだ。」と云う馬鹿者は多いだろう。
しかし、自分で作ったEXCELブックですら自動的に生成される書式もあるから難しいし、他人からもらったモノであれは猶更である。
・・・
困ったことに、WEBブラウザのページからEXCELシートにコピペすると
綺麗なWEBページが多いのでEXCELブックの書式の数が一気に増えてしまう
あちこちのサイトで参考資料としてEXCELブックに貼ると
あっという間に書式の数が凄いことになってしまうので、
その後に何かの拍子に「書式が多すぎます」のメッセージを見ることは決して少なくないハズ。
※そのせいか?最近のEXCEL君が無理にセルデータの押し込もうとするが、失敗(文字欠けやレイアウト崩壊等)することが多い。
・・・
これについて、根本的に解決策は今のところ見つかっていない。
正解に近い方法としては・・・

  1. 自分で作ったEXCELブックファイルを他人に渡さない。
  2. 他人の作ったEXCELブックファイルを貰わない。
  3. EXCELブックファイルの中身はPDFにして配布する。

である。
しかし、この方法は一時的に流行ったものの以下の事項により、スグに廃れた。

4.使い続ける限りEXCELブックファイルのメンテナンスが必要でPDF出力後に即廃棄はできない。

そんな訳で書式の数の問題は・・・
この先も同じこと(上限を上げて先伸ばしする)が続くのだろう。
 
 
 
 
 
 




top