サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
ソフトウェアの日本語文字が中華フォントに侵食されていて想像以上の危機らしい「違和感すごい」 というのが盛り上がっていた。 「想像以上」は主観的だけど、個人的にはちょっと煽りすぎのように思った。 前提: Han Unification はひっくりかえせない そもそも、UTF-8 がよく使われるようになって、絵文字もはいった UCS で、Han Unification しなくてもいいのでは、という話はある。 でもこれは後の祭りで、今更ひっくりかえすのは無理だと思うので、ここでは検討しません。 ユーザー側の言語情報を参照すれば、日本語のグリフは選べる ほとんどの OS には、このユーザーの言語はこれですよ、という情報があって、それでメニューやボタンの文字が日本語になる。日付の表示方法とかも、これを参照する。統合漢字でも日本語のグリフでレンダリングしたい、というのは、8割くらいはこれで解決するはな
電子メール、ネットワーク機器集中管理、異常検知、分散処理、クラウド基盤などのシステム開発に従事。古代Rubyist。 CLI や TUI なアプリケーションを使っていると、端末の画面が崩れてしまうことがよくあります。 たとえば、こんな TUI が、 環境によってはこんな感じで崩れます。 スクロールなどをしながらしばらく使っているとさらにどんどん崩れていきます。 こうなってしまった場合、とりあえず Ctrl-l で画面を再描画することで、大抵はなんとか読める程度にリセットできますので、ことあるごとに Ctrl-l を連打することになります。 ですが、どうしようもないケースもままあります。 例えば、私の場合は以下のようなシチュエーションで困ります。w3m でテーブルなどを表示するとレンダリングが崩れる less でログの閲覧の際に表示されるべき文字が表示されず見落としが発生する Wander
iOS 10.3 でAPFSが本番投入されました。それでiPhoneやiPadが文鎮化するなどの深刻な問題はみられなかったものの、やはり無問題とはいかなかったようで。 iOS10.3で不具合の出るアプリは、APFS関連の影響かも（Unicode Normalizationの振る舞いが変わったらしい）。GoodReaderとDropboxの同期でエラーが出るようになったのだが、ファイル名に濁点を含むファイルを除いたら同期できるように。 — 山路達也 (@Tats_y) March 29, 2017 原因を調べてみました。 # !/usr/bin/envperl use strict; use warnings; use feature ':all'; use Encode; use Unicode::Normalize; use utf8; binmode STDOUT, ':utf8';
MacでPDFからコピペした時のNFD問題の対策。MacでPDFからコピペした文字が、濁点/半濁点が離れる。 「お読みください」 「お読みくた゛さい」Macのファインダーのコピーだと見た目的な違いが無いので判別が難しい。 原因MacOSのファイルシステムであるHFS+が使用している、UTF-8の正規化方法が「NFD」というもので、２文字に分けて正規化されてしまうことが原因。Mac でPDF からコピーした濁点/半濁点付きの文字列を Firefox に貼り付けた時におかしくなる問題の対処方法 対策とどこでクリアするか？ NFD → NFCに変換をする。 nkf（Network Kanji Filter）で変換が可能。UTF-8にもいろいろある どこで？ コピーした時点で変換する。 タスクランナーに組み込んで変換する。 とりあえずの前者の仕組みをMacのAutomaterでシェル
Unicode正規化（ユニコードせいきか、英語: Unicode normalization）とは、等価な文字や文字の並びを統一的な内部表現に変換することでテキストの比較を容易にする、テキスト正規化処理の一種である。一般に、正規化はテキストの文字列を検索や整列のために比較（照合、英語: collation）するときに重要である[1]。 Unicodeの正規化手段の基礎は、文字の合成と分解という概念である。文字の合成とは、基底文字と結合文字の組み合わせによる結合文字列を、単一の符号位置である合成済み文字にする手続きである。たとえば、基底文字 n と結合文字 ~ の組み合わせを単独の ñ 文字に変換する、仮名文字と濁点の結合文字の組み合わせを単独の濁点つき仮名とするなど。分解はその逆で、合成済み文字を結合文字列にする。分解は単一の符号位置を別の単一の符号位置に変換することもある。 Unicod
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?40歳目前の中年エンジニアが独りよがりにUnicodeとの思い出を書き綴ってみる。 記憶をベースに細かいことを気にせずに大枠の雰囲気が伝わるように書いてみる。 なぜUnicode? 先日MySQLのバージョンアップを行ったが、その時にCharacter setをutf8からutf8mb4に変換した。MySQLを普段使わない人はutf8mb4なに？と思うかも知れません。そうです、これはMySQL固有のものです。 どうやらMySQLは永らくUTF8は1文字が1～3バイトであることが前提の実装になっていた。 で、4バイトな文字が登場して、「
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
イントロPython2.6/3.0共にRC版がリリースされ、正式リリースが近づいて来ました。Python3.0の大きな変更の一つが、Python2.xのstrとunicodeがunicode文字列のstrに統合され、従来のstrの代わりにbytesを導入することで、バイト列と文字列が明確に分けられたことです。 現在、Python2.5では、unicode文字列の内部表現がucs2のものとucs4のものがあり、それぞれの間では拡張 モジュールの互換性がなくなっています。Python2.6/3.0でこの状況がどう変化するのか調べてみました。Python2.xのunicode内部表現についてPython2.5/2.6では、configureオプションに、--enable-unicode=ucs[24] というものがあり、デフォルトでは2になっています。 また、FedoraやUbuntuの
絵文字肌色問題Appleが、Unicode 8.0で入る見込みのFitzpatrickスケールを実装したら、デフォルトを意図していた黄色い肌色の絵文字が黄色人種だと解釈されたり、赤毛の絵文字も入れて欲しいと要望が出たりと、まあ絵文字をめぐる事態は明らかにヤバイ方向に転がりだしている。絵文字の「肌の色」を5色から選べるようにしたアップル « WIRED.jp 黄色い肌色の絵文字の件は、SankeiBizでも記事になっている。その中に、“奇妙な”記述がある。 公開された6種類の肌の色が並んだ写真を見ると、黄色がアジア系人種をイメージしているのは明らかで、アップルの説明はいかにも苦しい。 アップル「黄色い顔文字」に中国で批判噴出 「あんな黄色い奴みたことない」「アジア人への偏見だ！」（1/3ページ） - 産経ニュース 「アップルの説明」というのは、「黄色は民族的中立(ethincally n
2019年8月6日に開催されたヤフー名古屋Tech Meetup #3の内容です。 #3 は「Webフロントエンドを支えるノウハウ」をテーマに開催しました。 JJUGCCC 2019 fall g3のセッション資料です。 「ちょっと凝ったことをしようとすると大量のXMLを書かなきゃいけない」「プラグインを並べてもうまく動いてくれない」など、Mavenは誤解され敬遠され、Gradleなどの他のビルドツールにシェアを奪われてきました。 が、依然としてMavenはJavaのデファクトスタンダードなビルドツールに位置づけられており、マスターする価値は十分にあります。そして良く学んでみると、そもそもXMLで過度なカスタマイズしようというのが誤った使い方だったのに気づきます。そこへ至るにも、タスクランナーの延長線上にある他のビルドツールと異なり、Maven独特なライフサイクルとプラグインの関係性もき
Unicode Character 'SNOWMAN' (U+2603) Browser Test Page Outline (asSVG file) Fonts that support U+2603 Unicode Data Name SNOWMANBlock Miscellaneous Symbols Category Symbol, Other [So] Combine 0 BIDI Other Neutrals [ON]Mirror N Index entries snowy weather weather, snowy SNOWMAN Comments snowy weather Version Unicode 1.1.0 (June, 1993) EncodingsHTML Entity (decimal) ☃HTML Entity (hex) 
Everything you did not want to know about Unicode inPython 3 written on May 12, 2014 Readers of thisblog on mytwitter feed know me as a person that likes to rant about Unicode inPython 3 a lot. This time will be no different. I’mgoing to tell you more about how painful “doing Unicode right” is and why. “Can you notjust shut up Armin?”. I spent two weeks fighting withPython 3 again and I nee
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
背景Python 2 用のコードを書くときは、Python 3 対応を見越して # -*- coding:utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native stringPython 2 には2つの文字列型 str (bytes) と unicode が
Python 3以降との違いを調べていたときのメモPython 2.7でも試せるもの 以下にPython 2.7でimportをすればPython 3風に書けるものを列挙しておきます from __future__ import divisionPython 2.7では割り算「/」の結果は切り捨てでしたが、Python 3以降ではちゃんと小数点以下まで保持されるようになります 以前のような切り捨ての割り算は「//」演算子でできるようになります >>> 3 / 2 1 >>> from __future__ import division >>> 3 / 2 1.5 >>> 3 // 2 1 from __future__ import print_functionPython3では「print」が関数になったので「print(何か)」のように書かないといけなくなります また改行したく
XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
