お薦め ページ


メニュー

ハワイ島 遊覧飛行ツアー

ハワイ島 B&B・ホテル

ハワイ島 不動産情報

ハワイ島 情報・観光ガイド

ブログ(Blog)

その他

関連サイト

: カテゴリー :

文字コード・文字化け

2007年5月 8日

ruby での「 Invalid char `\357' in expression 」エラーメッセージ

rubyのプログラムを実行してみて、
C:\soft\ruby>ruby URLencodeUTF8.rb
URLencodeUTF8.rb:1: Invalid char `\357' in expression
URLencodeUTF8.rb:1: Invalid char `\273' in expression
URLencodeUTF8.rb:1: Invalid char `\277' in expression
のようなエラーメッセージに遭遇することがあるかもしれない。

このエラーの原因は昨日のブログ 「UTF-8 と UTF-8N の違いは何か?」 でレポートした ユニコードの「バイトオーダーマーク (BOM:Byte Order Mark)」が原因である。 ちなみに 昨日のブログで
BOMの値は 具体的には上記の通り、「U+FEFF」である。 このBOMの値のUTF-8での表現は3バイトとなり 16進数の「 EF BB BF 」となる。 ちなみにこれを8進数で現すと「 357 273 277 」となる。
と書いたが、この「 357 273 277 」って rubyからのエラーメッセージの中にしっかり含まれている。

問題の原因がわかれば解決策は簡単である。 昨日のブログでも書いたが、 rubyのソース・ファイルを 例えば、「TeraPad」や「Xyzzy」のような UTF-8 と UTF-8N の両方に対応したエディターを使って開き、 改めて「UTF-8N」を指定して保存すること。

ちなみに、rubyを実行する際、 ユニコードを指定する「-Ku」オプションを付けた場合は、
C:\soft\ruby>ruby -Ku URLencodeUTF8.rb
URLencodeUTF8.rb:1: undefined method `・ソrequire' for main:Object (NoMethodError)
のようなエラーとなった。 結局「-Ku」オプションをつける場合でも、 ソースファイルは「UTF-8N」で保存する必要があるようだ。

【参考リンク】

カテゴリー: 文字コード・文字化け     22:43 | コメント (0) | トラックバック (2)

2007年5月 7日

UTF-8 と UTF-8N の違いは何か?

エディターの「TeraPad」 や 私が通常使っている「Xyzzy」などでは、 文字コードの指定に「UTF-8」 とは別に 「UTF-8N」というのがある。 はたして この2つはどう違うのだろうか?

ウィキペディア「Unicode」の 「UTF-8(UTF-2、UTF-FSS)」の欄に
日本国内でのみ、 BOM (Byte Order Mark) がついているものをUTF-8、 ついていないものをUTF-8Nとして区別することがあるが、 国際的には認知されていない。 Internet Explorerでは、 BOMのついていないUTF-8の文書を読み込むと(日本語版の場合)Shift_JISだと 誤認する一方で、BOMがついていると有効なデータとして受け付けない アプリケーションも存在する。
簡単には BOM (Byte Order Mark) 付いているのと いないとの違いのようだ。

では「バイトオーダーマーク (BOM:Byte Order Mark)」とは何か? 上記ページの脚注で
BOMとは、8ビットを基本とするシステムで バイトオーダーを識別するための印であり、 データストリームの先頭に付与される。 値はU+FEFF。 システムが読み込んだ先頭2バイトが0xFF,0xFEならリトルエンディアン、 0xFE,0xFFならビッグエンディアンとして後に続く文書を処理する。 RFC 2781 ではBOMが付いていないUTF-16文書は ビッグエンディアンとして解釈することになっている。 Windowsのメモ帳で作成した「Unicodeテキスト」は 標準でBOMが付与されるようになっている。
と説明されている。

さらに ウィキペディア「UTF-8」では「バイトオーダーマークについて」というセクションで 詳しく解説してある。

BOMの値は 具体的には上記の通り、「U+FEFF」である。 このBOMの値のUTF-8での表現は3バイトとなり 16進数の「 EF BB BF 」となる。 ちなみにこれを8進数で現すと「 357 273 277 」となる。

解説によると、 この BOMありのUTF-8 と BOMなしのUTF-8N は 場合によって使い分けなければならいようだ。 結局、適切な方を選択するためには、 UTF-8 と UTF-8N の両方に対応したエディターを使って、 エラーの出ない方を選択するということしかないようだ。

【参考リンク】

カテゴリー: 文字コード・文字化け     22:49 | コメント (0) | トラックバック (0)

2007年5月 6日

ruby で URLエンコード プログラミング

昨日のブログで「 URLエンコード(URIエンコード)」について レポートしたが、 それでは、rubyで実際にプログラミングしてみよう。

rubyのサンプル・プログラムは以下の様に
require 'uri'
p URI.escape('ウィキペディア')
たった2行である。 これで「ウィキペディア」という言葉を URLエンコードした結果が表示されるハズである。 ウィキペディア「URLエンコード」ページに 例題として「ウィキペディア」という言葉を Shift_JIS、EUC-JP、UTF-8 の各漢字コードで URLエンコードした結果があるので、 それと比較できるように、ここでは同じ言葉としてみた。

Shift_JIS、EUC-JP、UTF-8 の それぞれの漢字コードに 対応するために、それぞれに URLencodeSJIS.rb、URLencodeEUC.rb、URLencodeUTF8N.rb と名づけて、エディターから 漢字コードを指定して保存した。 それぞれを ruby で実行してみると、
C:\soft\ruby>ruby URLencodeSJIS.rb
"%83E%83B%83L%83y%83f%83B%83A"

C:\soft\ruby>ruby URLencodeEUC.rb
"%A5%A6%A5%A3%A5%AD%A5%DA%A5%C7%A5%A3%A5%A2"

C:\soft\ruby>ruby URLencodeUTF8N.rb
"%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2"
のような結果となり、当たり前であるが、 ウィキペディア「URLエンコード」ページ の結果と同じになった。

【参考リンク】

カテゴリー: DNS・URL・URI , Ruby , 文字コード・文字化け     22:54 | コメント (0) | トラックバック (0)

2007年5月 5日

URLエンコード(URIエンコード)

ウェブページのアドレス部分で 「%数字%数字...」 の羅列になっている部分を時々見かける。 「URLエンコード」または「URIエンコード」とは アドレス部分に直接記述することができない文字列を このような形式へ変換すること。

例えば、Google.co.jp で「エンコード」という文字を検索した結果、 ブラウザーのアドレス部分には 、
http://www.google.co.jp/search?hl=ja&q=%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%89&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
というように、「エンコード」という文字が 「%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%89」 のように変換されて表示されている。 この他にも、ウィキペディアや amazon.co.jp でも利用されているが、 ブラウザによっては「http://ja.wikipedia.org/wiki/URLエンコード」のように 日本語でキチンと表示されているので直接目にふれない場合もある。

この 「URLエンコード」 については ウィキペディア「URLエンコード」によると。
URLエンコード(ゆーあーるえるえんこーど)とはURIに2バイト文字を使う際に行われる符号化のことである。 URIの規則を定める RFC 3986 では、 URIにASCIIの非予約文字以外の文字データは、 「%xx」(xxは16進数)という形でコードを表記することが定められている。 その際にどの文字コードを用いるかは実装によって異なる。
とある。 ここで、「どの文字コードを用いるかは実装によって異なる」とあるが、 上記の Google、ウィキペディア、amazon.co.jp では UTF-8 を用いているようである。

ASCIIの非予約文字(記号文字)については、 Diaspar「URIエンコード(URLエンコード)」 ページに 例を挙げて詳しく解説されている。

また、 TAG index「URLエンコード・デコードフォーム」けんどもネット「URL エンコード/デコードフォーム」 のように、 、URLエンコード、URLデコードを行ってくれるツールを提供しているサイトも 多数 存在している。

【参考リンク】

カテゴリー: DNS・URL・URI , 文字コード・文字化け     22:18 | コメント (0) | トラックバック (0)

2007年5月 2日

nkf (Network Kanji Filter)

「nkf」とは、「Network Kanji Filter」の頭文字。 自分も昔からよくお世話になっている 日本語コード変換フィルター プログラム。 漢字コードの自動認識機能があるので、ほとんど気にする必要がない。 nkfには今では沢山の機能(オプション)があるが、 その中でも 自分が良く使う オプションのみをここにメモしておく。

出力するファイルのコードを指定するオプション。 この際のオプションの文字は必ず「小文字」。
  • -j   JISコードを出力する。(デフォルト)
  • -e   EUCコードを出力する。
  • -s   シフトJISコードを出力する。
  • -w   UTF-8コードを出力する。
(例)「INSTALL.jis」というファイルをUTF-8コードへ変換する場合。
% nkf -w INSTALL.jis > INSTALL.utf8


あるファイルの文字コードを知りたい場合は 「-g」オプションをつければよい。 すると、そのファイルの文字コードの解析結果を表示してくれる。
(例)
% nkf -g README.jis
ISO-2022-JP

% nkf -g README.utf8
UTF-8

% nkf -g README.euc
EUC-JP

% nkf -g README.sjis
Shift_JIS

% nkf -g README
ASCII


URL等で 「%数字%数字...」 の羅列になっている部分を デコードするには、 「--url-input」オプションを使う。。
(例)
% echo http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 | nkf --url-input -w
http://ja.wikipedia.org/wiki/メインページ
この際、使っているOSやターミナルの環境にあわせて 「-w」や「-e」「-s」等の出力コードを指定するオプションを 適切につけておかなければ結果の表示が文字化けしてしまう。

【参考リンク】

カテゴリー: Software , 文字コード・文字化け     22:21 | コメント (0) | トラックバック (0)

2007年4月30日

文字コードの調査

コンピュータの世界を議論しようと思ったら、 必ず出てくるのが「文字コード」である。 ではその文字コードについて調査しようと思って、 いろいろググっていたら、 「日本語フォントや文字コードについて(のリンク集)」 に よくまとめられていることがわかった。

調べてみると、このサイトを作っておられる「ず」さんという方は、 沖縄のインターネット業界では有名な方らしい。 文字コードに関しては、このページを基点としていろいろ調査してゆこうかな?

それから ITpro の 「文字コード規格の基礎」 に 文字コードについて 「文字の集合」 と 「エンコード方法」 の違い、 「コードページ」や「ロケール」と言った概念について、 などがまとめられている。 ただし、記事が 日経ソフトウエア 1999年10月号 のものを掲載しているので そぐわない部分もあることを考慮しないといけない。 特にUnicodeについては別に最新の情報を収集したほうがよさそうだ。

上記の「文字の集合」は 「(符号化)文字集合 (CCS: coded character set)」 に 「エンコード方法」については 「(文字)符号化方式 (CES: character encoding scheme) 」 に 詳しい説明がある。

【参考リンク】

カテゴリー: 文字コード・文字化け     22:53 | コメント (0) | トラックバック (0)

2005年4月29日

トラックバックの文字化け

最近、いくつかのブログサイトに対しトラックバックをさせていただたいたが、その際、懸念していた事態に遭遇してしまった。トラックバック情報が文字化けするのである。

ブログを公開するにあたり、初めにいくつかのサイトに対しトラックバックの実験をしたが文字化けは起こらなかった。 しかし、exciteブログ(exblog.jp)に対し、トラックバックを送ると、そのページのトラックバック表示が文字化けしてしまうことが判明した。

このサイトでは、既に存在する他のページと統一するために日本語文字コードとしてEUCを採用している。 しかし、Movable Typeをはじめとするブログソフトや、XMLの世界では、UTF-8を採用するのが標準となってきている。

今後を考えると、場合によっては、エントリーが少ない今のうちに、サイトの文字コード変換を行った方がよいのかもしれない。 早急に調査して、どうするかを決定する必要がある。

カテゴリー: Movable Type , 文字コード・文字化け     04:02 | コメント (1) | トラックバック (0)

 
ハワイ島での遊覧飛行ツアーとB&Bのスペシャリスト、スカイメリカ
Copyright © 2003,2009 Skymerica Corp. All rights reserved.