Tumblrまとめ（4/11-30）

Mac OS Xのメンテナンス

無料で使えるオープンソースのベクターアート集
http://www.vectorart.org/

メイリオがMacOSXでも使える
有名な海津さんのblog

<BR>と<P>

TimeCapsule

Mac系テクニカルライターのスクリーンダンプ（キャプチャ）術
システム環境設定のアピアランスダイアログ内の「滑らかな文字のスタイル」は「標準-CRTに最適」に。

フォント・マネージメントツール

アウトライン化してもPDF内の文字が文字として保持されているという話

たとえば「xdoc2txt( http://www31.ocn.ne.jp/~h_ishida/xdoc2txt.html )」を使って、そのPDFファイル（全文字をアウトライン化してあるもの）をtxt化してみると、まるっとごっそり隅から隅までお見通しなカンジで、文字列を抽出できてしまいました。

ヘアライン修正
RIP側で修正するものだと思ってます。

JPEGに出力するソフト
お客さんからPDFよりJPEGで！って要望が多いですから。

カラマネの基礎知識 （No.92）　

ブラウザからMacをリモートする
まだ実用化は先だが、いずれ在宅で出力業務ができるようになるかも。

突然メールが送信できなくなった
このシリーズは面白い^^
サブミッションポート詳細
こんどは先方からのメールが届かない!!
なんというオチ。。（DNS逆引き設定騒動）
関連1
関連2

AppleScriptのソースコードをScriptEditorで開く

OOoBasicについてのWebサイト情報

Acrobat 8 バッチシーケンスの制限・配置

XHTMLとCSS
p は paragraph（段落）。ul は unordered list（番号の付かない箇条書き），li は list item（箇条書きの項目）。ol は ordered list（番号付き箇条書き）。dl は definition list（定義リスト），dt は definition term（定義する用語），dd は definition description（定義の記述）。hr は horizontal rule（水平の罫線）。em は強調（emphasis）, br は line break（改行）。
解説がていねいです。

【Soft】Avast!4.8インストールによるPCフリーズの対策方法
とりあえずアンインストールしてから調子はいい。

Illustrator CS2・CS3で「入力変換ウィンドウ」を実現するフリーのプラグイン

三島梅花藻さんのjs
三島梅花藻さんの「そのままアンカー付きオブジェクト化.jsx」をInDesign CS3で使うで紹介されてました。

表組は XMLを利用するほうが圧倒的に便利

XMLのタグにスタイル割り当てられるし。
体裁を先に決められる場合はおすすめです。
エクセルのXML化は、がんばればエクセルとエディタでなんとか。
FileMakerから吐き出して、XSLTという手も。
あとは、市販のタグ付けソフトを使うか。

PDF印刷時の体裁の崩れ

XHTMLでやりがちな8個の間違い

とりあえずこんなとこで^^

Tumblrまとめ3

Illustratorでのアンカーポイント数の最大値
鏡面反射する文字の作り方
DTPヨタばなし
DTP関係の掲示板で何度かみかけるpi&puさんのblog
ブロッキング防止パウダー
モニタが何かの拍子に上下逆になっちゃった
Windows XPをセットアップするときに気をつけていること
１、コンピュータの名前の付け方
２、管理者パスワードの設定
３、ユーザー名の付け方
Vector Magic
bitmap画像を簡単なクリックだけでベクターデータに変換してくれる
HTMLからPDFに変換するWebサービスAPI
ハイフンの誤用
イラレでスライスがズレないようにする
まず表示を「ピクセルプレビュー」にします。そして、表示メニューから「ピクセルにスナップ」をチェックです。これで問題は解決。
出力の手引きWeb
Mac OS Xのズーム機能
controlキー+ホイール操作でユニバーサルアクセスのズーム機能が使える
Ｍａｃからのfax送信方法
現行機種ではオプション
WindowsからMacにVNCで接続
どうやってマークアップしますか？
写真に溶け込む文字を作る
Excel　セル内改行を除去する
「ほかの人またはプログラムによって使用されています。」などとエラー
HTMLとCSSからPDFを生成するPrince XML
AcrobnatのOLE機能(IAC)、又はPDFについて調査。
モアレ修正
写真を一瞬でセピア色にする方法
「色彩の統一」　にチェックをし、「色相：30　彩度：30　明度：5」にしてOKをクリック。
法人向けのレンタルサーバーの条件
色変換の仕組
人力検索だけを検索するカスタム検索
InDesign互換ファイルの効用
漢和辞典で文字コードを調べる
HTML解説サイト
【WindowsXP】社内LANなどで他のマシン時にアクセスする場合パスワードを求められ困る場合
Guestのパスワード設定を変えればいい

マイコンピュータ>右クリック>管理
コンピュータの管理のウィンドウが立ち上げる

ローカルユーザーとグループ>ユーザー　で
Guestのパスワードを設定しなおす

特にパスワードなしでアクセスしたい場合は
パスワードの部分は「空(から)」でOK

Classic環境でQuarkXPress4.1を利用していた場合、起動できなくなる場合
背幅の計算式
（本文ページ数 ÷ 2） ×紙の厚さ＝背幅（ミリ）
写真の大敵「バンディング」を消すには
画像は8ビットで作業し、調整レイヤーおよびマスクが乗った状態ですね。これを画像統合しないまま16ビットモードに変換した後、画像を統合してみてください。するとバンディングが消えるのです。
ブラウザに表示される色について
PDFをFlashに変換してパブリッシュするWebサービス
フォトショップが立ち上がらなくなったときの対処法

1. Photoshop CS/CS2 を起動した直後に Ctrl + Alt + Shift キーを同時に押し続けます。
2. 「Adobe Photoshop 設定ファイルを削除しますか？」と表示されたら [はい] をクリックします。

ショッピングカート

Tumblrまとめ2

拡張子pczのファイルを開く
QuarkXPress3.xや4.xのトンボ
日本語段落コンポーザと日本語単数行コンポーザ
欧米の場合スミインクの濃度が薄い
htmlの骨組
ハードディスク十訓
NTFSフォーマットのディスクの読み込み
Windows PCの修理の際にも、Macが大活躍しています。Windows XP上でうまく読み込みできないハードディスクでも、Macであればすんなり認識するものもあり、データのバックアップに大いに役に立っています。
Illustratorのファイルだけをサムネール表示
文字の中に写真を入れる
Rubyについて
「$」ドルマークの意味
絶対参照
DTPデザイナーの育児日記
ふりがなを下に表示する方法
鏡面仕上げのjavascript
文字化けの原因
輪郭抽出器
Open Publisher
XMLをDB化してInDesignに流し込みWord→XMLソフト、DBシンクロ機能も搭載
Macから来た画像データエラーの対処
｢編集/環境設定/ファイル･クリップボード｣でリンクされたEPSに低解像度の表示用画像(プレビュー)を使用のチェックを外す
Excelで作成した表をIllustratorへ
貼り付けるExcelの表の背景を、セルの書式設定－パターン－で、白の塗りつぶしにしておくと空白のセルの罫線が出ないようにできます。
不完全なPDF書き出し
「InDesignメニューバーのPDF書き出し」の印刷用では不完全なPDFらしくダメ。
PDF/X1aなら問題ないらしい。
HTML文書からPDF文書の指定ページにリンクするには
例：〈a href=”http://www.keiyu.com/test.pdf#page=3”〉3ページ目を表示
大容量データを渡す時のインターネットDisk使用例
Justsystemもある。
マンセル表色系の色相

印刷会社の裏技は必須！

Tumblrの使い道

派遣先にてOS9環境で確認。
NetscapeNavigator7で見れた。ただし、書き込みはできず。
このbloggerに似て軽いもののtag付けができないのがちと残念ながらメモにはちょうどイイ。
タイトルがUntitleだったので「バケツ」に修正。

使い道としては自宅にて（これは！）というものをTumblrに登録。
派遣先にて仕事の待ち時間に読む→このblogにtag付け登録がいいかも。

で、今日見つけたのが名解。
作者のイケッチさんは、せうぞーさんのBBSによく登場します。
OS-Xでしか動作しないのが残念な限り。

ググるとよく出てくるUNi*fIXはリンク切れのため手軽に変更できる方法は
文字化け解消サイトで紹介したhttp://www.shtml.jp/mojibake/google.htmlがGOOD！
寺にもレスつけて紹介したなぁ。

外字をコードで入力する

http://sharots.seesaa.net/article/78551825.htmlより

崎の異字体（﨑）や山が上にある崎（嵜）、はしごの高（髙）、船の左側が公（舩）、桑の異字体（桒）など探しにくい感じがあります。

エクセルなどで表を作る際、人名でコード入力が必要な時があります。

SMAPのくさなぎ君の「なぎ」は「彅」です。

コード入力の使い方は例えば

ＩＭＥでローマ字入力なら
「﨑」という字はシフトＪＩＳコードで ED95ですが、

えｄ９５

となってしまいます。

でも、このままでＦ５キーを押せば、ＩＭＥパッドが開いて一覧で「﨑」という文字が浮き上がっているはずです。
欧文は大文字でも小文字でも構いません。

 
■探しにくい漢字
http://www.sharots.com/linkhtml/filecon.htm#kanjiより

バックスラッシュを円記号で表記

http://blog.goo.ne.jp/xmldtp/e/69d0a6cf8bd58ffe45380566644dfe27より
前のblogで円記号がバックスラッシュに変わっていたのは文字コードの問題だったのね。
で、円記号で表記させるために「＆＃１６５；」を使ってみた。

一応半角スペースは¥s、 タブは¥t、リターンは¥r(Macなので改行コードCRで作業している。WinならCR/LFなので¥r¥nとする必要があるだろう)に置き換えた。

ついでにminiネタ
http://docs.info.apple.com/article.html?artnum=302152-jaより

“disc”は、オーディオ CD、CD-ROM、DVD-ROM、DVD-RAM、DVD ビデオディスクなどの光学式メディアを指します。“disc”には読み出し専用のもの (ROM) と、一度だけコンテンツを作成する（ファイルに書き込む）ことができるもの（複数回にわたる作成操作を行わない場合の CD-R や DVD-R など）と、消去して何度でも書き換えられるもの（CD-RW、DVD-RW、および DVD-RAM ディスクなど）があります。
“disc”はすべて取り外し可能です。つまり、デスクトップや「Finder」からマウント解除またはイジェクトすると、コンピュータから物理的に取り出すことができます。

“disk”は、磁気媒体を指します。たとえばフロッピーディスクやコンピュータのハードドライブのディスク、外部ハードドライブ、iPod もこれに相当します。“disk”は、意図的にロックやライトプロテクト（書き込み禁止）をしない限り、常に書き込み可能です。1 つの“disk”を簡単に複数の小さなボリュームに分割（パーティション設定）することもできます。

捜し物の途中で

昨日の日記の問題解決を捜している途中
http://www.majima.net/mac/113/より

File Juicer は PDF, Word, PowerPointなど各種書類からテキスト・画像・動画を抽出してくれるシェアウェア(€9.95)だ。

仕事でホームページの更新・作成を行うときに大いに力を発揮してくれる。

よくあることで、原稿をワードファイルやPDFで頂くことがある。
このときに書類に含まれている画像もページにアップして欲しいといわれる。
基本的には「その元の画像を下さい」とお願いするわけだが
原稿を作った人と窓口の人が異なっていると、簡単にはいかない場合がある。
窓口の人がよく分かっていなかったり、原稿作った人がまた別の会社だったりと、色々と大人の事情が出てくるわけである。

そういうときにはこの File Juicerだ。
もう手放せません。

操作は簡単で、「ここにファイルをドラッグ」と言うところにファイルをドラッグするだけ。

こうすることで、大体次のようにフォルダごとに抽出した画像・テキストなどを分類してくれるのだ。
（シェアウェア未登録時はたしか “File Juicer” の文字が入る画像などが全てにではないが入る）

自分の場合は、PDFからの抽出を大なうことが多い。
画像・テキストの抽出が主な目的。

ただ毎回注意しなければいけないことがあって
ここがどうにかならないかなーと常々思っている。

●全角スペースと半角スペース
PDFからの抽出しか試していないのだけど、全角スペースで入力されたものがテキスト抽出すると半角になっている。
これはMacのプレビューでファイルを開いてテキストをコピペしても半角になっているので、なんらか変換処理が入っているのか、Macの仕様なのか・・・よく分かりません。
素直に Acrobat Reader(全角スペースは全角スペースのままなのです)を使えと言うことか？

●日本語文字コード（UNICODE正規化）
まあ、これも Acrobat Readerからテキストコピペすればいいのだけど、File Juicerから抽出してテキストをたとえば、DreamWeaverにコピペをすると、濁点・半濁点などが１文字としてペーストされることがある。
なわけで、毎回 Cot Editor（この変換してくれるエディタはこれくらいだった）で UNICODE正規化ってのをやってからコピペしている。

File Juicerは使うことがないと思うが、Cot Editorは必要になってくるだろうな。

出所不明のPDF

http://gande.co.jp/cgi-momoco/2chview.cgi#t_20071012143420より

お客様よりPDFで入稿がありました．
文書のプロパティでは
作成アプリは空欄
作成OSはMacOS 10
フォントは全て埋め込みサブセットとなっていますが
フォント名が
font 98640　など他の書体も同様で数字が変わっているだけ
TypeはTrueType
となっております．
テキスト選択をしてエディターにコピペしてもすべて文字化けしています．
どなたかテキストを取り出す方法をご存知の方，
いらっしゃいましたらお願い致します．

自分のつけたレスのほかに
http://support.adobe.co.jp/faq/faq/qadoc.sv?225444+002があった。
問題点 （Issue）
Macintosh 版 Adobe Acrobat 7.0 および Acrobat 8 を使用して Mac OS X 上で変換した PDF ファイルの文字情報が正しくありません。

詳細 （Detail）
－　テキストに使用しているフォントは TrueType フォントです。
－　テキストを [選択ツール] などでコピー＆ペーストすると以下のように文字化けします。
※　下図はテキストエディットの文書にコピー＆ペーストした例です。
 

原因：これらの制限は、Mac OS X の PostScript ドライバが 2 バイトフォントを 1 バイトフォントに分割することにより、生じています。この問題は、Mac OS X に起因するものであり、Acrobat によるものではありません。

解決法
A. PDF ファイルの作成が可能なアプリケーションで PDF に変換します
この問題を回避するには、InDesign CS/CS2 または Illustrator CS/CS2 などの Acrobat Distiller を使用せずに直接 PDF を作成することが可能なアプリケーションで PDF に変換を行います。これにより、Mac OS X の PostScript ドライバを経由しないため、正しい文字情報で PDF に変換することが可能です。

OS-XではPSに書き出してからDistillerはトラブルの元なんですね。
http://code.nanigac.com/source/view/230は試してないけど、解決するのだろうか？
そういったPDFに遭遇してないだけに分からん。

文字化け解消サイト

http://www.shtml.jp/mojibake/google.htmlがGood!

派遣先のFTPサーバはWinに設置してあるためか、圧縮データを解凍すると濁音・半濁音を使用したファイル名は文字化けを起こします。

例：「海外パターン」→「豬ｷ螟悶ワ繧壹ち繝ｼ繝ｳ」

で、これを解消するツールを捜したところWinではフリーウエアとしてMbakerがあったのですが、Mac版でいいのがないかなぁ～などと捜したところ、上記のサイトを見つけました。

ここに入力すれば濁音・半濁音のみが？表示されるだけですので、リンクファイルが見つかりますね^^

Mac OS X上のUnicode

http://labs.unoh.net/2007/09/unicode-on-mac.htmlより

Mac OS Xでは、ファイルシステムでUnicodeが用いられています。いわゆるUTF-8なのですが、一般に言うところのUTF-8とは違います。 Macをお持ちの方は、「iconv -l」とTerminalからコマンドを実行してみてください。「UTF-8-MAC」という表示が見つかるかと思います。

一般的なUTF-8では、文字はNormalization Form C（NFC）で 符号化正規化されています。しかし、Mac OS Xのファイルシステムで用いられているUTF-8 （以下、便宜的にUTF-8-MACと呼びます）では、文字はNormalization Form D（NFD）で符号化正規化されます。日本語を扱う際にNFCとNFDでどこが違うかというと、ひらがな・カタカナの濁点・半濁点の扱いです。 UTF-8では「が」は「U+304C」（HIRAGANA LETTER GA）ですが、 UTF-8-MACでは「U+304B U+3099」（HIRAGANA LETTER KA、COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）となります。
（中略）
しかもややこしいことに、UTF-8で濁点をあらわすコードは「U+309B」（KATAKANA-HIRAGANA VOICED SOUND MARK）で、 UTF-8-MACから送信される「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）とは別物です。サーバ側できちんと変換できればよいのですが、 PHPのmbstringモジュールはUTF-8-MACをサポートしていません。（Javaの場合、Java SE 6から導入された java.text.Normalizerクラス を使えば一発で変換できますね。）

また、Mac上で動作する他のブラウザの挙動を調査したところ（「サンバの季節」というファイルをタイトルを変更せずにアップロードした場合）、それぞれの挙動が異なることがわかりました。

ブラウザ フォーム上のタイトル表記 登録されたタイトル
Safari サンバの季節 サンハ
Firefox サンバの季節 サンバの季節
Opera サンハ゛の季節 サンハ

Firefoxは内部的に変換処理を行うようになっているようです。問題はSafariとOperaですね。選択されたファイルのパスからJavaScriptでファイル名を抜き出してタイトルに設定する部分で、正しく扱えるような文字コードに変換することにしたいと思います。

基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう（ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。

で、この件に関してhttp://d.hatena.ne.jp/odz/20070904/1188884960

何のことを言っているか分からない人のために。

Unicode では、濁音/半濁音/アクセント記号(ウムラウト等)がついた文字を合成文字1文字(ガ(U+30AC))で表すことも、基底文字 + 結合文字(カ(U+30AB) + ゛(U+3099))で表すこともできる。前者の方法で正規化したものを NFC(Normalization Form Composition)、後者で正規化したものを NFD(Normalization Form Decomposition)という。他にも NFKC と NKFD があるが略。これは文字の表現形式の話で、エンコーディングとは違うレイヤの問題なんだけども、非 Unicode のエンコーディングには結合文字というのがないのが普通なので、NFD のままだとエンコーディングの変換に失敗したりする。

でまぁ、普通に入力するとたいてい NFC になっているので問題にならないが、Mac OS X のファイルシステムはファイル名を NFD で格納するので、Mac OS X のファイルを扱うと問題になったりするわけだ。Mac OS X も普通に入力したテキスト自体は NFC になっている。

Windowsで文字化けしないzipを作る

http://27-75-31.cocolog-nifty.com/blog/2007/09/windowszipapple_d900.htmlより

Mac OS XからFinderで簡単にzipファイルを作れるようになりました。しかし、保存されるファイル名の文字コードがユニコードらしくてWindowsで解凍すると日本語ファイル名が文字化けしてしまいます。

これを解決する方法がここ、これに書いてあって試した所日本語でもちゃんと文字化けしなくて解凍できるzipができました。ただ手順が手作業でやるには面倒なのでこれを自動でやるAppleScriptを作ってみました。

OS-XのFinder機能でzipファイルが作れるのか。。。知らなかった。。。orz
で、Windowsの文字コードってShift-JISだっけ？　文字コードが基本なだけに勉強不足を痛感。
シフトJISとUnicodeとの関連はどうなるのか？

Base64変換

http://blog.goo.ne.jp/xmldtp/e/ff5aeee50447ff369ddeb47ae374d5b2より

なんのために？というのがあったが最後に紹介していたhttp://www5b.biglobe.ne.jp/~kouta_y/c/c04.htmlは復習の意味で役立った。
ただ、62の+と63の/が理解できない。

関連不明なのだが

「需溘、涙がでちゃう―」　丸旋戍溘氏（３６）、衆院議員に抱きつき号泣…
の見出しのニュースサイトがあった。
http://newsing.jp/entry?url=haialfa.blog111.fc2.com%2Fblog-entry-137.html

見てみると
「珠代、涙がでちゃう―」　丸川珠代氏（３６）、片山さつき衆院議員に抱きつき、号泣…武蔵小山駅前
となっている。

意図的なのか？　文字コード絡みでこうなったのか？
　

勉強不足ゆえによくわからない（残念！）

2004JIS の死

http://openblog.meblog.biz/article/57292.htmlより

　「 Vista で採用されたのは、JIS2004ではない」
　このことは、重要だ。マイクロソフトは「Vista では JIS2004 が採用された」と述べているが、それは嘘（もしくは間違い）なのだ。では、なぜか？
　先日も述べたとおり、第３水準・第４水準の文字は、シフトJISで符号化がされていない。文字はあるが、その符号化は、 unicode による符号化であって、シフトJISによる符号化ではない。とすれば、この文字規格は、unicode の規格であって、JIS2004の規格ではない。
　たとえば、（01月28日の例で取り上げたが）「騨」という文字がある。この文字の正字である「馬單」は、シフトJISでは「EFB0」という符合位置に符号化される。では、シフトJISで「EFB0」という符合位置の文字を出力すると、その正字が出力されるか？　否。出力されるのは、「?」または「・」というような文字だ。つまり、「エラー」である。
　これは当然だ。その正字は、シフトJISでは符号化されていないのだから、符号化されていない文字が出力されるはずがない。「エラー」となるに決まっている。
　要するに、Vista においてシフトJISで出力される文字は、JIS90で出力される文字集合と
、まったく同じである。字形の差はあるが、文字集合としてはまったく同じである。字数の総数も同じだ。出力されない符合位置も同じだ。とすればVista において採用されたのは、JIS90 の規格（X 0208）であって、JIS2004 の規格（X 0213）ではないのだ。


中略

ここで、(1)(2) の点をまとめると、こうなる。
　「JIS2004 という規格は、欠陥規格である。MS版の JIS90に対して上位互換でない（文字化けが発生する）せいで、Windows では採用されない規格となった。また、文字集合としてみても、秀英明朝では正されている 20字以上の文字が正されていない（つまり誤字のままである）。
　要するに、JIS2004 という規格は欠陥規格であり、それゆえに、使われない規格なのだ。実際に使われるのは、JIS97（正字版）であって、JIS2004ではない。JIS2004 は、誰も使わない規格である。JIS2004 は死んだ。」

関連：http://yoshihashi.blogspot.com/2007/07/2004jis.html

シフトJIS と unicode

シフトJIS と unicodeより

(3) unicode
　一方、 unicode には問題が山積みだ。だいたい、素人は unicode という言葉を使っているが、 unicode というものは一種類しかないわけではない。UTF-8，UTF-16BE，UTF-16LE，UTF-32 などが混在している。

　　　　　【 追記 】
　　　　このことを理解しない人が多いので、実例として、
　　　　次の三つのファイルを示す。
　　　　　　→　UTF-8.txt ，UTF-16BE.txt ，UTF-16LE.txt
　　　　※　ブラウザによっては、文字化けします。その場合は、
　　　　　　いったん保存してから、メモ帳で開いてください。

　極端に言えば、 unicode という文字コードはない、とすら言える。 unicode の文字セットは存在するが、 unicode という単一の文字エンコードはないわけだ。（ UTF-8，UTF-16BE，UTF-16LE，UTF-32 ならばある。）
　そして、これらの文字エンコードには互換性がない。（部分的な互換性はあるが、まともな互換性はない。）
　その弊害は？
　たとえば、検索しても、まともに検索できない、ということがある。GREP 検索するにしても、それぞれは異なる文字コードだから、別々に検索し直す必要がある。つまり、上記の４通りで、４回も検索する必要がある。検索時間が４倍になる。バカバカしいとしか言いようがない。
　また、前にも述べたが、ファイル名を unicode にすると、古いＯＳ（Windows98など）ではファイルを扱えなくなる。ファイル内容を読み取ることもできないし、ファイルを開くことすらできなくなる。
　また、HTMLファイルを書くときは、ソースで文字コードの指定を正しく指定する必要が出てくる。間違った文字コードを指定すると、HTML文書全体が読み取れなくなる、ということがある。特に、UTF-8 しかサポートしていないソフトで、JIS第３水準・第４水準の難読文字を入力すると、まったく漢字を扱えなくなる、という問題が生じることもある。

　また、そもそもの話、Windows は UTF-8 を採用していない。Windows がOSとして採用しているのは、UTF-16LE である。だからWindowsにおける「ユニコード・テキスト」とは UTF-16LE のことである。というわけで、「 UTF-8 への統一」なんて、ハナから無理だ。
　まとめて言おう。 unicode については、次のように言える。
　 ・ ネット　　 では UTF-8 が圧倒的に優勢。（UTF-16 は通用しにくい。）
　 ・ Windows では UTF-16 が圧倒的に優勢。（UTF-8 は通用しにくい。）
　そして、双方（UTF-8とUTF-16）には、まともな互換性はない。どっちかに統一することなど無理である。だから、「 unicode に統一する」というのは、文字エンコードとしては無意味であるわけだ。（文字セットとしてならば意味はあるが。）

　※　ついでだが、従来はシフトJISでエンコードしていた人が、新たに 「 UTF-8 への統一」という方針を取ると、従来の シフトJISの文書または新規の unicode のどちらか一方が grep 検索の対象にならなくなる。両方をいっぺんに grep 検索することはできないからだ。……したがって、エディタを使っている人だと、非常に不便になる。
　※　HTMLの作成も同様だ。HTML を UTF-8 にして、テキストファイルを UTF-16LE にすれば、双方の文字エンコードが異なるので、いっしょに扱うのに不便だ。

チルダ

windows版のsafariが出たわけだが、
http://d.hatena.ne.jp/NAOI/20060623/1151049226の問題は解決されたのだろうか？

解決法はあるのだが
http://islandmac.exblog.jp/4723400/より

SafariでBBS等に〜（チルダ）の入ったアドレスを書き込むと、半角チルダが全角に置き変わってしまいリンクが行えなくなります。
その場合は〜（チルダ）のかわりに　%7E　を入力しましょう。

例　http://www.ds-island.jp/〜fukuhara/　（チルダの場合）
例　http://www.ds-island.jp/%7Efukuhara/　（%7Eの場合）
↑架空のページです。

%7Eが半角チルダと認識されてリンクが正常に行われます。


CLさんが以前こんなようなものを作ったのだが、よーわからん。
http://blog.dtpwiki.jp/dtp/2007/05/dtpsafarigrease_4bc5.html
ググったらFireFox用だったのね。。。
IE7に慣れているだけに。。。

期間限定のblog

タイトルからして年内には終了すると思うが、内容が濃いだけに要チェック。

Mac OS Xの文字コード問題に関するメモ

2004JISへの対応

m_ogawaさんのBBSを読み直してみたら、2004JISの提唱者のサイトが紹介されていた。
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm

以下の指摘のとおり誤解してました。
　［ 付記５ ］
　なお、誤解が広く見られるので、指摘しておく。それは、次の誤解だ。
　“ 新JISでは、字形の変更がなされ、略字から正字へと変更された。だから、略字の代表格である「鴎」は、「区鳥」から「區鳥」に変わった。”
　これは間違いである。正しくは、次の通り。
　“ 新JISでは、字形の変更がなされ、略字から正字へと変更された。ただしそれは原則であり、例外がある。略字の代表格である「鴎」は、この例外に該当する。ゆえに、「区鳥」から「區鳥」に変わることは、ない。「鴎」のコードポイントの文字は、略字の「区鳥」のままであり、正字の「區鳥」は、新たなコードポイントに追加された。つまり、従来の「鴎」という文字は、新JISでも、略字のままである。”
　具体的にコードポイントを述べると、次の通り　（ →　文字コード表 ）
　　　　区鳥　……　シフトJIS：　89a8
　　　　區鳥　……　シフトJIS：　efe3
　では、なぜ、そうなったか？　それは、文字コードの歴史と関係する。簡単に言えば、正字の「區鳥」と略字の「区鳥」はもともと unicode に存在するので、混乱を防ぐためだ。仮に、字形の変更をすると、「區鳥」という文字コードポイントが二つ存在することになってしまう。
　なお、同様の文字は、次の19字であるらしい。（出典は このサイト ）
　　　　 侠 倶 呑 填 掴 焔 痩 祷 箪 繋 繍 莱 蒋 蝉 蝋 醤 頬 顛 鴎
　これらの19字は、前述の通り、「 unicode にすでに正字と略字があるので、正字と略字がそのまま残る文字」と見なしていいだろう。全部チェックしたわけではないが、任意に７個チェックしたら、７個とも正字と略字がすでに unicode に入っていた。残りも同様だろう。
（ ※　実は、この種の例外は、私は５字ぐらいしかないだろうと予想したのだが、思ったよりはたくさんあったわけだ。……なお、これらの文字は、「補助漢字」のうちに「正字体」として組み込まれたもの。略字主義者が徹底的に排除しようとしたのだが、うまく19字をもぐりこませたわけだ。それは「正字を救うための処置」であったが、今となっては逆に「略字を救うための処置」になっている。歴史の皮肉。）

ご丁寧に対処策まで紹介してくれている^^

　新JISを受けて、企業や個人がどうするべきかを、示しておこう。

　［ 参考１ ］　企業の場合
　企業は今後、どう対処するべきか？　
　字形の変更があると、「人名の混同などでトラブルが起こる」という混乱が予想される。それで企業は「大変だ、大変だ」と騒ぐかもしれない。そこで、対処策を示しておこう。最善の対策は、こうだ。
　「何もしないこと」
　ただし、まったく何もしないのではなくて、頭だけは下げるといい。つまり、「一点が二点になった」と文句を言う顧客（クレーマー）がいくらか出るだろうから、これらの顧客に対する苦情受付の窓口を用意しておくといい。たぶん相手はしつこくネチネチと文句を言ってくるだろう。だが、ＪＩＳやマイクロソフトが決めたことに対して、自社としてはどうしようもない。だから、こういう顧客に対しては、ひたすら頭を下げるしかない。
　なお、頭を下げるだけでなく、何らかの対処をすると、とんでもないことになる。たとえば、「システムを書き換えて、これまでの一点しんにょうの略字を別のコードポイントの文字に自動的に置換する」というような措置を取ると、コードポイントが変更されるから、同一人物に二つの文字コードが割り当てられることになる。こんなことをやれば、必ず、どこかで大問題が発生する。
　ここでは、原則を理解しておこう。今回の「字形の変更」では、字形が変更されるだけであり、コードポイントそのものが移動するわけではない。現在の「辻」さんを、新たなコードポイントの略字の「辻」さんに移動すれば、問題が起こるが、現在の「辻」さんを、字形では正字にするだけ（コードポイントを変えない）のであれば、何も問題は起こらない。── コンピュータのシステムでは、コードポイントだけが大事であり、字形の差などは内部処理には使われないからだ。
　なお、どうしても「略字の辻にしろ」と文句を言う顧客もいるだろうから、そういう顧客に対しては、「コードポイントの変更の手続き」を取ってもらえばいい。それは、通常の「氏名変更の手続き」と同じである。結婚後に「改姓」があるように、今回も同じく「改姓」と同様の手続きを取ってもらえばいい。これはこれで、特に問題はない。
　とにかく、「自動処理で一挙にコードポイントを変更する」ということだけは、やめた方がいい。そんなことをすれば、トラブル続出は目に見えている。余計なことは、やらない方がいい。── そして、問題は、それだけだ。
　要するに、企業がやるべきことは、「顧客対応」の窓口にいる女の子をたくさん雇用することだけだ。それ以外には、何もやらなければいい。それで万事解決。
　ついでに言えば、マスコミがあらかじめ「こうなりますよ」と世間に情報提供しておけば、いちいち文句を言う顧客もいなくなる。その場合は、まったく何一つしなくていいことになる。
（ ※　ただし、文句を言う顧客だけは、「改姓」と同じ手続きが必要となる。これらの顧客だけは、少しだけ、余分な手間がかかる。……これらの顧客は、手続きをするか？　たぶん、しないでしょう。ぶつくさと文句をたくさん言うのは大好きだが、手続きをしてまで訂正したがる人は、たいしていないはずだ。要するに、一点か二点かの違いなんて、言っている本人だって、本当はたいして気にしないのだ。）

Unicode正規化 その４

引き続き引用
http://http://tama-san.com/document06.html

Unicode正規化の種類
これまでの流れだと「Unicode正規化」イコール「結合文字列を合成すること」と思ってしまうでしょうけど、すこし違います。Unicode正規化は合成するだけでなく、分解することにも使われるからです。

Unicode Consortium は、Unicode正規化を４種類に分けて規定しています。

　NFC　Normalization Form C
　NFD　Normalization Form D
　NFKC　Normalization Form KC
　NFKD　Normalization Form KD

「Normalization Form」は 正規形 と訳されています。「正規化した状態」というような意味です。つまりこの４つは、文字を

　合成（Composition）する
　分解（Decomposition）する
　互換分解（K(C)ompatibility Decomposition）してから合成（Composition）する
　互換分解（K(C)ompatibility Decomposition）する

ための方法であるということです。

ここでは、あまり深く掘り下げないことにしているので、「互換分解」には触れません。さらに、話を簡潔にするため、私たちの目的に直接関わる「NFC」だけに限定して見て行くことにします。

テキストエディットに「NFC」がない理由
OS Xには、Unicode正規化のAPIが用意されています。ですから、ソフトウェアにUnicode正規化の機能を実装する場合、そのAPIを利用するだけで簡単にできてしまいます。「その１」の簡単なソフトも、そうやって作りました。

それでは、どうしてOS Xの標準エディタであるテキストエディットに、ユーザが「NFC」を適用できる機能がないのでしょうか？

それは、一見とても便利そうな「NFC」に大きな問題があるからです。逆に、NFCを「結合文字列を合成するためだけに使う」商用ソフトは、その開発体制にひどい欠陥があると見て間違いないでしょう。

NFCの大きな問題
私は上記でNFCを「文字を合成する方法」と書きましたが、実際には予想外の処理をしています。すなわち、これが「NFC」のやっていることです。

　「分解（Decomposition）してから合成（Composition）する」
　

「その１」に登場したこの文字で見てみます。まず、この３つはまったく同じ字形ですが、データ上は
「01D6」「00FC 0304」「0075 0308 0304」
とどれも異なります。それぞれにNFCを適用してみます。

「01D6」→ 00FC 0304 → 0075 0308 0304 → 00FC 0304 → 01D6
「00FC 0304」→ 0075 0308 0304 → 00FC 0304 → 01D6
「0075 0308 0304」→ 00FC 0304 → 01D6

結果としてはいずれも単一の「01D6」になるのですが、はじめから「01D6」になっている文字も、徹底的に分解されて、再度また合成されます。つまり、分解マッピングで分解可能な文字は、それが単一コードであってもNFCでは分解されているということです。

そして、分解された文字がすべて元通りに合成されれば問題はないのですが、「すべて元通りに合成されるわけではない」ところにNFCの大きな問題があります。つまり、合成をしようとしてNFCを適用したら、かえって１文字がバラバラになったり、別の１文字に変わってしまう文字があるということです。（「その３」でも少し触れましたが、「分解」という用語は、１文字をバラバラにするだけでなく、別の１文字にする意味でも使われます）

「分解したあとに合成しない」ことを「合成除外 Composition Exclusion」といいます。Unicode Consortium の「CompositionExclusions.txt」はその合成除外文字の一覧です。一見すると少なそうですが、全部で1000文字以上もあります。

どうしてこんな文字があるのか、調べてみると理由はいくつかあり、なるほどと思うものもあれば、私では理解できないものもあります（チベット語とかヘブライ語なんて分かりませんし…）。そしてこれが遠い外国の文字だけなら、日本で作られるテキストにNFCを適用してもさして問題はないかなとも思うのですが、実は合成除外にもっとも多いのが「漢字」なのですから、困るのです。

次回は、この不遇な扱いを受ける漢字について見ていきます。

Unicode正規化 その３

引き続き引用
http://tama-san.com/document05.html

「単一コードの１文字」に変換する
「変換」と言うと、なにかとても難しい処理をするような印象をうけますよね。例えば、ある一定の数量的な法則に従ってバイナリコードを加工する、みたいな感じです。しかし、結合文字列を単一コードにする場合、この方法は使えません。そこには「一定の数量的な法則」がなく、あるのは言語の恣意性そのものだからです。

とは言うものの、やはり記号を扱うコンピュータ上の無機的な規格なので、Unicode Consortium は「結合文字列」と「単一コード１文字」の対応関係、いわばこの恣意的な関係を、属性のひとつとして各文字毎に逐一明記しています。

UnicodeData.txt

このファイルには各文字の属性が列挙されていて、その中に私たちが知りたい対応関係が書かれています。ここから「ポ」の文字を見てみましょう。

　30DD;KATAKANA LETTER PO;......;30DB 309A;......

カタカナ「ポ」は
　単一コードで「30DD」
　結合文字列で「30DB 309A」
であることが書かれています。

これから分かることは、ここに書かれている情報に従って、例えば「30DB 309A」を「30DD」に置換することで、私たちの目的である「単一コード１文字への変換」が実現できそうだということです。そして、この UnicodeData.txt の記述に従って置換することが、まさに「Unicode正規化」です。