ローコード開発で 小さな業務改善から、 デジタルの未来へ ローコード開発で業務システムの構築が可能な、 クラウド型アプリケーションプラットフォームです。
intra-mart
ローコード開発で 小さな業務改善から、 デジタルの未来へ ローコード開発で業務システムの構築が可能な、 クラウド型アプリケーションプラットフォームです。
文字列を指定の文字エンコーディングでのバイト数で切る - kameidの備忘録 - Sharpen the Saw!
文字列を指定の文字エンコーディングでのバイト数で切る処理を作ってみた。固定バイト長の文字コードであれば指定のバイト長で切る処理というのはさほど難しいところはないのだが。 たとえば、"1234" という ASCII 文字列を、3 バイトで切りたい場合、"123"。文字数とバイト数が一致するため、もっとも簡単だ。 しかし、ShiftJIS 等の主要な文字コードでは、文字種によってバイト長が変化する。結局のところ、指定のバイト数に何文字まで入るか、というのはその文字コードに変換してみないとわからない。 Java では文字の内部表現は普通 UTF-8 だけど、DB では EUC で、カラム長は 256 バイト。というような場合。カラム長がバイト指定なのが全部悪いんだが。 で、先日見たとあるロジックはこの「文字列を指定の文字エンコーディングでのバイト数で切る処理」を実装してたのだが、なかなか気になる
String#offsetByCodePointsでハマリ - ocha labs
文字列の補助文字対応をしていてハマッタのでメモ。 症状 下記のようにUnicodeのコードポイント単位で処理をしたいが、 offsetByCodePointsの値に期待値がこないで、妙にでかい値がくる。なぜ？！ for (int i = 0; i < s.length(); i = s.offsetByCodePoints(i, 1)) { ... } 調査 下記のようなテストプログラムでoffsetByCodePointsの出力を調べる。 期待値は１． class Test { public static void main(String[] args) throws Exception { String org = "＊＊＊＊＊ハロー"; String word = org.substring(5, org.length()); p("offsetByCodePoints:%s\n",
Javaでの文字数カウント(サロゲートペア)に関する実験 - Gaishimo
「プログラマのための文字コード技術入門」を読んで。 Stringの文字数をカウントする時、String#length()メソッドでは厳密に文字数をカウントできない場合があるという。 実験 実際にそのケースを試してみる。 本来5とカウントしたいところが、7とカウントされてしまった。これは、文字列の中にサロゲートペアに該当する文字が含まれているためである(1文字目と２文字目)。最初の2文字は「齟齬」(そご)ではなく、「齟齬」の異字体である。サロゲートペアの場合、1つの文字に対し１つのchar値が対応するわけではなく、2つのchar値が対応する形になる。String#length()はcharの数をカウントするため、この場合結果は7となってしまう。 そこでJDK1.5から追加されたString#codePointCount()メソッドを利用してカウントしてみる。これは、文字の符号位置の数をカウン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
サロゲートペアを考慮した
