いろいろ探したのだが、個人的に求めている「コレ！」というコーディングサンプルが見つからなかったので
自分なりに作ってみた「サロゲートペア置換」のjava実装。
（もっとスマートなやり方はないものだろうか）
やりたかったのは「サロゲートペアを元の文字数を維持しつつ置換する」である。
たとえば「あ𩸽」というStringがあった場合、
String#length()は見た目に反して２ではなく３になってしまう。
このため１文字ずつ文字を取得していく（String#lengthをループ上限にしてString#charAtで１文字ずつ取得する）と
２文字なのに３回ループすることになり、
「サロゲートだったら」が後半２回のループにあたって３文字になってしまう。
これをなんとかうまい具合に処理する方法はないものかと
いろいろネット探したのだが見当たらない。
仕方ないので自分で実装した。（ただいろいろ甘い気はする）
あ：0x3042
𩸽：0xD867,0xDE3D(0x29E3D)
ということだが、
↑の方法でループさせると
0x3042（１回目）⇒0xD867（２回目）⇒0xDE3D（３回目）
になる。
後半２回のループは実質２つのコードで１文字を表してるから
１回目のループ分１文字と合わせて
３回ループしたとしても「２文字」にしたい。
…というのが”やりたいこと”だった。
で、実際に書いたコードがこれ↓
private static String convertSurrogatePair(String plainText) {
char[] plainChars = plainText.toCharArray();
StringBuilder convChars = new StringBuilder();
for (int i=0; i < plainChars.length; i++){
char c = plainChars[i];
String ret = "";
if (Character.isLowSurrogate(c) || Character.isHighSurrogate(c)) {
ret = "Surrogate";
// 最初の要素以外は前要素のコードポイントを見て２コードでサロゲートになるかチェック
if (i > 0){
char bef_c = (char)Character.codePointBefore(plainChars,i);
if (Character.isSurrogatePair(bef_c,c)) {
ret = "Surrogate Pair With " + Integer.toHexString(bef_c) + "[" + String.valueOf(i-1) + "]";
convChars.append(CONV_SURROGATE_STR);
}
}
} else {
// サロゲートじゃなければ元の文字をそのまま生かす
ret = "No Surrogate";
convChars.append(c);
}
String hexStr = Integer.toHexString(c);
System.out.println(String.valueOf(c) + " - " + hexStr + " - " + ret);
}
String convText = convChars.toString();
System.out.println("Original String:" + plainText);
System.out.println("Convert String:" + convText);
System.out.println();
return convText;
}
変換前の文字列［Ａ］の中のサロゲートペアを"？"（全角ハテナ）に変換して
変換後の文字列［Ｂ］に格納する。
（０）以下（１）～（３）を［Ａ］の全文字に対して１文字ずつ処理する （１）［Ａ］から１文字を取得する （２）（１）のコードポイントを取得する （３）（２）が下位サロゲートもしくは上位サロゲートに該当するかチェックする （３－１）下位サロゲートもしくは上位サロゲートの場合 （３－１－１）検査中の要素が０番目以降の場合 （３－１－１－１）前要素のコードポイントを取得し 自要素のコードポイントと合わせてサロゲートペアかどうかチェックする （３－１－１－１－１）サロゲートペアの場合、"？"を［Ｂ］に格納する （３－２）下位サロゲートでも上位サロゲートでもない場合 （１）を［Ｂ］に格納する
↑プログラムを正当に翻訳するとこんな感じになるのか。
ifのネストが深いな。
もうちょいやりかたありそうなもんだが。
これをやると、「あ𩸽」は「あ？」になるので（喧嘩売ってるみたいだね）、
やろうと思っていた「見た目の文字数を維持」については満たすことができる。
しかし一方でバイト数が変換前後で変わってしまう。
変換前は「あ𩸽」で７バイト（あで３バイト、𩸽で４バイト）だが
変換後は「あ？」で６バイト（あで３バイト、？で３バイト）なので
変換後のほうがバイト数が少なくなる。
なのでバイト数でチェックするような仕組みがある場合は変換前後で動作が変わるので、
使用用途によっては使えないだろう。
少なくなる分にはDBエラーとか起きなそうだけど。
バイト数を合わせる場合は、例えば３バイト文字＋１バイト文字にすればいいので、
例えば「あ𩸽」⇒「あ？?」とかにすれば（やっぱり喧嘩売ってるみたいだね）いいのだが、
そうすると変換前後でバイト数は合うものの文字数が合わなくなるので
やっぱりこれも使用用途に寄る。
ただまあ「文字数」と聞いてjava的に最も身近に実装したくなるString#lengthでいえば
このやり方は変換前後で値が一致するので、
「サロゲートを除去」という目的に沿うならこっちのほうがなんとなく正しそうな気もする。
