الفنون رقم 010

ARTS12 أكتوبر 2018 في 01:46 ص10 min read

الفنون رقم 010

简体中文 العربية English Español Bahasa Indonesia Português

ARTS هو نشاط بدأه 由左耳朵耗子--陈皓: قم بإجراء سؤال واحد على الأقل عن خوارزمية leetcode كل أسبوع، واقرأ مقالًا تقنيًا واحدًا على الأقل باللغة الإنجليزية وعلق عليه، وتعلم مهارة فنية واحدة على الأقل، وشارك المقالة مع الآراء والأفكار. (أي أن الخوارزمية والمراجعة والنصائح والمشاركة يشار إليها باسم ARTS) وتستمر لمدة عام واحد على الأقل.

الفنون 010

هذه المادة 10

سؤال خوارزمية الخوارزمية

لقد قمت بطرح سؤالين حول الخوارزمية هذا الأسبوع

السؤال 1

سؤال خوارزمية leetcode رقم 767.إعادة تنظيم السلسلة: الصعوبة: معتدلة


Given a string S, check if the letters can be rearranged so that two characters that are adjacent to each other are not the same.

If possible, output any possible result.  If not possible, return the empty string.

Example 1:

Input: S = "aab"
Output: "aba"
Example 2:

Input: S = "aaab"
Output: ""
Note:

S will consist of lowercase letters and have length in range [1, 500].

فكرتي في حل المشكلة، أول ما خطر ببالي هو أنه إذا زاد عدد حرف معين عن نصف طول حرف S فيجب إرجاع “” . يتطلب السؤال أحرفًا صغيرة فقط، لذلك فكرت أولاً في حساب عدد كل حرف في السلسلة S، ثم فكرت في الفرز حسب عدد الأحرف. أخيرًا، كان علي أن أفكر في بعض الشروط الحدودية، التعقيد الزمني والتعقيد المكاني. التنفيذ المحدد هو على النحو التالي. وقت تشغيل LeetCode هو 0 مللي ثانية والتعقيد الزمني هو O(n).


char* reorganizeString(char* S) {
    int len = strlen(S);
    
    //计算S中每个字母的个数
    //Calculate the number of  letters in S
    int* charCount = (int*)malloc(sizeof(int) * 26);
    memset(charCount, 0, sizeof(int) * 26);
    for (int i = 0; i < len; i++) {
        int index = S[i] - 97;
        charCount[index]++;
    }
    
    //如果某一个字母的个数超过S长度的一半，直接返回""
    //If the number of letters is more than half the length of S, directly return  ""
    for (int i = 0; i < 26; i++) {
        int index  = charCount[i];
        if (index > len/2 + len%2) {
            return "";
        }
    }
   
    
    //"排序"，这里的排序是按字母的个数排序，字母多的放到前面。比如S="dddbbbbffkkkkkk",那么排序后的orderS是"kkkkkkbbbbdddff"
    //"sorting",The sorting here is sorted by the number of letters, and put the more letters in front,eg:if S="dddbbbbffkkkkkk",so orderS is "kkkkkkbbbbdddff"
    char * orderS = (char*)malloc(sizeof(char*) * len);
    int count = 0;
    for (int i = 0; i < 26; i++) {
        int  sortingNum = charCount[i];
        int maxIndex = i;
        for (int j =0; j < 26; j++) {
            if (sortingNum < charCount[j] ) {
                sortingNum = charCount[j];
                maxIndex = j;
            }
        }
        for (int j = 0; j < sortingNum; j++) {
            orderS[count++] = maxIndex + 97;
        }
        charCount[maxIndex] = 0;
    }
    
    //打乱顺序 比如orderS是'bbbc ccdd',打乱后就是bcbcbdcd
    //reorganizeString eg: orderS is 'bbbc ccdd', reorganizeString is bcbcbdcd
    int max = len/2;
    int mid = max+ len%2;
    for (int i =0; i < max; i++) {
        S[2*i] =orderS[i];
        S[2*i+1] =orderS[mid+i];
    }
    if (len%2) {
        S[len -1] = orderS[max];
    }
    free(orderS);
    free(charCount);
    
    return S;
}

السؤال 2

سؤال خوارزمية leetcode رقم 541.السلسلة العكسية II: الصعوبة : سهلة


Given a string and an integer k, you need to reverse the first k characters for every 2k characters counting from the start of the string. If there are less than k characters left, reverse all of them. If there are less than 2k but greater than or equal to k characters, then reverse the first k characters and left the other as original.
Example:
Input: s = "abcdefg", k = 2
Output: "bacdfeg"
Restrictions:
The string consists of lower English letters only.
Length of the given string and k will in the range [1, 10000]

هذا السؤال بسيط نسبيا، فقط فكر في بعض المواقف الأخرى.

void ReverseString(char* str,int min,int max) {
    int i = min;
    int j = max;
    while (i < j) {
        char temp = * (str + i);
        * (str + i) = * (str + j);
        * (str + j)  = temp;
        
        i++;
        j--;
    }
}

char* reverseStr(char* s, int k) {
    u_long strlength =  strlen(s);
    if ( k == 0) {
        ReverseString(s,0,strlength-1);
        
    }
    else {
        u_long count = strlength/(2*k);
        for (int i = 0; i < count; i++) {
            ReverseString(s,(2*k)*i,(2*k)*i + k-1);
        }
        u_long count_1 = strlength%(2*k);
        if (count_1 > 0) {
            if(count_1<k){//剩余少于 k 个字符
                ReverseString(s,strlength- count_1,strlength -1);
            }
            else{//小于 2k 但大于或等于 k 个字符
                ReverseString(s,strlength- count_1,strlength- count_1  + k -1);
            }
        } 
    }
    return s;
}

مراجعة

هذه المقالة مأخوذة من: https://medium.freecodecamp.org/how-to-become-a-git-expert-e7c38bf54826

كيف تصبح خبيرًا في Git كيف تصبح خبيرًا في Git

“تصوير فوتوغرافي بفاصل زمني لرجل يقف بجانب الطريق والجسر أثناء النهار” بواسطة أحسن آفي على Unsplash تصوير فوتوغرافي بفاصل زمني لأشخاص يقفون على جانب الطريق والجسر أثناء النهار بواسطة Ahsan Avi على Unsplash

لقد أخطأت في التزامي، كيف أصلحه؟ لقد أخطأت عند إرسال الكود، كيف يمكنني تصحيحه؟

سجل الالتزام الخاص بي في حالة من الفوضى، كيف يمكنني أن أجعله أكثر تنظيمًا؟ سجل تنفيذ التعليمات البرمجية الخاص بي في حالة من الفوضى، كيف يمكنني أن أبقيه مرتبًا؟

إذا كانت لديك الأسئلة المذكورة أعلاه من قبل، فهذه التدوينة مخصصة لك. يغطي هذا المنشور قائمة بالموضوعات التي ستجعلك خبيرًا في Git. إذا كانت لديك الأسئلة المذكورة أعلاه من قبل، فهذا المقال مخصص لك. تتناول هذه المقالة مجموعة من المواضيع التي ستجعلك خبيرًا في Git.

إذا كنت لا تعرف أساسيات Git، انقر هنا للتحقق من مدونتي حول أساسيات Git. من الضروري أن تعرف أساسيات Git لتحقيق أقصى استفادة من هذه المقالة. إذا كنت لا تعرف أساسيات Git، فيرجى النقر هنا لعرض مدونتي الخاصة بأساسيات Git. يعد فهم أساسيات Git ضروريًا لتحقيق أقصى استفادة من هذه المقالة.

“لوحة خزفية مكسورة على الأرض” بواسطة chuttersnap على Unsplash لوحة خزفية مكسورة على الأرض بواسطة chuttersnap على Unsplash

السيناريو 1 السيناريو 1

لنفترض (على افتراض) أنك قمت بتنفيذ مجموعة من الملفات وأدركت أن رسالة الالتزام التي أدخلتها ليست واضحة في الواقع. الآن تريد تغيير رسالة الالتزام. من أجل القيام بذلك يمكنك استخدام git commit --amend

لنفترض أنك ارتكبت مجموعة من الملفات وأدركت أن رسالة الالتزام التي أدخلتها ليست واضحة في الواقع. الآن يجب تغيير رسالة الالتزام. للقيام بذلك، يمكنك استخدام git Commit -amend

git commit --amend -m “New commit message”

السيناريو 2 السيناريو 2

لنفترض أنك أردت الالتزام بستة ملفات، ولكن عن طريق الخطأ، انتهى بك الأمر إلى الالتزام بخمسة ملفات فقط. قد تعتقد أنه يمكنك إنشاء التزام جديد وإضافة الملف السادس إلى هذا الالتزام.

لنفترض أنك تريد إرسال 6 ملفات، ولكن عن طريق الخطأ، انتهى بك الأمر إلى إرسال 5 ملفات فقط. قد تعتقد أنه يمكنك إنشاء التزام جديد وإضافة ملف سادس إلى هذا الالتزام.

لا حرج في هذا النهج. ولكن، للحفاظ على سجل التزام أنيق، ألن يكون من الأفضل أن تتمكن بطريقة أو بأخرى من إضافة هذا الملف إلى التزامك السابق نفسه؟ يمكن القيام بذلك من خلال git commit --amend أيضًا:

لا حرج في هذا النهج. ومع ذلك، من أجل الحفاظ على سجل التزام مرتب، أليس من الأفضل أن تتمكن بطريقة أو بأخرى من إضافة هذا الملف إلى الالتزام السابق نفسه؟ يمكن تحقيق ذلك باستخدام “git Commit -amend”:

git add file6
git commit --amend --no-edit

--no-edit يعني أن رسالة الالتزام لا تتغير.

السيناريو 3 المشهد 3

عندما تقوم بتنفيذ التزام في Git، يكون الالتزام مرتبطًا به اسم المؤلف والبريد الإلكتروني للمؤلف. بشكل عام، عندما تقوم بإعداد Git لأول مرة، فإنك تقوم بإعداد اسم المؤلف والبريد الإلكتروني. لا داعي للقلق بشأن تفاصيل المؤلف لكل التزام.

عند تنفيذ التزام في Git، يكون للالتزام اسم مؤلف وبريد إلكتروني للمؤلف. عادةً، عند قيامك بإعداد Git لأول مرة، تقوم بإعداد اسم المؤلف والبريد الإلكتروني. لا داعي للقلق بشأن تفاصيل المؤلف لكل إرسال.

ومع ذلك، من الممكن أن ترغب في استخدام معرف بريد إلكتروني مختلف لمشروع معين. تحتاج إلى تكوين معرف البريد الإلكتروني لهذا المشروع باستخدام الأمر: ومع ذلك، قد ترغب في استخدام معرف بريد إلكتروني مختلف لمشروع معين. تحتاج إلى تكوين معرف البريد الإلكتروني للمشروع باستخدام الأمر التالي:

git config user.email “your email id”

لنفترض أنك نسيت تكوين البريد الإلكتروني وقمت بالفعل بتنفيذ التزامك الأول. يمكن استخدام Amend لتغيير مؤلف التزامك السابق أيضًا. يمكن تغيير مؤلف الالتزام باستخدام الأمر التالي:

لنفترض أنك نسيت تكوين بريدك الإلكتروني وقمت بالفعل بتنفيذ التزامك الأول. يمكن أيضًا استخدام “تعديل” لتغيير مؤلف إرسالك السابق. يمكن تغيير مؤلف الالتزام باستخدام:

git commit --amend --author "Author Name <Author Email>"

أشر إلى ملاحظة الملاحظة

استخدم الأمر amend فقط في مستودعك المحلي. يمكن أن يؤدي استخدام amend للمستودع البعيد إلى حدوث الكثير من الالتباس. استخدم أمر “التعديل” فقط في المستودعات المحلية. يمكن أن يسبب استخدام التعديل مع المستودعات البعيدة الكثير من الارتباك.

سجل الالتزام الخاص بي في حالة من الفوضى. كيف أتعامل معها؟ سجل التزامي في حالة من الفوضى. كيف أتعامل معها؟

لنفترض أنك تعمل على جزء من التعليمات البرمجية. أنت تعلم أن الكود سيستغرق حوالي عشرة أيام حتى يكتمل. وفي غضون تلك الأيام العشرة، سيقوم المطورون الآخرون أيضًا بإرسال التعليمات البرمجية إلى المستودع البعيد. لنفترض أنك تعمل على جزء من التعليمات البرمجية. كما ترى، يستغرق إكمال الكود حوالي 10 أيام. خلال هذه الأيام العشرة، سيقوم المطورون الآخرون أيضًا بإرسال التعليمات البرمجية إلى المستودع البعيد.

إنها ممارسة جيدة أن تحافظ على تحديث كود المستودع المحلي لديك باستخدام الكود الموجود في المستودع البعيد. يؤدي هذا إلى تجنب الكثير من تعارضات الدمج لاحقًا عند رفع طلب سحب. لذلك قررت أنك ستقوم بسحب التغييرات من المستودع البعيد مرة كل يومين.من الممارسات الجيدة أن تحافظ على تحديث كود المستودع المحلي الخاص بك باستخدام الكود الموجود في المستودع البعيد. يؤدي هذا إلى تجنب الكثير من تعارضات الدمج عند تقديم طلبات السحب في المستقبل. لذلك قررت سحب التغييرات من المستودع البعيد كل يومين.

في كل مرة تقوم فيها بسحب التعليمات البرمجية من المستودع البعيد إلى المستودع المحلي، يتم إنشاء التزام دمج جديد في المستودع المحلي الخاص بك. هذا يعني أن سجل الالتزام المحلي الخاص بك سيحتوي على الكثير من عمليات الدمج مما قد يجعل الأمور تبدو مربكة للمراجع. في كل مرة يتم فيها سحب التعليمات البرمجية من المستودع البعيد إلى المستودع المحلي، يتم إنشاء التزام دمج جديد في المستودع المحلي. وهذا يعني أن سجل الالتزام المحلي الخاص بك سيحتوي على الكثير من عمليات الدمج، مما سيؤدي إلى إرباك المراجعين.

إليك كيف سيبدو سجل الالتزام في مستودعك المحلي. إليك ما يبدو عليه سجل الالتزام في مستودعك المحلي.

كيف تجعل سجل الالتزام يبدو أكثر أناقة؟ هذا هو المكان الذي يأتي فيه rebase للإنقاذ. كيف يمكنني أن أجعل سجل الالتزام الخاص بي يبدو أنظف؟ هذا هو المكان الذي يأتي فيه rebase للإنقاذ.

ما هو إعادة التأسيس؟ اسمحوا لي أن أشرح ذلك من خلال مثال.

يوضح هذا الرسم البياني الالتزامات في فرع الإصدار وفرع الميزات الخاص بك

يحتوي فرع الإصدار على ثلاث التزامات: Rcommit1، وRcommit2، وRcommit3.
لقد قمت بإنشاء فرع الميزات الخاص بك من فرع الإصدار عندما كان لديه التزام واحد فقط، وهو Rcommit1.
لقد قمت بإضافة التزامين إلى فرع الميزات. هم Fcommit1 وFcommit2.
هدفك هو نقل الالتزامات من فرع الإصدار إلى فرع الميزات لديك.
سوف تستخدم rebase للقيام بذلك.
ليكن اسم فرع الإصدار هو الإصدار واسم فرع الميزات هو الميزة.
يمكن إجراء إعادة التأسيس باستخدام الأوامر التالية:

يوضح هذا الرسم البياني الالتزامات في فروع الإصدار وفروع الميزات

يحتوي فرع الإصدار على ثلاث التزامات: Rcommit1 وRcommit2 وRcommit3.
عندما يكون لدى فرع الإصدار التزام واحد فقط (أي Rcommit1)، يمكنك إنشاء فرع الميزات من فرع الإصدار.
لقد قمت بإضافة التزامين إلى فرع الميزات. هم Fcommit1 وFcommit2.
هدفك هو دمج الالتزامات من فرع الإصدار في فرع الميزات الخاص بك.
تحتاج إلى استخدام rebase للقيام بذلك.
ليكن اسم فرع الإصدار هو الإصدار واسم فرع الميزات هو الميزة.
يمكنك استخدام الأمر التالي لإعادة التأسيس:

git checkout feature
git rebase release

إعادة التأسيس

أثناء إعادة التأسيس، فإن هدفك هو التأكد من حصول فرع الميزات على أحدث التعليمات البرمجية من فرع الإصدار.

يحاول إعادة التأسيس إضافة كل التزام، واحدًا تلو الآخر، والتحقق من التعارضات. هل يبدو هذا محيرا؟

اسمحوا لي أن أشرح بمساعدة الرسم التخطيطي.

يوضح هذا ما يفعله إعادة الأساس داخليًا:

إعادة الأساس عند إعادة التأسيس، يكون هدفك هو التأكد من حصول فرع الميزات على أحدث التعليمات البرمجية من فرع الإصدار.

يحاول rebase إضافة كل التزام واحدًا تلو الآخر والتحقق من التعارضات. يبدو مربكا؟

اسمحوا لي أن أشرح ذلك مع رسم تخطيطي.

يوضح هذا ما يفعله rebase فعليًا داخليًا:

الخطوة 1

في اللحظة التي تقوم فيها بتشغيل الأمر، يتم توجيه فرع الميزة إلى رأس فرع الإصدار.
الآن يحتوي فرع الميزة على ثلاث التزامات: Rcommit1، وRcommit2، وRcommit3.
ربما تتساءل عما حدث لـ Fcommit1 وFcommit2.
لا تزال الالتزامات موجودة وسيتم استخدامها في الخطوات أدناه. الخطوة 2
يحاول Git الآن إضافة Fcommit1 إلى فرع الميزات.
إذا لم يكن هناك تعارض، تتم إضافة Fcommit1 بعد Rcommit3
في حالة وجود تعارض، سيقوم Git بإعلامك، وسيتعين عليك حل التعارض يدويًا. الخطوة 3
بمجرد إضافة Fcommit1، سيحاول Git إضافة Fcommit2.
مرة أخرى، إذا لم يكن هناك تعارض، تتم إضافة Fcommit2 بعد Fcommit1 وتكون عملية إعادة الأساس ناجحة.
في حالة وجود تعارض، سيقوم Git بإعلامك، وسيتعين عليك حله يدويًا.
بعد الانتهاء من عملية إعادة الأساس بالكامل، ستلاحظ أن فرع الميزات يحتوي على Rcommit1 وRcommit2 وRcommit3 وFcommit1 وFcommit2.

الخطوة 1

عند تشغيل الأمر، يشير فرع الميزة إلى رأس فرع الإصدار.
يحتوي فرع الميزات الآن على ثلاث التزامات: Rcommit1 وRcommit2 وRcommit3.
ربما تتساءل عما حدث لـ Fcommit1 وFcommit2.
لا يزال الالتزام موجودًا وسيتم استخدامه في الخطوات التالية. الخطوة 2
يحاول Git الآن إضافة Fcommit1 إلى فرع الميزات.
إذا لم يكن هناك تعارض، أضف Fcommit1 بعد Rcommit3
في حالة وجود تعارض، سيقوم Git بإعلامك ويجب عليك حل التعارض يدويًا. الخطوة 3
بعد إضافة Fcommit1، سيحاول Git إضافة Fcommit2.
وبالمثل، إذا لم يكن هناك تعارض بعد Fcommit1، أضف Fcommit2 بعد Fcommit1، وستنجح عملية إعادة الأساس.
في حالة حدوث تعارض، سيقوم Git بإخطارك ويجب عليك حله يدويًا.
مبين. بعد الانتهاء من عملية إعادة الأساس بالكامل، ستلاحظ أن فروع الميزات هي Rcommit1 وRcommit2 وRcommit3 وFcommit1 وFcommit2.

نقاط يجب ملاحظتها

يُعد كل من Rebase وMerge مفيدًا في Git. واحد ليس أفضل من الآخر.
في حالة الدمج، سيكون لديك التزام بالدمج. في حالة إعادة الأساس، لا يوجد التزام إضافي مثل التزام الدمج.
إحدى أفضل الممارسات هي استخدام الأوامر في نقاط مختلفة. استخدم rebase عندما تقوم بتحديث مستودع التعليمات البرمجية المحلي الخاص بك بأحدث التعليمات البرمجية من المستودع البعيد. استخدم الدمج عندما تتعامل مع طلبات السحب لدمج فرع الميزة مرة أخرى مع فرع الإصدار أو الفرع الرئيسي.

ملاحظة

في Git، يعد كل من Rebase وMerge مفيدًا. واحد ليس أفضل من الآخر.
في حالة الدمج، سيكون لديك التزام بالدمج. في حالة إعادة الأساس، لا توجد التزامات إضافية مثل التزامات الدمج.
أفضل الممارسات هي استخدام أوامر مختلفة في أماكن مختلفة. استخدم rebase عند تحديث مستودع التعليمات البرمجية المحلي الخاص بك بأحدث التعليمات البرمجية من المستودع البعيد. عند معالجة طلب سحب، استخدم الدمج لدمج فرع الميزة مرة أخرى إلى فرع الإصدار أو الفرع الرئيسي.

مبروك

أنت الآن خبير في Git 😃تعرفت في هذه التدوينة على:

تعديل الالتزامات
إعادة الأساس وكلاهما مفاهيم مفيدة للغاية. اذهب لاستكشاف عالم Git لمعرفة المزيد.

تهانينا

أنت الآن خبير في Git

تعلمت في هذا المقال:

تعديل وتقديم
إعادة الأساس كلا المفهومين مفيدان. اذهب واستكشف عالم Git وتعلم المزيد.

عن المؤلف أحب التكنولوجيا وأتابع التطورات في هذا المجال. أحب أيضًا مساعدة الآخرين بمعرفتي التكنولوجية.

لا تتردد في التواصل معي على حسابي على LinkedIn https://www.linkedin.com/in/aditya1811/

يمكنك أيضًا متابعتي على تويتر https://twitter.com/adityasridhar18

مشاركات أخرى بقلمي مقدمة إلى Git

كيفية استخدام Git بكفاءة

نصائح:

كيفية استخدام خدمات itms لتثبيت خادم توزيع ipa المزود بشهادات المؤسسة

عملية إعداد الخادم بسيطة نسبيًا. يمكنك استخدام بايدو أو جوجل بنفسك. أستخدم nginx ضمن نظام Mac

الخادم الذي أستخدمه هو Mac Nginx. التكوين بسيط للغاية وهناك العديد من البرامج التعليمية على الإنترنت. المفتاح الآن هو كيفية تمكين https.

بعد نظام IOS7.1، إذا كنت تريد استخدام شهادة مؤسسة (299 دولارًا) لتثبيت ipa عبر الإنترنت من خلال خدمات itms، فيجب عليك استخدام بروتوكول https.

يتيح nginx تكوين https: https://www.jianshu.com/p/fe0fadb38600、

هناك خطوة إعادة تشغيل في المقالة الآن: تقوم خدمات الشراب بإعادة تشغيل Nginx

يوصى بتمكين سجل الأخطاء في ملف تكوين nginx، بحيث يمكنك عرضها مباشرة في حالة وجود أخطاء أثناء عملية بدء التشغيل. لا يمكن رؤية بعض الأخطاء على الجهاز. على سبيل المثال، عندما أستخدم إعادة تشغيل خدمة Brew nginx لإعادة التشغيل، فإنه يطالب بالنجاح.

Stopping `nginx`... (might take a while)
==> Successfully stopped `nginx` (label: homebrew.mxcl.nginx)
==> Successfully started `nginx` (label: homebrew.mxcl.nginx)

لكنها فشلت في الواقع.

لاحقًا رأيت في سجل الخطأ: فشل ربط () بـ 0.0.0.0:443 (13: تم رفض الإذن)

تحتاج إلى استخدام: تقوم خدمات sudo Brew بإعادة تشغيل nginx للبدء

يوجد هنا مفهوم يتطلب CA، شرحًا حول CA: https://www.cnblogs.com/handsomeBoys/p/6556336.html、https://www.jianshu.com/p/57066821b863 بكل بساطة، يتطلب تشغيل https شهادة. يجب تطبيق هذه الشهادة على موقع ويب موثوق لجهة خارجية، أو يمكنك إنشائها بنفسك. بالطبع، يجب معالجة مواقع الويب https التي تعمل عبر الإنترنت مثل مواقع الويب الموثوقة التابعة لجهات خارجية. لأن الشهادات المبنية ذاتيًا تتطلب من المستخدمين تثبيتها يدويًا، ولا تثق بها المتصفحات. لن يكون هناك أي فائدة من https إذا كان بإمكان أي شخص إنشاء شهادة. لكن هدفنا الحالي هو استخدامه على الشبكة المحلية الخاصة بالشركة، لذلك نستخدم شهادة ذاتية الصنع. يجب أن يتم تثبيت الشهادة ذاتية الصنع يدويًا بواسطة المستخدم.

المقالة أدناه حول إعدادات خدمات itms واضحة جدًا أيضًا: http://www.cnblogs.com/feiyiban588/p/5788310.html https://blog.csdn.net/RazerTang/article/details/46898051/

يمكنك أيضًا إنشاء CA باتباع الخطوات التالية:

قم بإنشاء CA الخاص بك

1. مقدمة

من قبل، كانت مدونتي تدعم https واستخدمت شهادة مجانية مدتها عام واحد صادرة عن StartCom CA. StartCom هو مرجع مصدق موثوق به. إن شهادة الجذر الخاصة به موثوقة من قبل أنظمة التشغيل والمتصفحات المختلفة، لذلك سيتم الوثوق أيضًا بالشهادات الصادرة عنها.

لقد قمت مؤخرًا بإنشاء برنامج تحميل وتنزيل حزمة iOS ipa، والذي يتطلب أيضًا استخدام روابط https. لقد قمت بالتحقق عبر الإنترنت ووجدت أنه يمكنني التوقيع على الشهادة بنفسي، لذلك قمت بتطبيق ذلك. فيما يلي الخطوات التفصيلية.

أوصي بشكل خاص بموقع الويب أدناه، والذي يتحدث عنه بالتفصيل.

https://jamielinux.com/docs/openssl-certificate-authority/index.html

هناك بعض الوظائف في البرنامج التعليمي التي تحتاج فقط إلى فهمها، ولكننا لا نحتاج إلى استخدامها، لذلك قمت بإزالة بعض الخطوات لجعلها أكثر بساطة وأسهل في الاستخدام.

2. كاليفورنيا

عندما تعمل كمرجع مصدق بنفسك، فإنك تستخدم الأمر openssl لإنشاء شهادة الجذر الخاصة بك والسماح للمستخدمين بتثبيتها والوثوق بها. ومن ثم يمكن أيضًا الوثوق بجميع الشهادات الموقعة باستخدام شهادة الجذر هذه.

لذا، باعتبارنا CA، يجب علينا أولاً إنشاء شهادة الجذر الخاصة بنا ca.cert.pem، ويتطلب إنشاء شهادة الجذر ca.key.pem.

ابدأ قم بإنشاء المجلد /root/ca. سيتم تنفيذ جميع عمليات CA في هذا المجلد.


 # mkdir /root/ca
    # cd /root/ca
    # mkdir certs crl newcerts private
    # chmod 700 private
    # touch index.txt
    # echo 1000 > serial
    # touch openssl.cnf

/root/ca: مجلد CA

/root/ca/certs: الموقع الذي يتم فيه تخزين الشهادة الموقعة حديثًا وشهادة الجذر

/root/ca/crl: موقع تخزين ملف طلب الشهادة

/root/ca/newcerts: الموقع الذي يتم فيه تخزين الشهادة الموقعة حديثًا، وهي نسخة احتياطية من /root/ca/certs

/root/ca/private: موقع تخزين ca.key.pem، لا تفقده

/root/ca/index.txt: سجل توقيع الشهادة

/root/ca/serial: الرقم التسلسلي لتوقيع الشهادة التالي، المحفوظ في ملف Index.txt

انسخ المحتوى التالي إلى /root/ca/openssl.cnf

# OpenSSL root CA configuration file.
# Copy to `/root/ca/openssl.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 3750
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = CN
stateOrProvinceName_default     = JiangSu
localityName_default            = NanJing
0.organizationName_default      = SIYOU325
organizationalUnitName_default  = SIYOU325
emailAddress_default            = webmaster@siyou325.com

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

للحصول على شرح مفصل، يمكنك الاطلاع على الرابط أعلاه (موصى به حقًا). وهنا سأختار المهم منها.

dir = /root/ca: يجب تغيير هذا إلى مجلد CA أعلاه

السياسة = Policy_strict: استخدم السياسة الصارمة لتوقيع شهادة CA

CountryName_default = CN

0.organizationName_default = SIYOU325 CA

وهذان الاسمان هما أسماء البلدان والمنظمات، والتي سيتم عرضها على الشهادة التي تم إنشاؤها. ما عليك سوى التوقيع على شهادة CA. نحن نحدد هاتين القيمتين فقط ونترك القيمتين الأخريين فارغتين.

[v3_ca]: هذا التكوين مطلوب لتوقيع شهادة CA

[server_cert]: هذا مطلوب لتوقيع شهادة الخادم بعد ذلك

توليد مفتاح الجذر

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096

输入两次密码siyou325123456,这个是很重要的密码，设置严格点。

# chmod 400 private/ca.key.pem

إنشاء شهادة الجذر

# cd /root/ca
# openssl req -config openssl.cnf \
      -key private/ca.key.pem \
      -new -x509 -days 7500 -sha256 -extensions v3_ca \
      -out certs/ca.cert.pem

根据提示输入key的密码：siyou325123456
然后一值回车下去，使用默认值

# chmod 444 certs/ca.cert.pem

-أيام 7300: صالحة لمدة 20 سنة

عند هذه النقطة، تم إنشاء ca.key.pem (مفتاح الجذر) وca.cert.pem (شهادة الجذر). المسارات هي كما يلي

/root/ca/private/ca.key.pem
/root/ca/certs/ca.cert.pem

عند هذه النقطة، تم الانتهاء من إنشاء الشهادة الجذر.

كلمة المرور الخاصة بـ ca.key.pem هي siyou325123456، وهي مهمة جدًا ويجب حفظها جيدًا.

ca.cert.pem هي الشهادة الجذرية. يجب إرسالها إلى المستخدم حتى يتمكن المستخدم من تثبيتها والوثوق بها، بحيث يمكن الوثوق بجميع الشهادات التي نوقعها بهذه الشهادة في المستقبل.

3. إنشاء شهادة الخادم

تم الانتهاء من عمل دور CA. نستخدم الآن دور المستخدم لإنشاء شهادة خادم يمكن استخدامها بواسطة Tomcat وnginx.

لنفترض هنا أن اسم المجال أو عنوان IP الخاص بموقعنا هو 127.0.0.1، ثم قم بإنشاء المجلد 127.0.0.1 في الدليل بنفس مستوى ca، وقم بإنشاء شهادة الخادم في هذا الدليل.

# mkdir /root/127.0.0.1
# cd /root/127.0.0.1

# openssl genrsa -out server.key 2048
# openssl req -new -key server.key -out server.csr

会出现提示，简单点，除了下面几个，其他的都按回车就可以了。
Country Name输入:CN
Common Name输入域名或ip：127.0.0.1
A challenge password输入:server123456

openssl genrsa -out server.key 2048: 2048 بعد هذا الأمر يمثل عدد بتات التشفير. استخدم 4096 بدقة. على سبيل المثال، تستخدم شهادة الجذر أعلاه هذا. بشكل عام، 2048 و1024 كافية. كلما زادت القيمة، زاد وقت انتظار رابط https.

في هذه المرحلة، يتم إنشاء مفتاح الخادم الخاص بنا (server.key) وطلب الشهادة (server.csr).

قم بعد ذلك بنسخ server.csr إلى ca/crl وأعد تسميته إلى 127.0.0.1.csr.pem

cp server.csr ../ca/crl/127.0.0.1.csr.pem

ثم يتم تحويل الدور إلى دور CA لمعالجة الطلب.

قم أولاً بتعديل /root/ca/openssl.cnf

policy            = policy_strict
改为
policy            = policy_loose

يتم استخدام Policy_strict فقط عند إنشاء شهادة جذر. وفي أحيان أخرى، استخدم فقط السياسة الفضفاضة.

# cd /root/ca
# openssl ca -config openssl.cnf \
  -extensions server_cert -days 375 -notext -md sha256 \
  -in crl/127.0.0.1.csr.pem \
  -out certs/127.0.0.1.cert.pem

-أيام 375: مدة الصلاحية هي 375 يومًا، والقيمة الافتراضية هي أيضًا 375 يومًا

في هذا الوقت سوف تجد

يوجد 127.0.0.1.cert.pem إضافي ضمن /root/ca/certs (هذه هي الشهادة التي تم إنشاؤها) يوجد 1000.pem إضافي ضمن الشهادات الجديدة (هذه هي النسخة الاحتياطية للشهادة، 1000 مأخوذ من المسلسل) يحتوي /root/ca/index.txt على المزيد من الأسطر

/root/ca/index.txt
V   171014020124Z       1000    unknown /C=CN/ST=Some-State/O=Internet Widgits Pty Ltd/CN=127.0.0.1

القيمة في /root/ca/serial +1 تصبح 1001. أرسل الشهادة /root/ca/certs/127.0.0.1.cert.pem إلى المستخدم، واكتمل عمل دور CA.

بعد إعادة الدور إلى المستخدم مرة أخرى، نقوم بنسخ 127.0.0.1.cert.pem الذي أرسله إلينا CA إلى الدليل /root/127.0.0.1 ونعيد تسميته إلى server.crt.

في هذا الوقت لدينا الملفات الثلاثة التالية في الدليل

server.crt server.csr server.key

server.crt هي الشهادة التي نريدها. يمكننا تكوين nginx لدعم https.

تكوين نجينكس

server {
    listen       443;
    server_name  127.0.0.1;

    ssl on;
    ssl_certificate      /root/127.0.0.1/server.crt;
    ssl_certificate_key  /root/127.0.0.1/server.key;
    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    location / {
        proxy_pass   http://127.0.0.1;
    }

    location ~ ^(.*)\/\.svn\/ {
        deny all;
    }
}

لدعم Tomcat، نحتاج أيضًا إلى تنفيذ العمليات التالية.

# cd /root/127.0.0.1
# openssl pkcs12 -export \
    -in server.crt \
    -inkey server.key \
    -out server.p12

输入两次密码：server123456

# keytool -importkeystore -v \
    -srckeystore  server.p12 \
    -srcstoretype pkcs12 \
    -srcstorepass server123456 \
    -destkeystore server.keystore \
    -deststoretype jks \
    -deststorepass server123456

دليل الملفات بعد العملية

server.crt      server.csr      server.key  
server.p12      server.keystore

تكوين القط

<Connector SSLEnabled="true" clientAuth="false" 
keystoreFile="/root/127.0.0.1/server.keystore" 
keystorePass="server123456" 
maxThreads="150" port="8443" protocol="org.apache.coyote.http11.Http11Protocol" scheme="https" secure="true" sslProtocol="TLS"/>

إنهاء إذا أردنا إنشاء شهادات خادم أخرى في المستقبل، فيمكننا البدء من 3. إنشاء شهادات الخادم. أليس من السهل جدا؟

المرجع:

https://jamielinux.com/docs/openssl-certificate-authority/index.html http://blog.csdn.net/RazerTang/article/details/46898051/ كمبيوتر نظام https كاليفورنيا

1 يجب عدم المماطلة عند القيام بالأشياء. لقد خططت أصلاً لإنهاء عملين فنيين هذا الأسبوع، لكنني كنت مشغولاً بأشياء أخرى ولم أستطع كتابة سوى عمل واحد. 2 أنا معجب حقًا بـ Cui Yongyuan. قام بإبلاغ fbb بذلك أولاً، وبعد ذلك، كما هو موضح أدناه، قام Cui بشيء لم يرغب الكثير من الأشخاص في القيام به، أو أشياء تجرأوا على القيام بها ولكن لم يتمكنوا من القيام بها. وكانت النتيجة أن كوي تعرض للتهديد بالقتل. الصين تفتقر إلى أشخاص مثل تسوى. قد يكون Cui آمنًا.