書体関係 Wiki - unixuser200403-2
Pango とその周辺 図?? に Pango におけるフォントの取り扱いに関するフローチャートを示す。この図の中で、実線はデータが直接やりとりされることを表している。また、点線はデータが間接的に (プロセス間通信を使って) やりとりされることを表している。そして線の色については、 ピンク フォントファミリ名による一覧の取得 緑 XLFD による一覧の取得 黄色 グリフのレンダリング 赤 フォントファイルへのアクセス という意味を表している。 ★「図? Pango におけるフォントの取り扱い」 gdk-font-diagram.eps.gz Pango は次の3つのフォントシステムを使用する。 FreeType2? Xft Xlib (コアフォントシステム) これらのフォントシステムのうち、実際にどれを使用するかを決定するのは GDK*7 である。 FreeType2? は、GDK が D
バイナリを cat して文字化けした端末を直す - ~fumi/ChangeLog
便利なシェルスクリプト見せろ URL:http://pc.2ch.net/test/read.cgi/unix/996949546/ から． shell From: [493] 名無しさん＠お腹いっぱい。 <sage> Date: 04/02/23 07:56 #!/bin/sh echo -ne "\017"; # SI/SO による半角カタカナを抜ける echo -ne "\e(B"; # ESC $ B による全角モードを抜ける echo -ne "\e[0m"; # 文字の色をデフォルトに戻す exec /usr/bin/reset _______________________________________________________________________________ perl From: [355] 名無しさん＠お腹いっぱい。 <sage> Date: 03
LC_ALL環境変数とsortコマンド - sileのブログ
自分の環境では、sortコマンドを実行する時にLC_ALL環境変数に'C'をセットするかしないかで、処理終了までの時間が著しく変わる。 # 約40万行のデータ > wc -l words 392126 words # 入っているのはUTF-8の日本語(IPA辞書を利用) > head words やぼったい やぼったし やぼったから やぼったかろ やぼったかっ # 普通のソート > time sort words > /dev/null real 0m37.158s user 0m37.098s sys 0m0.056s # LC_ALL=Cでのソート > time LC_ALL=C sort words > /dev/null real 0m0.293s user 0m0.284s sys 0m0.008s ロケールを考慮してソートするかどうかの違いだと思うが(LC_ALL=Cの場合は、
Wanderlustと文字コード - 技術日記＠kiwanami
Wanderlustをもう5年以上使っているが、丸数字を含むメールで苦労していた。ローカルのファイルの読み書きは問題ないが、Wanderlust上では送信・受信でうまくいかない。 昔は Content-Type に charset=ISO-2022-JP って書いてありながら、iso-2022-jpの文字集合にない文字を使うようなメールは容赦なく切り捨てていた。添付ファイルの扱いも変だし、そんなうんこメー(ry 時は流れて、今や方眼紙Excelとメールに明け暮れるスーツな毎日。今時メールで丸数字や人名にハシゴ高が使えないメールソフトを使い続けるのは単に痛い人でしかない。というより、FromやToの欄にiso-2022-jp以外の文字集合の人（例えば(株)とか）がいるだけでアウトなので自分が辛い。 もう世間はGmailでUTF-8で本文を送っても問題が無くなり、しかも cp50220 という
Macのバックスラッシュと円マークの違いの洗礼を受けた - @kyanny's blog
知識として知ってはいたけど、JISキーボードを使ってないせいもあっていままでハマらなかったが、今日ついにMacのバックスラッシュと円マークの違いの洗礼を受けた。 細かいことはここなどに詳しい。 7 | 2004/06/06 05:02:40 | 確認待ち | 保留 | 中 | 重大 | 未定 これには複雑な事情があります。 まず、Macでのクリップボードとのやりとりには、UTF-16またはMacJapaneseが使わ れます。 Emacsの場合はMacJapaneseです。 MacJapaneseとUnicodeでは、次のような変換が行われます。 \x5C |0 # YEN SIGN \x7E |0 # TILDE # Apple change from standard Shift-JIS \x80 |0 # REVERSE SOLIDUS # Apple addition; chang
文字コードの基本：ITpro
コンピュータで文字を取り扱う際，文字コードについて知っておく必要があります。特に日本では複数の文字コードが混在して使われる上，プラットフォームによって取り扱う文字の種類も異なることから，状況が複雑になっています。本記事では文字を正しく取り扱うための基礎知識について簡単に紹介します。 コンピュータはすべてのデータを数値として取り扱います。文字を取り扱うときも，数値に対応づけて処理します。 例えば，「ようこそITpro」というテキスト・データをWindows XPのメモ帳で作成し，ファイルに保存します。そのファイルをバイナリ・エディタで開くと写真1のような数値が並んでいることが分かります。各文字と数値は表1のように対応づけられています。
UTF8 フラグあれこれ - daily dayflower
UTF8 フラグについてわかってるつもりだったんですが，utf8::is_utf8 considered harmful - Bulknews::Subtech - subtech を読んで混乱したので，自分なりにまとめてみました。間違いがありましたらご指摘よろしく。 まとめ スカラー変数の内部表象の状態を示すものとして UTF8 フラグというものがある スカラー変数は（リファレンス等は別として）下記のものを格納できる (A) 文字列（内部表象: UTF-8） (B) 文字列（内部表象: ISO-8859-1） (C) バイナリ列 純粋なバイナリストリーム（画像ファイル等）かもしれないし， UTF-8 octet stream かもしれないし， CP932 octet stream かもしれないし，etc, etc ... Perl は（後方互換性確保などの理由から）ISO-8859-1
MySQL 文字化け問題を本気で直す
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
Python でUTF-8, shift_jis, euc_jpなど日本語を使う方法
[Home] [Setting up Mac OS X] [Python]: [ファイルを読む] 日本語を使う Pythonで日本語を使う Python 2.4以降では、標準で日本語を扱うことができます。 PythonのソースコードをUTF-8で書くには 日本語を扱うPythonのスクリプトの中では、UTF-8の文字コードを使うのが 楽です。 Mac OS Xのターミナルで日本語を扱う場合は、 ここの「4. Terminalの設定を変える」の 指示に従ってください。 以下、ソースコードの簡単な例を示します。 #!/usr/bin/env python # -*- coding: utf-8 -*- import re jtext = u'子猫が隠れんぼをしています' print 'jtext has', len(jtext), 'Japanese characters.' if re.se
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
エンコードマニアックス - 各種エンコードやハッシュを一発作成
SHA-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 SHA-384 38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b SHA-512 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
UTF-8なターミナルからEUC-JPベースのサーバーにログインする：テクノロジー解放日記：オルタナティブ・ブログ
（技術的なメモをエントリにしてみる実験です） 最近のLinuxディストリビューションはUTF-8がデフォルトになっているので、相互に利用するには問題は無いのだが、少し前のサーバーなんかだと、EUC-JPで環境構築されていることも多く、sshでログインする際など、文字コード設定がいちいちややこしい。 今まで、私も毎回ターミナルの設定を変えたり、ターミナルにサーバー毎のプロファイルを作っていたりしたのだが、IWAMURO Motonoriさんらが中心に開発されている「cocot」を使ってみて、感動した（いまさらですかね？）。 例えば、私の実例だと、LANG=ja_JP.UTF-8なMac OS XのターミナルからLANG=ja_JP.EUC-JPなサーバーにログインして、vimで日本語ファイルを編集しなければいけないような場合に、 $ cocot -t UTF-8 -p EUC-JP ssh
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字コードに起因する脆弱性とその対策
ma<s>atokinugawaの日記
azito.com
MacOSX の Java - odz buffer
舊 平成拾捌年神無月捌日 (火・曇):遅刻した。 // 辭めて仕舞へば良いのに。 // 晩御飯。 // Perl と Python で文字種を判別する。 - Pyon's Diary(2006-11-28)
http://72.14.253.104/search?q=cache:JCrNKUR3CMcJ:wota.jp/ac/%3Fdate%3D20061011+mysql+%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89%E3%80%80db&hl=ja&gl=jp&ct=clnk&cd=2&client=firefox