アイヌ語仮名「ㇷ゚」に対する正規表現の罠
導入 アイヌ語は日本語と異なり、閉音節（子音で終わる音節）も存在するので、表記の際音素文字であるラテン文字なら、そのまま p, t, k, m, n, s, r などの子音文字を後ろの付ければ良いわけなので、アイヌ語ローマ字表記では、何も問題が生じない。しかし、元々開音節言語である日本語に特化したカタカナのような仮名文字で表記する際、鼻音 n は「ン」でなんとかなる（実はそれでもまずい事になっているけどここでは割愛する）が、p, t, k, m, n, s, r, h はどうしようもないので、特殊の捨て仮名（小書き仮名文字）を利用することになっている。 具体的には以下のような特殊仮名文字（通称 アイヌ語仮名）である。 ㇷ゚ -p ッ -t ㇰ -k ㇺ -m ㇱ -s ㇻ -(a)r, ㇼ -(i)r, ㇽ -(u)r, ㇾ -(e)r, ㇿ -(o)r お分かり頂けただろうか… 問題 r
Gitはどうやってテキストファイルとバイナリファイルを自動識別しているのか？ - Qiita
tl;dr 先頭 8000 バイト以内に NUL が有ったらバイナリファイル。 Gitの実装 Gitの内蔵diffは FIRST_FEW_BYTES だけ検索するようになっている。 https://github.com/git/git/blob/6e0cc6776106079ed4efa0cc9abace4107657abf/xdiff-interface.c#L187 #define FIRST_FEW_BYTES 8000 int buffer_is_binary(const char *ptr, unsigned long size) { if (FIRST_FEW_BYTES < size) size = FIRST_FEW_BYTES; return !!memchr(ptr, 0, size); }
16進っぽいメモ - Richard蒸しパン工場
昔々、某MMOで「バトルアックス」という武器が「バトルヂッハベ」と表記されていた時代がありました。また、プログラムを書く際に、適当な絶対パスなんかを全部大文字にしようとして、「デスクトップ」という文字が「デベハトップ」に化けてしまうという現象が起こることがあります。 何でこんなことになるかというと、文字列中のバイトを走査して行ったときに1バイトずつ見ていってしまうと、本来は2バイト文字の一部であるところが変換されてしまうためです。具体的な例を挙げます。 83 6F 83 67 83 8B 83 41 83 62 83 4E 83 58 バトルアックス 00 6F 00 67 00 8B 00 41 00 62 00 4E 00 58 .o.g...A.b.N.X 00 6F 00 67 00 8B 00 61 00 62 00 6E 00 78 .o.g...a.b.n.x 83 6F 8
C/C++のとんだ落とし穴（ハマっちまったよ） - 檜山正幸のキマイラ飼育記 (はてなBlog)
とあるC++コードがコンパイルエラーするんですが、原因がまったく分からなかったんですよ。「そんなバカな?!」という感じ。しばらくハマってしまいましたよ。 結局、C++でもCでも同じことが起きることが分かりました。次は、僕が遭遇したのと同じ現象が起きるC言語のソースコードです。 // -*- coding: sjis -*- // strange.c struct ThreeNums { int x; // 負の数も指定可能 int y; int z; }; int total(struct ThreeNums nums) { return nums.x + nums.y + nums.z; } コンパイルすると： $ type tdm-gcc tdm-gcc is aliased to `/c/Installed/TDM-GCC-64/bin/gcc.exe' $ tdm-gcc --ve
JIS2004 with Windows SDK
JIS X 0213:2004をWindows SDKレベルでどうやって対応しようかというプレゼンしたときの資料です。2007年に作ったものですが、今でもあまり変わらないはずです。
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
Shift_JISにおける危険な文字まとめ
今時Shift_JISでプログラミングするバカな奴はいないだろうけど折角まとめたので公開 2バイト目がアスキーコードど丸被りしているものを列挙する@[\]^_`{|}~405B5C5D5E5F607B7C7D7E81 ー―‐／＼??＋??±×82・・・・・・Ａ・・・・83ァゼソゾタダチボポマミ84АЪЫЬЭЮЯклмн85・・・・・・・・・・・86・・・・・・・・・・・87????????・????・・・??88・・・・・・・・・・・89院閏噂云運雲荏閲榎厭円8A魁骸浬馨蛙垣柿顎掛笠樫8B機擬欺犠疑祇義宮弓急救8C掘啓圭珪型契形鶏芸迎鯨8D后梗構江洪浩港砿鋼閤降8E察纂蚕讃賛酸餐施旨枝止8F宗充十従戎柔汁旬楯殉淳90拭深申疹真神秦須酢図厨91繊措曾曽楚狙疏捜掃挿掻92叩端箪綻耽胆蛋畜竹筑蓄93邸甜貼転顛点伝怒倒党冬94如納能脳膿農覗倍培媒梅95鼻票表評豹廟描府怖扶敷96法房暴望某棒冒本翻凡
ディベロッパー製品開発統括部 Blog : Silverlight 4 Runtime がリリースされました
マイクロソフトのディベロッパー製品開発を担当している部署です。 Silverlight 4 SDK/Tools 正式版が公開されました 先週からになりますが、 Silverlight4 SDK および Visual Studio 2010 用の開発アドインが公開されました。... Author: DDJPNVS Date: 06/15/2010 Small Basic 0.9 がリリースされました 前回のリリースから大幅に機能強化を施して、Small Basic の最新バージョンである 0.9 がリリースされました。 今回の強化ポイントは、第一にパフォーマンスが大幅に高くなったことです。... Author: DDJPNVS Date: 06/13/2010 VS フィードバックのツイッターを始めました まだ試験運用中ですがhttps://connect.microsoft.com/Vis
第2回：C#プログラムでサロゲート・ペアの動作を検証する（前編）
.NET Framework対応のアプリケーションが扱う文字列に，4バイト長で1文字を表す「サロゲート・ペア」が含まれる場合，文字列操作にどのような影響があるだろうか。.NET Frameworkの文字列操作には，ユーザー・インタフェースやファイル操作，プログラム内部での処理など様々な形態が考えられる。ここでは，基本的な振舞いを見極めるために，文字列処理において最も基本的で頻繁に利用されるStringクラス（Stringオブジェクト）に着目し，2回に分けて検証する。 Stringクラスには，メソッドやプロパティなどの構成メンバーが，50個くらい定義されており，それを一つひとつ詳細に解説するのはきりがない（注1）。ここでは，今後皆さんが，.NET Framework環境でサロゲート・ペアに対応したアプリケーションを構築する際にヒントや留意点を導き出せるように，Stringクラスの代表的な機能
第1回：進まないJIS2004への移行，その原因は？
2004年に制定された最新の文字コード規格「JIS X 0213:2004（通称：JIS2004）」。このJIS2004に対応したWindows Vistaがリリースされて，早1年が経過した。JIS2004自体は，フォントやIMEの普及に合わせて，ユーザーに順調に浸透している。しかし，ユーザーからのデータを受け取る企業情報システムの側では，JIS2004への対応が進んでいないのが実情だ。なぜJIS2004への対応が進まないのか。その現状をまとめてみよう。 JIS X 0213:2004（JIS2004）は，2004年に制定された最新の文字コード規格。過去の文字コード規格に対して多くの文字を追加しており，従来扱えなかった日本の地名・人名などが表現できるようになった（JIS X 0213の概要や，2004年に改訂された経緯については，ITproの記事「VistaでUnicode以外の選択肢はな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
