UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
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
更新日: $Date: 2006-09-29 09:21:22 $ UTC ($Revision: 1.10 $) 公開日: 2004/04/13 目的 今のところ(mysql 4.0.27, 5.0.24a)、MySQLのネイティブ関数REGEXPは日本語の文字列を正しく処理できません (一方、LIKEやSUBSTRINGなどは日本語の処理に対応しています)。そこで日本語をきちんと扱える正規表現関数、mregexpというものをユーザー定義関数(UDF=User Defined Function)という仕組みを用いて作りました。 機能 パターン'あ.う'が文字列'あいう'にマッチしません。 正規表現の「.」が、任意の1文字ではなく、任意の1バイトにマッチしてしまうからです。 ● LIKEは期待通り「あいう」がマッチするが、 mysql> SELECT * FROM regexp_test
最新版は2001年12月24日にリリースされたVersion 1.01uです。 1.概要 インターネットが広まるにつれて、文字セットの変換という作業を行うことが増えました。パソコン上では、Shift_JIS、UNIXサーバー上では、EUC-JPといった具合です。 CharsetConverterは、文字セットの変換を手軽に行うためのツールです。 主な特徴 Shift_JIS、EUC-JP、ISO-2022-JP、Unicode(le)、UTF-8 の相互変換が可能 変換先 改行コードを CR/LF, LF, CRの三種類から指定可能 Shift_JIS、EUC-JP、ISO-2022-JP では、ある程度の文字セット判別が可能 Unicodeテキストファイルでは、先頭のバイトオーダー判別コードからの判別が可能 コマンドラインからの全自動変換機能 2.動作環境 Windows95, Wind
コンピュータは0と1しか理解できないため、文字をそのまま使うことはできません。そこで普通は、文字に数値を割り当てることによりコンピュータで利用できるようにしています。各文字を数値で表現するためには文字符号化を行います。実際の文字符号化は奥が深く難しいのですが、正しく文字を処理するプログラムを作成するには、これを避けて通ることはできません。基本となる概念自体はけっして難しくありませんので、それを理解しておきましょう。 符号化文字集合と文字符号化方式 文字がコンピュータでどのように表現されているのかは、文字符号化を理解できればわかるようになります。文字符号化を理解するためには、符号化文字集合（code character set）と文字符号化方式（character encoding scheme）について理解する必要があります。これらについて、順番に解説をします。 符号化文字集合 まず、コン
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
Windows 10 の入ったディスクのバックアップが clonezilla で外形的にできることがわかった Posted on Jun 27, 2020 Windows10 が載ってるディスクに破壊的な変更加える前にバックアップしたくて、SystemRescueCd で clonezilla 使ってディスクまるごとイメージ化した(内部的には partimage が使われてる?)。 でこれ、レストアしたら起動する状態まで持っていけるんかな? すんごく不安だ。。。 — woremacx (@woremacx) June 15, 2020 systemrescuecd に同梱されている clonezilla を使ってまるまる取った Windows 10 のバックアップが戻せるか不安で仕方なかったので、VirtualBox に戻せるか試した。 そもそもなぜ clonezilla を試したかったの
http://www.unixuser.org/~euske/doc/python/sample.py.html # 日本語トークンを切り出すための正規表現。 JP_TOKEN = re.compile(u"[一-龠]+|[ぁ-ん]+|[ァ-ヴ]+|[a-zA-Z0-9]+") http://www.ascii.co.jp/pb/ascii/archive/aftercare/1999.html ［亜-煕］はJIS漢字を検出するときに使う正規表現になります。 本文中で触れている「一太郎 Lite2」の正規表現はUnicode仕様なので，すべての漢字を検出するには，[一-龠]を使用してください（龠は音読みで「ヤク」，訓読みで「ふえ」，Unicodeでは「9FA0」にあたります）。 追記 ※「すべての漢字を取り出す正規表現」については、id:toton:20051105 に記事を追加しました。
JapaneseCodecs version 1.4.11 梶山民人 (2004年11月28日) はじめに 本パッケージは、Unicode をサポートした Python において、EUC-JP、Shift_JIS、ISO-2022-JP などの日本語の文字エンコーディングを利用できるようにするためのコデック集です。本パッケージを用いることにより、日本語の文字データをバイト列としてではなく文字列として扱えるようになります。 Python の Unicode 関連の API は、Marc-Andre Lemburg によって提案され、以下の仕様書で定義されています。 http://starship.python.net/crew/lemburg/unicode-proposal.txt 本パッケージの提供するコデックは Proposal Version 1.8 に準拠しています。コデックの詳細
関連リンク集：/「Javaの哲学」の恥かき/「Javaによるテキスト処理」の恥かき/「モア・サーブレット」の恥かき/恥かきのホームページ/JavaBeginner/javacのエラーメッセージ/UIDefaultsのkeyとデフォルト値/comp.lang.java.guiのFAQ/ ★2006年より、Javaプログラミング関連記事の新規掲載場所を[Javaの手帖]に統一しました。 [ ][HOME][NEXT](シングルトンと同期化) 「コア・サーブレット」（原書）は昨年(2003)８月に第二版が出まして、大幅に改定＆増補されました。私（岩谷）自身の経験も含めて、ここに、有意義なメモを作っていこうと思います。 (1)FORMデータ, GET/POST, multipartの問題 第一版16章には、FORMデータをGETでなくPOSTで送るためにはENCTYPE="mult
文字化けは Web アプリ開発で最も頭の痛い問題のひとつです。(少なくとも日本人向けの Web アプリでは) 今回のチュートリアルでは、文字化けが発生する理由から、発生箇所の特定および文字化け解消の方法までを、理解します。 なぜ、文字化けが発生するのでしょうか？そして、なぜ、その解決は難しいのでしょうか？ その理由は Web システム(分散システム)特有の複雑なアーキテクチャが原因です(少なくとも私はそう思います)。 ここでは、Struts アプリケーションが動作する仕組みを整理し、文字化けが発生する箇所を特定します。 第１回でも簡単に触れましたが、Struts アプリケーションは ユーザのアクセスに応じて下図のようにメッセージ通信を行い、アプリケーションとして動作します。 「文字化け」は、これらのメッセージ通信の間で文字コードの違いが存在する場合に発生します。 ユーザが Web
Servlet・JSPで作成したプログラムをブラウザに出力する際の文字コードの指定方法について解説します。HTMLでは以下の順序で文字コードの認識が行われます。 HTTPヘッダのContent-Type（charset）の値 HTMLファイル内のMETAタグのContent-Type（charset）の値 Tomcatなどのサーブレットコンテナは指定しない限りデフォルトの文字コード（Tomcatの場合は、ISO-8859-1）をHTTPヘッダのContent-Typeに指定します。そのため、Servlet・JSPでMETAタグを記載し、文字コードを指定していた場合でもその値は無視されます。 Servlet・JSPで文字コードを指定するためには、HTTPヘッダのContent-Typeを指定する必要があります。HTTPヘッダのContent-Typeを指定する方法を以下に記載します。 Ser
質問1： Webブラウザが文字コードを判定する基準は何ですか？ 解答：HTTPのContent-Typeヘッダです まずは、Webにおける文字コードの扱いをおさらいしておこう。HTML 4.01仕様では、Webブラウザが以下の優先順位で文字コードを決定することを規定している。 HTTPにおけるContent-Typeヘッダのcharsetパラメータ HTML文書内のMETA宣言およびhttp-equiv属性で設定された、Content-Typeヘッダのcharsetパラメータ HTML文書内の各要素のcharset属性 Webサーバが送信するHTTPヘッダの中には、送信内容がどのような素性のコンテンツなのかをWebブラウザに教えるために、以下のようなContent-Typeヘッダを通じてコンテンツのメディアタイプ（下記例ではtext/html）を明示する。 これによりWebブラウザは、受信
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く