cksumposix - מקוון בענן

תָכְנִית:

שֵׁם

cksum - כתוב סכומי ביקורת וגדלים של קבצים

תַקצִיר

csum [פילה...]

תיאור

אל האני csum השירות יחשב ותכתוב לפלט סטנדרטי בדיקת יתירות מחזורית
(CRC) עבור כל קובץ קלט, וגם לכתוב לפלט סטנדרטי את מספר האוקטטים בכל אחד
קוֹבֶץ. ה-CRC המשמש מבוסס על הפולינום המשמש לבדיקת שגיאות CRC ב-
תקן ISO/IEC 8802-3:1996 (Ethernet).

הקידוד עבור סכום הבדיקה של CRC מוגדר על ידי הפולינום המייצר:

G(x)=x32 +x26 +x23 +x22 +x16 +x12 +x11 +x10 +x8+x7+x5+x4+x2+x+1

מבחינה מתמטית, ערך ה-CRC המתאים לקובץ נתון יוגדר על ידי ה-
הנוהל הבא:

1. n סיביות שיש להעריך נחשבות למקדמים של פולינום mod 2
M(x) של תואר n−1. אלה n סיביות הן הסיביות מהקובץ, עם הכי הרבה
ביט משמעותי הוא ה-bit המשמעותי ביותר של האוקטט הראשון של הקובץ וה-
הביט האחרון הוא הסיביות הפחות משמעותיות של האוקטט האחרון, מרופד באפס ביטים (אם
הכרחי) כדי להשיג מספר אינטגרלי של אוקטטים, ואחריו אוקטטה אחת או יותר
מייצג את אורך הקובץ כערך בינארי, אוקטטה הכי פחות משמעותית תחילה.
יש להשתמש במספר הקטן ביותר של אוקטטים המסוגלים לייצג את המספר השלם הזה.

2. M(x) מוכפל ב x32 (כלומר, הוסט שמאלה 32 סיביות) ומחולק ב G(x) באמצעות
חלוקת mod 2, מייצרת שארית R(x) בדרגה ≤ 31.

3. המקדמים של R(x) נחשבים לרצף של 32 סיביות.

4. רצף הסיביות משלים והתוצאה היא CRC.

אפשרויות

אין.

אופרנדים

האופרנד הבא יהיה נתמך:

פילה שם נתיב של קובץ שיש לבדוק. אם לא פילה אופרנדים מצוינים, ה
יש להשתמש בקלט סטנדרטי.

STDIN

יש להשתמש בקלט הסטנדרטי אם לא פילה אופרנדים מפורטים, וישמשו אם א
פילה אופרנד הוא '-' והיישום מתייחס ל '-' כלומר קלט סטנדרטי.
אחרת, לא ייעשה שימוש בקלט הסטנדרטי. עיין בסעיף קבצי קלט.

קלט קבצים

קבצי הקלט יכולים להיות כל סוג קובץ.

הסביבה וריאציות

משתני הסביבה הבאים ישפיעו על הביצוע של csum:

שפה ספק ערך ברירת מחדל עבור משתני הבינאום שאינם מוגדרים או
ריק. (ראה את הכרך של הגדרות הבסיס של POSIX.1-2008, סעיף 8.2,
בינאום משתנים בעד הבכורה של בינאום
משתנים המשמשים לקביעת הערכים של קטגוריות מקומיות.)

LC_ALL אם מוגדר לערך מחרוזת לא ריקה, עוקף את הערכים של כל האחרים
משתני בינאום.

LC_CTYPE קבע את המקום לפרשנות של רצפים של בתים של נתוני טקסט
כתווים (לדוגמה, בייט בודד לעומת תווים מרובי בייטים ב
טיעונים).

LC_MESSAGES
קבע את המקום שבו יש להשתמש כדי להשפיע על הפורמט והתוכן של
הודעות אבחון שנכתבו לפי שגיאת תקן.

NLSPATH קבע את המיקום של קטלוגי הודעות לעיבוד של LC_MESSAGES.

אסינכרוני אירועים

בְּרִירַת מֶחדָל.

STDOUT

עבור כל קובץ שעובד בהצלחה, ה- csum שירות יכתוב להלן
פורמט:

"%u %d %s\n", <בדיקת>,# of אוקטטים>,שם נתיב>

אם לא פילה צוין אופרנד, שם הנתיב והמוביל שלו יושמט.

STDERR

השגיאה הסטנדרטית תשמש רק עבור הודעות אבחון.

תפוקה קבצים

אין.

מורחבים תיאור

אין.

יְצִיאָה סטָטוּס

יוחזרו ערכי היציאה הבאים:

0 כל הקבצים עובדו בהצלחה.

>0 אירעה שגיאה.

השלכות OF שגיאות

בְּרִירַת מֶחדָל.

אל האני הבא סעיפים יש לו אִינפוֹרמָטִיבִי.

בקשה נוהג

אל האני csum כלי השירות משמש בדרך כלל כדי להשוות במהירות בין קובץ חשוד לקובץ מהימן
גרסה של אותו הדבר, כדי להבטיח שקבצים המועברים באמצעות מדיה רועשת מגיעים
שָׁלֵם. עם זאת, השוואה זו אינה יכולה להיחשב מאובטחת מבחינה קריפטוגרפית. ה
הסיכוי שקובץ פגום יפיק את אותו CRC כמו המקור קטן; מְכוּוָן
הונאה היא קשה, אבל כנראה לא בלתי אפשרית.

למרות קבצי קלט ל csum יכול להיות כל סוג, התוצאות לא חייבות להיות מה שיהיו
צפוי בקבצי מכשיר מיוחד לתווים או בסוגי קבצים שאינם מתוארים על ידי המערכת
נפח ממשקים של POSIX.1-2008. מכיוון שכרך זה של POSIX.1-2008 אינו מציין את
גודל הבלוק המשמש בעת ביצוע קלט, סכומי ביקורת של קבצים מיוחדים של תווים אינם צריכים לעבד
כל הנתונים בקבצים האלה.

האלגוריתם מתבטא במונחים של זרם סיביות המחולק לאוקטטים. אם קובץ הוא
מועבר בין שתי מערכות ועובר כל טרנספורמציה של נתונים (כגון שינוי
סדר בתים של little-endian ל-big-endian), לא ניתן לצפות לערכי CRC זהים.
הטמעות המבצעות טרנספורמציות כאלה עשויות להתרחב csum לטפל בכאלה
מצבים.

דוגמאות

אין.

Rationalale

התוכנית הבאה בשפת C יכולה לשמש כמודל לתיאור האלגוריתם. זה
מניח שא char הוא אוקטט אחד. זה גם מניח שהקובץ כולו זמין עבור
אחד לעבור דרך הפונקציה. זה נעשה למען הפשטות בהדגמת ה
אלגוריתם, ולא כמודל יישום.

סטטי לא חתום ארוך crctab[] = {
0x00000000,
0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4
};

unsigned long memcrc(const unsigned char *b, size_t n)
{
/* ארגומנטים קלט:
* const unsigned char* b == רצף בתים ל-checksum
* size_t n == אורך הרצף
*/

רשום size_t i;
רשום לא חתום c, s = 0;

for (i = n; i > 0; −−i) {
c = *b++;
s = (s << 8) ^ crctab[(s >> 24) ^ c];
}

/* הארך עם אורך המחרוזת. */
while (n != 0) {
c = n & 0377;
n >>= 8;
s = (s << 8) ^ crctab[(s >> 24) ^ c];
}

להחזיר ~s;
}

הפרקטיקה ההיסטורית של כתיבת מספר ``בלוקים'' שונה לכתיבה
מספר האוקטטים, שכן האחרון הוא לא רק שימושי יותר, אלא גם מאז היסטורי
יישומים לא היו עקביים בהגדרת המשמעות של ``חסימה''.

האלגוריתם שבו נעשה שימוש נבחר כדי להגביר את החוסן התפעולי של csum. לא זה ולא זה
מערכת V ולא BSD סכום נבחר אלגוריתם. מאחר וכל אחד מאלה היה שונה ו
כל אחת מהן הייתה התנהגות ברירת המחדל במערכות אלו, לא הייתה פשרה מציאותית זמינה אם
שניהם נבחרו - קבוצה כלשהי של יישומים היסטוריים יישבר. לכן, השם
שונה ל csum. למרות ההיסטורי סכום פקודות כנראה ימשיכו להיות
מסופק במשך שנים רבות, תוכניות המיועדות לניוד בין מערכות צריכות להשתמש ב-
שם חדש.

האלגוריתם שנבחר מבוסס על זה שבו נעשה שימוש בתקן ISO/IEC 8802-3:1996
(Ethernet) עבור שדה רצף בדיקת המסגרת. האלגוריתם בו נעשה שימוש אינו תואם את
הגדרה טכנית של א בדיקת; המונח משמש מסיבות היסטוריות. האורך של
הקובץ נכלל בחישוב ה-CRC מכיוון שזה מקביל להכללה של אורך
שדה באמצעות Ethernet ב-CRC שלו, אבל גם בגלל שהוא שומר מפני התנגשויות בשוגג
בין קבצים שמתחילים בסדרות שונות של אפס אוקטטים. הסיכוי ששניים
קבצים שונים מייצרים CRCs זהים הרבה יותר כאשר אורכם אינו
נחשב. שמירה על האורך וסכום הבדיקה של הקובץ עצמו בנפרד תניב א
אלגוריתם מעט חזק יותר, אבל השימוש ההיסטורי תמיד היה מספר בודד
(סכום הבדיקה כפי שהודפס) מייצג את החתימה של הקובץ. כך הוחלט
השימוש ההיסטורי היה השיקול החשוב יותר.

ההצעות המוקדמות הכילו שינויים באלגוריתם ה-Ethernet שכללו חילוץ
ערכי טבלה בכל פעם שתוצאת ביניים הפכה לאפס. הוכח שזה פחות
חזק מהשיטה הנוכחית וקשה מתמטית לתיאור או להצדקה.

החישוב בו נעשה שימוש זהה לזה שניתן בקוד פסאודו ב-Sarwate הנזכר
מאמר. העיבוד הפסאודו-קוד הוא:

X <− 0; Y <− 0;
ל i <− m -1 צעד -1 עד 0 do
להתחיל
T <− X(1) ^ א[i];
X(1) <− X(0); X(0) <− Y(1); Y(1) <− Y(0); Y(0) <− 0;
איך: f[T] ו f'[T] לציין מה היא ט-ה מילים in מה היא
שולחן f ו f' ;
X <− X ^ f[T]; Y <− Y ^ f'[ת];
סוף

הפסאודו-קוד משוחזר בדיוק כפי שניתן; עם זאת, שים לב שבמקרה של csum,
א [i] מייצג בייט של הקובץ, המילים X ו Y מתייחסים כאל 32 סיביות בודדות
ערך, והטבלאות f ו f' הם טבלה בודדת המכילה ערכים של 32 סיביות.

המאמר המוזכר של Sarwate דן גם ביצירת הטבלה.

FUTURE כיוונים

אין.

השתמש ב-cksumposix באינטרנט באמצעות שירותי onworks.net