*：8 ビット バイト モード 型番をあまり大きくすると処理が遅くなります．このプログラムではエンコード可能な型番を最大 10 に制限してあります． 最大の型番に合わせてあらかじめ表示領域を用意しているため，入力データ長が同じであっても最大の型番を大きく設定するとそれだけ処理が遅くなります． 処理速度はブラウザの種類／バージョンによってかなり差があります．特に入力データが長くなると差が顕著になります．私がテストしたブラウザの中では Netscape 4，Netscape 7 が比較的速く，Opera 6 はかなり遅いという結果になりました． エンコード可能な最大型番は，プログラムの最初の方にある MAX_VER = 10; で定義してあります．この数字を大きく（最大 40）すれば，より大きな型番の QR コードを作成できるようになりますが，型番を大きくするとそれだけ処理が遅くなります． 表
unicodeに関するgazi4のブックマーク (21)
-
gazi4 2020/05/15
-
UNICODE ZIPに対応した圧縮/解凍ソフトについて - Qiita
概要 ZIPファイルはPhil Katzさん(PKWARE)が開発した、主に Windows 向けの圧縮ファイル コンテナです。 Windows XPでExplorerが対応した為か、今ではほぼ標準的に世界で利用されている(様子)。 また現在では、JavaのJAR形式やOpen Document、Office Open XML、FirefoxのプラグインのXPIなど様々なプラットフォームで多種多様な利用がされている。 ZIPファイルは途中からUNICODEにも対応しているフォーマットなのだが、未だに浸透度が低く、文字化けの問題が多く起きる。そもそも、正しいUNICODE ZIPを作成出来るツールは？と言うことで私見で幾つかのWindows向けのツールを調べてみた。 補足 本記事は2017年1月に調査した結果の記して下書きになっていたものを多少手直ししたものです。 (勿体ないので) 最終的な
-
一般社団法人文字情報技術促進協議会
Unicode IVSは、外字を使わずにいた字を表現できる 国際標準規格です。（Unicode、ISO-10646規格の一部）
-
-
EPUBの外字画像の使用事例について
JEPAの村田真さんよりEPUB Accessibility 1.0絡みで現状のEPUBでの「外字画像」の使用事例を知りたいとのお話をいただきましたので、私の知る限りで書いてみます。何人かの方にもお話をお聞きし、参考とさせていただきました。 どういった種類の外字かをわかりやすくするために、各種文字集合規格のマップを作成し、各外字がどこに位置するかを以下に図示しました。解説の番号に対応しています。併せてご参照ください。 画像内で使用している文字関連の専門用語をまとめて記述しておきます。 Unicode：1991年にバージョン1.0が出版された国際的な符号化文字集合の規格。世界中の文字を単一の文字集合で表記することを目的としている。2016年6月にUnicode9.0が出版されている。詳しくはこちら。 JIS X 0208：1978年に最初に制定された日本の符号化文字集合の規格。改訂年度によっ
-
Unicode 10.0リリース、変体仮名を収録 - yanok.net
Unicode 10.0が2017年6月20日にリリースされました。今回は8,518文字が追加されています。 日本語話者にとって最も関係しそうなのは変体仮名の導入でしょう。 変体仮名とは 現在、平仮名は1音につき1文字ですが、以前は同じ音に対して複数の書き方がありました。例えば、平仮名の「か」は漢字「加」が元になっているもので、これ以外に「か」と読む平仮名はありませんが、かつては「可」を元にした仮名も使われていて同じく「か」と読まれました。そうした複数のバリエーションがあった仮名を明治時代に標準化したものが今の平仮名です。このとき採用されなかった異体が変体仮名と呼ばれるものです。 変体仮名は今日では文章を綴るのには使われませんが、そば屋の看板などで装飾的に用いられることがあります。 Unicodeにおける変体仮名 変体仮名はUnicodeではBMPでなく面01に配置されました。U+1B00
-
源ノ明朝／角ゴシック-４ Unicodeの漢字統合 – ものかの
源ノ明朝／角ゴシック-３の続きです。 ここでは源ノ明朝／角ゴシックを使うときに知っておきたい「Unicodeの漢字統合」を説明します。そもそも、どうしてここでUnicodeが出てくるのでしょうか。 どこもかしこもUnicode Unicodeは、世界中の文字を同時に一緒に使うためのものです。இとか☯︎とか∭とか、さらに😀のような文字がここで日本語と一緒に表示できるのは、ここにいるのがUnicodeの文字コードだからです。 パソコンやスマホにデジタルの文字が表示されていたら、そこにいるのは例外なくUnicodeの文字コードだと思ってかまいません。そのくらい今は満遍なく広く行き渡っています。源ノ明朝／角ゴシックもUnicodeがネイティブな文字コードです。 それぞれの文字コードが「何の文字なのか」は、１文字ずつ人間が考えて決めています。 例えば、“あ” は日本語の平仮名のひとつ。他のいろいろ
-
源ノ明朝／角ゴシック-３ デジタルの文字 – ものかの
源ノ明朝／角ゴシック-２の続きです。 ここで源ノ明朝／角ゴシックからすこし離れて、先にどうしても知ってほしいフォントの基本的なことをお話しします。回り道のようですが、急がば回れです。 今の私たちは、日常的にパソコンやスマホで文字を読んでいますよね。読むだけでなく、自分で文字を入力したりもします。そのときに見ている文字は、すべてデジタルの文字です。 文字を読むとき、私たちに見えているのは文字の形です。しかしデジタルの文字は、見えるデータだけではなく、見えないデータも一緒にくっついているのです。 私たちに見えるのは「フォントのグリフ」です。グリフは人間が見るためのデータです。 そこに、人間には見えない「文字コード」がくっついています。文字コードはコンピューターのためのデータです。人間のためではないので、人間が感じるようにはできていません。そこに文字コードがあることは、人間には絶対に分かりません
-
-
Unicode正規化 用語の混乱について 第4.2版 – ものかの
初版 2010/4/5 第2版 2013/5/10 誤解を修正。全面的に書き直し。 第3版 2014/7/13 なるべく分かりやすく全面的に書き直し。 第4版 2015/5/20 さらに分かりやすく全面的に書き直し。 第4.1版 2015/5/27 まだ分かりにくいと不評なので書き直し。 第4.2版 2015/5/27 さらに分かりやすく調整。 Unicode正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日本で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか？ “合成済み文字” と “合成文字” の２か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。
-
-
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
-
HFS+のテキストエンコーディング – ものかの
HFS+はファイルやフォルダなどのアイテム名をどのテキストエンコーディングで扱っているのでしょうか？ Appleは最近までこの情報をドキュメントに記載して公開していたのですが、今はしていません（2016年10月現在）。それでも第三者によるアーカイブがかろうじて残っており、典拠として貴重なのでここに記録しておきます。 2009年時点のFile Systems and Unicode Support 追記：いつのまにかリンク切れしていました。キャプチャを貼っておいてよかった…。 見ての通りUTF-16ですね。インターネット上ではUTF-8-MACであるとの説明が散見されますが間違いです。 HFS+のUnicode正規化形式 Unicode正規化形式はUAX#15で4種類が正式に決められています。HFS+はそのうちのNFDをさらにAppleが改変した特殊な正規化形式を実装しています。アイテム名は
-
-
InDesignで引用符はなぜ呪われているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリでも触れたが、InDesignにはプロポーショナル（やイタリックや半角）の引用符を縦組みにするとグリフが正しく回転しないという、よく知られた問題が存在する（下図）。今回は、この問題について詳しく見てみようと思う。 InDesignは、「ある文字を縦組みの際に回転するかどうか」を、Unicodeの符号位置を基準として決定しているものと思われる。たとえば、U+0021 EXCLAMATION MARKなら回転するし、U+FF01 FULLWIDTH EXCLAMATION MARKなら回転しない（下図）。 だが、Unicodeの符号位置を基準とする方法は、ユーザによるグリフ置換が行われている場合には、うまく機能するとは限らない。たとえばU+0021 EXCLAMATION MARKに'fwid'タグを適用して全角グリフとした場合は、見た目は（置換なしの）U+FF01と同じCID+
-
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
-
最近、モリサワのようすがちょっとおかしいんだが。 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ところで、モリサワのPr6Nフォントがやばいらしいですね。 twitterで話題になってたね。 まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか？ リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。 うー、それはかなりイヤですね。 だよね。新バージョンのほうは、IVS（異体字シーケンス）対応版なんだけど、cmapも新しいのになってるから。 しーまっぷ？ cmapっていうのは、符号位置とグリフの対応表。DTP用の日本語OpenTypeフォント（Adobe-Japan1フォント）には、Unicodeに入ってないグリフもたくさん入ってるでしょ。 入ってますね。 「Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録さ
-
Unicode標準6.3が公開、日中韓の互換表意文字改善
Unicode Consortiumは、Unicode標準バージョン6.3を発表した。日本語・中国語・韓国語の互換表意文字に関する改善などが盛り込まれた。 Unicode Consortiumは2013年9月30日、Unicode標準の更新版となるバージョン6.3を発表した。日本語・中国語・韓国語で使われている、字形が異なるが同じ意味の文字（互換表意文字）に関する改善などが盛り込まれた。 公式ブログによると、バージョン6.3のUnicode双方向アルゴリズム（Bidirectional Algorithm）では、丸カッコやかぎカッコの組み合わせのレイアウト一致を図り、カッコの表示方法や位置などを調整したという。また、テキスト処理を孤立化させる仕組みを提供し、別々のソースからメッセージを、文字の順番を乱すことなく組み立てられるようにした。 日中韓の言語への対応では、1002文字の日中韓の互換
-
UTF-8-mac - Apple コミュニティ
shinichiro.aska さんによる書き込み: Gitboxやその他の多くの製品で文字化けが発生する原因となっているUTF-8-macを廃止し、UTF-8を利用したいです。 実際にトラブルに遭遇されているようなので、その点はお気の毒ではあります。 UTF-8-MAC に関する情報は「MacWiki - UTF-8-MAC」や「Unicode正規化」に詳しいようです。「Unicode正規化」はなかなか詳しいようです。私もじっくり読んでみたいと思っています。「MacWiki - UTF-8-MAC」の方はもう１つ程詳しくはありませんが、簡明にわかりやすく記述されています。それによれば 将来的には UTF-8 を扱うアプリケーションは全て分解をサポートすべきであると考えられますが、 現在のところ NFD で正規化された UTF-8 は OS X のファイルシステムでしか使われていない状況に
-
旧AiファイルをMac版CS以降で開く時に文字化けを防ぐ方法 – ものかの
更新：CC以降のマッピングファイルの場所を追記しました。 注１：ここで説明する方法は、くれぐれも自己責任で慎重に行ってください。 旧Aiファイル（＝シフトJISベースで保存されるv10までのAiファイル）をMac版CS以降で開くと、シフトJIS外字がすべて化けます。こんな具合に。 見て分かるように、化けるだけではありません。文字そのものが完全に消失している箇所まであります。（イラレ8の文字化け見本ファイル） OpenTypeが登場するまで、日本のMac DTPでは83pvの和文PostScriptフォントが使われていました。83pvはWindowsのシフトJISであるCP932とほとんど同じです。シフトJIS外字領域の13区にもCP932と同様に丸数字、ローマ数字、単位記号などがあり、外字フォントなしで使えたため、日本語のMac DTPで普通によく使われました。その外字領域の文字がMac版
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました