タグ

文字コードに関するpaselaのブックマーク (46)

  • JISから迫る文字コード入門

    第16回 渋谷Javaでの発表資料です。

    JISから迫る文字コード入門
  • ASCIIコードの秘密 - ザリガニが見ていた...。

    当はエスケープシーケンスのことを調べていたのだが、その前にASCIIコードについて調べることになってしまった...。文字コードの基として知っているつもりだったASCIIコードについて、あらためて見直してみると、実は当の意味をよく分かっていなかったことに気づいた。 ASCIIコード表 ASCIIコードは、7ビット(2進数7桁)の文字コードであり、全部で128のコードが定義されている。 最も基的な文字コードであり、その他多くの文字コードはこのASCIIコードと互換性を維持している。 00 10 20 30 40 50 60 70 00 NUL DLE SP 0 @ P ` p 01 SOH DC1 ! 1 A Q a q 02 STX DC2 " 2 B R b r 03 ETX DC3 # 3 C S c s 04 EOT DC4 $ 4 D T d t 05 ENQ NAK % 5

  • 文字コード地獄秘話 第1話:Unicodeにおける全角・半角 - ALBERT Engineering Blog

    ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか

    文字コード地獄秘話 第1話:Unicodeにおける全角・半角 - ALBERT Engineering Blog
  • Shift_JIS、CP932、MS932、Windows-31J(文字コード関連) | 読み物 | ウナのIT資格一問一答

    Windows標準の文字コードはShift_JISではなく、Windows-31Jです。 それらの違いやCP932、MS932といった用語もあわせて整理してみましょう。 まずはShift_JIS。 これは日語の文字集合を符号化する文字符号化方式のうちの一つです。 Microsoftにより、MS-DOSの標準日語コードとして採用され、CP932という管理番号を与えられるとともに独自の拡張が行われました。 MicrosoftはこのCP932を独自に拡張することを、OEMメーカー(MS-DOSを搭載したパソコンを販売するメーカー)に許していたため、各OEMメーカーごとに異なる拡張が行われました。 その後、MicrosoftWindows3.1の日語版を出すにあたり、OEMメーカーにCP932の独自拡張を許すという方針を撤回し、当時、日のパソコン市場で特に大きなシェアを持っていたIBMと

  • Rubyのエンコーディング - tmtms のメモ

    Ruby 1.9 から文字列や正規表現オブジェクトはそれぞれエンコーディング(いわゆる文字コード)を保持するようになりました。 たとえば 0xB1 0xB2 という2バイトは EUC-JP エンコーディングでは「渦」、SHIFT_JIS エンコーディングでは「アイ」という文字になります。つまり同じバイト列でもエンコーディングが異なれば異なる文字として解釈されます。 1.8 では文字列はただのバイト列でした。なので、それがどのような文字を表しているのか、つまりエンコーディングが何なのかはプログラムが知っている必要がありました。 1.9 では文字列オブジェクト自身が自分が何のエンコーディングかを知っています。同じ 0xB1 0xB2 というバイト列でも、それが EUC-JP の「渦」なのか SHIFT_JIS の「アイ」なのかは、文字列自身が知っています。 スクリプトエンコーディング スクリプ

    Rubyのエンコーディング - tmtms のメモ
  • SoftBank iPhoneのShift_JISがすごいことになっている件 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    下図は、SoftBank iPhoneのMailが用いるShift_JISのIBM拡張文字領域*1。どうだ、驚いたろう。 SoftBank iPhoneのMailは、charset=Shift_JISをよく使う。髙村薫の「髙」や宮﨑あおいの「﨑」などのWindows外字もShift_JISで送るし、絵文字もShift_JISで送る。しかし、WindowsのIBM拡張文字領域とSoftBankの絵文字領域は、もともと衝突しており、共存できない。なので、SoftBank iPhoneのShift_JISでは、IBM拡張文字のうち下図ピンク部分が使えない。 だったらその分は、NEC選定IBM拡張文字のほうを使えばいいじゃないですか、どうせダブってるんだから(下図)。というのが、大ざっぱに言えば、SoftBank iPhoneのMailが用いるShift_JISである。 その外字領域をまとめると、

    SoftBank iPhoneのShift_JISがすごいことになっている件 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • Mac OS X におけるファイル名に関するメモ(NFC, NFD等)

    このblogは、著者である「sakito」が技術的に生存している事を報告するために存在します タイトルを「紹介マニアどらふと版」から変更しました Mac OS X で ファイルシステムのフォーマットに HFS+ を利用している場合、ファイル名の取り扱いが、 WindowsLinux と異なります。 具体的には濁点や半濁点の扱いが異なります。これは Unicode の正規化に関係しています。 「Unicode の正規化」とは簡単に言うと、どの文字を同じ文字として処理するか、という問題への対処で、「が」を「が」として扱うか「か + ゛」として扱うか、ということです。 「Unicode の正規化」を実施することで「が」で入力されても、「か + ゛」で入力されても、どちらか一方に統一して、同じ文字として扱えるようにします。 こうした正規化形式には4種類存在します。 Normalization

  • 電子書籍.club - 

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • https://tanaka.sakura.ad.jp/archives/001071.html

  • Unicodeの似た文字を整理してみた - y-kawazの日記

    XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。 Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄

    Unicodeの似た文字を整理してみた - y-kawazの日記
  • 文字コード(UTF-8,Shift_JIS,EUC-JP,ISO-2022-JP)についての俺的まとめ - 今日もスミマセン。

    「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか? 日語の文字コードは大きく以下の2つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング(文字符号化方式)」の事を指す。 文字符号化方式 文字集合って? 読んでそのまんま”文字の種類の集まり”。「キャラ

    文字コード(UTF-8,Shift_JIS,EUC-JP,ISO-2022-JP)についての俺的まとめ - 今日もスミマセン。
  • 第33回 enc2xs:標準の文字コード表にはない文字を変換する | gihyo.jp

    Encodeを使っても文字化けするとき Encodeは特定のエンコーディングにしたがって配列されたバイナリを「文字列」に置き換えるためのモジュールですが、かならずしもすべてのエンコーディングがあらゆるバイナリの組み合わせに対応しているわけではありません。 たとえば、「⁠シフトJIS」環境における機種依存文字の例としてよく取り上げられる丸付き数字をEncodeのお作法通りにdecode、encodeする場合、「⁠シフトJIS」だからと思って安易にshiftjis系列のエンコーディングでdecodeしてしまうと、丸付き数字のマッピングデータがないため「?@」のように文字化けを起こしてしまいます。 use strict; use warnings; use Encode; my $binary = pack('C*', 0x87, 0x40); # ①; my $string = decode(

    第33回 enc2xs:標準の文字コード表にはない文字を変換する | gihyo.jp
  • 円記号問題とウェブブラウザ - はてなるせだいあり

    起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSE SOLIDUS を割り当てました。一方、日版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日ではシフトJIS、日語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日語 EUC 日

    円記号問題とウェブブラウザ - はてなるせだいあり
  • るびま

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

  • 論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)

    _文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不

  • セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?

    (Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書(「例えば、PHPを使用しない」と勧める文書)を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに

    セキュリティ専門家でも間違える!文字エンコーディング問題は難しいのか?
  • PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)

    _既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト(言語、フレームワークなど)か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ

  • 7.2 ASCII の NUL と DEL の本来の意味 - 文字コードに関する覚え書きと実験

    文字コードについて調べたことや実験したこと, テストプログラム,データファイルなどを随時掲載する予定です. ただし筆者の理解不足や誤解により誤りがあるかもしれませんので, ご利用は自己責任で. このページの主な更新は Blog でお知らせします. 表示確認ブラウザ:FireFox 22.0,IE8. 0.目次 シフトJIS Shift_JIS と Windows-31J (CP932) の違い シフトJIS 2バイト文字の判定 謎の検索ワード集 (シフトJIS編) 「Shift_JIS(SJIS,Windows-31J,CP932) 3バイト文字」 「Shift_JIS(SJIS,Windows-31J,CP932) サロゲート(ペア)」 「UTF-8 4バイト文字 Shift_JIS(SJIS,Windows-31J,CP932) 変換」 「Unicode(UTF-8,UTF-16) か

    7.2 ASCII の NUL と DEL の本来の意味 - 文字コードに関する覚え書きと実験
  • 日本語文字コード

    フォームメール(mb_send_mail)php ジェネレーター オープンフォトライブラリー自由に画像を登録・紹介できます 文字コード(日語漢字コード表) 日語漢字コード表が、Shift-JIS、EUC-JP、JIS、UTF-8と複数存在する事から、 ホームページ作成・維持管理、データ収集をする上で、文字コードについての多くの諸問題が発生します。 その解決に少しでもお役に立てれば幸いです 文字コード表(実体) シフトJISコード表 Shift-JIS による一覧表 EUCコード表 EUC-JP による一覧表 JISコード表 JIS による一覧表 JIS X 0201 (1976) to Unicode 文字コード表 Shift-JIS による一覧表 JIS X 0208 (1990) to Unicode 漢字コード表 Shift-JIS による一覧表(UTF-8のコードはこちらにあり

  • 講習会「文字集合と文字エンコーディング」について - はてなるせだいあり

    なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char

    講習会「文字集合と文字エンコーディング」について - はてなるせだいあり