Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
自分の頭を整理するために書いておく。正しいかは知らない。 まず前提として、Javaの内部表現としての「文字」は16ビット長のUTF-16ということがある。そうすると、普通に長さを取得すると、UTF-16のサロゲートペアで表される文字は2文字と扱われる。 また、文字には合成済み文字という話がある。「か」の後に濁点を結合することで、「が」を表現するみたいなやつ。 これらから、どこまで考慮して文字列の長さを取得するかでやり方が違う。 UTF-16のサロゲートペアを考慮しない UTF-16のサロゲートペアを考慮する 合成済み文字を考慮する 以下試したサンプルコード。 import java.text.BreakIterator; public class UnicodeCharSample { public static void main(String[] args) { // 𪛀あが St
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
下図は、SoftBank iPhoneのMailが用いるShift_JISのIBM拡張文字領域*1。どうだ、驚いたろう。 SoftBank iPhoneのMailは、charset=Shift_JISをよく使う。髙村薫の「髙」や宮﨑あおいの「﨑」などのWindows外字もShift_JISで送るし、絵文字もShift_JISで送る。しかし、WindowsのIBM拡張文字領域とSoftBankの絵文字領域は、もともと衝突しており、共存できない。なので、SoftBank iPhoneのShift_JISでは、IBM拡張文字のうち下図ピンク部分が使えない。 だったらその分は、NEC選定IBM拡張文字のほうを使えばいいじゃないですか、どうせダブってるんだから（下図）。というのが、大ざっぱに言えば、SoftBank iPhoneのMailが用いるShift_JISである。 その外字領域をまとめると、
同僚の女性からクッキーをすすめられても、「サードパーティークッキーは拒否します」とキッパリお断り申し上げたiPhoneアプリ開発担当の七尾です。というか、どう考えてもホワイトデーの(ry さて先週に引き続き、iOS開発でUnicode絵文字を扱う際の注意点について書いていこうと思います。 Combining Character/結合文字 サロゲートペアの他にも同様に気をつけなければいけないのが、結合文字です。 アルファベットに対しての修飾文字を付けたり、数字を四角で囲ったりした文字があります。 そういった文字は結合文字と呼ばれ、iPhoneで入力できる文字でいうと、 1を四角で囲った文字 = 0x31 0x20E3 2を四角で囲った文字 = 0x32 0x20E3 というようになります。 結合文字の文字数を取りたい場合は、特定の修飾文字を読み飛ばせば良いだけなので、 以下のようにさらっと対
git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit（Git for Windows） がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin は UTF-8 な日本語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けの GUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪い Windows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す
Windowsがデフォルトでzip圧縮形式に対応して以来、メールに添付されるzipファイルが急増した気がする。しかしファイル名の文字コードの関係で、unzip するとファイル名がいつも文字化けしてしまい、下記のようなコマンドで修正していた。 % convmv -f sjis -t utf-8 --notest *しかし、unzipにはファイル名をiconvで変換するパッチがあって、FreeBSD の ports にもずいぶん前から取り込まれていたようだ。ただし、コンパイル時にオプションを指定する必要があった。 # cd /usr/ports/archives/unzip # make -DWITH_ICONV # make install使うときは、たいていWindowsで圧縮されたファイルを解凍するので、ほぼ100％こういうコマンドになる。 % unzip -Ocp932 -l [ファイ
ねえねえ。これ何に見える？ もしかして何かエッチなこと言わそうとしてます？ いや、そういうのじゃないから。 宇宙人……でしょうね。 ふーん。宇宙人に見えるかあ。 宇宙人に見えるっていうより、宇宙人とでも言うしかないというか。 うん。これ、U+1F47E ALIEN MONSTERっていうUnicode絵文字の例示字形なんだけどね。ちょっとアレだよね。その元になった携帯キャリアの絵文字は、SoftBankのインベーダーのカニ星人*1。それから、auのタコ星人。 どっちもわかりやすい宇宙人ですよね。それがどうしてこんな不吉な脳みそ星人になっちゃったんですか？ 話せば長いんだけどね。 じゃあ、またの機会に……。 ま、座れよ。ケータイの世界には、SoftBankにはアリ星人（「宇宙人」）とカニ星人（「ゲーム」）がいて、auにはタコ星人（「宇宙人」）とUFOがいる。 はい。ありますね、これ。 こいつ
ご指定のホームページは下記のアドレスに移動しました。 ブックマークなどの登録変更をお願いします。 http://tomneko.la.coocan.jp/ ※10秒後に自動的に移転先のページにジャンプします。
はてなブログは、文字コードがEUC_JPであったはてなダイアリーとは違い、UTF-8（Unicode）でエンコーディングされているらしい。 そこでこのはてなブログに、ハングル文字を貼り付けて投稿してみる。 크리스마스는 외국 명절입니다. 꼭 행복해야 되고나, 꼭 카플해야 돼 필요없다고 생각해. 가끔 혼자 외롭게 보내는 크리스마스도 되게 멋있고요, 카플들은 잘 보내실테니까, ＊＊ 한잔에 그럴 ＊＊＊＊ 분위기도 좋고 그런 크리스마스도 좋은 것같습니다. 저＊＊ 라디오하고 있을테니까, 라디오 들이시고요. クリスマスは、外国の行事です。必ず幸せにならなければならないとか、必ずカップルでなければならないわけはないと思うよ。ときには、ひとりで淋しく過ごすクリスマスもけっこうすてきでしょう。カップルたちは楽しく過ごしているんですから、＊＊ 一杯？ そんな ＊＊＊＊＊雰囲気
Firefox などで下の半角濁点「ﾞ」・半角半濁点「ﾟ」を選択してみてほしい。 ｶﾞ、あﾞ、漢ﾞ、aﾞ、 ﾞ、☃ﾞ、✐ﾞ えﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞっ!! ふﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟ。 ぬﾞﾞﾟﾞﾞﾞﾟﾟﾟﾟﾞﾞﾞﾞﾟﾞﾟﾞﾞﾟﾞﾞﾞﾞﾞﾟﾞﾞﾞﾟﾞﾟﾟﾟﾞﾞﾞﾟﾟﾟﾟﾟﾟﾟﾞﾞﾞﾟーん いくら半角（半）濁点だけを選択しようとしても、前の文字まで（それがスペースだろうが記号だろうが）一緒に選択されてしまうと思う。もう少し正確に言えば選択されるのは [^ﾞﾟ][ﾞﾟ]* にマッチする部分で、カーソルの移動の際にも [^ﾞﾟ][ﾞﾟ]* が一文字として扱われる。delete キーを押すと [^ﾞﾟ][ﾞﾟ]* が一気に消えるが、backspace キーでは半角（半）濁点がひとつずつ消える。 Windows のメモ帳*1など昔ながらのアプリケーショ
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
ちょっと久々のJavaネタですが、 前から書き溜めていた、文字コードやエンコードについてのノウハウを書きます。 今回は、詳細な説明に入る前に、前提になる知識や用語について説明しておきます。 文字コードとエンコードって違うの？ 新人くん「では、HTMLの文字コードはUTF-8でお願いします」 先輩社員「文字コードじゃなくてエンコーディングでしょ？」 新人くん「えっ。あぁ、はい、それで」 文字コードとエンコード（エンコーディング）を混同して使ったりすると、 ちょっと原理主義的な人に怒られたりするんですけど、 大まかに言えば、「文字コード」は文字に割り当てられた「数字」のことで、 「エンコード」は文字と数字をマッピングする「方式」のことだと捉えていれば、大きくは外れません。 ただ、「文字コード」という言葉は、「数字」「方式」の両方で使われるほか、 文字一覧を示す「Charset」という意味で使わ
Emacs23 以降の Unicode の曖昧幅文字取り扱いについてのメモです。 曖昧幅文字とは 環境によって、幅が1だったり、2だったりする文字のことで、具体的には、「○」とか「×」とか「α」とかそんな文字を指します。 CJK 環境だと、2 と解釈して欲しいけれども、それ以外の環境は、1と解釈して欲しかったりする文字です。 一覧としては、以下の URL のテキストで、A とついているものがそれにあたります。 http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt Emacs23 での扱い 使っている環境に依存します。具体的には、以下の2つに依存します。 # 23 と書いてありますは、主に 24 で確認しています。やっている事は同じはずです。 環境変数 LC_ALL、LC_CTYPE、LANG に何を設定しているか set-lang
日本語EUC（EUC-JP）にはいろいろあって頭がこんがらがってきたので、サルにもわかるように（つまり、自分があとから見て理解できるように）まとめてみた*1。まず、EUC-JPにはどんな種類があるのだろうということで、わたしの環境で実装例を確認できるものをピックアップしてみた。下図のうちeucJP-openとIANAのEUC-JPについては身近な実装例を思いつかなかったが、これを外すわけにはいかないだろうと思って入れておいた。 各EUC-JPのレパートリをまとめたのが、下図。eucJP-openには上図に示したようなバリエーションがあるが、レパートリは共通。「JIS X 0208の国際基準版・漢字用8ビット符号 + JIS X 0201片仮名」については、これを一言で表現できる呼称を思いつかないので、以下の図では仮に「TextEdit」と表記する。 下図は、各EUC-JPのレパートリと符号
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Vine Linux 4.2 で稼動していたサーバ PC に、突然電源が入らなくなってしまいました。ずいぶん古い PC だったので、あきらめてバックアップからデータだけ取り出して、別のサーバに移行することにしました。 ここで困ったのが、日本語ファイル名の扱い。バックアップデータは tar.gz で圧縮して保存していました。これを Windows 上に持ってきて 7-Zip を使って解凍してみると、日本語のファイル名がおかしなものになりました。 おそらく、日本語ファイル名の文字コードが異なるためでしょう。Vine 4.2 上では EUC-JP、Windows 上では Shift_JIS ですね。（ちなみに、Vine 5.x は UTF-8 になっていますね） さてどうしようか。使えるのは Windows マシンしかない。ファイル名の文字コード変換といえば convmv ですが、Windows
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2017年4月） 独自研究が含まれているおそれがあります。（2017年4月） 出典検索?: "東アジアの文字幅" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 「東アジアの文字幅」（英: East Asian Width）は、Unicode標準の附属書 (英: Unicode Standard Annex) の一つ。Unicodeに収録されている各文字の文字幅に関するヒントを与える East_Asian_Width 参考特性（英: informative property）を定めている。 東アジアのマルチバイト文字コード規格は必ずしも文字幅を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く