Java 18正式リリース。デフォルトのCharsetが「UTF-8」に、シンプルWebサーバ搭載など新機能
Java 18正式リリース。デフォルトのCharsetが「UTF-8」に、シンプルWebサーバ搭載など新機能 Javaの新バージョン「Java 18」が正式にリリースされました。 Java 18 is now available! #Java18 #JDK18 #openjdk Download now: https://t.co/hTJU1ZzAWQ Release notes: https://t.co/Xdkj5TObNP API Javadoc: https://t.co/izFBPlYkd9 Features: https://t.co/3z0l5sXyDX pic.twitter.com/Ct1BvYmDYs — Java (@java) March 22, 2022 Javaは6カ月ごとに「フィーチャーリリース」と呼ばれるバージョンアップが行われ、そのなかの1つのバージョンが
全角半角混在の文章で 1 行に半角何文字分あるか調べる方法
「ソースコードは 1 行あたり 80 文字以内」とか「コミットログは横幅 72 文字以内」とか、文字数に関するルールはいろいろある。 ルールを徹底するには機械的に判定したい。と思って、簡単なスクリプトを書こうとした瞬間、意外と「1 行あたりの文字数」をカウントするのが難しいことに気付いた。 たとえば、「あA」は「全角 1 文字＋半角 1 文字」なので半角 3 文字分としてカウントしたい。 しかし、UTF-8 の世界では「あA」の文字長は 2 だし、バイト数は 4 (あ=0xE38182、a=0x41) である。 EUC-JP や Shift-JIS の時代なら、単純に「あA」は 3 バイトなので「半角 3 つ分」とすぐ分かったのだけども… (逆に文字長を調べるのが面倒だった)。 はて、どうするか？ というのがこの記事でいいたいこと。 East Asian Width を見よ いろいろとググ
いまさらgrepが10倍高速化したのはなぜか – はむかず！
最近GNU grepコマンドの最新バージョンがリリースされ、速度が10倍になったとのアナウンスがあった。それを聞いて、なんであんな枯れた技術に10倍もの高速化の余地があったのだろうと不思議に思った人も多いだろう。 ニュース記事：grepコマンド最新版、”-i”で10倍の高速化 本家のリリースノート：grep – News: grep-2.17 released [stable] 今回のリリースでは正確には、マルチバイトロケールで、-iオプション（–ignore-case、つまり大文字小文字を区別しないオプション）をオンにした時の速度が10倍くらいになったそうだ。 なぜそんなに速くなったのか？逆を言えば今までなぜそんなに遅かったのか？ そもそも、多くの日本人にとって「大文字小文字の区別」というと英語のアルファベットか、せいぜいフランス語とかドイツ語とかのアクサン記号・ウムラウトがついたものく
L'eclat des jours(2012-04-05)
_ ユーザ入力の住所は怖い データベースには、ADDRESSみたいなカラムがあり、そこはvarchar(64)みたいになっているとしよう。 で、これまでは従業員が入力していた（たとえば、客が書いた配送先住所を手打ちで入れていたりとか）とする。 「これまで」というくらいだから、何も考えずにシフトJIS（でもその実体はWindows-31J）にしていたことだろう。 で、なぜかそれをユーザーがWebから直入力できるようにしてしまったとする。 これは、つくづくと相当な死亡フラグなのだが、問題となったという事例を見ない。 不思議だ。他の人たちはどうやっているのだろうか？ ユーザーは、こちらが驚くほど多様だ。 たとえば、「ザ・グレート歌舞伎町」というマンション名があるとする。 「・」を知っている人は「/」を変換するだろう。知らなくても普通はそう入力するような気がする。全然知らなくても「中黒」という用語
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外字を使うのはやめてくれ！ Unicodeへの移行を呼びかけるMicrosoftの公式ブログ記事が話題に／今や「メモ帳」でさえテキストファイルをUnicodeで保存する時代！ Shift_JISはやめよう【やじうまの杜】
